ADC Papers

Web Fraud Detection

Protecting Web Applications and End Users from JavaScript Hijacking and CSRF Attacks

Table of Contents Abstract Introduction References		By Guy Karlebach, ADC Expert and Amichai Shulman, CTO & Co-founder
		Download printer-friendly PDF format: WebFraudDetection.PDF (135 KB)

Abstract

Recent years have seen a proliferation of online fraud schemes. According to the IC3 report1, the total loss from all cases of internet fraud in 2006 was 198.44 million USD, compared to 183.12 million USD in 2005.  Besides the direct loss of funds that results from such crimes, the damage to business reputation and to client trust inflicts severe financial losses.

Cross Site Request Forgery, or CSRF, is one way to commit Web fraud, since it generates a client request to the server without the knowledge of the client.  The detection of this type of attack is tricky since malicious requests are very similar to legitimate ones.  Experts predict that CSRF will have a significant impact on future Web security.

JavaScript Hijacking is a vulnerability that was recently identified in Web applications which use JSON as a communication format2.  It enables attackers to generate malicious requests and steal data that is delivered via the response.  Similar to CSRF, it is hard to distinguish legal requests from JavaScript Hijacking attack vectors.  This form of vulnerability has been detected in the most popular AJAX frameworks, making it a very significant threat to Web 2.0 technologies.

So far, prevention of CSRF and JavaScript Hijacking involved rewriting application code and adding validation mechanisms to legal requests.  We are going to discuss more efficient and effective techniques that can be implemented using a Web Application Firewall.  In addition, we describe an attack scenario in which the attacker attempts to engage in an online fraud attack against a Web site that is enhanced with Web 2.0 technologies.  The attack makes use of the two attack techniques discussed above.  Using this example, we illustrate how Web fraud due to JavaScript Hijacking and CSRF can be identified and prevented.

Defeating JavaScript Hijacking Attacks JavaScript Hijacking – Introduction

JavaScript Hijacking attacks target Web applications that generate data formatted as JavaScript or JavaScript Object Notation (JSON).3  JavaScript Hijacking attacks depend on a property of the HTML <script> tag.  This tag generates an inter-domain HTTP GET request if the src attribute is used to reference a JavaScript source in a different domain.  While most HTML content is inherently protected from access by hostile code through the Same Domain access policy of the browser, the contents of a script are inherently not. In fact, any global object defined by the embedded script are accessible to code in the calling page.  The difference between a JavaScript Hijacking attack and a legal request for a script resource is subtle.  Consider for example the following scenario:

• A Web user logs into a site called www.superveda-stockquotes.com, which offers a stock portfolio evaluation utility.
• The site sends to the user’s browser JavaScript code that evaluates the potential of a given stock portfolio.
• The site uses a <script> tag in order to import into the user’s browser information about his stock portfolio.  This information belongs to the client’s bank site, which resides in a different domain.

In this case, there is no illegal access to the client’s personal information, since all the data goes through the client’s browser.  However, suppose that the Web site www.superveda-stockquotes.com is a malicious site. This site could use JavaScript code to send the client’s real stock portfolio to the site, thus stealing sensitive information.  The latter case is explained in more detail in the next section.

JavaScript Hijacking Attack Prevention - Attack Scenario

The following section describes a scenario in which an attacker attempts to steal sensitive financial information, in this case credit card numbers, through a JavaScript Hijacking attack.  The fraud proceeds in the following steps:

