5

I've been searching for XSS vulnerabilities in a friend's website (blackbox) and in one of the pages he takes your input and puts it inside a js script, window.location="[INPUT]";
I couldn't break the quotes because they are being replaced with " and %22 stays %22, But I can put a \ at the end of my input and it escapes the original quote (window.location="[INPUT]\";) Which gives me an unterminated string but I can't influence any code after that so there's no XSS there, right? All I can basicly do is break the code and that's it

Edit:
--Some more info--

  1. <, >, & and " are being replaced with &lt;, &gt;, &amp;and &quot;
  2. the server checks if INPUT begins with http:// or https://

Things I've tried:

  1. Break the string with </script> => being replaced with &lt;/script&gt; (and fails)
  2. Tried to break it with URL Encoded </script> (%3C%2Fscript%3E) but it shows it as string (window.location = "http://test.com%3C%2Fscript%3E\";) and the error is still SyntaxError: unterminated string literal
3
  • 1
    window.location="javascript:alert(1)";
    – grc
    Oct 16, 2016 at 12:17
  • @grc Can't, it checks if the input starts with http:// or https:// Oct 16, 2016 at 12:25
  • Even if this should not be exploitable, open redirects can be a vulnerability - owasp.org/index.php/… Oct 16, 2016 at 23:05

1 Answer 1

5

This is not exploitable.

  • You cannot escape the string because quotes are encoded. (" -> &quot;)
  • You cannot escape the script tag context because angle brackets are encoded. (< -> &lt;)
  • You cannot create anything but http[s]:// URLs because the beginning of the string is checked. It does not matter what you append after the protocol part, you cannot turn this into a data: or javascript: URL afterwards.

There are other tricks you could try but they are implementation-specific. There is no evidence they would work in this case, so these are just a few examples to give you an idea:

  • Maybe the filter stops after a NULL byte? (e.g. http://%00"<>...)
  • Maybe for some reason unicode variants work? (e.g. U+FF02: )
  • Maybe other encoding schemes work? (e.g. \x22 instead of ")
  • etc.
0

You must log in to answer this question.

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