[Esapi-user] Tricky encoding question

Mon Jun 20 16:31:56 EDT 2011

I’ve always thought that the *correct* way to handle these nested encoding contexts is to use multiple encoding schemes – carefully!!  But I haven’t done extensive testing necessary to figure out exactly how to deal with all the possible nested encoding contexts.

--Jeff

From: esapi-user-bounces at lists.owasp.org [mailto:esapi-user-bounces at lists.owasp.org] On Behalf Of Chris Schmidt
Sent: Monday, June 20, 2011 4:27 PM
To: esapi-user at lists.owasp.org
Subject: Re: [Esapi-user] Tricky encoding question

Couple of things - always use the context that most closely matches where you are outputting the data - in this case, the data is a URL and thus url encoding should be used. However, as you mentioned, the data is in a javascript parameter (jsdata) context, so ideally you would want to ensure that there are no unescaped javascript terminators in your output as well. Without writing some test cases, I am not 100% sure - but I imagine that URL encoding along would also encode the relevant javascript terminators ", ' which would eliminate the possibility of the user being able to break context from the javascript parameter string. 

That being said, and moving on to your point of "blah&a=b" - this should absolutely be verboten as it opens up a slew of parameter injection and override possibilities for an attacker to play with. 

On 6/20/2011 8:33 AM, Matthew Presson wrote: 

I have come across a scenario in an application and would like some advice on the subject of applying the proper encoding.  

Scenario:

A developer is taking user input and using it to dynamically construct an URL which is used in an onClick event handler of an <a> tag.  The code (JSP) looks similar to this:

	<a HREF=""
	onClick="window.open('http://www.example.com/app/page.jsp?param1=a&param2=b&param3= <http://www.example.com/app/page.jsp?param1=a&param2=b&param3=> <%=request.getParameter("test")%>', 'windowRef', '

	resizable=yes,scrollbars=yes,status=no,location=no,toolbars=yes,height=500,width=800'); return false;">link text</a>

As you can see, param3 is vulnerable to XSS.  The tricky part is that the data is being used to form a URL (URL Context) but from within a JavaScript event handler (JavaScript Context). 

The question is - Which of the following encoding strategies would be the right one to use? 

Option 1: Only use URL encoding

	<a HREF=""
	onClick="window.open('http://www.example.com/app/page.jsp?param1=a&param2=b&param3= <http://www.example.com/app/page.jsp?param1=a&param2=b&param3=> <%= OutputEncoder.encodeForURL(request.getParameter("test")) %>', 'windowRef', '

	resizable=yes,scrollbars=yes,status=no,location=no,toolbars=yes,height=500,width=800'); return false;">link text</a>

This option appears to work well, but are still in a JavaScript context and are unsure if there would still be attack strings that would allow for a successful XSS attack.

Option 2: Only use JavaScript encoding:

	<a HREF=""
	onClick="window.open('http://www.example.com/app/page.jsp?param1=a&param2=b&param3= <http://www.example.com/app/page.jsp?param1=a&param2=b&param3=> <%= OutputEncoder.encodeForJavaScript(request.getParameter("test")) %>', 'windowRef', '
	resizable=yes,scrollbars=yes,status=no,location=no,toolbars=yes,height=500,width=800'); return false;">link text</a>

This option works from a security standpoint, but breaks in scenarios where the value of the parameter test is supposed to equal "blah&a=b".  When using only JavaScript encoding, page.jsp would read the value of param3 as blah and have an extra parameter named a with the value b instead of having the value of param3 equal blah&a=b which ultimately results in a functional defect.

Option 3: Double encode using URL AND JavaScript encoding

	<a HREF=""
	onClick="window.open('http://www.example.com/app/page.jsp?param1=a&param2=b&param3= <http://www.example.com/app/page.jsp?param1=a&param2=b&param3=> <%= OutputEncoder.encodeForJavaScript(OutputEncoder.encodeForURL(request.getParameter("test"))) %>', 'windowRef', '
	resizable=yes,scrollbars=yes,status=no,location=no,toolbars=yes,height=500,width=800'); return false;">link text</a>

This seems to also work, but am not sure about recommending a double-encoding strategy.  For one, it adds another level of complexity that could potentially lead to problems down the road.  Secondly, isn't double-encoding usually frowned upon as a solution? 

Please let me know if any of this does not make sense, or if I can provide you with any additional information.

Thanks, 
Matt

_______________________________________________
Esapi-user mailing list
Esapi-user at lists.owasp.org
https://lists.owasp.org/mailman/listinfo/esapi-user

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/esapi-user/attachments/20110620/5ce5b55c/attachment.html 