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

--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
  • 1
    window.location="javascript:alert(1)"; – grc Oct 16 '16 at 12:17
  • @grc Can't, it checks if the input starts with http:// or https:// – badprogrammerqq Oct 16 '16 at 12:25
  • Even if this should not be exploitable, open redirects can be a vulnerability - owasp.org/index.php/… – Dog eat cat world Oct 16 '16 at 23:05

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.

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.