鬼仔's Blog

来源：securityfocus

Introduction

AJAX and interactive web services form the backbone of “web 2.0”applications. This technological transformation brings about newchallenges for security professionals. This article looks at some of the methods, tools and tricks to dissectweb 2.0 applications (including Ajax) and discover security holes usingFirefox and its plugins. The key learning objectives of this articleare to understand the:

• web 2.0 application architecture and its security concerns.
• hacking challenges such as discovering hidden calls, crawling issues, and Ajax side logic discovery.
• discovery of XHR calls with the Firebug tool.
• simulation of browser event automation with the Chickenfoot plugin.
• debugging of applications from a security standpoint, using the Firebug debugger.
• methodical approach to vulnerability detection.

Web 2.0 application overview

The newly coined term “web 2.0”refers to the next generation of web applications that have logicallyevolved with the adoption of new technological vectors. XML-driven webservices that are running on SOAP, XML-RPC and REST are empoweringserver-side components. New applications offer powerful end-userinterfaces by utilizing Ajax and rich internet application (Flash)components.This technological shift has an impact on the overall architectureof web applications and the communication mechanism between client andserver. At the same time, this shift has opened up new securityconcerns [ref 1] and challenges.
New worms such as Yamanner, Samy and Spaceflash are exploiting “client-side” AJAX frameworks, providing new avenues of attack and compromising confidential information.

Figure 1. Web 2.0 architecture layout.

As shown in Figure 1, the browser processes on the left can be divided into the following layers:

• Presentation layer – HTML/CSS provides the overall appearance to the application in the browser window.
• Logic & Process– JavaScript running in the browser empowers applications to executebusiness and communication logic. AJAX-driven components reside in thislayer.
• Transport – XMLHttpRequest (XHR) [ref 2].This object empowers asynchronous communication capabilities and XMLexchange mechanism between client and server over HTTP(S).

The server-side components on the right of Figure 1 that typicallyreside in the corporate infrastructure behind a firewall may includedeployed web services along with traditional web application resources.An Ajax resource running on the browser can directly talk to XML-basedweb services and exchange information without refreshing the page. This entire communication is hidden from the end-user, in other words the end-user would not “feel” any redirects. The use of a “Refresh” and “Redirects”were an integral part of the first generation of web application logic.In the web 2.0 framework they are reduced substantially by implementingAjax.

Web 2.0 assessment challenges

In this asynchronousframework, the application does not have many “Refreshes” and“Redirects”. As a result, many interesting server-side resources thatcan be exploited by an attacker are hidden. The following are threeimportant challenges for security people trying to understand web 2.0applications:

• Discovering hidden calls – It is imperative that oneidentify XHR-driven calls generated by the loaded page in the browser.It uses JavaScript over HTTP(S) to make these calls to the backendservers.
• Crawling challenges – Traditional crawler applicationsfail on two key fronts: one, to replicate browser behavior and two, toidentify key server-side resources in the process. If a resource isaccessed by an XHR object via JavaScript, then it is more than likelythat the crawling application may not pick it up at all.
• Logic discovery – Web applications today are loadedwith JavaScript and it is difficult to isolate the logic for aparticular event. Each HTML page may load three or four JavaScriptresources from the server. Each of these files may have many functions,but the event may be using only a very small part of all these filesfor its execution logic.

We need to investigate and identify the methodology and tools toovercome these hurdles during a web application assessment. For thepurpose of this article, we will use Firefox as our browser and try toleverage some of its plugins to combat the above challenges.

Discovering hidden calls

Web 2.0 applications may load asingle page from the server but may make several XHR object calls whenconstructing the final page. These calls may pull content or JavaScriptfrom the server asynchronously. In such a scenario, the challenge is todetermine all XHR calls and resources pulled from the server. This isinformation that could help in identifying all possible resources andassociated vulnerabilities. Let’s start with a simple example.Suppose we can get today’s business news by visiting a simple news portal located at:
http://example.com/news.aspx
The page in the browser would resemble the screenshot illustrated below in Figure 2.

Figure 2. A simple news portal page.

Being a web 2.0 application, Ajax calls are made to the server usingan XHR object. We can determine these calls by using a tool known as Firebug [ref 3]. Firebug is a plug-in to the Firefox browser and has the ability to identify XHR object calls.
Prior to browsing a page with the plugin, ensure the option to intercept XHR calls is selected, as shown in Figure 3.

