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:
<!--[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.
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. =)
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