Re: [WEB SECURITY] XSS/injection/... evading technique

["Ivan Ristic" <ivan.ristic@xxxxxxxxx>]

On Fri, Jul 25, 2008 at 2:28 PM, Arshan Dabirsiaghi
<arshan.dabirsiaghi@xxxxxxxxxxxxxxxxxx> wrote:
> Inline:
>
>>> which are often
>>> legitimate (for example, they're used to wrap JSON objects).
>>
>>> While that may be true, why on earth would untrusted users be allowed to
>>> be
>>> submitting HTML comments or submitting JSON objects that need to be
>>> depantsed before processing? As an author of a rich content validation
>>> tool,
>>> I can say that this is categorically a bad idea. Consider the IE5+ XSS
>>> vector:
>
>> On the other hand, consider a content management system where users
>> are allowed to edit HTML templates in a browser. HTML comments,
>> including IE's conditional comments, are legitimate content in that
>> situation.
>
> Why would you have a WAF to protect this functionality? It's bound to set
> off red alerts 24/7, and if users are trusted to send in malicious content,
> same question?

A few reasons:

1) Our users don't know in advance what their applications are using
underneath. Hence we have to be able everything, including the corner
cases.

2) If you really have to tell a WAF what to do and what not to do then
your life's going to be very difficult. Plus it's a waste of time. If
a technology is not easy to use people just won't use it.

3) Why not have a WAF protect that? That's the whole point of having a
WAF in the first place :)


>>> It's definitely going to be slower than simple pattern matching, but
>>> that still doesn't mean that it's going to slow, because what's slow
>>> for one deployment might not be slow for another. Either way, I think
>>> we should first focus on how to secure things and then (if we need to)
>>> how to scale the security measures.
>
> Well, if you know what the rules are for a parameter, it's pretty easy to
> secure it. In the case of all the original emailer where the rule for the
> parameter appeared to be "any printable character" the right choice would've
> been to apply that rule simply output encode all non-alphanumeric in their
> data on the way out (assuming it didn't end up inside an event handler,
> <script> tag or CSS definition).

-- 
Ivan Ristic

----------------------------------------------------------------------------
Join us on IRC: irc.freenode.net #webappsec

Have a question? Search The Web Security Mailing List Archives: 
http://www.webappsec.org/lists/websecurity/archive/

Subscribe via RSS: 
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]

Join WASC on LinkedIn
http://www.linkedin.com/e/gis/83336/4B20E4374DBA