Will JavaScript be executed which is in an HREF?

Question

I located an issue with a site where I can insert a script tag into the href of an anchor tag:

<a href="<script>alert(8007)</script>">Click Me</a>

What I am trying to determine is, what is the chance that a browser, even an older one would execute this JavaScript located withing the HREF?

I understand that this value needs to be encoded before being written to the page, etc. This question is strictly around the threat level of the statement above and the chance a browser will execute the JavaScript while creating the page.

I am finding more difficult to test xss vulnerabilities now that browsers are doing a better job of detecting and protecting against them.

Answer 1

I do not know of any browser that will execute Javascript for the particular example you mention. I consider it highly unlikely that any browser will execute Javascript in this situation. This is not related to newer protections in modern browsers.

However, I suspect you are still vulnerable. If an attacker can insert markup into an href attribute, it probably means they can insert anything they want. And if an attacker can insert anything they want, then bad things happen. For instance, the attacker can make it look like this:

<a href="javascript:alert(8007)">Click me</a>

And that is bad news, because browsers will execute Javascript in that situation. So this is a way that an attacker could try to exploit the XSS vulnerability.

Also, if there are no quotes around the value of the href parameter, there will be other ways to attack your system. For example, <a href=blah onclick=alert(8007)>Click me</a> is bad news and will execute Javascript. (Thanks to @AviD for pointing this out.) Even if there are quotes around the value of the href parameter, if the attacker completely controls the value placed in there, the attacker may be able to supply his own quotes to break out of the attribute and then cause trouble, like this: <a href="blah" onclick=alert(8007) ignoreme="blah">Click me</a>. (Here the attacker inserted the value blah" onclick=alert(8007) ignoreme="blah.) There are likely more examples like this.

The bottom line. I definitely recommend you fix the XSS vulnerability. I suspect you are at risk. Bad guys have developed a large number of surprising and clever ways of exploiting XSS vulnerabilities which you can't be expected to know about; as a result, if you have a XSS vulnerability, your best bet is to fix it preemptively and not take any chances.

Fixing the flaw. To fix the flaw, I recommend that you use a combination of validation and output escaping. First, ensure the URL's protocol handler is one of a whitelisted set (e.g., http, https, ftp, mailto). Then, apply HTML escaping to escape all angle brackets, quotes, and ampersands before inserting the URL into the markup, and make sure the attribute value is surrounded by quotes.

The exact way of implementing this fix is language-dependent, but you can find a lot of information on the web about how to avoid XSS flaws in this situation. For instance, after ensuring the dynamic value contains a safe protocol, in PHP you could use htmlspecialchars(., ENT_QUOTES) to escape angle brackets, quotes, and ampersands. Or you could use OWASP ESAPI, which provides support for exactly this situation.

To learn more, I can recommend a good introduction for web developers. This is just an introduction and you will need to read more, but it will help you be aware of the threats at a high level. OWASP has some good resources on defending against XSS; for instance, they have a useful cheatsheet for how to use OWASP ESPI to avoid XSS vulnerabilities.