[Esapi-user] Tricky encoding question

Mon Jun 20 16:26:44 EDT 2011

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/af5414fc/attachment.html 