This is a cool paper and all of you should read it for many reasons.

First, because it’s a perfect example of hacking. Hacking is just critical thinking and understanding how a system works. In this paper by understanding the nuances of web technologies the researchers found a very trivial way to bypass the authentication systems of many popular web frameworks!

Second, it’s a classic example how programmers with even a little security knowledge can make big mistakes.

Here is the paper in a nutshell:

Various web frameworks like Jave EE, ASP.NET, etc, allow you to configure the website so certain directories are only accessible to certain users with certain HTTP methods. So anyone can do a GET or POST to /public/ but only an admin can do a GET or POST to /admin/.

Enter the HTTP HEAD method. This is usually used to diagnostics and caching. If you send an HTTP HEAD instead of an HTTP GET to a URL, the website is supposed to do everything it would normally do when processing a GET, only it should only the HTTP response contains only header and no body. To make sure the same response (sans body) is sent for an HEAD as a GET, web servers simply handle the response as if it was a GET, and suppress the body when sending the response.

Do you see the trick yet?

HTTP HEAD method can be used to side-step authentication systems in many web applications. An attacker simply sends a HEAD to /admin/deleteUser?user=billy? instead of an GET. The authentication framework checks and sees that anyone can send HEADs to /admin/ and does not stop the processing of the request. The web server runs all the back end code that it normally runs for a GET, which deletes Billy as a user. The attacker does not see the body on the response, so it’s a blind attack. However the attacker can see the HTTP status code that is returned with the response to the HEAD and based on its value (200, vs 500) the attacker can tell if it worked.

This is exactly the reason why HTTP GET should be idempotent. In other works, GETs and HEADs should not modify the state of the web server so you can send multiple gets to the exact same URL and it should not cause problems. POSTs on the other hand are not idempotent. This is why e-commerce sites say things like “don’t click checkout again!” and your browser will say things like “You have already submitted POST data, are you sure you want to refresh and send this again?” (AMP, we aren’t doing this in our web frontend right?)

We even have an idea about how widespread this problem could be. In 2005 Google launched Google Web Accelerator. This was a browser plug in that pre-fetched links on the page you were looking to better utilize your bandwidth. Unfortunately, thousands of sites started breaking because developers all of the world were using simple hyperlinks (which issue a GET) to modify the state of the web app. There was lots of kicking and screaming, and I acquired a healthy dislike for Ruby on Rails developers who kept insisted that the rest of the world was wrong and they were right, but I digress.

In short, by knowing HTTP and understanding that a developer implemented a default “Allow All” feature, this very cool attack was discovered.