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

["Arian J. Evans" <arian.evans@xxxxxxxxxxxxxx>]

good feedback. <more inline>

On Thu, Jul 24, 2008 at 1:59 PM, Jon McClintock <jammer@xxxxxxxx> wrote:
> On Thu, Jul 24, 2008 at 01:35:02PM -0700, Arian J. Evans wrote:
>> On Thu, Jul 24, 2008 at 10:19 AM, Jon McClintock <jammer@xxxxxxxx> wrote:
>> > This is a challenging problem to solve, and you're not going to be able
>> > to address it with any pattern-based engine. To do it properly, you need
>> > to actually parse the input in the same manner that it will be consumed.
>>
>> Why? Please support this contention.
>>
>> I see a p@/**<!-->**/attern here. Or two. Or three.
>
> Nesting, linearity, unintended consequences. One consumer's perfectly
> valid string is dangerous and unsafe in another.
>
>  output="sc/*";benign=true;foo="*/ript";
>
> Your WAF doesn't know all of the contexts the data will be used in. If
> you blindly remove all things that look like comments in all
> environments, you're going to break a lot of cases where something that
> looks like a comment is a valid input.


Agreed on breakage. Completely disagree on valid input.

I do not see many cases in the wild where something that looks like
a comment is necessary for valid input. Maybe you are correct here,
but I haven't seen many/any legitimate cases of this.

(ignoring CVS and bug tracking systems)


>  message="Meet me@noon"
>
> The dumber and more broad-reaching a WAF filter is, the more likely it
> is to cause problems with false positives, and subsequently be turned off.

Oh, gotcha. You are critiquing the fundamental WAF Fallacy perpetuated
most guiltily by Imperva and Teros(Citrix) that we call:

GlobalMagicElfRules=ON

and then they force you to chose between two lame options:

DefendAllParametersMode=(BreakNothing) or (SlowDown&BreakAll)


There are other ways to use a WAF that solve for your objections.


>> > Further, you'd be best served by using the same parsing engine that your
>> > application is using, otherwise you'll likely run into edge cases.
>>
>> Why? We do not need to successfully execute the code or interpret it
>> to block it.
>
> You don't need to execute it, but you certainly need to parse it to
> determine what will actually be interpreted as a comment and what won't.


I do not agree. Comments still fall into the largely-unneeded
metacharacter problem that is in the domain of things a WAF
can successfully scrub. (Though, today, most don't do this well)


>> > For XML data, this is straightforward, as most WAFs implement XML
>> > validation, translation and filtering. For things like JavaScript or
>> > (worse) ColdFusion, you're running far beyond the bounds of what a
>> > WAF's parser can reasonably implement.
>>
>> Why?
>>
>> And how is ColdFusion worse than Javascript in terms of WAF-able
>> issues? You lost me on that last bit.
>
> ColdFusion comments are identical to HTML comments. Which are often
> legitimate (for example, they're used to wrap JSON objects).


You mean client-side CF comments used to wrap objects?


-- 
-- 
Arian J. Evans.
Software. Security. Stuff.

----------------------------------------------------------------------------
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