2

I've encountered a strange behavior while I was performing a security audit of a web application. Some user controlled inputs were displaying their values, unencoded, into the page that processed the request. After testing a few characters to see if they were encoded/removed, I went for the classic <script>alert(1);</script> in order to provide a sample "attack" vector. The alert was displayed while I tested it on my computer - Debian/CentOS/Windows 8.1 - (on both Chrome and Firefox), but it just wouldn't work on another computer - Windows 7 - neither on Chrome, nor on Firefox or Internet Explorer. The code was still unencoded in the page source, but the alert never popped up. I ran various JavaScript code and it worked (assigning a variable, redirect etc.). I made sure no add-ons were interfering with what I was doing. What could possibly cause this?

Improve this question
3
  • 1
    You're probably hitting the anti-XSS filters that modern browsers have. But you can probably get past them with a bit of tweaking! sites.google.com/site/xssvulnerabilities/…
    – paj28
    Sep 17, 2014 at 8:12
  • I thought about this, but it wouldn't make sense in this case. I used the same browsers. The page was different (redirect to the page that processed the code) so the Chrome XSS auditor wasn't able to get it. Other JavaScript code (besides alert) was executed.
    – RC004
    Sep 17, 2014 at 8:23
  • only other things I can think is anti-virus, or a malware filtering proxy. My next step would be to try a third computer, to try and determine if it's something weird about your computer, or about the Windows 7 computer.
    – paj28
    Sep 17, 2014 at 8:56

1 Answer 1

Reset to default
1

I'd be tempted to put a proxy between the server and the client and compare the output of the request byte for byte. That should rule out server differences due to browser headers in the request etc. and will narrow it down to local differences. You could then also capture the output in the proxy and load it into each of the browsers on each machine (as a replay of the response, not just loaded as a file i.e. trap the send/response and replace the response) and see the results - this would rule out network filtering between local reception of the responses and passing to the browser for rendering. You'll then know where in the chain the difference might be.

Improve this answer

You must log in to answer this question.

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