Hacking Web 2.

0 JavaScript - Reverse Engineering,

Discovery and Revelations

Abstract
Traditionally a large number of applications were carried out without the intervention of global
networks like the Internet. But now, as the Web 2.0 era is emerging at an increasingly fast rate today
and is here to stay, these applications are becoming increasingly dependent on the internet as a
foundation platform. As the application domain increases worldwide, the variety in the kind of web
content also increases and rises above mere traditional HTML. The kind of enhancements brought
about in HTML pages, as viewed by a client, are introduced by technologies such as JavaScript, Flash
and Silverlight. Since, these applications are widely growing and becoming crucial, here the intention
is to throw light on the methods to look for security loopholes such as XSS (Cross-Site Scripting) in
JavaScript, specific to the Web 2.0 implementations of the same which consume information from
the un-trusted sources. The methods described pertain to static as well as dynamic analysis. Tools
that have been employed in this paper are

– Static Code Analysis of JavaScript by AppCodeScan ( http://

blueinfy.com/appcodeaudit.html)
– Dynamic Debugging and Analysis by using firebug with DOM context
(http://getfirebug.com/).

Rishita Anubhai ([email protected])

1 Abstract | Blueinfy Solutions Pvt. Ltd.

Problem Domain
JavaScript as we know is a client side technology that uses scripting on the client side to process
certain elements of the HTML page while it is rendered on the browser with DOM context – the
client. In such a case,

– All the client side code files are available for the users to inspect and look out for validation
loopholes and any other business logic residing.
– The malicious attackers have a chance to inject client side code snippets in their own favour,
since the <script> tags are permissible in HTML pages with the coming of JavaScript.
– With reference to the Web 2.0 applications, JavaScript contains a lot of information and
business logic in specific. This logic can be reverse engineered by an attacker.
– Web 2.0 applications are using the Document Object Model (DOM) extensively. As a result, it
becomes easier for an attacker to exploit weakly implemented DOM calls across client side
logic. For example, eval() on an un-trusted stream.
– XMLHttpRequests (XHR) Object also makes hidden calls at the back-end. These calls can be
discovered and exploited by any attacker. We have seen popular applications like Twitter or
Facebook that were compromised by exploiting XHR calls in this manner.

Of the many web security attacks that can be used as a result of this, the recent statistics show the
following for the distribution with regard to the type of attacks:
(http://projects.webappsec.org/Web-Application-Security-Statistics)

Percent of vulnerabilities out of total number of vulnerabilities

The criticality of XSS

Since the one of the easiest exploitations of JavaScript occurs via the XSS attack it has been taken up
as the focus hereafter. It is imperative to observe the trend as well; we are seeing rise of DOM based
XSS in Web 2.0 application context. The synoptic view for the same is as follows:

XSS: Cross-Site Scripting

XSS is basically a scenario where the ‘trust on the user, of the hosting webpage is exploited’. This
means that client-side code snippets will be injected into the places that the host of the page least
expects and will be used for maliciously.

The three major categories can be summarized as described on the next page but we will focus on
DOM based XSS during this particular paper:
2 Hacking JavaScript | Blueinfy Solutions Pvt. Ltd.
Type Fundamental Concept Example Scenario
Vulnerability Exploit
Reflected Any user input A script tag that A field which takes for input, a
(Non enabled field’s value includes JavaScript keyword for searching and
Persistent) is directly reflected code snippet can hence generates the result page with the
back into the be injected in this field. string ‘<keyword-here> search
response page Thus, when response is results:’. Here if along with the
without validation. generated the code keyword the user also adds:
gets executed. ‘<script>alert(“xss”);</script>’.
Using this category, Then when the field value is
URLs could be extracted and duplicated on the
malformed to pass response page, this script also
parameter values with becomes a part of the response and
such codes and used by gets auto-executed.
third party attackers
for vulnerable sites and
corresponding user
victims.
Stored The HTML links The malformed link Consider the following link on a
(Persistent) posted on message- being permanently page:
boards, blogs are stored on the server, <a href=http://xyz.com/home.ht
tailored in a manner whenever visited by m?name=3;<script>alert(“hi”);
that already any user will cause the </script>”>>
JavaScript code. code to get executed Thus, whenever clicked, the
These will be each time. unaware user visits the page
permanently stored No individual targets home.htm but also causes the code
on the server of this are required. to be executed which could extract
message-board or information and pass it on to the
blog site. attacker

DOM Here, the response page is not altered. The The document.location object
based Document-Object-Model aspects of the page could contain a string such as
are accessed and caused to behave http://xyz.com/home.ht
unexpectedly to each user based on the DOM m?default=<script>alert(documen
modifications that have been maliciously t.cookie); </script>.
caused. Various different calls like Since this might not expect a code
document.write or eval can be exploited. snippet it will render the entire
page here and the script too is
rendered and executed alongside.

3 Hacking JavaScript | Blueinfy Solutions Pvt. Ltd.

Diagrammatic Representation of the Scenario

Approach and Tools

The approaches to analyse the JavaScript loopholes as aforementioned can be categorized into two
distinct types:

Static Code Analysis

In this approach, we will be downloading all the JavaScript files along with the HTML source code of
the target page to be audited for such loopholes and analyse it without running it. This means
means, that
without execution n of the source and interference by supplying runtime data, we shall merely
examine the call-return
return hierarchy of the code and look for loopholes such as slack validation during
XHR Requests and others that will be proposed at a later point.

Since the code can be very lengthy to go over it manually the tool that will be used in the
demonstration is the AppCodeScan Tool, a tool put forth by Blueinfy for the purpose of tracking and
walking over functions via calls. This will be used for our purpose here by putting
putting the suspicious start
point in the ‘Trace’’ field to start with and then analysing the results.

The detailed demonstrations will be accompanied by screenshots now for a particular example.
example We
download the source page for the following page which has widgets.
widgets. Seeing the html page the
following is notable:

4 Hacking JavaScript | Blueinfy Solutions Pvt. Ltd.

 This triggers us to check get_rss_feed and lbFeeds

Therefore we trace the function ‘get_rss_feed’ & ‘lbFeeds’ in the .js files loaded from the page.

Now we know the file

rss_xml_parser.js is
our target focused

‘get_xml_file’ new to trace.

Thus now we walk for ‘get_xml_file’. The result in our target focus file gives:

5 Hacking JavaScript | Blueinfy Solutions Pvt. Ltd.

Seeing this, we take up our next target as ‘url’:

Proceeding, we focus on the object ‘httpreq’ now:

Now the variable ‘xmlfile’ seems interesting to check in this function:

In this result that has come out, our interesting target seems ‘processRSS’:

We move further to trace ‘response’ now:

There we are! Without any validation on the requested url and data, the response has been
obtained. This could be risky, which is demonstrated by the following screenshots in the sequence of
the events (next page):

6 Hacking JavaScript | Blueinfy Solutions Pvt. Ltd.

 When you hover over,
the status bar shows:

JavaScript:alert(“xss”)

Code for anything else could have

been hence injected

On click

Dynamic Code Debugging

As far as this approach goes, the looking up of entire code will be avoided. Instead we will be on the
lookout for areas in the rendered page which are popular for such vulnerabilities or look
incriminating anyway. Hereafter we will try the XSS injection and analyse the working of the internal
codes by inspecting them via a JavaScript debugger.

7 Hacking JavaScript | Blueinfy Solutions Pvt. Ltd.

The tool that would be convenient to use for this purpose as a debugger for JavaScript code would
be a Firefox extension called Firebug (http://getfirebug.com/).

In this, we can identify the area on the page then use the extension’s capacity to map the area to the
corresponding HTML block and thereafter set a breakpoint on the function being called. Once that is
done, working on the page will be followed up in the Firebug panel on the side by correspondingly
highlighted function call-returns. By setting successive breakpoints in this manner and analysing the
XHR requests being made and the validation used if any, along with runtime data supplying to HTML
elements such as forms, a dynamic analysis of the page with respect to XSS security can be done.

Once again, the detailed demonstration of a sample case will be accompanied by screenshots for a
particular case in the Dynamic Approach Detailing below.

In the firebug panel shown, we input the function-name: ‘get_rss_feed’ and the ‘Script’ area in the
left frame will get us to the function header. On clicking the area marked ‘Click here’ we can add a
breakpoint there.

Add the phrase to search

here: ‘get_rss_feed’

Click here: Adds a breakpoint

Now, as and when we click on the actual page anywhere the function is traced into by using the
‘play, step into, step over’ functions in the right hand top corner of the left frame in the firebug
panel.

Now as we select ‘Trade News’ from the dropdown list shown on the page (‘Trade News’ is where
the XSS exploit has been planted), as we saw in the HTML code earlier due to the event ‘onchange’
the function get_rss_feed is called and our breakpoint is encountered. Now on pressing ‘Step into’
the trace begins. The screenshot shown below is that when on the first pressing of ‘Step Into’ the
line 54 is highlighted to show current line of operation.

8 Hacking JavaScript | Blueinfy Solutions Pvt. Ltd.

We follow the trace to line 56 and then the call to get_xml_file is made and shown as follows in the
trace:

On tracing further we reach the following stage where line 31 is the operative line:

Now the page is loaded with the ‘Trade News’ widget too. Now on tracing the click on the
‘Interesting News Item’ the following appears:

And there we are once again! Starting from choosing the item to here, we have not validated against
such code snippets and therefore, this will be executed in the same manner as shown in the final
result in the ‘Static Code Analysis Section’.

9 Hacking JavaScript | Blueinfy Solutions Pvt. Ltd.

Conclusion

Methodologies and approach described in this paper can help in discovering vulnerabilities in
JavaScript driven Web 2.0 applications. The popular lookout areas apart from DOM based XSS are:

– Password comparisons in .js

– Business Logic Leaks in the client side: example: price
– Evals() used without appropriate validations
– All XHR requests without filters for ‘script’, ‘JavaScript’ tags and commands
– Injections by Unicode or escape sequences
– Direct reflection of the input from user forms
– Cookies not limited or localised to IPs and thus permitted cookie leakages
– Server side filters to avoid stored XSS
– Unescaped usage of < or > can permit tags more easily too
– Emails unescaped could increase the spamming disadvantages

10 Hacking JavaScript | Blueinfy Solutions Pvt. Ltd.