9

I found a markup processor that allows users to include arbitrary links, as long as they contain a "netloc" (// after the first :). Due to the myriad of exploitable protocol handlers, this is certainly a bad idea. But does it allow XSS on a system without vulnerable protocol handlers?

All browsers I tested (Chrome 22, FF 18, IE 9, Opera 12) do not show anything when pointed to javascript://alert('XSS'), but that could certainly just be because I'm not creative enough. Similarily, javascript://alert('XSS') (which would make the first double slashes a comment, and the alert a new line) doesn't work either.

Community
  • 1
phihag
  • 279
  • 2
  • 10
  • 1
    This isn't really an on-topic question - it falls well within the normal handling of URL's. – Rory Alsop Feb 05 '13 at 18:09
  • 2
    @RoryAlsop Sorry, I'm new to sec.sx. Could you elaborate why this question is off-topic? (and why you didn't close it as such?) Isn't this related to web app hardening, the first item in the list of topics? And how come dozens of quite similar questions about XSS details are still open? – phihag Feb 05 '13 at 18:12
  • It was flagged up as not really a question, and I tend to agree with the flag - it seems like normal behaviour for javascript URLs. – Rory Alsop Feb 05 '13 at 18:22
  • 1
    @phihag - Your question is whether a commented out part of a JavaScript code can be executed by browsers, and then answer your very own question within the same minute that they don't if it's contained in the same line that was commented out. Of course, the JavaScript command that was moved to a new line that isn't commented out will be processed. It doesn't matter if the new line identifier was written using escape characters, which is rather obvious, isn't it? Being part of a HTML document, it is parsed by the browser, escape characters including. What's strange here? – TildalWave Feb 05 '13 at 18:24
  • 1
    @TidalWave Note that I answered within the same second, and I see nothing wrong with that. I should've asked you guys earlier; for me, it wasn't obvious at all. I just inserted a newline (or ) and didn't realize that although that does not work, simply urlencoding does. – phihag Feb 05 '13 at 18:37
  • 2
    Reopened - thanks for the discussion on the DMZ to help clarify. – Rory Alsop Feb 05 '13 at 18:42
  • @phihag - I do apologize for taking this long to reply, I didn't get the usual notification a comment was addressed at me, I guess due to the question being closed? OK, first of, I have nothing against you answering your own question, but I have to admit the time-stamps didn't help after I saw both the question and your answer contents. And secondly, I think the answer you provide is self-obvious; Anchor's href is URL parsed, that's why you'd also have to put in javascript: to notify the parser of its format. And why %0 would work and 
 (that is HTML encoded code) wouldn't. – TildalWave Feb 06 '13 at 01:44
  • @phihag - Web browsers thus rely on two different parsers (that are part of any HTTP library, including Indy, Python-urllib, JS-Kit, curl, Java, NMAP, Synapse, XML-RPC.net,... you name it), one being able to encode/decode URL contents, and the other parser is capable of encoding/decoding HTML contents. %0A is a URL encoded line feed LF escape character. When entered in the address bar directly, it will stop parsing the URL provided (left to right), as it should. javascript: however will mark it for the browser to process it as JS code, up until the end of quote terminated URL string. – TildalWave Feb 06 '13 at 02:02
  • @phihag - You see, you could play all you want with URL encoded characters, and it would still work. Even javascript://%0A%61%6C%65%72%74%28%27%4F%4B%27%29%3B would return an alert with 'OK' as the URL parser sees this code as valid JavaScript after URL decode. Writing your URLs this way shouldn't be considered as a possible security threat either, as they would be properly decoded through the URL parser before being evaluated. If your program doesn't see my last example as alert('OK'); then it's broken and could use a good URL library. – TildalWave Feb 06 '13 at 02:19

1 Answers1

9

Yes, it allows XSS. You can inject a newline after the // if you use the right trick. The // makes the line a comment, but the newline is (as whitespace) not allowed in a URL, htmlencoded or not. Simply urlencode it, like this:

<a href="javascript://%0Aalert('XSS');">XSS</a>
D.W.
  • 99,525
  • 33
  • 275
  • 596
phihag
  • 279
  • 2
  • 10