[Esapi-user] Tricky encoding question

Chris Schmidt chris.schmidt at owasp.org
Mon Jun 20 16:36:29 EDT 2011


I agree in principle, but I also think using the least amount of 
encoding simplifies the process - so I think the best course of action 
is to start with URL encoding - then throw some tests at it, run it 
through the gambit of javascript xss vectors and if need be apply the 
next layer of encoding.

Good testing and good validation/sanitization are key here as well.

On 6/20/2011 2:31 PM, Jeff Williams wrote:
>
> 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  <mailto: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/f73454d2/attachment.html 


More information about the Esapi-user mailing list