• An attacker picks her target site.  In this example we will refer to this site as www.superveda-bank.com.  The attacker chooses this site for a reason:  superveda-bank.com Web site relies on AJAX to transfer data between the client and the server.  In particular, the URL www.superveda-bank.com/accounts/get_account_details, when queried by an XMLHttpRequest object that runs at the client side, responds with JavaScript code that contains credit card information.  The JavaScript array contains a call to a client side function named display_cc, a function whose execution displays a credit card number on the customer’s browser.  The XMLHttpRequest object then evaluates the response and clients are presented with their credit card details.  It is also important to mention that HTTP GET requests are answered only if they carry a valid session cookie.
• The attacker creates a Web page that contains a <script> element.  The element’s src attribute points to the URL www.superveda-bank.com/accounts/get_account_details. In addition, the attacker creates her own display_cc function on that page. The new function uses the XMLHttpRequest object to send the credit card details to the attacker.
• The next phase in this scheme is to lure Web users to visit the attacker’s Web page.  She can select one of the many social engineering tricks in her repertoire.  Let’s assume that she uses banners through an advertising server.
• Many users have a single multi-tabbed browser open on their desktop where one tab is used for access to their bank account while other tabs are used to access different server, including those that show advertisements (which eventually contain a link to the attacker’s site).
• When a Web user follows the attacker’s link, his browser automatically generates a GET request directed at www.superveda-bank.com/accounts/get_account_details. Since the user is logged into his account, his browser also sends his session cookie to the bank’s site.
• At the end of the day, the attacker has gathered the credit card numbers of many of legitimate bank’s clients.

Several application security research firms have published techniques to help mitigate JavaScript Hijacking through application code changes. In particular code should be inserted into applications to generate a random session nonce that must be included in all sensitive links and verified by the application upon receipt of a request. Although all of these mitigation techniques are still relatively new, they will be referred to as the traditional approach.  The traditional approach, though theoretically applicable, encounters many difficulties when attempted in practice.  First, large software development projects usually include third party modules or development frameworks.  Clearly, reviewing third party code and making the necessary changes is not always feasible.  Even if vulnerabilities can be detected and the corrective changes applied, such a process defeats the purpose of using third party application code in the first place.  A second reason for the impracticality of this approach is that changing the code of deployed applications without hindering ongoing functionality is a very difficult if not an impossible undertaking.  In addition, a recent study has found that disclosure of software vulnerabilities hurts the stock of the disclosing company.4  This implies that progressive fixing of vulnerabilities is not an option for software companies.  Rather, a global solution that monitors every part of the application should be implemented.  Finally, there are no fully automatic solutions for performing code review.  As a result, humans must always be involved in this process, and so the chance of human error is unavoidable—meaning that vulnerabilities may remain in the application even after it has been reviewed.  Moreover, incorporating secure code review by skilled security personnel into the software development lifecycle greatly increases the financial cost and development time5.  This is due to the high cost of hiring security experts to review large scale applications and to the fact that new vulnerabilities may be introduced when fixing known vulnerabilities.

An innovative approach

We begin by discussing several observations and then describe the implementation of an innovative prevention mechanism.  The most important observation regarding mitigation is perhaps that in JavaScript Hijacking, the victim is the one who sends the malicious request.  As a consequence, we cannot block his IP address, and we cannot block the user even if we can identify him by his credentials.  Another important characteristic of the malicious request is that it was generated by a link from an HTML <script> element.  This <script> tag points to a resource at a domain other than that of the fraud’s target.  An additional property of the request is that it must be part of a valid session (otherwise, the attack is useless).  Moreover, unless a “remember me” feature is active, a client must authenticate before being subjected to the attack.  Therefore, his requests must have a valid session cookie.  These observations are important for the qualification of malicious requests and the detection of the attacker’s Website.

• In order to derive more mitigation insights, we need to discuss some aspects of the HTTP protocol.  The HTTP specification determines that if a request is generated by a source that does not have its own URI then it MUST NOT contain a Referer header.  In addition, it strongly recommends that the user be able to choose whether the Referer header is used or not.  The latter functionality is often implemented by desktop protection software that consistently remove some HTTP headers in order to protect customer privacy.  While the Referer header cannot play a significant role in mitigating classic Web application attacks, it can be a helpful tool when dealing with attacks induced on a victim by a third party.  In this spirit, we will enforce the following policy regarding the Referer header in HTTP requests:

If a Referer header is present, then its domain will be compared to the domain of the protected site. If these two domains differ, the client will be alerted about the suspicious request.  The client will be given the option to disable further alerts that are triggered by requests from a friendly site.
If a Referer header is missing then one of the following holds:
The request is malicious.
The client disabled the header in order to be more discrete about where he browses.

• So, if the Referer header is missing we will alert the client, and give him the option to disable alerts that are triggered by a missing Referer.

One last observation regarding JavaScript Hijacking is that a successful attack requires that the response will contain JavaScript in the message body.  As we shall see, the Web Application Firewall can utilize this property in order to communicate with the client.
Presently we describe a prevention scheme that will be implemented in a Web Application Firewall.  This scheme is more practical than the traditional approach, and additionally can detect the fraud attempt and its origin.  In accordance with our “Superveda bank” example, we will assume that the bank’s site is protected by a Web Application Firewall.

Upon receiving a request, the Web Application Firewall will take the following steps:
Verify that the request belongs to a valid session.  If this is not the case, no further processing is required.

Compare the domain of the Referer header content to the domain of the bank’s Web site.  If they are the same, no further processing is required.

• If the requesting site is not the bank’s site, then an inter-domain request has occurred.  In this case, we would like to ask the client if he allows the requesting site to initiate a request to the protected site (Note that the request is made by the client’s browser.  The requesting site is not intended to receive the response).  The client’s consent is either received directly from the client, or taken from a previously set cookie. If consent is not given, then any JavaScript code execution that results from processing the response must be stopped.  If the client allows the request, however, then response processing must not be hindered. 
• In order to achieve the functionality that we described, the Web Application Firewall will prepend the following code to the server’s HTTP response:
  
  



This code will alert the client to the attack and allow him to block it.  Blocking will occur as follows:

• The client’s browser will eval the code that was sent by the Web Application Firewall
• The client will decline the request, which will set the variable r to false

The next statement that will be executed throws an exception, which cancels any further JavaScript code execution.

It is important to note in the code of figure 2 that the appended code does not invoke any functions which can be overridden by the attacker.

If the client decides that the request is not an attack, then a cookie will be set and he will not be queried in consequent requests.  The code can be extended to enable the client an ‘Ignore no Referer header’ option, in case the client prefers to be discrete about his browsing habits.  Another extension is allowing a ‘one time rejection’, i.e. rejecting a request without setting a cookie.

JavaScript Hijacking Fraud Detection

What we did not accomplish yet is identification of the fraud attempt.  We would like to allow the bank’s security administrator to identify that his site was the target of a fraud attack rather than an individual hacking attempt. There are two major approaches that can be taken in order to accomplish this: the centralized reporting approach and the localized reporting approach.  In centralized reporting, all reports about rejected HTTP requests are sent to a central reporting authority.  This authority makes decisions about fraud attempts and alerts Web Application Firewall clients when necessary.  In localized reporting, each Web Application Firewall gathers its own fraud detection data.  Sharing of this data is at the discretion of the security administrator of each site. 

The reporting authority should be able to decide whether a site is blocked automatically, that is, all requests from this site will be denied without consulting users.  In addition, it should be able to enter a semi-automatic blocking mode, in which users are warned about a request but are still given a decision about whether to block it or not.  Visual effects such as message color may come in handy in the implementation of the semi-automatic mode.

The decisions about automatic or semi-automatic blocking can be made by a software agent or according to human discretion.  In the case of an agent making the decisions, there are several risks that should be avoided, among which are:

• An attacker can open a user account at a Web Application Firewall protected site, and then fake decisions in order to affect the decisions of the reporting authority.  In order to avoid this sort of tampering, decisions must be made according to input from multiple different users.
• An attacker can use Web space in legal sites, or Web vulnerabilities in other sites, in order to affect the decisions of the reporting authority.  For example, sites that provide Web space upon simple registration, or sites that contain script injection vulnerabilities.  The attacker would lure users into a page that contains a CSRF attack in a legal site in order to provide the reporting authority with misleading data.   In order to prevent this, blocking should be performed per URL.  A whole domain will be blocked only after several URLs from the same domain were blocked.

The two reporting approaches differ in their implementations. Localized reporting can be implemented by modifying the appended JavaScript code to send the client’s choice to the local reporting authority.  This authority will reside within the domain of the protected site, and verify that client reports contain valid session cookies.  The code that the Web Application Firewall sent to the client can use AJAX to conduct a complex interaction with the local authority, such as receive data or provide client feedback. When a relevant security event is detected by the local authority, it will contact the security administrator of the protected site.

In the centralized reporting model, the Web Application Firewall will provide the client’s browser with a session token, so that the central reporting authority will recognize the authenticity of the report.  The browser will then contact the centralized authority with a cross domain request – and consequently will not be able to access the response.  This means that interaction between the browser and the centralized authority is limited.  When events of relevance are detected by the reporting authority, it will either contact the management unit of each Web Application Firewall, or contact security administrators directly.

Note that in both approaches each security administrator can configure the conditions that he sees fit for triggering a security alert.  If the localized approach is implemented, the security administrator will be responsible to contact his fellows at other organizations, and take action to bring down the malicious site.

Centralized reporting may be more accurate and faster than localized reporting, providing that a smart analysis algorithm is used.  The downsides of this approach are that it requires information sharing and an additional authentication mechanism.  For example, Superveda bank may not like the idea that a mass of its clients report to a central authority about a fraud attempt.  In contrast, localized reporting is easier to implement, technically and legally, but the reporting authority has less data at its disposal.

CSRF

CSRF – Introduction

CSRF has been referred to as the Web’s “sleeping giant”, due to the fact that it has not been given enough attention and due to the destructive effect that exploiting the abundance of these still invisible flaws can generate67. A CSRF attack vector is generated by loading HTML elements or JavaScript code into a client’s browser that generate an authenticated HTTP request to a target site.  In this respect it is a generalization of JavaScript Hijacking, which only uses a <script> element to generate malicious requests for the sake of data collection. CSRF attacks are becoming a serious concern since the introduction of multi-tab interfaces in popular browsers. This usage scenario creates the opportunity for an attacker in which access to a sensitive application and access to attacker’s controlled pages are executed from the same browser process.  In contrast to JavaScript Hijacking, however, a CSRF attack does not require any specific response format.

Let’s make a distinction between two types of CSRF:  CSRF that is executed within the domain of the attacked Website, and CSRF that is triggered from a different domain.  The former requires that the attacked site contain a vulnerability such that the attacker could introduce the user’s browser with JavaScript code or HTML elements from within the domain of the attacked site.  A famous example for such an exploit is the Samy AJAX worm, which infected MySpace in October 20058. This type of CSRF can be mitigated through a combination of input validation and output sanitation. Consider for example the case of a Web mail application where the malicious content is delivered to the application not through HTTP but rather SMTP.  In such an attack scenario, the Web Application Firewall will encounter the attack vector when output is generated such as when a browser requests a malicious Web mail message.  CSRF that is executed from a different domain, on the other hand, does not send or generate any malicious content at the attacked site.  This means that neither the request nor the output contain any illegal combination of characters.  Another distinction between the two types of CSRF is that inter-domain CSRF always generates a request that has a harmful effect which does not rely on the content of the response.  This is essential for the attacker because he will not normally have access to the response that inter-domain requests generate (unless of course a JavaScript Hijacking vulnerability is present as well).  The prevention of inter-domain CSRF will be discussed in the next section.

CSRF Attack Detection

Attack Scenario

To illustrate CSRF fraud we will modify our example from the previous section as follows:

• The www.superveda-bank.com. Web site allows transfer of funds via HTTP GET requests to the following URL: 
  www.superveda-bank.com/accounts/transfer_funds?amount=500&accnt=2827267. 
  This action requires a valid session cookie.
• The attacker’s Web page contains the following HTML element:

<img src=“www.superveda-bank.com/accounts/transfer_funds?amount=500&accnt=2827267”>, where 2827267 is the attacker’s bank account.
This time, prevention cannot occur at the time the client’s browser receives its response, because the funds will have already been transferred to the attacker’s bank account.  In order to deal with this reality, we introduce the Security Monitor concept.

The Security Monitor

The Security Monitor is a JavaScript agent that runs in the client’s browser.  As we shall see, it forms a link between the Web Application Firewall and the client that will allow us to prevent CSRF attacks. 
The Security Monitor is initialized when the client logs into a protected site.  Namely, the Web Application Firewall will either open the Security Monitor automatically if popups from the protected site are enabled, or present the client with a Web page that allows him to instantiate the Security Monitor.  For example:


            Figure 3a: Initialization screen of the Security Monitor

The loadSecurityMonitor function will initialize the Security Monitor using JavaScript code such as:

Figure 3b:  JavaScript code that opens the Security Monitor

This code opens a new browser window that requests the Security Monitor code from the Web Application Firewall.  The Web Application Firewall intercepts the request and sends the Security Monitor code to the new browser window.  Following this, the original browser window is redirected to the protected site’s home page.  The use of an initialization page rather than always using an automatic popup makes sure that the Security Monitor is initialized even when the client has disabled popups.

The main body of code of the Security Monitor is an infinite loop that sends AJAX requests to the Web Application Firewall in a synchronous mode, and performs client side actions according to the Web Application Firewall responses.  Thus, the Web Application Firewall initiates every interaction between itself and the Security Monitor, and sends instructions that are executed at the client.  The Web Application Firewall instructions should contain a one-time token that the Security Monitor will send when it is required to deliver the client’s response to the Web Application Firewall.  This prevents CSRF attacks that attempt to fake the Security Monitor’s response.  It is strongly recommended that the Web Application Firewall instructions will be encodable by as few octets as possible.  Efficient implementation is further discussed in section 4.1.

The Security Monitor implements storage space in the form of browser cookies.  More specifically, data will be stored in a cookie whose path attribute contains the domain of the protected site but a relative path that does not exist.  The choice of a non-existent path is meant to prevent the generation of unnecessary traffic. Using this special cookie the Security Monitor can save information such as the URLs of friendly sites whose requests need not be verified, or URLs that the user wants to expose to any requesting party.
In order to optimize Web Application Firewall performance, the protocol that underlies the HTTP communication on the server side is a modified version of TCP.  The modified version is optimized for communications in which data is delivered infrequently, and most of the data is sent from the server to the client.  The guidelines for creating this protocol are given in section 4.1.  We will stress here that sequence numbers must still be chosen carefully in order to prevent IP Spoofing attacks against the Security Monitor.

Using the Security Monitor to prevent CSRF attacks

Now that the Security Monitor is part of our toolbox, the Web Application Firewall will take the following actions:

Whenever a client sends the first request that contains a session cookie, the Web Application Firewall will check if a Security Monitor has been initialized for that client.  If one does not exist it will present the client with the initialization page.
Following our observation from the JavaScript Hijacking attack, when the Web Application Firewall detects a request from a valid, authenticated session whose Referer is outside the application domain, it will take the following actions:

• Send a HTTP 307 Temporary Redirect response to the client’s browser.  The Location header of the response will point to a URL that the Web Application Firewall creates and recognizes.  This URL is the URL of the original request with an added suffix.  The suffix will contain a counter that counts the number of redirections which were already performed.
• Instruct the Security Monitor to get user verification for the action. This could be a simple click on a button, a CAPTCHA, or a repeated authentication.
• As long as the Security Monitor has not delivered back the user’s decision, redirect the browser’s requests as described above.  The number of redirections will be limited to a threshold after which the request will be blocked.
• In case the HTTP method of the request was POST, some user agents such as Netscape Navigator will hold the request and alert the client about an HTTP 307 response.  This behavior is desirable since the Web Application Firewall needs to create less redirect messages.  However, we have found that other browsers such as Internet Explorer 6.0 do not implement this behavior.

The request will be relayed to the server only if the Security Monitor authorized it.  This may be the result of client consent or a previous client configuration of the Security Monitor.

