2

I am able to get reflected XSS through burp repeater using a GET request. I then click on show response in browser and I am able to get an XSS alert. But when I manually go to the URL in my browser the payload is not executed!

When I was using payloads like this in my Burp reapeater I was able to get an alert:

"><html><body><script>alert("1")</script></body></html>

But when I go to same URL, like

https://example.com/exp="><html><body><script>alert("1")</script></body></html>`

it gets encoded into

https%3A%2F%2Fexample.com%2Fexp%3D%22%3E%3Chtml%3E%3Cbody%3E%3Cscript%3Ealert%28%221%22%29%3C%2Fscript%3E%3C%2Fbody%3E%3C%2Fhtml%3E

in the burp interceptor and the XSS doesn't execute. Any workaround for this?

|improve this question
  • Is the last quoted URL directly copy-pasted from the reply you get? Including the encoding of https://example.com/ (so not just the parameters)? – tim Feb 9 '18 at 19:57
  • Yes @tim This is what I get when I request from the browser and then intercept the request by burp. – Humble Feb 10 '18 at 5:48
  • I mean the the payload is getting encoded in burp . for example request in browser and intercept with browser; you will get to see a GET request from exp=%22%3E%3Chtml%3E%3Cbody%3E%3Cscript%3Ealert(%221%22)%3C/script%3E%3C/body%3E%3C/html%3E – Humble Feb 10 '18 at 5:51
  • The browser does the encoding. All browsers have protections against XSS-type syntax entered into the URL bar. – Jonah Benton Feb 10 '18 at 22:36
  • Related, if not a duplicate: security.stackexchange.com/questions/170626/… – Anders Feb 12 '18 at 11:58
1

There's two things potentially going on here:

1) URL encoding - Most browsers encode any special characters in the URL before it is transmitted. Internet Explorer does not URL encode characters in the query string. However, in your example the payload is in the path. As far as I'm aware all modern browsers will URL encoded that, so it is non exploitable.

2) Browser XSS filter - Most moderns browsers (but not Firefox) have XSS filters that try to block reflected XSS. The filters are not watertight, and many pen testers disable them during testing. I recommend that you first reproduce XSS with the browser filter disabled, before attempting to use a filter bypass.

|improve this answer
1

Came across similar scenario today. Upon debugging I found that vulnerable web page was reflecting exact URL path onto the web page which was making it vulnerable to reflected XSS. Modern web browsers do encode URL path every time and the GET variable does get decoded on the server. But in this case, the server side script isn't reflecting any specific GET variable but the whole URL path. For example following should be vulnerable PHP code in that case.

<?php echo $_SERVER['REQUEST_URI']; ?>

Here the $_SERVER variable doesn't care if the input it is getting is either URL decoded or encoded, it will just reflect as it is. So since modern browsers encode URL by default so it will be almost impossible to exploit it. If you find this XSS while doing Penetration Testing for your client, you should mention this in the report but with a low CVSS score.

AFAIK, this XSS has nothing to do with XSS filter as answered above by PortSwigger.

|improve this answer

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.