[Esapi-user] Tricky encoding question

Matthew Presson matthew.presson at gmail.com
Mon Jun 20 19:30:00 EDT 2011


To add another $0.02, we must also remember that it is generally
easier to secure simpler constructs, e.g. the situation that started
this whole discussion in light of the final solution.

As such, IMO, part of recommending a good security strategy lies in
helping developers simplify overly complex designs, while maintaining
the ability to meet the necessary business functionality.  This is
where being a good developer comes in very handy.

Being able to break an application is one thing.  Being able to
describe and illustrate a robust solution to the root cause issue is
quite another.  Personally, I strive hard to be more heavily weighted
on the solutions end of things.  After all, we security professionals
are paid to do more than just "break" things and walk away.

Sent from my iPhone

On Jun 20, 2011, at 5:21 PM, Jim Manico <jim.manico at owasp.org> wrote:

> 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
>>> P0,widthÄ0');
>>> 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,heightP0,widthÄ0');
>>>    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