Unfortunately there was nothing interesting on the back-end to attempt to bypass the front-end security controls, or no sensitive information being passed from users to attempt to capture their requests. However, earlier a common reflected XSS was found:
Which in the source code looked like:
Which made me think, could we force other users to search for the reflected XSS, escalating it to site-wide, no user interaction XSS?
I crafted the following request to test the identified CL.TE vulnerability:
1
2
3
4
5
6
7
8
9
10
POST /redacted.aspx HTTP/1.1
Transfer-Encoding: chunked
Host: redacted.com
Content-Length: 21
X-Blah-Ignore: chunked
0
GET /404
Foo: x
This request works by taking advantage of discrepancies in HTTP specifications, which provides two different methods for specifying the length of HTTP messages:
The front-end server processes the Content-Length: header, which forwards the whole request.
The back-end uses Transfer-Encoding: chunked processing only the first chunk, which is set at 0 length, which in chunked encoding will terminate the request.
The remaining bytes GET /404 are left unprocessed, which the back-end will process these bytes as the start of the next request. GET /404 was chosen as it returns a 404, making it easier to identify if the vulnerability exists.
When sending the request twice, a 404 is returned for the second request, showing the GET /404 has successfully been processed within the next request.
This led onto launching a CL.TE smuggle attack with the following Turbo Intruder payload, including the XSS vulnerability:
and sure enough, the request was successfully smuggled, and one of the next requests received the poisoned XSS response:
XSS being smuggled
Later response poisoned with XSS
Although this programme accepted reflected XSS as is, this same approach could have been used to chain together XSS with CSRF or a CORS misconfiguration. If the attack kept being fired, nearly every user who visited the site would receive a poisoned response.