[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [WEB SECURITY] RE: [Webappsec] [WEB SECURITY] Re: Comparisons of Web ApplicationFirewalls



Extending on Arshan's post about Unicode regular expressions, Chris
Weber wrote a very interesting post about using Unicode Category for
internationalized white-lists in .Net -
http://lookout.net/2007/04/02/i18n-input-validation-whitelist-filtering-with-systemglobalization-and-getunicodecategory/

Java also has similar functionality with the Character.getType()
method http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Character.html#getType


Cheers,

Rohit Sethi
Security Compass

On Mon, Jul 7, 2008 at 12:30 PM, Arshan Dabirsiaghi
<arshan.dabirsiaghi@xxxxxxxxxxxxxxxxxx> wrote:
> Ernest,
>
> In the interest of making things clear, I'm going to seperate the two issues
> you have with WAFs:
>
> 1) The WAF doesn't work (crashes, doesn't block anything, etc.)
> 2) Lack of i18n in whitelisting rules
>
> Considering #1, this is pretty inexcusable for a WAF product that should be
> relatively mature by this point.
>
> However, I totally concur with you on #2, and its much bigger than people
> think. I also don't think there's any good documentation on this subject out
> there in the real world (besides the little post from Matt).
>
> Being a guy that has shown a slide or 3 with the string "[a-zA-Z0-9]" on it,
> I realize it may not work for your company, but it's more the technique that
> we're trying to get across rather than any specific implementation.
>
> You should investigate standardized Unicode patterns like \p{L} and \p{N}
> which are extremely useful for doing cross-language input validation without
> getting deep into the weeds of Unicode character ranges [1]. You can also
> validate the data you're receiving against the locale you're receiving it
> from. For instance, \p{Greek} will tell you whether or not your letters are
> in the Greek character range.
>
> I can't say whether or not any WAF out there has this kind of capability
> (the few I've seen do not).
>
> Regarding the backwards languages - won't the attacks have to be in the
> normal direction to work anyway? =]
>
> Cheers,
> Arshan
>
> [1] http://unicode.org/unicode/reports/tr18/
>
>
> ________________________________
> From: webappsec-bounces@xxxxxxxxxxxxxxx on behalf of Ernest Mueller
> Sent: Mon 7/7/2008 11:29 AM
> To: Martin O'Neal
> Cc: websecurity@xxxxxxxxxxxxx; webappsec @OWASP;
> webappsec-bounces@xxxxxxxxxxxxxxx
> Subject: Re: [Webappsec] [WEB SECURITY] Re: Comparisons of Web
> ApplicationFirewalls
>
> Although I think WAFs do have an important role especially when confronted
> by a mass of untrained/indifferent IT programmers tossing stuff on a Web
> site (as in our case), I'd like to note that Martin brings out one severe
> problem below - multiple locale support.
>
> All of the security community "whitelisting is a best practice" business
> pretty much hasn't kept up with the times; our site is available in eight
> languages fully and has parts in others, including dual-byte and
> "backwards" like Arabic and Hebrew.  Every time some security guy does a
> presentation at us that starts off with "regexps to include [a-zA-Z1-9]" I
> think to myself "bah" and tune them out the rest of the time.
>
> So note to WAF vendors, and people working on things like
> Stinger/mod_security, the problem has become much more complex and your
> products are only useful to the degree they don't lag behind how people are
> using the Web nowadays.
>
> Frankly, though I believe in the theoretical usefulness of a WAF, we don't
> have one yet.  We did one round of evals, where we basically decided to
> pass at the time because nothing was compelling (this was before F5 and
> Netscalar integrated theirs) and then we did another round of evals
> recently, where we also decided to cancel the project and do it again in a
> year hoping that the products would get better.  Not naming names, but the
> major dedicated product we evalled crashed all the time and the supplier
> was unable to resolve that, and the other major product that was on a load
> balancer didn't block jack (we tested with Watchfire).   We decided with
> the PCI push on our security money this year could more effectively be
> spent in other areas.
>
> Which is sad because we'd really like one to work.  Our site has more than
> a hundred Web applications on it.  We work to harden the more important
> ones, but no one is willing to take the time to manually characterize
> inputs etc. on the lesser ones especially the 50% of apps that are not
> under active feature development.
>
> Ernest
> ______________________
> UN-altered REPRODUCTION and DISSEMINATION of
> this IMPORTANT information is ENCOURAGED.
>
>
>
>
>              "Martin O'Neal"
>              <martin.oneal@cor
>              saire.com>                                                 To
>              Sent by:                  "Arian J. Evans"
>              webappsec-bounces         <arian.evans@xxxxxxxxxxxxxx>
>              @lists.owasp.org                                           cc
>                                        "webappsec @OWASP"
>                                        <webappsec@xxxxxxxxxxxxxxx>,
>              07/07/2008 05:28          websecurity@xxxxxxxxxxxxx
>              AM                                                    Subject
>                                        Re: [Webappsec] [WEB SECURITY] Re:
>                                        Comparisons of Web Application
>                                        Firewalls
>
>
>
>
>
>
>
>
>
>
>
>> Actually, statistically speaking:
>> we do know the problem exists Martin.
>
> LOL; that's not what I meant!  Because of where a WAF sits in the mix,
> the only tool it has at its disposal is data validation.  Which means
> that when you apply it to the most emotive web app issues of the day,
> SQL injection and XSS (which are encoding failures, not validation
> failures) it is trying to solve a problem that simply doesn't exist.
>
> A WAF can actually be very good at enforcing validation, when validation
> is the problem.  For example an application that fails creatively when
> its session ID is tampered with.  The session ID should be a
> predictable, consistent format; safe territory for a WAF.
>
> But (and it is a big BUTT) a WAF is generally not so useful for general
> form fields in a site, where the usecase requires a non-alphanumeric
> character set, like a name field.  Add in multi-locale support etc, and
> I would put money on it that (like my recent F5 project), it won't be
> long before you have to cripple the user experience to stop the attack
> you are trying to prevent.
>
>> Now Martin, I have to go shoot off some
>> guns and fireworks and celebrate my
>> freedom from those oppressive Brits! :)
>
> LOL2; we're much more reserved in our celebrations (being stuffy brits),
> but trust me; it is a landmark occasion for us too. :)
>
> Martin...
>
>
> ----------------------------------------------------------------------
> CONFIDENTIALITY:  This e-mail and any files transmitted with it are
> confidential and intended solely for the use of the recipient(s) only.
> Any review, retransmission, dissemination or other use of, or taking
> any action in reliance upon this information by persons or entities
> other than the intended recipient(s) is prohibited.  If you have
> received this e-mail in error please notify the sender immediately
> and destroy the material whether stored on a computer or otherwise.
> ----------------------------------------------------------------------
> DISCLAIMER:  Any views or opinions presented within this e-mail are
> solely those of the author and do not necessarily represent those
> of Corsaire Limited, unless otherwise specifically stated.
> ----------------------------------------------------------------------
> Corsaire Limited, registered in England No. 3338312. Registered
> office: Portland House, Park Street, Bagshot, Surrey GU19 5PG.
> Telephone: +44 (0)1483-746700
>
> _______________________________________________
> Webappsec mailing list
> Webappsec@xxxxxxxxxxxxxxx
> https://lists.owasp.org/mailman/listinfo/webappsec
>
>
> _______________________________________________
> Webappsec mailing list
> Webappsec@xxxxxxxxxxxxxxx
> https://lists.owasp.org/mailman/listinfo/webappsec
>

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



Brought to you by http://www.webappsec.org
Search this site