Most of the request smuggling attacks we've discussed so far are possible due to the same connection between the front-end and back-end handling multiple requests. While some servers reuse the connection for any request, others have stricter rules.
For instance, some servers only allow connection reuse for requests coming from the same IP address or the same client. Others won't reuse the connection at all, limiting what you can achieve via classical request smuggling since there's no clear way to influence other users' traffic.
While you may not be able to manipulate the socket to interfere with other users' requests, you can send a single request to the back-end and receive two responses. This potentially allows you to completely conceal a request and its corresponding response from the front-end.
To circumvent front-end security measures that might prevent you from sending specific requests, you can employ this technique. In fact, some mechanisms specifically designed to prevent request forgery can still fail to stop request tunneling.
Tunneling requests to the back-end in this manner presents a more limited form of request forgery, but can still lead to highly dangerous attacks in the hands of knowledgeable attackers.
Creating a Request Tunnel with HTTP/2
Request tunneling is possible with both HTTP/1 and HTTP/2, although it is much harder to detect in HTTP/1 environments. Due to the way persistent connections operate in HTTP/1, even if you receive two responses, it does not necessarily mean the request has been successfully smuggled.
In contrast, in HTTP/2, each "stream" should contain only a single request and response. If you receive a response in the body that appears like an HTTP/1 response in HTTP/2, you can be sure that you have successfully tunneled the second request.
Leaking Internal Headers via HTTP/2 Request Tunneling
When request tunneling is your only option, you cannot leak internal headers using the technique we discussed in one of our previous labs, but version downgrading in HTTP/2 provides an alternative solution.
By potentially deceiving the front-end, you can facilitate the inclusion of internal headers that will become body parameters at the backend. Let's say we send a request like this
For instance, some servers only allow connection reuse for requests coming from the same IP address or the same client. Others won't reuse the connection at all, limiting what you can achieve via classical request smuggling since there's no clear way to influence other users' traffic.
While you may not be able to manipulate the socket to interfere with other users' requests, you can send a single request to the back-end and receive two responses. This potentially allows you to completely conceal a request and its corresponding response from the front-end.
To circumvent front-end security measures that might prevent you from sending specific requests, you can employ this technique. In fact, some mechanisms specifically designed to prevent request forgery can still fail to stop request tunneling.
Tunneling requests to the back-end in this manner presents a more limited form of request forgery, but can still lead to highly dangerous attacks in the hands of knowledgeable attackers.
Creating a Request Tunnel with HTTP/2
Request tunneling is possible with both HTTP/1 and HTTP/2, although it is much harder to detect in HTTP/1 environments. Due to the way persistent connections operate in HTTP/1, even if you receive two responses, it does not necessarily mean the request has been successfully smuggled.
In contrast, in HTTP/2, each "stream" should contain only a single request and response. If you receive a response in the body that appears like an HTTP/1 response in HTTP/2, you can be sure that you have successfully tunneled the second request.
Leaking Internal Headers via HTTP/2 Request Tunneling
When request tunneling is your only option, you cannot leak internal headers using the technique we discussed in one of our previous labs, but version downgrading in HTTP/2 provides an alternative solution.
By potentially deceiving the front-end, you can facilitate the inclusion of internal headers that will become body parameters at the backend. Let's say we send a request like this
Kod:
:method POST
:path /comment
:authority vulnerable-website.com
content-type application/x-www-form-urlencoded
foo
bar\r\n
Content-Length: 200\r\n
\r\n
comment=
x=1In this case, both the front-end and back-end agree that there is only one request. What's interesting is that they may disagree on where the headers end.
The front-end sees everything we inject as part of a header, so it appends new headers after the comment= string at the end. On the other hand, the back-end sees the \r\n\r\n sequence and considers it the end of the headers. The comment= string is then considered part of the body along with the internal headers. The result is a comment parameter with the value being the internal headers.
Kod:
POST /comment HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 200
comment=X-Internal-Header: secretContent-Length: 3
x=1Blind Request Tunneling
Some front-end servers read all the data they receive from the back-end. This means that if you successfully tunnel a request, they will potentially forward both responses to the client, including the response to the tunneled request embedded within the main response body.
Other front-end servers only read the number of bytes specified in the Content-Length header of the response. Therefore, only the first response is forwarded to the client. This blind request tunneling vulnerability arises because you won't be able to see the response given to your tunneled request.
Non-blind Request Tunneling using HEAD
Blind request tunneling can be challenging, but sometimes you can make these vulnerabilities non-blind by using HEAD requests.
Responses to HEAD requests typically include a Content-Length header indicating the length of the resource that would normally be returned by a GET request to the same endpoint, even though they don’t have their own body. Some front-end servers ignore this and attempt to read the number of bytes specified in the header regardless. If you successfully pass a request through such a front-end server, this behavior may result in the server overreading the response from the back-end. As a result, the response you receive may contain bytes starting from the response to your tunneled
request.
Kod:
:method HEAD
:path /example
:authority vulnerable-website.com
foo
bar\r\n
\r\n
GET /tunnelled HTTP/1.1\r\n
Host: vulnerable-website.com\r\n
X: xResponse
Kod:
:status 200
content-type text/html
content-length 131
*******************************
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 4286
<!DOCTYPE html>
<h1>Tunnelled</h1>
<p>This is a tunnelled respoSince you effectively mix the Content-Length header of one response with the body of another, successfully utilizing this technique is somewhat a balancing act.
If the endpoint you send your HEAD request to returns a resource shorter than the tunneled response you're trying to read, it might simply truncate this resource without revealing anything interesting, as seen in the example above. On the other hand, if the returned content length is longer than the response to your tunneled request, you'll likely encounter a timeout as the front-end server expects additional bytes to come from the back-end.
Fortunately, with a bit of trial and error, you can overcome these issues using one of the following solutions:
Redirect your HEAD request to a different endpoint that returns a resource of the appropriate length, either longer or shorter. Use a reflected input in the main HEAD request to add optional padding characters. Even if you don't see your input actually reflected, the returned content length will still increase accordingly. If the resource is too long, use a reflected input in the tunneled request to add random characters to match or exceed the expected length of the tunneled response.
Cache Manipulation via HTTP/2 Request Tunneling
While request tunneling is often more limited than classical request smuggling, it can still occasionally lead to highly significant attacks. For instance, you can combine the request tunneling techniques we've explored so far to create an extra potent form of web cache manipulation.
With non-blind request tunneling, you can effectively mix and match the headers of one response with the body of another. If the response reflects unencoded user input in the body, you can exploit this behavior for reflected XSS in contexts where the browser wouldn't typically execute the code.
For example, the following response includes unencoded, attacker-controlled input
Kod:
HTTP/1.1 200 OK
Content-Type: application/json
{ "name" : "test<script>alert(1)</script>" }
[etc.]On its own, this is relatively harmless. The Content-Type implies that the payload will simply be interpreted as JSON by the browser. But consider what happens when you forward the request to the back-end. This response will appear within the body of a different response and effectively inherit its headers, including the content type.
Because caching occurs on the front-end, caches can also be tricked into serving these mixed responses to other users.
Topic Owner : @Dolyetyus HTTP Request Tünelleme
Son düzenleme:
