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.