Following the reply from the Security Monitor, the Web Application Firewall may set cookies in the response in order to configure client preferences, for example to allow all requests from a certain site.

CSRF Fraud Detection

CSRF fraud detection is handled similarly to JavaScript Hijacking fraud detection.  In addition to taking action to bring down the malicious site and alerting his colleagues, the security administrator of superveda-bank.com will probably try to locate the person who opened account number 2827267. 

Some differences between the consequences of a successful JavaScript Hijacking fraud and a successful CSRF fraud should be pointed out:

• In order to reap the benefits of a successful JavaScript Hijacking fraud, an attacker needs to take additional action.  Namely, he needs to exploit the data stolen.  This is not the case with CSRF; in the superveda-bank.com scenario, a successful fraud means that cash has already been transferred to the attacker’s account.
• The results of a CSRF fraud can be detected by a post-mortem analysis of the transactions that have taken place in the attacked Web site.  For example, in the superveda-bank.com scenario, the bank’s logs should show that many people transferred funds into account 2827267.  On the other hand, JavaScript Hijacking does not require any transactions to take place in order to succeed.
• JavaScript Hijacking can be potentially exploited without the knowledge of the victims.  For example, if my “friends” list has been stolen for advertisement purposes, I may never be aware of it.  However, if I am the victim of CSRF, I am bound to know about it sooner or later—for example, when I receive 100 copies of a SpongeBob DVD by mail.

Centralized reporting performed by the Security Monitor is illustrated in figure 4.


Reporting Center Site


Figure 4:  The Security Monitor reporting an illegal request to a central authority

Implementation and Extension of the Security Monitor

Creating a practical implementation of the Security Monitor

The Security Monitor enhances the Web Application Firewall by harnessing the power of client mass, client discretion and client computational power.  Implementation should consider how to efficiently utilize these elements.  The following guidelines should be followed:

As much of the logic, computational effort and storage as possible should be relayed to the client side.  This reduces traffic and distributes the computational tasks rather than centralize them in the Web Application Firewall.

Client responses should be as compact as possible.  All the scenarios that are described in this paper can be implemented while preserving this guideline.

The Web Application Firewall may initiate communication with the client, however the client can only respond to Web Application Firewall requests.  This practice gives the Web Application Firewall control over the amount of client interaction that it handles, and is more secure than bidirectional initiation.
 A “frugal” version of TCP, as described in section 3.2.2, should be used at the server (Web Application Firewall) side.  We recommend the following adjustments:

Server to client data transmission should be repeated a constant number of times, without coordinating retransmission.  This spares the need for a retransmissions queue at each server-side TCP stack, and in addition a retransmission timer need not be set.

The window size (at the server side) should be constant for all TCP connections.  According to the first design principle in this section, the client will infrequently send small amounts of data.  In addition, only the server (Web Application Firewall) initiates data transfer.  Therefore, the server can manage the receiving of all client data without the need for TCP window management.

The server side protocol should not send keep-alive requests.  In addition, the connection should be terminated if all of the client’s HTTP sessions are terminated.

Congestion control mechanisms should not be employed.  We trust that the nature of the described client-server communication will not have an effect on congestion conditions.

Extending the capabilities of the Security Monitor

The capabilities of the Security Monitor can be extended beyond the bare minimum that we described in previous sections.  Some of the possible extensions:

• Black listing URLs:  When a client browses to a URL in the protected site, and the Web Application Firewall recognizes this URL as sensitive, the client can be given the choice to block requests to this URL from all foreign domains.
• White listing URLs:  Similarly to black listing URLs, the Web Application Firewall can allow input from the client regarding URLs which the client wants to expose to all requesters without discretion.

A Twist in the Plot
The solutions described so far have two important characteristics: they are gateway based and they support end-user discretion. They also have two perceived deficiencies: they provide weak protection for end-users who omit their Referer header field and they support end-user discretion. It would have been nice to provide yet another protection mechanism that is gateway based and yet accurate enough to operate without any end-user discretion.