Figure 3. Setting Firebug to intercept XMLHttpRequest calls.

With the Firebug option to intercept XMLHttpRequest calls enabled, webrowse the same page to discover all XHR object calls made by thisparticular page to the server. This exchange is shown in Figure 4.

Figure 4. Capturing Ajax calls.

We can see several requests made by the browser using XHR. It has loaded the dojo AJAX framework from the server while simultaneously making a call to a resource on the server to fetch news articles.
http://example.com/ getnews.aspx?date=09262006
If we closely look at the code, we can see following function in JavaScript:

function getNews()
{
var http;
http = new XMLHttpRequest();
http.open("GET", " getnews.aspx?date=09262006", true);
http.onreadystatechange = function()
{
if (http.readyState == 4) {
var response = http.responseText;
document.getElementById('result').innerHTML = response;
}
}
http.send(null);
}

The preceding code makes an asynchronous call to the backend web server and asks for the resource getnews.aspx?date=09262006.The content of this page is placed at the ‘result’ id location in theresulting HTML page. This is clearly an Ajax call using the XHR object.
By analyzing the application in this format, we can identify vulnerable internal URLs, querystringsand POST requests as well. For example, again using the above case, theparameter “date” is vulnerable to an SQL injection attack.
continued

[“] Ajax security, http://www.securityfocus.com/infocus/1868
[“] XHR Object specification, http://www.w3.org/TR/XMLHttpRequest/
[“] Firebug download, https://addons.mozilla.org/firefox/1843/; Firebug usage, http://www.joehewitt.com/software/firebug/docs.php

Crawling challenges and browser simulation

An important reconnaissance tool when performing web applicationassessment is a web crawler. A web crawler crawls every single page andcollects all HREFs (links). But what if these HREFs point to aJavaScript function that makes Ajax calls using the XHR object? The webcrawler may miss this information altogether. In many cases it becomes very difficult to simulate this environment. For example, here is a set of simple links:

<a href="#" onclick="getMe(); return false;">go1</a><br>

<a href="/hi.html">go2</a><br>

<a href="#" onclick="getMe(); return false;">go3</a><br>

The “go1” link when clicked will execute the getMe() function. The codefor getMe() function is as shown below. Note that this function may beimplemented in a completely separate file.

function getMe()
{
var http;
http = new XMLHttpRequest();
http.open("GET", "hi.html", true);
http.onreadystatechange = function()
{
if (http.readyState == 4) {
var response = http.responseText;
document.getElementById('result').innerHTML = response;
}
}
http.send(null);
}

The preceding code makes a simple Ajax call to the hi.html resource on the server.
Is it possible to simulate this click using automation? Yes! Here is one approach using the Firefox plug-in Chickenfoot [ref 4] that provides JavaScript-based APIs and extends the programmable interface to the browser.
By using the Chickenfoot plugin, you can write simpleJavaScript to automate browser behavior. With this methodology, simpletasks such as crawling web pages can be automated with ease. Forexample, the following simple script will “click” all anchors with onClick events. The advantage of this plug-in over traditional web crawlers is distinct: each of these onClickevents makes backend XHR-based AJAX calls which may be missed bycrawlers because crawlers try to parse JavaScript and collect possiblelinks but cannot replace actual onClick events.

l=find('link')
for(i=0;i<l.count;i++){
a = document.links;
test = a.onclick;
if(!(test== null)){
var e = document.createEvent('MouseEvents');
e.initMouseEvent('click',true,true,document.defaultView,1,0,0,0,
0,false,false,false,false,0,null);
a.dispatchEvent(e);
}
}

You can load this script in the [i]Chickenfoot console and run it as shown in Figure 5.

Figure 5. Simulating onClick AJAX call with chickenfoot.

This way, one can create JavaScript and assess AJAX-based applicationsfrom within the Firefox browser. There are several API calls [ref 5] that can be used in the chickenfoot plugin. A useful one is the “fetch” command to build a crawling utility.

Logic discovery & dissecting applications

To dissect client-side Ajax-based applications, one needs to go througheach of the events very carefully in order to determine process logic.One way of determining the entire logic is to walk through each line ofcode. Often, each of these event calls process just a few functionsfrom specific files only. Hence, one needs to use a technique to stepthrough the relevant code that gets executed in a browser. There are a few powerful debuggers for JavaScript that can be used to achieve the above objective. Firebug is one of them. Another one is venkman [ref 6]. We shall use Firebug again in our example.
Let’s take a simple example of a login process. The login.htmlpage accepts a username and password from the end-user, as shown inFigure 6. Use the “inspect” feature of Firebug to determine theproperty of the form.

