[Esapi-user] Tricky encoding question

Jim Manico jim.manico at owasp.org
Mon Jun 20 16:35:23 EDT 2011


> I’ve always thought that the **correct** way to handle these nested
> encoding contexts is to use multiple encoding schemes – carefully!!

You are right on, Jeff.

I would first URL encode the variable since this is a GET parameter,
then I would JS Encode the variable to stop injecting out of the JS
function argument. This will work just fine without breaking the URL.

As  browsers increase functionality, there are cases where even encoded
data still pops as XSS (especially in the JS and CSS contexts) so be
sure to strictly validate as well.

- Jim

> 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
> 
>  
> 
> 
> 
> _______________________________________________
> Esapi-user mailing list
> Esapi-user at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/esapi-user



More information about the Esapi-user mailing list