Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question
Without knowing the answer off-hand, I'd say: Build a test system in a VM, load it with some older browsers, write a sample page, and try it out. You can even do this at home with a relatively modern computer, VirtualBox, and your preferred flavor of Linux or even an un-activated copy of Windows. – Iszi Feb 21 '12 at 18:09
I see that this question was asked long back. But, this error is happening in chrome 35 currently. So, is there a solution where you need not unescape everything before insertion as unescaping would make the actual href 404 while navigating. – theshadowmonkey Apr 2 '14 at 18:40
up vote 3 down vote accepted

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.

share|improve this answer
I think the second example wouldn't work in the OP's situation since they are encoding the input. Besides which, if they could remove the quotes, then they could add any number of tags, quotes, etc. to create valid HTML. – logicalscope Feb 21 '12 at 18:49
+1, small correction: not some browsers, all browsers will execute that, it is the standard. Second example could even be <a href=blah onclick=alert(8007)>Click me</a> (attacker inserted "blah onclick=alert(8007)"), even without the script tags, standard HTML encoding would not help here. – AviD Feb 21 '12 at 18:52
@AviD, great points. I've updated my answer to reflect your better attack and your correction. Thank you! – D.W. Feb 21 '12 at 19:03
@D.W., thanks, and I would another +1 for ESAPI mention. In particular, it should be noted that in this case you dont want HtmlEncoding - you would need to encode specifically for Html attributes (.encodeForHtmlAttribute() in ESAPI lingo). – AviD Feb 21 '12 at 19:26
Thank you for your response, it nailed it down pretty well. Yes, the one part forgotten in this case is the encoding. And a few extra checks would hurt either. – Brettski Feb 21 '12 at 19:55

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.