Xss Prevention in Jsp/Servlet Web Application

XSS prevention in JSP/Servlet web application

XSS can be prevented in JSP by using JSTL <c:out> tag or fn:escapeXml() EL function when (re)displaying user-controlled input. This includes request parameters, headers, cookies, URL, body, etc. Anything which you extract from the request object. Also the user-controlled input from previous requests which is stored in a database needs to be escaped during redisplaying.

For example:

<p><c:out value="${bean.userControlledValue}"></p>
<p><input name="foo" value="${fn:escapeXml(param.foo)}"></p>

This will escape characters which may malform the rendered HTML such as <, >, ", ' and & into HTML/XML entities such as <, >, ", ' and &.

Note that you don't need to escape them in the Java (Servlet) code, since they are harmless over there. Some may opt to escape them during request processing (as you do in Servlet or Filter) instead of response processing (as you do in JSP), but this way you may risk that the data unnecessarily get double-escaped (e.g. & becomes & instead of & and ultimately the enduser would see & being presented), or that the DB-stored data becomes unportable (e.g. when exporting data to JSON, CSV, XLS, PDF, etc which doesn't require HTML-escaping at all). You'll also lose social control because you don't know anymore what the user has actually filled in. You'd as being a site admin really like to know which users/IPs are trying to perform XSS, so that you can easily track them and take actions accordingly. Escaping during request processing should only and only be used as latest resort when you really need to fix a train wreck of a badly developed legacy web application in the shortest time as possible. Still, you should ultimately rewrite your JSP files to become XSS-safe.

If you'd like to redisplay user-controlled input as HTML wherein you would like to allow only a specific subset of HTML tags like <b>, <i>, <u>, etc, then you need to sanitize the input by a whitelist. You can use a HTML parser like Jsoup for this. But, much better is to introduce a human friendly markup language such as Markdown (also used here on Stack Overflow). Then you can use a Markdown parser like CommonMark for this. It has also builtin HTML sanitizing capabilities. See also Markdown or HTML.

The only concern in the server side with regard to databases is SQL injection prevention. You need to make sure that you never string-concatenate user-controlled input straight in the SQL or JPQL query and that you're using parameterized queries all the way. In JDBC terms, this means that you should use PreparedStatement instead of Statement. In JPA terms, use Query.

---

An alternative would be to migrate from JSP/Servlet to Java EE's MVC framework JSF. It has builtin XSS (and CSRF!) prevention over all place. See also CSRF, XSS and SQL Injection attack prevention in JSF.

XSS prevention in JSP/Servlet web application

XSS can be prevented in JSP by using JSTL <c:out> tag or fn:escapeXml() EL function when (re)displaying user-controlled input. This includes request parameters, headers, cookies, URL, body, etc. Anything which you extract from the request object. Also the user-controlled input from previous requests which is stored in a database needs to be escaped during redisplaying.

For example:

<p><c:out value="${bean.userControlledValue}"></p>
<p><input name="foo" value="${fn:escapeXml(param.foo)}"></p>

This will escape characters which may malform the rendered HTML such as <, >, ", ' and & into HTML/XML entities such as <, >, ", ' and &.

Note that you don't need to escape them in the Java (Servlet) code, since they are harmless over there. Some may opt to escape them during request processing (as you do in Servlet or Filter) instead of response processing (as you do in JSP), but this way you may risk that the data unnecessarily get double-escaped (e.g. & becomes & instead of & and ultimately the enduser would see & being presented), or that the DB-stored data becomes unportable (e.g. when exporting data to JSON, CSV, XLS, PDF, etc which doesn't require HTML-escaping at all). You'll also lose social control because you don't know anymore what the user has actually filled in. You'd as being a site admin really like to know which users/IPs are trying to perform XSS, so that you can easily track them and take actions accordingly. Escaping during request processing should only and only be used as latest resort when you really need to fix a train wreck of a badly developed legacy web application in the shortest time as possible. Still, you should ultimately rewrite your JSP files to become XSS-safe.

If you'd like to redisplay user-controlled input as HTML wherein you would like to allow only a specific subset of HTML tags like <b>, <i>, <u>, etc, then you need to sanitize the input by a whitelist. You can use a HTML parser like Jsoup for this. But, much better is to introduce a human friendly markup language such as Markdown (also used here on Stack Overflow). Then you can use a Markdown parser like CommonMark for this. It has also builtin HTML sanitizing capabilities. See also Markdown or HTML.

The only concern in the server side with regard to databases is SQL injection prevention. You need to make sure that you never string-concatenate user-controlled input straight in the SQL or JPQL query and that you're using parameterized queries all the way. In JDBC terms, this means that you should use PreparedStatement instead of Statement. In JPA terms, use Query.

---

An alternative would be to migrate from JSP/Servlet to Java EE's MVC framework JSF. It has builtin XSS (and CSRF!) prevention over all place. See also CSRF, XSS and SQL Injection attack prevention in JSF.

XSS Cross Site Scripting - Jsp Input tag

I have used the following solution,

The scriplet in the value attribute is the problem, I replaced it with jstl tag, I read somewhere that jstl tags have inbuild escaping mechanism to avoid xss issues.

<input class="tbl1" type="text" id="acctId" name="acctId" size="20" maxlength="10" value="<c:out value=${rptBean.acctId}"/>"/>

This works good for my issue.

Thanks

How to solve this XSS security issue in JSP page

It is because you are doing validation instead of sanitization. Validation is control flow type of approach for checking for vulnerable data (if not valid then...else...). Checkmarx SAST does data flow analysis but not control flow analysis.

While today you could mark it false positive, someone could come in and refactor the code and perhaps inadvertently change your validation regex. Since it is marked false positive, it is possible the broken validation won't be caught. This is a simple regex, but think what might happen if it were a more complicated regex in addition to other validation logic.

If you use something like the ESAPI encoder, it takes your potentially vulnerable input, changes it into a sanitized form, then returns the sanitized form. This would put the ESAPI encoder into the data flow, and should cause the result to be removed. Checkmarx SAST looks for sanitizers on the data flow path and, if a sanitizer is found, the data flow path is not reported as vulnerable.

So you would have code like:

<%
    String version = ESAPI.encoder().encodeForHTML(request.getParameter("version"));
%>

There are other encoder options, you'd just have to make sure they are recognized in your version of Checkmarx SAST.

protect jsp pages againt xss

Use some Filter to sanitize HTTP request data.

You may go for jsoup, it is very handy:

String unsafe = "<p><a href='http://example.com/' onclick='stealCookies()'>Link</a></p>";
String safe = Jsoup.clean(unsafe, Whitelist.basic());
// now: <p><a href="http://example.com/" rel="nofollow">Link</a></p>

Ref: http://jsoup.org/cookbook/cleaning-html/whitelist-sanitizer

How to escape values from HTML attribute inside jsp to avoid XSS attack?

Use JSTL fn:escapeXml() function.

<%@taglib prefix="fn" uri="http://java.sun.com/jsp/jstl/functions" %>
...
<input value="${fn:escapeXml(param.name)}" />

An alternative is using a decent MVC framework offering taglibs to represent HTML input elements which already implicitly escape XML/HTML,such as JSF and Spring MVC, so that you don't need to repeat the same over all place and worry about accidently overlooking one.

See also:

• XSS prevention in JSP/Servlet web application

---

Related Topics