2

So I was put on an engagement over the last week and I found a potential XSS when using Burp's intruder/repeater. However, the strange thing that I noticed was that the response in Burp is different to when I request it in the browser (Firefox & Chrome - both with the security measures, such as XSS Protection, turned off). I also tried to "Request in Browser" through Burp, but to no avail.

At first I assumed it was a different UA, so I made sure that they were both the same (even tried removing it from Burp), and eventually I did this with all of the HTTP headers just to make sure there was no difference there.

With Burp I get the page back with a successful XSS payload in the source, in the browser I get a 404. Obviously as this is a work engagement I cannot provide specific details of the host/target.

My question is, why would burp give me a 200 response with the source code and the browser throw a 404 error?

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
  <head></head>
  <frameset>
    <frame src="http://host/injection_point_here">
      <script>alert(1);M</script><frame src=""></frame></frameset></html>

Thanks

Improve this question
5
  • Does your browser have any built in XSS protection turned off? See phillips321.co.uk/2012/03/01/…
    – Matthew
    Feb 19, 2016 at 15:15
  • Yes, I even tried the "Request in browser" feature in burp which still gives me a 404
    – DarkMantis
    Feb 19, 2016 at 15:20
  • 1
    That is weird. I've seen it the other way round, where Java SSL support was letting the side down...
    – Matthew
    Feb 19, 2016 at 15:22
  • 5
    Did you try to reproduce the request with eg curl? One difference I know of is that Burp tries non-URL encoded payloads, while browsers do URL encode, leading to different payloads (for example with PHP, you can see this with echo $_SERVER['REQUEST_URI'], which is not vulnerable with browsers, but which is flagged by Burp). There may be some odd check on the URI that produces the different results in your case.
    – tim
    Feb 19, 2016 at 16:10
  • I just tried that and figured out that I was being a dumbass. When I did that I saw that the page loaded fine, so I thought I'd test the internal frame to see what happened with that. The internal frame was throwing a 404 and full-screened the external page thus making me think that the entire page was 404d. Thanks guys!
    – DarkMantis
    Feb 22, 2016 at 11:43

1 Answer 1

Reset to default
1

Intercept the request using a browser and send that request to the comparer. Then take your original Burp repeater request and send it to the comparer. Compare the two. If nothing is different, then you must have something set that updates requests. I know there are options to automatically update content-length and things like that.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .