1. Server code: writing a response directly
1.A. Using the PrintWriter from HttpServletResponse
The PrintWriter from `HttpServletResponse permits writing data directly to the response
that will be returned to the user. This bypasses any safety mechanisms built into any
frameworks in use.
Recommendation: Render JSP pages using request forwarding: request.getRequestDispatcher("/page.jsp").forward(...);
Code example:
response.getWriter().write("<p>Hello, " + name + "!</p>");References:
1.B. Using the OutputStream from HttpServletResponse
The OutputStream from HttpServletResponse permits writing data directly to the response
that will be returned to the user. This bypasses any safety mechanisms built into any
frameworks in use.
Recommendation: Render JSP pages using request forwarding: request.getRequestDispatcher("/page.jsp").forward(...);
Code example:
String template = "<p>Hello, " + name + "!</p>";
response.getOutputStream().write(template.getBytes());References:
2. JSP page: Variable is not explicitly escaped
2.A. Any variable used without
The out tag from the JSTL taglib escapes the given value. Without this or another escaping method,
data in the JSP will be unescaped. This could create XSS vulnerabilities.
Recommendation: Require use of JSTL escapeXml function in every expression.
Code example:
<div>${userObj.name}</div>References:
2.B. Any expression without escapeXml
The escapeXml JSTL expression will escape XML characters. Any data rendered without
this or another escaping method will be a potential site for XSS.
Recommendation: Require use of JSTL escapeXml function in every expression.
Code example:
<div>${userObj.name}</div>References:
3. JSP page: Variable in dangerous location
3.A. Unquoted variable in HTML attribute
Unquoted template variables rendered into HTML attributes is a potential XSS vector
because an attacker could inject JavaScript handlers which do not require HTML characters.
An example handler might look like: onmouseover=alert(1). HTML escaping will not mitigate this.
The variable must be quoted to avoid this.
Recommendation: Always use quotes around HTML attributes.
Code example:
<div class=${classes}></div>References:
3.B. Variable in href attribute
Template variables in a href value could still accept the javascript: URI.
This could be a XSS vulnerability. HTML escaping will not prevent this. Use url_for
to generate links.
Recommendation: N/A
Code example:
<a href="${link}"></a>References:
3.C. Variable in <script> block
Template variables placed directly into JavaScript or similar are now directly in a code execution context. Normal HTML escaping will not prevent the possibility of code injection because code can be written without HTML characters. This creates the potential for XSS vulnerabilities, or worse.
Recommendation: N/A
Code example:
<script>var name = ${name};</script>References:
Mitigations
| Item | Name | Semgrep rule | Recommendation |
|---|---|---|---|
| 1.A. | Ban use of PrintWriter from HttpServletResponse |
java.lang.security.audit.xss.no-direct-response-writer.no-direct-response-writer | Render JSP pages using request forwarding: request.getRequestDispatcher("/page.jsp").forward(...); |
| 1.B. | Ban use of OutputStream from HttpServletResponse |
java.lang.security.audit.xss.no-direct-response-writer.no-direct-response-writer | Render JSP pages using request forwarding: request.getRequestDispatcher("/page.jsp").forward(...); |
| 2.A. | Require use of JSTL escapeXml function in every expression. |
java.lang.security.audit.xss.jsp.use-escapexml.use-escapexml | Require use of JSTL escapeXml function in every expression. |
| 2.B. | Require use of JSTL escapeXml function in every expression. |
java.lang.security.audit.xss.jsp.use-escapexml.use-escapexml | Require use of JSTL escapeXml function in every expression. |
| 3.A. | Flag unquoted HTML attributes with Jinja expressions | N/A | Always use quotes around HTML attributes. |
| 3.B. | Flag template variables in href attributes |
N/A | N/A |
| 3.C. | Ban template variables in <script> blocks. |
N/A | N/A |