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

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

On Thu, Jul 24, 2008 at 11:42 PM, Arshan Dabirsiaghi
<arshan.dabirsiaghi@xxxxxxxxxxxxxxxxxx> wrote:
> I agree with a lot of what you both are saying. Just a few notes. First,
> ColdFusion and HTML comments are not identical:
>
> HTML = <!-- comment -->
> CFML = <!--- comment --->
>
> Though I guess it could be said accurately that all CFML comments can be,
> pattern-matching wise, considered subsets of the HTML comments.
>
>> 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.


> <!--[if gte IE 4]>
> <SCRIPT>alert('XSS');</SCRIPT>
> <![endif]-->
>
>> 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.
>
> Agree 100%.
>
>> 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.
>
> Disagree. Reliable parsing inevitably means slow execution time and still
> not 100% security, sounds like a non-starter for a WAF.

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.

Speaking of parsers, I am a believer, but the challenge is which
parser to use? Thus, I think the combination of learning, where you
figure out what a field is supposed to look like (which allows you to
choose the correct parser) and parsing is a winner.


> My question is this: are the WAF people paying attention to PHPIDS's
> Centrifuge (obligatory comment about how nothing is 100% reliable)? I think
> that's the direction WAFs should be headed, and who knows, maybe they're
> already there. I fully expect that they already claim to be. =)

I prefer WAFs to be 100% reliable (side note: I will settle for
anything that works). A positive security model (e.g. where you check
a parameter is a number) can be, the only problem is getting to a good
positive security model. As you know from my other recent emails here,
that's something I am looking into right now. In reality, a
combination of negative and positive security is the best way forward.

By the way, I spoke to Mario recently and ModSecurity will be
supporting PHPIDS directly in the near future.


> Cheers,
> Arshan
> ________________________________
> From: Jon McClintock [mailto:jammer@xxxxxxxx]
> Sent: Thu 7/24/2008 4:59 PM
> To: Arian J. Evans
> Cc: Nick Gearls; websecurity@xxxxxxxxxxxxx
> Subject: Re: [WEB SECURITY] XSS/injection/... evading technique
>
> 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.
>
>   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.
>
>> > 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.
>
>> > 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).
>
> -Jon
>



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