<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=idOWAReplyText31611 dir=ltr>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2>Martin,</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2>Not sure how you can question whether or not I know the RFC when I cite the RFC multiple times in the paper - o</FONT><FONT face=Arial color=#000000 size=2>f course HEAD is GET. There's no other way to ensure the similarity between HEAD response headers and GET response headers. Here's a snippet from the paper:</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>> The HTTP specification, RFC 2616 [1], specifies that HEAD requests should produce the same results as </FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2>> a GET request but with no response body.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>It's not that we expect anything else from HEAD, indeed it's doing exactly as the spec says - we're just alerting most people to its usefulness to attackers to access non-idempotent GETs behind URL authorization schemes. That is the fact that, which you may still not believe, is not well known. Of course that's just half the story, the other half is the vendor craziness when dealing with arbitrary HTTP verbs.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT size=2>> Ooop; a bit defensive there.  I was commenting based on the content in<BR>> the blog, which is primarily written by you.</FONT></DIV>
<DIV dir=ltr><FONT size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>Of course, but being arbitrary about labeling those things that you don't know are claims amounts to the same insinuation. I'll try not to take offense in the future, but it's hard - I can't share this with everybody or someone will leak it and steal credit. On the other hand, we do a lot of research and ask some people in the field we consider extremely knowledgeable if they know of any prior art. They tell us no, it's great and to move on it, and we still get 2 people calling it "obvious". C'est la vie, after thinking about it, having 2 non-positive feedbacks compared to the numerous positive responses we've gotten is not so bad at all.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>Incidentally I browsed around for a few hours during our research to see what, if any HEAD requests were issued by the browser. The only thing that evoked anything other than GET or POST was OWA (WebDAV verbs). Has anyone evaluated what, if anything, would break if HEAD suddenly went away?</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>What is more reasonable action, from this point forward? R</FONT><FONT face=Arial size=2>un into these URL authorization mistakes constantly from here on out, or </FONT><FONT face=Arial size=2>turn off HEAD and deal with the consequences?</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> </DIV></DIV>
<DIV dir=ltr><BR>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> Martin O'Neal [mailto:martin.oneal@corsaire.com]<BR><B>Sent:</B> Thu 5/29/2008 8:19 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>> It is obvious after reading the paper, isn't it?<BR><BR>You are having a laugh, no?  RFC2616: "The HEAD method is identical to<BR>GET except that the server MUST NOT return a message-body in the<BR>response".  And your expectation of how this would be otherwise<BR>implemented in a server other than a wrapper for GET?  Wasteful,<BR>unmanageable, duplicate code?<BR><BR>> The journalist's assassin word: "claim" - always<BR>> used to install doubt without having actually<BR>> doing any follow up.<BR><BR>Ooop; a bit defensive there.  I was commenting based on the content in<BR>the blog, which is primarily written by you.  I haven't spoken to any of<BR>the chaps listed, so logically whether they did or didn't know is<BR>unsubstantiated (this isn't a personal attack on your integrity, it is<BR>an auditors approach to life; if I can't validate it, then it is chalked<BR>up as conjecture until I can).  So in context, the use of "claimed" is<BR>both accurate and appropriate.  Like 9 out of 10 cat owners will know.<BR><BR>> Did you read the paper?<BR><BR>Yes and watched the clip too.<BR><BR>> The HEAD-redirect-to-GET and arbitrary verbs being forwarded to GET<BR>handler are the unique takeaways.<BR><BR>You're not getting this are you?  HEAD *is* GET, just without the body.<BR>It is by design!  I'm not sure how or why you would expect something<BR>else!<BR><BR>Martin...<BR><BR><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>