I would assume just about any app with a shopping cart does. This is of course compounded by libraries like struts and spring mvc that autobind your form variables for you. Use a form with a double in it and your boned.
Sent from my iPwn On Feb 14, 2011, at 8:57 AM, "Wall, Kevin" <kevin.w...@qwest.com> wrote: > Jim Manico wrote... >> Rafal, >> >> It's not that tough to blacklist this vuln while you are waiting for your >> team to patch your JVM (IBM and other JVM's have not even patched yet). >> I've seen three generations of this filter already. Walk with me, Rafal and >> I'll show you. :) >> >> 1) Generation 1 WAF rule (reject one number only) >> >> This mod security rule only blocks a small portion of the DOSable range. >> The mod security team is working to improve this now (no disrespect meant >> at all!) >> >> SecRule ARGS|REQUEST_HEADERS "@contains 2.2250738585072012e-308" >> "phase:2,block,msg:'Java Floating Point DoS Attack',tag:'CVE-2010-4476'" >> >> Reference: http://mobile.twitter.com/modsecurity/status/35734652652093441 >> > > Depending how & when the exponent conversion is done, this mod_security rule > may be completely ineffective. For example, if an attacker can write this > floating point # as the equivalent > > 22.250738585072012e-309 > > (which note, I have not tested), then the test above is invalid. I presumed > that > this was why Adobe's blacklist *first* removed the decimal point. Adobe's > blacklist > could be generalized a bit to cover appropriate ranges with a regular > expression, > but I agree wholeheartedly with you that what you dubbed as the "Chess > Defense" > (I like it) is the best approach short of getting a fix from the vendor of > your > JRE. > > So on a somewhat related note, does anyone have any idea as to how common it > is for > application developers to call ServletRequest.getLocale() or > ServletRequest.getLocales() > for Tomcat applications? Just curious. I'm sure it's a lot more common than > developers using double-precision floating point in their applications (with > the possible exception within the scientific computing community). > > -kevin > --- > Kevin W. Wall Qwest Risk Mgmt / Information Security > kevin.w...@qwest.com Phone: 614.215.4788 > "It is practically impossible to teach good programming to students > that have had a prior exposure to BASIC: as potential programmers > they are mentally mutilated beyond hope of regeneration" > - Edsger Dijkstra, How do we tell truths that matter? > http://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD498.html > > This communication is the property of Qwest and may contain confidential or > privileged information. Unauthorized use of this communication is strictly > prohibited and may be unlawful. If you have received this communication > in error, please immediately notify the sender by reply e-mail and destroy > all copies of the communication and any attachments. > > _______________________________________________ > Secure Coding mailing list (SC-L) SC-L@securecoding.org > List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l > List charter available at - http://www.securecoding.org/list/charter.php > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates > _______________________________________________ _______________________________________________ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates _______________________________________________
