[Esapi-user] Tricky encoding question

Jim Manico jim.manico at owasp.org
Mon Jun 20 18:20:56 EDT 2011


I'm with you Jeff. I think that the right balance is contextual to each
organization. It really depends on each organizations risk tolerance and
overall AppSec maturity to truly make that call.

To your point, the XSS cheat-sheet is getting very complex. Not quite a
"cheat" anymore. Perhaps someday we could migrate the cheat-sheet to a
more comprehensive guide that gets into the deeper mitigation strategies
necessary to stop XSS in complex and DOM contexts?

I'm seeing more and more shops who do want to approach "deep assurance".

- Jim


> I know - it's a dilemma that we all face.  How should one proceed in the face of uncertainty?
> 
> The philosophy in both ESAPI and the cheatsheets is that you can use anything you've figured out how to use safely, and that you should avoid the rest.  To me this is only common sense, but many organizations rush into new technologies without doing their homework on how to use it securely.  I'm only suggesting that before you use nested contexts, that you should figure out how to make them safe first.  Since nobody IIRC has done any exhaustive exploration of the space, I think all we can do is indicate how far we've been able to push the boundaries of the 'safe'
> 
> The really tricky problem is that even if we knew how to make all the possible HTML contexts safe, the resulting guidance would be so insanely complicated that nobody could use it.  Striking the right balance here is critically important to getting adoption.  I've been working intermittently on a way to simplify all the encoding rules, but it's still a work in progress.
> 
> --Jeff
> 
> 
> -----Original Message-----
> From: Jim Manico [mailto:jim.manico at owasp.org] 
> Sent: Monday, June 20, 2011 5:56 PM
> To: Jeff Williams
> Cc: Chris Schmidt; Matthew Presson; esapi-user at lists.owasp.org
> Subject: Re: [Esapi-user] Tricky encoding question
> 
> Jeff,
> 
> Most advanced modern AJAX apps are full of nested contexts, I'm not sure if this is something that developers can reasonably avoid.
> 
> - Jim
> 
>> That’s an excellent point and something that we often forget. ESAPI 
>> and the OWASP Cheatsheets are all about trying to keep you on a safe path.
>> If you try hard enough, there are ways to use just about anything 
>> insecurely.
>>
>>  
>>
>> In the XSS Cheatsheet
>> <https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention
>> _Cheat_Sheet>, Rule 0 is probably the most important…. “Never Insert 
>> Untrusted Data
>> Except in Allowed Locations”.   I just updated it with a note to avoid
>> “nested contexts”
>>
>>  
>>
>> --Jeff
>>
>>  
>>
>>  
>>
>> *From:*Chris Schmidt [mailto:chris.schmidt at owasp.org]
>> *Sent:* Monday, June 20, 2011 5:39 PM
>> *To:* Matthew Presson
>> *Cc:* Jeff Williams; esapi-user at lists.owasp.org
>> *Subject:* Re: [Esapi-user] Tricky encoding question
>>
>>  
>>
>> Best solution yet. :)
>>
>> On 6/20/2011 3:21 PM, Matthew Presson wrote:
>>
>> Thank you all for your responses.
>>
>>  
>>
>> As an aside, I was able to recommend a "better way" to write the above 
>> code so as not to require the double encoding.
>>
>>  
>>
>> Original:
>>
>> <a HREF=""
>> onClick="window.open('http://www.example.com/app/page.jsp?param1=a&par
>> am2=b&param3= 
>> <http://www.example.com/app/page.jsp?param1=a&param2=b&param3=><%=requ
>> est.getParameter("test")%>',
>> 'windowRef', '
>> resizable=yes,scrollbars=yes,status=no,location=no,toolbars=yes,height
>> =500,width=800');
>> return false;">link text</a>
>>
>>  
>>
>> "Better" version:
>>
>>     <a
>>     href="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")) %>"
>>     target="_blank" onclick="window.open(this.href,
>>     this.target,'resizable=yes,scrollbars=yes,status=no,location=no,toolbars=yes,height=500,width=800');
>>     return false">
>>
>>  
>>
>> Matt
>>
>>  
>>
>>  
>>
>>
>>
>> _______________________________________________
>> 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