<HTML dir=ltr><HEAD><TITLE>RE: [WEB SECURITY] Bypassing URL Authentication and Authorization with HTTP Verb Tampering</TITLE>
<META http-equiv=Content-Type content="text/html; charset=unicode">
<META content="MSHTML 6.00.6000.16640" name=GENERATOR></HEAD>
<BODY>
<DIV id=idOWAReplyText40122 dir=ltr>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2>I'd like to respond inline:</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT size=2><FONT face=Arial>> </FONT>The paper is grammatically well written but somewhat states the obvious.</FONT></DIV>
<DIV dir=ltr><FONT size=2>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2>It is obvious after reading the paper, isn't it? Well, that's the goal of the paper. =) Given the amount of off-list responses I got from bugtraq... I don't know, I can't think of a really good way of saying I think you're just wrong. </FONT></DIV></FONT></DIV>
<DIV dir=ltr><FONT size=2></FONT> </DIV></DIV>
<DIV dir=ltr><FONT size=2>> I think the most surprising bit about this is the list of people on the<BR>> blog who it is claimed didn't know about this stuff. </FONT></DIV><FONT size=2></FONT>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2>The journalist's assassin word: "claim" - always used to install doubt without having actually doing any follow up. You can talk to any of them, though you'll probably want to be a little less insulting with the 'obvious' bit. If there is definitive prior art I'm happy to cite it, but the only thing that's obvious is that the new stuff in the paper is not common knowledge.</FONT></DIV>
<DIV dir=ltr><FONT size=2></FONT> </DIV>
<DIV dir=ltr><FONT size=2>> The core of the issue is the implicit-allow used in some rulebases,<BR>> which is ancient news. </FONT><BR></DIV>
<DIV dir=ltr><FONT face=Arial size=2>Did you read the paper? The HEAD-redirect-to-GET and arbitrary verbs being forwarded to GET handler are the unique takeaways. There is a lot of supporting information in there to allow the conversation to get to that point. <FONT face=Arial size=2>We've all changed a GET to a POST or a POST to a GET to bypass some poorly built URL authorization scheme. That's so not what this is about.</FONT></FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>I think it's very telling that I've gotten loads of off-list emails with the complete opposite feedback, and from people who you'd think are "in the know". Something about appearing to not know about something in public scares people - especially something (HEAD/arbitrary verb handling) that is so fundamental to what we do.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>Cheers,</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2>Arshan</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr>
<HR tabIndex=-1>
</DIV>
<DIV dir=ltr><FONT face=Tahoma size=2><B>From:</B> Martin O'Neal [mailto:martin.oneal@corsaire.com]<BR><B>Sent:</B> Thu 5/29/2008 6:16 AM<BR><B>To:</B> Arshan Dabirsiaghi; websecurity@webappsec.org<BR><B>Subject:</B> RE: [WEB SECURITY] Bypassing URL Authentication and Authorization with HTTP Verb Tampering<BR></FONT><BR></DIV>
<DIV><BR>
<P><FONT size=2>The paper is grammatically well written but somewhat states the obvious.<BR>I think the most surprising bit about this is the list of people on the<BR>blog who it is claimed didn't know about this stuff. <BR><BR>The core of the issue is the implicit-allow used in some rulebases,<BR>which is ancient news.  Firewall engineers all over the globe will be<BR>spitting coffee and soggy doughnut bits into their keyboards when they<BR>find this in their in-box...<BR><BR>We test for this stuff as part of our standard methodology, and one of<BR>the things that isn't picked out in the paper which we see from time to<BR>time is functional configuration to block unwanted methods, but only<BR>applied to the root URI (and not flowing down the tree on a wild-card).<BR>Generally the tools won't pick this up, but you can happily get<BR>OPTIONS/TRACE/TRACK/DELETE/WEBDAV/PUT etc to run on a URI post auth,<BR>further down the tree.<BR><BR>The other thing not mentioned in the paper is that you need to watch out<BR>when testing this stuff, as some of the MITMs use common libraries to<BR>deliver the HTTP transport, which helpfully fix your deliberately broken<BR>methods or silently drop the request.<BR><BR>Martin...<BR><BR><BR><BR><BR>----------------------------------------------------------------------<BR>CONFIDENTIALITY:  This e-mail and any files transmitted with it are<BR>confidential and intended solely for the use of the recipient(s) only.<BR>Any review, retransmission, dissemination or other use of, or taking<BR>any action in reliance upon this information by persons or entities<BR>other than the intended recipient(s) is prohibited.  If you have<BR>received this e-mail in error please notify the sender immediately<BR>and destroy the material whether stored on a computer or otherwise.<BR>----------------------------------------------------------------------<BR>DISCLAIMER:  Any views or opinions presented within this e-mail are<BR>solely those of the author and do not necessarily represent those<BR>of Corsaire Limited, unless otherwise specifically stated.<BR>----------------------------------------------------------------------<BR>Corsaire Limited, registered in England No. 3338312. Registered<BR>office: Portland House, Park Street, Bagshot, Surrey GU19 5PG.<BR>Telephone: +44 (0)1483-746700<BR><BR></FONT></P></DIV></BODY><!--[object_id=#aspectsecurity.com#]--></HTML>