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

Gunter Ollmann gollmann at us.ibm.com
Thu May 29 11:32:09 EDT 2008

"Arshan Dabirsiaghi" <arshan.dabirsiaghi at aspectsecurity.com> wrote on
05/29/2008 08:47:02 AM:
> > 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.

Now, I don't normally pipe up in these kinds of discussions, but I'm afraid
I'm going to have to agree with Martin on this.

Your paper is a good summary of the problem, but lets not get caught up on
any novelty of this vector.

Any of the pentesters I've worked with in the past decade will tell you how
they use these techniques to bypass restricting
authentication/authorization filtering. For example, the 3-day "Ethical
Hacking" training course given by ISS from 2001-2005 covered these
techniques, and I believe that the NGS Software "Web Application
(In)security" course's at Blackhat have covered/discussed it as well.

You'll also find a few bruteforce attack tools that will flip to HEAD etc.
for launching attacks - but this is a little more to do with speed
improvements and bandwidth constraints - but, at the end of the day, I
can't agree with the assertion that this is not well known.

I don't have a copy handy, but you may also want to check out Dafydd
Stuttard's and Marcus Pinto's book "The Web Application Hackers Handbook"


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

More information about the websecurity mailing list