[WEB SECURITY] Bypassing URL Authentication and Authorization with HTTP Verb Tampering

Arshan Dabirsiaghi arshan.dabirsiaghi at aspectsecurity.com
Thu May 29 08:47:02 EDT 2008

Not sure how you can question whether or not I know the RFC when I cite the RFC multiple times in the paper - of 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:
> The HTTP specification, RFC 2616 [1], specifies that HEAD requests should produce the same results as 
> a GET request but with no response body.
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.
> Ooop; a bit defensive there.  I was commenting based on the content in
> the blog, which is primarily written by you.
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.
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?
What is more reasonable action, from this point forward? Run into these URL authorization mistakes constantly from here on out, or turn off HEAD and deal with the consequences?


From: Martin O'Neal [mailto:martin.oneal at corsaire.com]
Sent: Thu 5/29/2008 8:19 AM
To: Arshan Dabirsiaghi; websecurity at webappsec.org
Subject: RE: [WEB SECURITY] Bypassing URL Authentication and Authorization with HTTP Verb Tampering

> It is obvious after reading the paper, isn't it?

You are having a laugh, no?  RFC2616: "The HEAD method is identical to
GET except that the server MUST NOT return a message-body in the
response".  And your expectation of how this would be otherwise
implemented in a server other than a wrapper for GET?  Wasteful,
unmanageable, duplicate code?

> The journalist's assassin word: "claim" - always
> used to install doubt without having actually
> doing any follow up.

Ooop; a bit defensive there.  I was commenting based on the content in
the blog, which is primarily written by you.  I haven't spoken to any of
the chaps listed, so logically whether they did or didn't know is
unsubstantiated (this isn't a personal attack on your integrity, it is
an auditors approach to life; if I can't validate it, then it is chalked
up as conjecture until I can).  So in context, the use of "claimed" is
both accurate and appropriate.  Like 9 out of 10 cat owners will know.

> Did you read the paper?

Yes and watched the clip too.

> The HEAD-redirect-to-GET and arbitrary verbs being forwarded to GET
handler are the unique takeaways.

You're not getting this are you?  HEAD *is* GET, just without the body.
It is by design!  I'm not sure how or why you would expect something


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20080529/ce7f18e7/attachment.html>

More information about the websecurity mailing list