Scanning Ajax component for XSS entry pointsIntroductionThe continuous adoption of Web 2.0 architecture for web applications is instrumental in Ajax,Web services and Flash, emerging as key components. Ajax is a combination of technologiessuch as JavaScript with the XMLHttpRequest object, DOM and XML streams. Cross sitescripting (XSS) can make browsers vulnerable to critical information hijacking if exploited withmalicious intent. XSS is already categorized as persistent [1], non-persistent [1] and DOM-based[2]. Ajax code loaded in browser can have entry points to XSS and it is the job of the securityanalyst to identify these entry points. It is difficult to decisively conclude that possible entrypoints to an application can be exploited. One may need to do a trace or debug to measure therisk of these entry points. This paper introduces you to a quick way to identify XSS entry pointsin an application.Application scenarioAn AJAX-enabled application is hosted on a Web server, with the Ajax functions residing in .jsfiles (for example, prototype.js). These files get included when the HTML page is loaded in thebrowser. Target applications may have several functions in multiple .js files or libraries. An Ajaxfunction would have the following key elements residing in a single function call or multiplefunction calls depending on how the application has been designed.

• An XMLHttpRequest call to communicate to the backend application as shown in Figure1.0. The objective of this call is to fetch information by opening an asynchronous socketfrom the browser.• In another scenario, the XMLHttpRequest object and browser policy do not supportcross-domain or cross-site calls but such functionality is required. The application isdesigned a way that allows users to provide RSS addresses to fetch news, blogs, videos.At the same time, the application uses third-party Web Services or Open APIs to gainaccess to information. All this information cannot be accessed from the browser. As asolution, a cross-site proxy is opened up on the server side. (Figure 1.0)• In yet another scenario, JavaScript can manipulate the DOM on-the-fly once a response isreceived by XMLHttpRequest or it can eval() certain parts of the information based onthe streams being received. (Figure 1.0)

Possible XSS entry points

An Ajax function that fetches information from the backend may either use the DOM or have asmall JavaScript routine to update the browser. This update process can have a possible XSSentry point. The chances of exposing the browser to a potential XSS attack are compounded iffor example, document.write() can be used to initiate a DOM-based XSS [2] attack or theroutine calls eval() to inject certain values to already defined variables. (Figure 1).

Scanning Ajax for XSS entry points

Shreeraj Shah shreeraj@net-square.com

The Ajax routine that calls a cross-site proxy and fetches information from untrusted sources ishighly vulnerable to an XSS attack. A user who uses an Ajax function to configure an RSS feedor uses Web Services APIs to fetch information without properly filtering the stream thatoriginates from the proxy, is opening up the framework to the possibility of a successful XSSattack. Recommended measures include scanning the routine for XSS entry points andperforming logic analysis prior to deploying the application on a production system.

Figure 1.0 – Possible XSS entry points

Scanning XSS entry points

The objective here is to scan the target page or functionality for possible Ajax entry points. To doso one must perform the following tasks:• Scanning the target page and collecting all dependent JavaScript (.js) files. Thesedependencies are a part of the <script> tag with “src”• Fetching and scanning each of these JavaScript files from the server to identify functions.• Looking for Ajax or XMLHttpRequest calls in each of these functions – of primaryinterest for security professionals.• Grabbing certain regex patterns to help us identify potential XSS entry points.

This defines the scope and identifies high-value Ajax routines. With this information in place wecan move to the next analysis phase. Exhibit 1 is a simple ruby script to achieve this. Runningthe script against a target such ashttp://example.com/custom.aspxprovides the following output.Scanning Ajax for XSS entry points

Shreeraj Shah shreeraj@net-square.com

The “process.js” file that is fetched from the server contains two Ajax-based functions and usesan instance of the XMLHttpRequest object. Grab the two functions named “getnews” and“showblog”. These functions may be fetching RSS feeds or APIs via cross-site proxy. Lines 31and 69 are possible XSS entry points. One needs to analyze the script between lines 5 and 31 tocheck the eval call and how the “story” variable is constructed. At the same time the linesbetween 43 and 69 contain code to create the “blogdetail” variable that also needs to beanalyzed. Assuming the stream originates from an untrusted source and the variables areconstructed using this unsanitized content, it is possible to inject malicious content. This contentmay get executed in the browser and can lead to an XSS attack.

Analyzing XSS entry points

Analysis of XSS entry points can be done using the following two methods.

1. Debugging the JavaScript code – a JavaScript debugger such as Firebug or Venkman canbe used. The complete explanation is available in the article titled “Hacking Web 2.0Applications with Firefox” [3]2. Tracing the call – Another way of analyzing xss entry points is to trace or reverse tracethe JavaScript call to its source and in the process determine the possibility of XSSexploitation. The process is explained in the article titled “Detecting Web ApplicationSecurity Vulnerabilities” [4]

The preceding process is difficult to automate completely because human intelligence is neededto analyze the call thoroughly. Developers have plenty of ways available for implementation. ToD:\scanajax> scanajax http://ajax.example.com/custom.aspx

analyze each in automated fashion is a bit tricky. However, tools can be of help in reverseengineering via tracing or debugging.Conclusion

Determining Ajax calls in Web 2.0 applications is important for tracking some of thevulnerabilities. The approach explained in this article can be taken as a starting point. Othermethods can be followed to measure browser-side security for end clients. We are witnessing anincreasing number of browser-side attacks in the form of worms and viruses. It is important toidentify entry points and perform a thorough analysis for better threat modeling for nextgeneration web applications.References: