2

Is it true that following code adds a XSS vulnerability to some JSP page?

<!--    <%=paramName%>=<%=request.getParameter(paramName)%><BR>  -->

It looks like a "leftover debug" and definitely should be removed from the code, but how dangerous is it?

BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
okutane
  • 13,754
  • 10
  • 59
  • 67

2 Answers2

5

Yes, what you are looking at is a reflective XSS attack. This is dangerous because it allows an attacker to hijack an authenticated session. If you have this code running on your system, an attacker will be able to access other peoples accounts without needing to know their username/password.

XSS vulnerabilities can also be used to bypass CSRF protection. This is because XSS allows the attacker to read the value of a CSRF token using XmlHTTPRequest. XSS can also be used to fool referer checks.

Here is simple way to manually test for xss, here i am breaking out of the HTML comment to execute javascript.

http://localhost/xss_vuln.jsp?paramName='--><script>alert(document.cookie)</script><!--' 

This is a free xss scanner, you should test all applications that you write.

rook
  • 66,304
  • 38
  • 162
  • 239
  • 1
    Bear in mind that most, if not all, xss scanners find only the simplest classes of XSS vulnerabilities and use only a very limited set of attack vectors. Understand the problem better to fix you code. See http://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet for some simple rules. – Cheekysoft May 06 '10 at 12:05
  • @Cheekysoft very true, but its also likely that an attacker is using the same simple tests against your application. Nothing is 100%, and that is yet another advantage the attacker has. – rook May 06 '10 at 19:40
2

The JSP parser handles HTML comments as template text. It doesn't ignore its contents. The HTML comments are only ignored by HTML parsers/interpreters (webbrowsers!). You should use JSP comments instead to prevent the JSP parser from processing the particular piece of code.

<%--    <%=paramName%>=<%=request.getParameter(paramName)%><BR>  --%>

Note the <%-- --%> style as opposed to <!-- --> HTML comment style. The JSP parser won't parse them, but it removes them from the output. Thus you won't see them in the generated HTML output.

The XSS risk is here because you're not escaping user-controlled input here. Request parameters are fully controllable by endsers. The enduser may for instance pass --><script>alert('xss')</script><!-- as parameter value and it would get executed. This puts the doors wide open for XSS and CSRF attacks. The malicious script may for example send all cookies by an ajax request to a malicious server. The attacker can then just copy the cookie value to be able to be logged in as yourself.

You should use JSTL c:out tag or fn:escapeXml function to escape user-controlled input. I've answered this in detail several times before, under each here. More explanation about CSRF can be found in my answer here.

Community
  • 1
  • 1
BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
  • I've heard that JSTL tag is useful against XSS that comes from your server to your client, but not when going from client to server. In this case the request is coming from client, not from Server, then how JSTL will prevent this attack? Please clarify my doubt. Appreciate your help! – Sam Jun 28 '13 at 18:06
  • @Sam: XSS content is harmless in server. XSS is only a problem during redisplaying user-controlled input in HTML code. HTML doesn't run in webserver at all, instead, the webserver *produces* HTML. See also http://stackoverflow.com/questions/2658922/xss-prevention-in-java/2658941#2658941 – BalusC Jun 28 '13 at 18:20
  • Thanks for your help. I've gone through this useful link. I've posted another thread here below link but did not get proper answer how to prevent this: http://stackoverflow.com/questions/16743043/how-to-prevent-xss-attack/16743710?noredirect=1#16743710 Could you please have a look and suggest with the code? – Sam Jun 28 '13 at 18:52
  • @Sam: Just use `` or `${fn:escapeXml()}` to redisplay user-controlled input. Just stop using `<% ... %>` altogether. – BalusC Jun 28 '13 at 18:55
  • Thanks again! I thing is still not clear to me is how to use or ${fn:escapeXml()} to handle request.getQueryString()? I can write in that jsp to handle this. Pls let me know if I'm missing something. Thank you! – Sam Jun 28 '13 at 19:51
  • @Sam: the request is in EL available via `${pageContext.request}`. – BalusC Jun 28 '13 at 19:59
  • Do you mean similar to this? – Sam Jun 28 '13 at 20:28
  • is it like this ? function redirect() { if (window.focus) self.focus(); var req = ''; this.location = "/test/DownloadReport?req"; } – Sam Jun 28 '13 at 21:09