Figure 6. Form property inspection with Firebug.

After inspecting the form property, it is clear that a call is madeto the “auth” function. We can now go to the debugger feature ofFirebug as illustrated in Figure 7 and isolate internal logic for aparticular event.

Figure 7. Debugging with Firebug.

All JavaScript dependencies of this particular page can be viewed. Calls are made to the ajaxlib.js and validation.jsscripts. These two scripts must have several functions. It can bededuced that the login process utilizes some of these functions. We canuse a “breakpoint” to step through the entire application. Once abreakpoint is set, we can input credential information, click the“Submit” button and control the execution process. In our example, wehave set a breakpoint in the “auth” function as shown in Figure 8.

Figure 8. Setting a breakpoint and controlling execution process.

We now step through the debugging process by clicking the “step in”button, which was highlighted in Figure 8. JavaScript execution movesto another function, userval, residing in the file validation.js as shown in Figure 9.

Figure 9. Moving to validation.js script page.

The preceding screenshot shows the regular expression pattern used tovalidate the username field. Once validation is done execution moves toanother function callGetMethod as shown in Figure 10.

Figure 10. Making an Ajax call.

Finally, at the end of the execution sequence, we can observe the callto backend web services as being made by the XHR object. This is shownin Figure 11.

Figure 11. Web services call on the Firebug console.

Here we have identified the resource location for the backend web services:
http://example.com/2/auth/ws/login.asmx/getSecurityToken?username=amish&password=amish
The preceding resource is clearly some web services runningunder the .NET framework. This entire dissection process has thrown upan interesting detail: we’ve found a user validation routine that canbe bypassed very easily. It is a potential security threat to the webapplication.
Taking our assessment further, we can now access the web service andits endpoints by using a WSDL file and directly bruteforce the service.We can launch several different injection attacks – SQL or XPATH – withtools such as wsChess [ref 7].
In this particular case, the application is vulnerable to an XPATHinjection. The methodology for web services assessment overall isdifferent and is outside the scope of this article. However thiswalkthrough technique helps identify several client-side attacks suchas XSS, DOM manipulation attacks, client-side security controlbypassing, malicious Ajax code execution, and so on.

Conclusion

Service-oriented architecture (SOA), Ajax, Rich Internet Applications(RIA) and web services are critical components to next generation webapplications. To keep pace with these technologies and combatnext-generation application security challenges, one needs to designand develop different methodologies and tools. One of the efficientmethodologies of assessing applications is by effectively using abrowser. In this article we have seen three techniques to assess web 2.0applications. By using these methodologies it is possible to identifyand isolate several Ajax-related vulnerabilities. Browser automationscripting can assist us in web asset profiling and discovery, that inturn can help in identifying vulnerable server-side resources.
Next generation applications use JavaScript extensively. Smoothdebugging tools are our knights in shining armor. The overalltechniques covered in this article is a good starting point for web 2.0assessments using Firefox.

References

[“] Ajax security,http://www.securityfocus.com/infocus/1868
[“] XHR Object specification, http://www.w3.org/TR/XMLHttpRequest/
[“] Firebug download, https://addons.mozilla.org/firefox/1843/; Firebug usage, http://www.joehewitt.com/software/firebug/docs.php
[“] Chickenfoot quick start, http://groups.csail.mit.edu/uid/chickenfoot/quickstart.html
[“] Chickenfoot API reference – http://groups.csail.mit.edu/uid/chickenfoot/api.html
[“] Venkman walkthrough, http://www.mozilla.org/projects/venkman/venkman-walkthrough.html
[“] wsChess, http://net-square.com/wschess

About the author

Shreeraj Shah, BE, MSCS, MBA, is the founderof Net Square and leads Net Square’s consulting, training and R&Dactivities. He previously worked with Foundstone, Chase Manhattan Bankand IBM. He is also the author of Hacking Web Services (Thomson) and co-author of Web Hacking: Attacks and Defense(Addison-Wesley). In addition, he has published several advisories,tools, and whitepapers, and has presented at numerous conferencesincluding RSA, AusCERT, InfosecWorld (Misti), HackInTheBox, Blackhat,OSCON, Bellua, Syscan, etc. You can read his blog at http://shreeraj.blogspot.com/.