Wednesday, June 04, 2008

What you need to know about HTTP Verb Tampering

Recently Arshan Dabirsiaghi, Director of Research of Aspect Security, published a white paper entitled “Bypassing URL Authentication and Authorization with HTTP Verb Tampering”. Initially there was a lot of confusion about what exactly was being explained or claimed. Including, is it real? Is it novel? Is it dangerous? What is this? Most will get lost in the semantics of the debate and only care if it impacts them in some way. So I hope to get to the relevant bits, borrow from Arian Evan’s summaries, and make things a bit easier to understand.

1) No one is claiming the HTTP Verb (GET/POST/HEAD) manipulation is new. Manipulating what type of HTTP request a webapp is expecting to receive, such changing GET to POST and POST to GET, has been done for years. Our websites should only be using the types of requests we expect to receive and no more. What is interesting here is when it can be used and for what purpose.

2) HTTP Verb tampering is generally used in conjunction with syntactic (XSS, SQLi, etc.) and semantic (bypass authentication/authorization controls) attacks as way to bypass certain defense measures. Arshan’s work on implementation details focus on the semantic version.

3) In syntactic attacks you can use verb manipulation to get malicious data (‘ DROP TABLE …’) in a session object that might now have otherwise been allowed. i.e. Query string parameters were sanity checked, but the attacker used POST placing the data in the message body where it was overlooked by the application. This can lead to SQLi, XSS, and several other common technical vulnerabilities.

4) To protect yourself from syntactic HTTP verb manipulation attacks, make sure you only include user-supplied data from where it’s expected to be received (Query string or POST data), or sanity check them both the same if necessary. Also only include the parameter names in the session object you expect to receive. Don’t allow attackers to add arbitrary name/value pairs.

5) In semantic attacks verb manipulation can be used to bypass authorization/authentication protection for specific verbs and areas of the site. A config might say HTTP requests to the /admin/* directory using “GET” must have an “admin” session role. One would ASSUME any methods not listed (POST, HEAD, WHATEVER) in the config would automatically be placed in default-deny mode, but this is not necessarily the case. RFC’s say the HEAD verb is supposed to be treated exactly the same as GET, just don’t return any response data. So its possible for an attacker to send a request to /admin/delete_user.cgi?id=1 with a HEAD verb with no authentication/authorization. They just wouldn’t get a response to the action and certain frameworks are known to be vulnerable to similar attacks. Nasty stuff and commonly goes untested for.

6) There are several things one can do to protect themselves, the most direct is ensuring ALL HTTP verbs are placed in default-deny mode unless otherwise specified. What you are looking for in consistency of authentication/authorization controls across the various methods you expect to receive. Addition details are going to be implementation specific and can be found in the white paper or list chatter.

7) Scanning for syntactic issues is possible, but can easily double or triple the number of requests that need to be sent. Varying degrees of effectiveness are wide across the commercial vendor range. Scanning for semantic issues is going to be extremely hard and likely to be a manual process for quite some time. Its basically a business logic flaw even though the scanner can technically manipulate the verb, it just doesn’t know what the outcome of a test means.

Overall good paper, I learned some good stuff about the particulars of certain implementations. Plus it sparked a lot of good debate. Hope this helps clear some things up.


dre said...

In no way do I intend to diss on Arshan (he's great!), but there is almost nothing in his paper that is new. Not the authorization bypass. Not the use of HTTP verb tampering to bypass authorization. Ok, maybe the HEAD part (but this doesn't matter!).

Many who thought that what Arshan said is new and never been done before (including myself) were indeed wrong.

Quoting Adam Muntner from the webappsec-l mailing-list:

Here is the whitepaper from 2004 I had been trying to find

An Apache 2.0 land one should use LimitExcept instead of Limit in .htaccess files. Still, this is an interesting paper because it describes using method tampering to bypass an authentication mechanism.

Arshan Dabirsiaghi said...

Yeah, it reminds me of that NBC tagline: "if I haven't seen it, its new to me!" Jeremiah, Arian, Jeff and I (and you I think to some degree) spent time poring over advisories trying to find something like the paper Adam posted - to no avail.

Saying it has been done before is true - not acting on it and getting the word out about is another. DNS rebinding went through the same thing - discovered 11 years ago by Princeton folks, then forgot about until someone gave us a good shaking.

The scenarios, vendor studies and exploitability requirements are not documented in CWE, OWASP, WASC, etc., so we obviously need that same shaking on this subject and I think that's what Jeremiah was saying.

All the credit in the world to those guys, though - even though they missed the HEAD vector (oh yes Dre, it does matter!). BILBAO method 4ever.

In summary, go read their paper, go read mine, go read both, whatever - but let's do a better job of disseminating the technique/vulnerability this time around!

Yousif Yalda said...

What is this exactly? Are we suddenly hyped on creating fancy words like "Verb Tampering"? From what I understand so far, this is basically explaining the dangers of leaving other HTTP vectors out.. and that you should deny all if not in use, and accept ones that are in use; specifically because the rest can be manipulated.

Anonymous said...

I always find it to be a good idea to forward all requests made with unexpected methods to a nice 403 page. Although it's limited I only allow GET requests on my own domains, have blocked 30 other HTTP verbs (Apache and IIS), and also filter out any user-generated methods as well. I am however building a new framework for my domains, and have already included mechanisms to prevent this right in the code itself.

Anonymous said...

Dear Arshan, yes, it´s is new for you ... but ... old in this world:

The paper:

The Bugtraq Mail:

The BID:

The w3af plugin:

Good for you, ¡you discover "the head"!

Anonymous said...


Glad to see some people (Arshan) is making KPK famous again ;)

Keep the good job rediscovering stuff we did before, no bad thoughts about that.

Seriously, is great to see somebody read our stuff (some did at proper time, some others are doing now, but it's cool!)

Arshan Dabirsiaghi said...

Yes, KPK won the discovery race!

If nothing else, we are just happy to let people know the problem existed - it's not just an Apache problem, though. It's all over the place. We should get a SecurityFocus BID that's a dozen pages too.. =P