When hunting for vulnerabilities in web applications, we have to consider more than the web application itself. This includes the actual deployment setting with additional intermediary systems such as reverse proxies. Due to misconfigurations or bugs in the reverse proxy or web server software, additional vulnerabilities can arise due to the increased attack surface and deployment complexity. This module covers three such vulnerabilities:
CRLF Injection which is often caused by coding mistakes in the web application itself. If user input is used in places where newline characters have a special semantic meaning and the web application fails to properly sanitize the user input, these vulnerabilities can arise. Furthermore, the module covers
HTTP Request Smuggling and
HTTP/2 Downgrading which are often caused by misconfigurations and bugs in reverse proxy or web server software.
This module is related to the Abusing HTTP Misconfigurations module as both modules exploit misconfigurations and vulnerabilities on the HTTP level. Feel free to complete both modules in any order you prefer to learn more about real-world HTTP vulnerabilities that go beyond the scope of the web application by itself.
In more detail, this module covers the following:
- What is CRLF injection?
- Exploitation of CRLF injection leading to log injection
- Exploitation of CRLF injection leading to HTTP response splitting
- Exploitation of CRLF injection leading to SMTP header injection
HTTP Request Smuggling:
- How does a system determine the length of a request body?
- View of multiple HTTP requests in the same TCP stream
- Exploiting HTTP request smuggling vulnerabilities in different variants
- Exploiting bugs in web server software leading to HTTP request smuggling
- Exploiting HTTP request smuggling vulnerabilities to bypass Web Application Firewalls, steal user data, and weaponize reflected XSS
- Differences between HTTP/1.1 and HTTP/2
- What is HTTP/2 Downgrading?
- Exploiting HTTP request smuggling due to HTTP/2 downgrading
This module is broken into sections with accompanying hands-on exercises to practice each of the tactics and techniques we cover. The module ends with a practical hands-on skills assessment to gauge your understanding of the various topic areas.
You can start and stop the module at any time and pick up where you left off. There is no time limit or "grading," but you must complete all of the exercises and the skills assessment to receive the maximum number of cubes and have this module marked as complete in any paths you have chosen.
As you work through the module, you will see example commands and command output for the various topics introduced. It is worth reproducing as many of these examples as possible to reinforce further the concepts presented in each section. You can do this in the
PwnBox provided in the interactive sections or your virtual machine.
Introduction to HTTP Attacks
In real-world deployment contexts of web applications, we often face additional complexity due to intermediary systems such as reverse proxies. Similarly to the Abusing HTTP Misconfigurations module, we will cover three HTTP attacks that are common in modern web applications, discussing how to detect, exploit, and prevent them, in addition to knowing the misconfigurations that cause them. Prior completion of the
Abusing HTTP Misconfiguration module is not required since we cover three different HTTP vulnerabilities here.
Since HTTP is a stateless protocol, we often view HTTP requests isolated from each other. However, HTTP/1.1 allows the reuse of TCP sockets to send multiple requests and responses to improve performance. In that case, the TCP stream contains multiple HTTP requests. To determine where one request ends and the next one begins, the web server needs to know the length of each request's body. To determine the length, the
Transfer-Encoding HTTP headers can be used. While the Content-Length header specifies the length of the request body in bytes, the Transfer-Encoding header can specify a
chunked encoding which indicates that the request body contains multiple chunks of data. In this module, we will discuss vulnerabilities that arise from inconsistencies and discrepancies between multiple systems in determining the length of HTTP requests.
HTTP/2 implements many improvements over HTTP/1.1. While HTTP/1.1 is a string-based protocol, HTTP/2 is a binary protocol, meaning requests and responses are transmitted in a binary format to improve performance. Additionally, HTTP/2 uses a built-in mechanism to specify the length of the request's body. In some deployment settings, HTTP/2 requests are rewritten to HTTP/1.1 by an intermediary system before forwarding the request to the web server. We will discuss vulnerabilities that can be caused by such deployment settings.
The first HTTP attack discussed in this module is CRLF Injection. This attack exploits improper validation of user input. The term
CRLF consists of the name of the two control characters
Carriage Return (CR) and
Line Feed (LF) that mark the beginning of a new line. As such, CRLF injection attacks arise when a web application does not sanitize the CRLF control characters in user input. The impact differs depending on the underlying web application and can be a minor issue or a major security flaw.
HTTP Request Smuggling/Desync Attacks
The second attack discussed in this module is HTTP Request Smuggling, sometimes also called
Desync Attacks as they create desynchronization between the reverse proxy and the web server behind it. This is an advanced attack that allows an attacker to bypass security controls such as
Web Application Firewalls (WAFs) or completely compromise other users by influencing their requests.
HTTP/2 Downgrade Attack
The third and final attack covered in this module is a HTTP/2 Downgrade Attack or
HTTP/2 Request Smuggling. HTTP/2 implements measures that effectively prevent request smuggling attacks entirely. However, since HTTP/2 is not widely supported yet, there are deployment settings where the user talks HTTP/2 to the reverse proxy, but the reverse proxy talks HTTP/1.1 to the actual web server. These settings may be vulnerable to request smuggling even though HTTP/2 is used in the front end.
Let's get started by discussing the first of these attacks in the next section.