Opened 10 years ago

Closed 10 years ago

Last modified 7 years ago

#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: ?


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



<title>Bad Request</title>


<h1>Bad Request</h1>
<p>Invalid HTTP Version 'Invalid HTTP Version: <script>alert(1)</script> HTTP/1.0'</p>



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 Maxim Dounin, 10 years ago

Resolution: invalid
Status: newclosed

The response provided is not something returned by nginx, likely it's a backend response.

comment:2 by Maxim Dounin, 7 years ago

sensitive: 10
Note: See TracTickets for help on using tickets.