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

Arian J. Evans arian.evans at anachronic.com
Wed May 28 20:24:29 EDT 2008


This is a very clearly, concisely written paper that
communicates the key points effectively. Nice.

The subject of this paper is part of a larger bucket
of software weaknesses that I do not think most
automation tools or pen testers test for today.

The programming practices that give rise to the
issues you explore here also give rise to another
related subset of issues.

Let's think of these issues as devided into
two major buckets:

1) Syntax (XSS, SQLi) and
2) Semantic (Authentication, Authorization, Workflow)...

...weaknesses. By Semantic I mean involving
the expected or intended dialogue of the
application. You are subverting that with your
examples. By Syntax I mean all technical
attacks subverting the data/function boundary.

Three of the excellent points made in this paper:

(a) HEAD:  The use of HEAD to perform replay and
bypass authentication or authorization of requests

(b) Arbitrary HTTP Verbs: The use of Arbitrary HTTP
[Verb] to re-play HTTP requests

(c) Semantic Attacks via Verb Manipulation:

The *most* interesting thing to me here is that you
can using HTTP verb manipulation to perform semantic
attacks allowing an attacker to subvert the business
logic of an application. Steal money. Create Admin. Etc.


***Syntax Attacks still Rock Too***

This is relevant right now, today. We are testing
one of the most popular PHP portals used in Europe
as I write and it is riddled with holes related to
these attack vectors. Unfortunately today's
webappsec scanners do not find them.

Given that the Network VA scanners like Scan
Alert, Rapid7, and Qualys cannot even find the
basic webappsec issues that the desktop webapp
scanners find, I suspect Network VA Scanners
are useless here too.



***HTTP Verb Manipulation puts new twist on old Syntax Attacks***

There is an entire subset of these attacks that
I've documented under "filter evasions" in the
paper I'm planning to release at BH Vegas.
(this is the same talk I'll be giving at OWASP).

After talking with Arshan I realized that the
Semantic issues in his paper are part of the
same *kind* of class of defect in software.

Let's talk software examples:

Common implementation practices in ASP Classic
that lead to this sort of vulnerable state (and you'll
find similar implementation practices in almost
every crappy PHP 4/5 portal project):

Example 1:  Syntax Attacks through Session objects:

The weak code will iterate through the Session
object grabbing all name=value pairs found. It will
then persist them via cookies or (most commonly)
hidden form-fields....

So: regardless of how the name=value pairs
wind up in the session -- no matter what HTTP
verb is used, they wind up in objects in the
HTTP session namespace. So by changing
the HTTP Verb you can often introduce unallowed
data types, or entirely new value pairs into
the session object(s).

e.g. by converting GET to POST, POST to
HEAD, HEAD to YOYO, etc. etc. you can
inject whatever you want

These name-value pairs often wind up written
out to the page and in headers, allowing XSS
and HTTP RS (or say the examples from Aspect's
previous \r\n content download paper).

They also wind up, less commonly, in dynamic
SQL queries, particularly when those queries
use the querystring or URI, creating SQL injection.

So the simplest form of HTTP Verb manipulation:

+ Changing GET to POST

+ Change POST to GET

+ etc.

Will often enable you to bypass input validation
filters with syntax attacks like SQLi and XSS.

So this does not work:

GET /uri/path?name=Arshan&account=' DROP Table Users ;--

This does work:

HEAD/PUT/YOYO /uri/path?name=Arshan&account=' DROP Table Users ;--



Example 2: Bypassing strong type/input validation by Creating New Data Types

In many implementations, from JSPs to PHP, but
especially in ASP Classic, I have found the ability
to bypass input validation filters using these
exact same techniques.

The guilty software usually has some function
that globs through:

Session.serverVariableName(all)

(or similar namespace in other implementation languages)

and persists all variables discovered in this namespace
via Hidden Form Fields or HTTP cookies, or uses them
later in a query.

So this does not work

HEAD /uri/path?name=Arshan&account=' DROP Table Users ;--

This does work:

GET /uri/path?name=Arshan&account=1234&NewValue=' DROP Table Users ;--

(as an aside, in this situation often times making
the NAME of the name=value pair the attack works
too -- if the code strongly types the VALUE but
ignores the names.)


Example 3: HTTP Verb Request-structure mangling

There is another twist to this as well, that I've
found many pieces of old software, and early
versions of .NET to be vulnerable to:

+ Submit [Syntax Attack] in querystring on POST

+ Submit [Syntax Attack] in Postdata on GET

+ Submit [Syntax Attack] in [non-expected request element] on [Wrong Verb]

+ etc.


So this does not work

GET /uri/path?name=Arshan&account=' DROP Table Users ;--

But this does work:

POST /uri/path?name=Arshan&account=' DROP Table Users ;--

And this works too:

GET /uri/path?name=Arshan


(Postdata) &account=' DROP Table Users ;--

----


Conclusion:

Great paper, and excellent ideas.

Given that I have found software vulnerable to
Syntax attacks using these methods, from Cisco
apps to every PHP app I've ever tested, I suspect
that a lot of software is vulnerable to the issues
you describe.


nota bene: Ed Welsh and I posted to the OWASP
and WASC lists about enabling Syntax (not
Semantic) attacks via VERB manipulation back
in 2004 or 5 (search the archives if you care).

The responses we got when trying to start a
dialogue on this were of the misguided "you
can exploit GETs or POSTs !!!" variety so we
dropped the subject.

Hopefully this paper will breathe some new
life into this dialogue.

Whether or not people read the paper -- there
is plenty of software out there weak to these
types of attacks.


-- 
-- 
Arian J. Evans. software security stuff.

I spend most of my money on motorcycles, mistresses, and martinis. The
rest of it I squander.


On Wed, May 28, 2008 at 7:48 AM, Arshan Dabirsiaghi
<arshan.dabirsiaghi at aspectsecurity.com> wrote:
> Internetizens,
>
> Many URL authentication and authorization mechanisms make security decisions
> based on the HTTP verb in the request. Many of these mechanisms work in a
> counter-intuitive way. This fact, in combination with some oddities in the
> way that both web and application servers handle unexpected HTTP verbs
> causes the rules dictated by those mechanisms to be bypassable.
>
> Many of us rely on the mechanisms I'm talking about. The Internet is not
> exactly going to burn down when this email goes out, but there is probably a
> fair number of externally facing web applications out there that are relying
> on the shaky security provided by these configurations.
>
> We have written a whitepaper that goes into some detail discussing the
> vulnerability and how the various vendors are affected. You can grab the
> whitepaper from Aspect Security's website:
>
> http://www.aspectsecurity.com/documents/Bypassing_VBAAC_with_HTTP_Verb_Tampering.pdf
>
> Jeff Williams and Jim Manico also put together a demo that shows the attack
> in progress:
>
> http://www.aspectsecurity.com/documents/Aspect_VBAAC_Bypass.swf
>
> Cheers,
>
> Arshan Dabirsiaghi
>
> Director of Research
>
> Aspect Security
>
> http://www.aspectsecurity.com/

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

Have a question? Search The Web Security Mailing List Archives: 
http://www.webappsec.org/lists/websecurity/

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

Join WASC on LinkedIn
http://www.linkedin.com/e/gis/83336/4B20E4374DBA



More information about the websecurity mailing list