Ideally we would like to implement a nonce tracking mechanism using a security gateway. This would provide us all the benefits of gateway based solution with the accuracy of the nonce tracking method. Theoretically, such a solution would require gateway intervention for each and every HTTP response, tediously manipulating all instances of links, forms and other elements to include the session nonce. This would probably introduce latency into the application not to mention the potential of breaking down its correctness. In addition there is this problem of JavaScript code within HTML pages that must be interpreted and understood in order to introduce the nonce into links generated by mobile code.

In reality, we have looked into a number of prominent AJAX frameworks (DWR, Prototype, GWT) and found out that they all have a central engine that contains the logic of generating request URLs and sending requests to the server. We have seen this same behavior with homegrown AJAX infrastructure as well. Thus, we realized that for a substantial proportion of AJAX applications there is indeed a viable solution. It takes only minimal configuration and very simple search-and-replace capabilities to manipulate the request generation engine code on its way from the server to clients to include a randomly generated nonce in each and every request.

Take for example DWR version 1.4 (which is vulnerable to CSRF, unlike newer DWR versions). It turns out that all the request generation code is included in the file engine.js . A security gateway can easily make sure that the file is requested by the client (rather than taken from internal cache), and delivered by the server (rather than responding with HTTP 304) at least once per session, by manipulating HTTP header fields in the beginning of a session. We have implemented a simple gateway module that looks for the request generation statement in the code (similar code exists for POST requests as well):

try {


batch.req.open("GET", batch.path + "/exec/" + urlPostfix + "?" + query, batch.async);

batch.req.send(null);
if (!batch.async) DWREngine._stateChange(batch);

Our module then changes the code to look like the following:

try {

batch.req.open("GET", batch.path + "/exec/" + urlPostfix + /token=xxxxxxxxxxxxxxxx"?" + query, batch.async);

batch.req.send(null);
if (!batch.async) DWREngine._stateChange(batch);

Where xxxxxxxxxxxxxxxx is a randomly generated nonce for the session. The gateway’s code checks each incoming request for the token= part, validates the value of the token against the token for the specific session and removes the additional part from the request. A different implementation could use a parameter in the query string to do the same, or even an extra HTTP header.

Once the gateway detects an inconsistency with the token (or the lack of a token) the gateway can react by blocking the request or appeal for user discretion using the mechanisms previously described in this paper.

As we have mentioned before a similar approach can be taken for almost any AJAX framework out there, and for a lot of the homegrown AJAX code in use. Once the mechanism is in place, additional configuration options can be provided to administrators for selecting specific parts of the application to be protected using this mechanism and specific response types. Therefore, parts of the application can be left open to inter-domain requests, other parts can be configured to block on CSRF, and yet other parts can be configured to request a CAPTCHA upon inter-domain requests.

References

1    The Internet Crime Complaint Center, 2006 Internet Fraud Crime Report
2   Brian Chess, Yekaterina Tsipenyuk O'Neil, and Jacob West, “Javascript Hijacking”, Fortify Software whitepaper, Mar 2007
3   Jeremiah Grossman, “Gmail, XSRF, JSON, Call-Back Hackery”, Jeremiah Grossman’s weblog, Jan 2007
4   Rahul Telang and Sunil Wattal, “Impact of Software Vulnerability Announcements on the Market Value of Software Vendors – an Empirical Investigation”, Fourth Workshop on the Economics of Information Security, Jun 2005
5   Imperva , “The New PCI Requirement: Application Firewall Vs. Code Review”, 2006
6   Kelly Jackson Higgins, “CSRF Vulnerability: A 'Sleeping Giant'”, Dark Reading, Oct 2007
7   Jeremiah Grossman, “More on Netflix's CSRF advisory”, Jeremiah Grossman’s weblog, Oct 2006
8   Eric Lai, ”Teen uses worm to boost ratings on MySpace.com”, COMPUTERWORLD Security, Oct 2005
9   Tom Jagatic et al., “Social Phishing”, Communications of the ACM, 2005

 

For comments and suggestions please contact adc@imperva.com.