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

Arian J. Evans arian.evans at anachronic.com
Thu May 29 13:57:22 EDT 2008

What funny responses from all the "usual suspects"
on the list. I admit, I had the same reaction as  many
of you when Arshan sent over his paper:

"WTF?, this is old news, I've tested for, discussed this,
and released vulns for years using these type of techniques"

Verb manipulation, blah blah, explicity auth or input
validation checks bound to verbs, bypass them by....

But come on guys -- let's be fair:

Arshan did great work here clearly documenting
exploitable conditions. I don't see his exact examples
clearly documented anywhere else.

I was *SURPRISED* not to find this anywhere else.

Yes: I could make a list of brains this info is inside.
That's not the point.

Sure: testers using any fuzzer or fuzzing framework
could (and should) be testing for this, but really:
how many testers are using SPIKE or Peach? vs.
using "WebInspect" or the like?

Folks dismissing this (Martin, Gunter) are not the norm,
for webappsec domain knowledge -- even for this list!
You guys are some of the most knowledgeable
people in this space, and have been around longer
than what, 99% of the people in our "industry" now?

The pen-testers at NGS are not anywhere near the norm
either; they are amongst the most respectable I've met.

Have these techniques been used before?

Of course.

We published advisories while I was @FishNet
using these kind of techniques. It was in the
extensive methodology I wrote for testing there.

I've personally brought up variants of these on the
webappsec and pen testing lists years ago, and the
responses then largely demonstrated poor understanding
of the subject.

None of this is the point.

The vast majority of webappsec-land today, including
the people reading this list and attending our conferences,
consist largely of folks new to the space, or inexperienced.

And their domain knowledge inputs include:

1.) The desktop webapp scanners that don't test for these
things well, and the network VA scanners that claim to
test for these things but, in most cases, do not at all.

In 2008. (!)

2.) Most "pen-testers" and "consultants" testing webapps
today are scanner or checklist jockeys. The NGS folks
are the edge case of top talent. I see apps all the time
right behind average "pen testers" and from what I can
tell, they are not testing for these things thoroughly, if at all.

So while I am highly concerned that I appear to be
agreeing with Andre, I think Arshan did nice work
here and it's clearly documented.

Someone find me a white paper that clearly documents
my response examples of how & why XSS or SQLi
works by changing a verb to HEAD or YOYO? Or
by creating mal-formed requests, which I don't
see anywhere.

Same thing, and I bet all the good testers I know already
know these techniques, but I also think they are
about 1% of the population testing software now,
let alone those on the list reading it to learn more,
who've never tested software before for security.

Arian Evans. Software Security Stuff.

On Thu, May 29, 2008 at 9:44 AM, Andre Gironda <andreg at gmail.com> wrote:
> On Thu, May 29, 2008 at 8:32 AM, Gunter Ollmann <gollmann at us.ibm.com> wrote:
> Gunter
>> 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.
> Exactly why this type of vulnerability-finding technique shouldn't be
> locked up in $5k-10k/person courseware IP and instead published in the
> open.  Or given to the community through OWASP, BSI, or MITRE
> enumeration projects.
>> 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 am curious about this as well.  Elza (1998?) or any spider probably
> has done HEAD/Verb operations for authentication bypass purposes.
> SPIKEproxy or another fuzzer would have found vulnerabilities like
> this in the past.  But not everything that SPIKEproxy or Elza have
> picked up has been announced to the public as bad practice with
> identification, impact, variations, and countermeasures -- especially
> when combinatorial aspects factor in (e.g. combining an authenticated
> spider set of results with an external HTTP method fuzzer).  The tools
> don't do this on their own: the people driving them do.
> Either way you look at it, if it has been done in the past (and I'm
> not arguing that it hasn't) -- it's been exploratory.  With
> documentation like Arshan's, now it can be a formal test case and part
> of a checklist.
>> 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"
>> http://www.amazon.com/Web-Application-Hackers-Handbook-Discovering/dp/0470170778/ref=sr_1_1?ie=UTF8&s=books&qid=1212074361&sr=8-1
> I have the PDF.  Did some searches.  Read chapters 4, 6, and 8.  It's
> not in there.
> Cheers,
> Andre

Join us on IRC: irc.freenode.net #webappsec

Have a question? Search The Web Security Mailing List Archives: 

Subscribe via RSS: 
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]

Join WASC on LinkedIn

More information about the websecurity mailing list