Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

Websites do not simply go from request to server now-a-days. There are proxies in between, redirects and many other things going on. What would happen if two different passes understood the request or response differently?

This attack was originally used on the request in order to trick the service to what request was actually being sent. This can be done by sending multiple Content-Length headers, Transfer-Encoding and Content-Length or whenever two different requests are being made. This article discusses a new way to cause a desync but via the response pipeline.

The Connection header is used to specify connection information in a request. In particular, it tells how persistent a connection should be. This is a Hop-by-Hop, which means it is dropped between proxies.

The Connection header specifies which other headers are part of the specific connection. Then, this other connection specific headers are removed from the request when it is forwarded to the next part of the pipeline. What if we sent the Content-Length header instead?

By removing the Content-Length header from the request, the body of the original request will be interpreted as the start of the next request. The original request is just seen to have an empty body; this is a vulnerability in the RFC itself! Can this be exploited?

A few ideas from the original request smuggling:

• Bypass FrontEnd controls with the new smuggled request.
• Change Response of a different user with the desynced queue.
• Web Cache Attacks.
• Make an existing vulnerability, such as reflected XSS, much more impactful.

We can do something better though! By smuggling in two requests within a single request, we can mess up the response queue! The second attacker requests response will go back to the victim, leaving the victims request! By making a final request, we will receive the response to the victims request instead of our own. Damn!

There is an issue with getting the correct response back though. If there is a response but not connection in the queue, the response is dropped. As a result, the smuggled request should be a time consuming operation to get it to be sent back to our victim.

It is also possible to concatenate responses back to the victim from a users request. This is done by smuggling in a HEAD request that contains a Content-Length header, which is against the RFC but very common. Then, with the second smuggled request contains a reflected endpoint, we can send arbitrary data back to the victim.

The article contains a few other techniques that work as denial of services as well. Overall, this is amazing research that will help many researchers find bugs in the future!