CSRF and Big Data
Rethinking Cross-Site Request Forgery in Light of Big Data
Maria Angel Marquez-Andrade, Hamzeh Roumani and Natalija Vlajic, York University, Toronto, ON, Canada
In the realm of Big Data analytics, a critical yet often overlooked issue is that of (big) data integrity and accuracy. Namely, the largest generators of Big Data—the major social and media sites—are known to be the most frequent and most attractive victims to various forms of security attacks and social engineering ploys. Almost by rule, the ultimate collateral victim of these attacks is the contextual integrity of the data being stored at or collected out of the target sites. One such form of attack, which is particularly potent when it comes to the compromise of contextual data integrity, is Cross-Site Request Forgery (CSRF).
The goal of our work was to examine the current state of CSRF defense in some of the major social and media sites. We have discovered that, even though it has been more than a decade since CSRF was first identified, many of these sites (including YouTube, LinkedIn, and Wikipedia) still remain vulnerable to some easily exploitable forms of CSRF. We have also learned that these particular forms of CSRF exploits are not recognizable as dangerous, even by some of the leading URL scanning tools. Finally, we have discovered that the three leading browsers employ slightly different sets of measures against CSRF, which means the CSRF attack vector may need to be configured adaptively per browser by the adversary.
Keywords
cross-site request forgery; big data; data integrity
Information in this chapter
Introduction
Big Data has become one of the most buzzed-about topics in today’s business world. It is widely believed that the wealth of information buried in Big Data carries an enormous potential and is key to achieving a competitive advantage (i.e., superior productivity and higher profits) in the new digital age. According to [1], a retailer using Big Data to the fullest has the potential to increase its operating margin by more than 60 percent. Moreover, according to [2], the worldwide market for Big Data is expected to grow to a $16.9 billion industry by 2015.
Social and media sites are considered to be the biggest generators of Big Data. For example, it is estimated that on any given day, Facebook processes 500 terabytes of data, Twitter processes over 400 million tweets, and YouTube users upload 48 hours of new video every minute [3]. The sheer volume and availability of this data, however, does not translate into the same amount of intelligible or useful information. This is because, in its raw, unprocessed form, Big Data is known to comprise lots of noise. Thus, effective mining of Big Data requires that an appropriate level of pre-processing be applied.
Noise, however, is not the only challenge when it comes to the mining of Big Data. Another critical yet often overlooked issue is that of Big Data integrity and accuracy. This is especially true for data collected from social and media sites. In the past, these sites have often fallen victim to various forms of security attacks and social-engineering ploys. As an inherent consequence, the integrity of data stored at and/or collected out of these sites has also frequently suffered.
Cross-Site Request Forgery is a type of malicious exploit of a website in which unauthorized commands get executed simply by virtue of being transmitted via the browser of a previously successfully authenticated/authorized user. Clearly, when utilized on a larger scale (e.g., affecting hundreds or thousands of user), unauthorized commands that get falsely attributed to legitimate users can have a profound effect on the integrity of the data being stored/collected at the site targeted by a CSRF attack. If the victim site happens to be any of the popular social or media domains, it is easy to see how CSRF can be used as a deliberate (or accidental) tool against the integrity of Big Data.
In our work, we have looked at several major social and media sites and examined the current state of their CSRF defense. We have discovered that, even though it has been more than a decade since CSRF was first identified, many of these sites (including YouTube, LinkedIn, and Wikipedia) still remain vulnerable to some easily exploitable forms of CSRF. We have also learned that these particular forms of CSRF exploits are not recognizable as dangerous, even by some of the leading URL scanning tools (i.e., they successfully pass the safety checks). In addition, we have looked at the three leading Web browsers and the mechanisms that they employ in order to facilitate the global defense against CSRF. Our findings show that each browser type employs a slightly different set of anti-CSRF measures. We have also discovered that some of the developer tools in Chrome and Firefox might unintentionally serve as an aid to CSRF.
The content of this paper is organized as follows: In the section titled “SOP and CSRF,” we give an overview of CSRF in relation to the Same Origin Policy (SOP)—the key browser-side mechanism against CSRF and XSS. In the section titled “Motivation and Related Work,” we describe the motivation for our work and give an overview of the related literature. In the section titled “Defenses against CSRF: Server and Browser Sides,” we discuss the importance of both the browser and the server side defense against CSRF, and also present some of our findings on this topic. In the section titled “Experimental Results: CSRF in Social Media and Networking Sites,” we describe our experimental framework and provide a summary of our main findings concerning the CSRF vulnerabilities in YouTube, LinkedIn, Dailymotion, and Wikipedia. In the section titled “Analysis of Test Framework with Popular Web/URL Scanning Tools,” we present the safety scan scores for our experimental/attack framework as provided by Jsunpack and Wepawet. Finally, in the section titled “Conclusions and Future Work,” we make our concluding remarks and outline the future work.
SOP and CSRF
Many modern Web applications rely on browser state data such as certificates, cookies, and authorization headers to authenticate users and consequently provide them with services that handle their private data [4]. These applications send pages containing several elements to the user’s Web browser, which it subsequently organizes as a document. At any given time, several such documents may coexist within the browser (in separate frames, tabs, or windows), and hence, a mechanism is needed to control inter-document access and protect each document’s private data. The Same Origin Policy (SOP), implemented by most Web browsers, prevents elements in one document from reading or modifying the data in another, unless the two documents have originated from the same Web application. Specifically, each document is tagged by its origin, which is defined as the (domain, port, protocol) tuple of the sending Web application. This organization can be observed with the DOM Inspector Firefox add-on, as shown in Figure 20.1[5].
Figure 20.1 Organization of huffingtonpost.ca as depicted by DOM Inspector.
In the example depicted in Figure 20.1, the document from huffingtonpost.ca contains an iframe with id “ttwttrHubFrame”, and that iframe fetches a page from platform.twitter.com. This is, thus, an example of a Web page comprising two documents, and since they have different origins, elements in the huffingtonpost.ca document should not get access to elements in the iframe (i.e., platform.twitter.com document) and vice versa.
Note that SOP does not prevent documents from making cross-origin requests (e.g., to populate an iframe, include a script, or fetch an image from a different origin). Instead, SOP only blocks access to the response of that request. This property of SOP is precisely what Cross-Site Request Forgery (CSRF) aims to exploit. Namely, a typical CSRF attack involves a user who is logged into a legitimate site S in one document and is visiting the attacker’s site in another document , in a different tab, for example. If the attacker’s site makes a cross-site request to S, the browser will not only allow such a request, it will also attach the login or cookie credentials of the victim user to it. In effect, the attacker can impersonate the victim-user by making the victim-user’s browser perform authenticated requests without the victim-user’s explicit knowledge.
To illustrate the above, let us assume that search engine S allows users to make search queries with a simple GET request, such as www.S.com/search?q=Toronto to search for “Toronto.” Assume also that S allows users to sign up for accounts so it can keep track of their queries. The account feature also enables users to see their search histories and enables S to deliver user-targeted ads and collect aggregate statistics about popular searches. In a CSRF scenario involving S, we envision the user being logged into S in one tab and subsequently visiting the attacker’s page in a second tab. We also envision the attacker’s page containing an image or an auto-submitted form that submits a search request for “York” to S: www.S.com/search?q=York. (The request can be made covert so that the user does not notice it being sent and/or its respective reply being received.) Since such an action does not violate the SOP policy, the browser will allow the request to be sent and will also attach the user’s authentication data to it. When the response arrives, the browser will correctly prevent the attacker’s page from accessing it, as per SOP, but this is irrelevant because the damage has already been done: (1) the “York” search will be added to the user’s history, and (2) if the same attack is repeated in large numbers, “York” can become a popular trendy search word even though no user has consciously searched for it. Moreover, S will start sending ads about “York” to all affected users.
Luring the user to visit the attacker’s page while logged in to a legitimate site can be achieved through a variety of attack vectors such as cross-site scripting (XSS), SQL injection, or social engineering (e.g., clicking a link in an email). For certain legitimate sites, such as Facebook or Google, the success rate of CSRF is high because most users are logged in to them at all times.
CSRF has traditionally targeted use cases involving financial transactions (e.g., the attacker’s page issues a money transfer request to the user’s online baking site) or identity theft (e.g., the attacker’s page issues a password change request). Lately, however, the focus has shifted to “softer” targets such as posting a “Like,” adding a new contact, or inserting a phone number in someone’s dial log. At first glance, these may seem to be harmless or mere mischiefs, but in the context of Big Data, the implications are far more serious. In a world where major marketing decisions are based on the number of “Likes,” and where the importance of events is based on what is trending on Twitter, these petty mischiefs aggregate a tectonic impact. To better appreciate the connection between CSRF and Big Data, let us analyze the impact of the attack in the above example, in which a search for “York” was forged. Three victims are involved here:
• The end user: Since the user repeatedly searches for “York” (or so it seems), it will be assumed that the user may have an interest in “York” or an association with it. If this (incorrect) observation is shared with security/law enforcement agencies or insurance companies, then it may affect the profile that these parties create for the user.
• The website’s revenue: Data collected at the site will indicate that this user is interested in “York”; hence, ads related to “York” will be embedded in all pages sent to this user. Since this apparent interest is false, the user will not click on these ads and the advertising site will have wasted a marketing opportunity.
• The website’s Big Data integrity: Analytics at the site, which track frequent searches by distinct IP addresses, will indicate that “York” is a very popular subject because many users are looking it up. This can occur, for example, if the attack vector involves a mass email containing a link with “York” as its query (with a large number of recipients, chances are high that some will click on the link while logged into S). The integrity of the data collected out of the site will thus suffer.
Of these three victims, the last is often overlooked and has the potential, in our view, of inflicting the most wide-spread damage.
Motivation and related work
Prevalence of CSRF
Statistics on Web application attacks, such as the one published in April 2013 by the cloud hosting company FireHost, reveal that CSRF is one of the most prevalent attacks. Moreover, the volume of such attacks has increased 132 percent since 2012 [6]. In recent years, some of the most popular sites have also been victims of CSRF attacks.
In August 2012, a CSRF vulnerability was found in Facebook’s new feature, the App Center, where users can manage and download applications for Facebook. The attack consists of forging a request to download a specific application. Consequently, an attacker can force victims to download an application of the attacker’s choosing. The vulnerability exists because the request required for downloading a Facebook application is a simple POST request with an anti-CSRF token, which cannot be forged but that the App Center Web application does not validate! Hence, even though the token may not appear in the request, the server will accept it. A proof-o-concept-attack page was published by the discoverer of the vulnerability once he reported it to Facebook, and in return he was awarded USD $5000 for the discovery. The attack page contains a form which sends a POST request to www.facebook.com/connect/uiserver.php. The form input fields contain several static parameters such as the ID of the application being requested. The form is auto-submitted via the onload event in the body tag [7]. The attack would succeed if the user visiting the attack page has already authenticated in Facebook, which would make the browser attach the user’s Facebook credentials to the forged request.
More recently, in January, 2013, a CSRF vulnerability was found in LinkedIn, a social networking site for professionals, with over 175 million users. The vulnerability resided in LinkedIn’s Add Connections functionality, which is one of the most important functionalities in the site, since the visibility of a profile depends mainly on the number of connections it has. This functionality includes a Send Invitation option, which allows a user to send an invitation to other users to become part of the first user’s network. The user receiving the invitation is only required to accept the invitation in order to be added into the sending user’s network. The attack consists of forging the Send Invitation request to force a user to send an invitation to the attacker. This enables the attacker to be added to the user’s network, thus increasing the attacker’s visibility. The Send Invitation request consists of a POST request with four parameters: the email of the user being invited, an invitation message, a CSRF token, and a sourceAlias token. The vulnerability exists because the CSRF token is not validated by the LinkedIn Web application. Additionally, the Web application processes POST and GET requests identically, thereby making it easier to forge the request covertly. The discoverer gave the following example as a proof of concept for the attack [8]:
1. The attacker creates a page (csrf-exploit.html) containing this image tag: <img src="http://www.linkedin.com/fetch/manual-invite-create?emailAddresses=&subject=" width=0 height=0>.
2. A user authenticated to LinkedIn visits csrf-exploit.html.
3. The attacker receives the invitation from the user and accepts it.
The success of this attack also affects the user, as the attacker can now view information only visible to the user’s contacts.
Previously published work on CSRF
W Zeller and EW Felten, 2008 [9]
In the paper [9], the authors present four CSRF vulnerabilities discovered in popular websites, as well as recommendations for server-side defenses and a client-side plugin to protect against CSRF. The first vulnerability was found in 2007 in The New York Times website (nytimes.com), a major news site and US newspaper that allows users to recommend articles to other users through an “Email This” tool. The tool sends an email to the recipient of the recommendation, specifying the email of the authenticated user who recommended the article. Hence, a request could be forged to covertly force a user to send a recommendation to the attacker and thus reveal the user’s email address. The second attack discussed was a much more serious vulnerability in ING Direct, which permitted opening new accounts and transferring funds from a user’s account. The site did not implement any protection against CSRF, hence all the requests required to perform the previously mentioned actions could be forged covertly as a series of GET and POST requests using JavaScript. At that time, YouTube, a video-sharing website, did not implement any CSRF defenses either, so vulnerabilities in almost all features in the site were discovered.
In addition to identifying the above-mentioned vulnerabilities, [9] also provides the following recommendations to protect against CSRF at the server side:
1. Restrict the use of GET requests to actions with no persistent side effects in order to reduce the possible attack variations and covertness.
2. Add a pseudo-random value to all POST requests site-wide. This value should be unrelated to the user’s account so that it can be conferred even before authentication.
The authors of [9] have also developed a plugin for the Code Igniter framework, which validates pseudo-random values in POST requests and appends pseudo-random values to function calls requesting form tags as well as AJAX requests.
Regarding the client side (browser side), a Firefox extension was developed that restricts HTTP requests, allowing all GET requests and blocking all cross-origin POST requests to sites not implementing Adobe’s cross-domain policy [9].
A Barth, C Jackson, and JC Mitchell, 2008 [4]
The work presented in paper [4] studies some known forms of CSRF vulnerabilities, analyzes current defenses, and proposes an implementation of a browser defense. The authors introduce login CSRF attacks, which consist of forging a login request to a victim site with the attacker’s credentials and sending the request from the user’s browser. The impact of the attack depends on the data managed by the application. One of the attacks they describe is an attack to a search engine that logs user queries, indicating that the attacker would have access to the victims’ queries since the victim would be navigating with the attacker’s account [4].
The authors experiment with the Referer header as an alternative CSRF defense. The results indicate that the Referer header is mostly suppressed by the network and not the browser, and that it is more likely to be suppressed in cross-site requests than in same-origin requests. Thus, they propose analyzing the Referer header of requests sent through HTTPS to spot CSRF attacks, since the network cannot suppress headers of HTTPS requests. The Referer header, however, exposes the path and querystring of the referring document and thus represents a privacy concern. Consequently, the authors propose adding an Origin header instead—which includes only the scheme, host, and port of the referring document—to all POST requests. To implement their scheme, the authors created a patch for WebKit and an extension for Firefox, as well as a server-side Web application firewall in ModSecurity [4].
R Shaikh, 2013 [10]
In this most recent paper on CSRF [10], the author describes how most client-side CSRF defenses arebased on either anomaly or signature detection schemes, and as such, are too restrictive or not scalable. With the assumption that pseudo-random values in requests do not provide sufficient protection, the author proceeds to describe a solution employing a variation of Bayesian Belief Networks, a graphical probability model that aims to predict whether the current request constitutes a CSRF. In this model, the probability of a request being a CSRF is measured based on the characteristics of previously monitored requests. The model is implemented through a browser plugin that monitors and collects requests and proceeds to suppress authentication data from suspected CSRF requests. Figure 20.2 illustrates the screening process for each request according to the proposed algorithm [10].
Figure 20.2 High level diagram of proposed CSRF detection algorithm [10].
Motivation for our work
The term CSRF was coined 12 years ago [11]; since then, numerous countermeasures have been identified both on the server and browser sides, as well as in the HTTP protocol itself. It is therefore surprising, and frustrating, that despite all this effort, today CSRF remains in the OWASP’s Top 10 2013 vulnerabilities [12] and the fourth most prevalent vulnerability discovered by WhiteHat Security in 2012 [13].
Moreover, it seems that, primarily, sites that hold sensitive data, such as banks, are implementing CSRF countermeasures. This is alarming in the context of a Big Data world, as decisions are increasingly being based on mining insensitive data, such as number of views, number of follows, or browsing history, which are easy CSRF targets. Furthermore, an increasing number of websites—most notably sites such as Reddit, Tumblr and Pinterest, where the re-post functionality is essential—are basing their value on the fact that their content is appraised by users. Consequently, CSRF is a prevalent vulnerability that threats to perturb the data that gives trend and structure to Web application use.
The choice of CSRF protection also impacts the efficiency of gathering user data. For instance, users, as well as the developers of Pinterest, are often confused by anti-CSRF token errors. The error message presented in Figure 20.3 proceeds from the Django implementation of CSRF protection, as further discussed in the next section [15].
Defenses against CSRF: Server and browser Sides
Existing Anti-CSRF mechanisms in the web
As suggested in [4], the validation of HTTP Referer is the simplest CSRF defense. This defense, however, requires that the browser attaches the header to each request and the Web application or server firewall analyzes its value. It also has several drawbacks, such as being suppressed by the network and introducing privacy concerns, as mentioned earlier.
Using the origin HTTP header overcomes the privacy concerns of the Referer header. Nevertheless, since HTTP origin does not contain the path of the requesting document (only the host), it restricts validation to complete domains. For instance, a site wanting to accept requests only from example.com/private/ cannot differentiate between it and requests from example.com/forum/. Furthermore, the origin header is not added to requests such as links in anchor tags or script window navigation such as “window.open” [14].
Introducing pseudo-random numbers/tokens in POST requests is a widely used CSRF defense. The defense consists of making the Web application/server produce a token tied to the user’s session and appending this token to the page sent to the browser. Once in the browser, the document will decide when to add the token to POST requests. Subsequently, the Web application/server will validate the token and either allow or block the request. It might be somewhat challenging to implement this solution from scratch, as evidenced by the Facebook and LinkedIn CSRF vulnerabilities discussed in the section titled “SOP and CSRF.” Furthermore, tokens can only be added to POST requests, since they should not be visible from the querystring; thus, only POST requests can be protected [14].
Server-side modifications
CSRF token protection is included in the standard development packages of modern Web development platforms such as ASP.NET, Django and Ruby on Rails. These frameworks append tokens to HTML output and validate tokens in received POST requests. Developers can choose which pages or their elements will submit the token. The use of these frameworks, however, may also confuse developers—as in the Pinterest example from the section titled “Motivation for Our Work”—which may also lead to developers making cross-site requests that include the token and thus reveal it to other domains [14].
Browser-side modifications
Most browser-side solutions are browser extensions (similar to the ones described in the section titled "Previous Published Work on CSRF"), whereby the extension screens HTTP requests to either block or strip authentication data from a specific class of requests.
Request Rodeo is a proxy that runs parallel to the browser, intercepting requests and responses to label them according to origin and subsequently strips their authentication data if they do not adhere to the configured policy. It is similar to the server-side solution, but occurs in the browser-side machine. Since the solution requires traffic to go through a process of modification, the implementation of this solution can introduce significant latency [14].
Our findings and observations
The following summarizes our findings and observations:
1. AJAX accompanied by Origin header: Through our work on CSRF, it has been observed that, in the executed tests, AJAX requests are always accompanied by an origin header in both Google Chrome and Mozilla Firefox requests. Internet Explorer (IE), however, has its own preferences regarding which requests should include the origin header. There is only partial support for the origin header on IE 8 and 9 and full support in IE 10, as discussed in [16].
2. The SOP is enforced, but developer tools leak headers; Firefox and Chrome have built-in developer tools that allow users to observe the response headers from a cross-site request. Even though the body of the request is not revealed, the rest of the headers are shown, as seen in Figure 20.4.
Experiment results: CSRF in social media and networking sites
We conducted several tests consisting of uploading test pages containing cross-site requests to popular sites, which attempt to impersonate the user who loaded the test page and has previously been successfully authenticated by the target website.
Description of the test framework
Table 20.1 gives a description of each test page we created. The tests can be found at http://www.cse.yorku.ca/~mma/tests/. As YouTube was the first site we tested, a few of the presented test pages apply only to YouTube and have a Y in their test number.
The tests were carried out by authenticating the victim user to the target site in one tab and subsequently requesting the attack page in another tab, as shown in Figure 20.5.
If the attack page is indicated as covert, then it carries out the attack in the background and displays an innocent page. Otherwise, the user is aware of a new request for the target site, since the user will get to see the respective response in clear sight.
YouTube results
YouTube is a major video-sharing site. Our objective on YouTube was to generate a GET request for a specific video and thus impact the user’s watch history—a YouTube feature that logs the authenticated user’s viewed videos. The generation of a watch history element is linked to the generation of a view, or hit count, in a video. Thus, if a user generates a view, the video is added to the user’s history. YouTube has three different APIs to give access to its videos. If the video is watched in YouTube, then the link communicates to www.youtube.com/watch. If the video is embedded in a site, then the HTML5 code communicates to www.youtube.com/embed (the embed API). If the video is embedded as a flash file, then the resource is from www.youtube.com/v (old YouTube embed code). The results from our tests indicate that, if the embed API is used, then the view count increases only if the user clicks on the video to play it. Responses with autoplay do not count as views.
As observed in Table 20.2, only our non-covert CSRF attacks on YouTube where successful. There are, however, mechanisms through which the visible manifestations of our successful CSRF attacks could be made less obvious, thereby reducing the likelihood that the exploits get detected (i.e., the overall effectiveness of the attacks are increased).
LinkedIn results
LinkedIn is a social networking site focused on creating a network of business partners and colleagues for the purpose of career advancement. Its users are encouraged to constantly visit the site to create bigger networks, update their profiles, and observe who has commented on or viewed their profiles. The tests generate a simple GET request for the user’s profile at http://www.linkedin.com/in/(username). If the attack is successful, then the attacker sees the victim added to the list of users who have viewed the attacker’s profile, as depicted in Figure 20.6. The results of the tests are shown in Table 20.3.
Table 20.3
FF is Firefox, IE is Internet Explorer, GC is Google Chrome.
✓ indicates that the victim was added to the list of users who viewed the attacker’s profile.
× indicates that there was no change in the list of users who viewed the attacker’s profile.
On this occasion, there were two successful covert attacks, tests 9 and 10, in Firefox and Chrome, respectively. Using these attacks, an attacker can easily boost his or her view rating by forging victim views.
Wikipedia results
Wikipedia is a free online encyclopedia built by volunteers who can either have a user account or be anonymous. Having an account gives users access to more functionality such as creating a Watchlist, which allows them to follow the modifications that have recently been made to a specific article. We found a CSRF vulnerability that exists if several users use the same browser in a device (i.e., the browser on a computer in a cybercafé). The request for adding a new item in the Watchlist is a POST request to http://en.wikipedia.org/w/api.php. The body of this request contains the following parameters:
The token attribute protects the request by linking it to the user’s browser state. Once the user logs out, however, if the next user logs in the same browser, the token will still be valid for this new user for about a day. Subsequently, we attempted to get the same result by forging the request as a GET request. Wikipedia does not accept this request as GET and responds with the following error header: MediaWiki-API-Error: mustbeposted, so the test was carried out with a POST XMLHttpRequest. The test script consisted of the following lines:
xmlhttp.withCredentials=true;
xmlhttp.open(“POST”,”http://en.wikipedia.org/w/api.php”,true);
xmlhttp.setRequestHeader(“Content-type”, “application/x-www-form-urlencoded”);
xmlhttp.send(“action=watch&format=json&title=Love&uselang=en&token=274660c0fdf3a8b10f91a415f2e5c8b3%2B%5C”);
The attack has to be carried out in several steps:
1. The attacker makes a request to add an article to their Watchlist and logs the request made by the browser.
2. The attacker extracts the parameters in the request body and adds them to the test script in the “xmlhttp.send” method.
3. The attacker logs out and the victim logs into Wikipedia employing the same browser.
Once the victim loads the test page, the new item will be added to their Watchlist. Step 1 will generate a request, as shown at the top of Figure 20.7 (where user Secma is the attacker), and Step 4 will generate a request, shown at the bottom (where user Secdrma is the victim).
Figure 20.7 Requests made to Wikipedia. At top is a legitimate request made by the attacker to add an article to Watchlist. At bottom is a forged request with the victim’s credentials.
We can observe that none of the authentication data (cookies) match. Therefore, the token is most likely tied to the initial sections of the values of the cookies, which do match. If the attack is successful, then the attacker will be able to add articles to the victim’s Watchlists and make them appear as more relevant than they really are.
Dailymotion results
Dailymotion is a video-sharing site whose users are predominantly interested in video blogging and artistic content creation. It has a global Alexa rank of #83, ranking it near sites such as CNN and Netflix [17]. As with many other video-sharing sites, Dailymotion provides authenticated users with the capability to post comments on videos. We found a CSRF vulnerability in this function, which requires a POST request, as the one shown in Figure 20.8.
Figure 20.8 A POST request made to Dailymotion requesting the addition of a comment consisting of the string “funny”.
Forging the request was done with a JavaScript POST XMLHttpRequest sent to http://www.dailymotion.com/pageitem/comment/post/?request=%2Fvideo%2Fxzfw9p_(name of video), including the following string in the body of the request:
The attack was successful in both Chrome and Firefox Web browsers. Internet Explorer, however, did not allow the attack for reasons possibly related to its Platform of Privacy Preferences, as mentioned in [9]. If the attack succeeds, then the comment appears at the bottom of the video and in the victim’s comment history, as shown in Figure 20.9, where user secdrma is the victim.
This attack impersonates a user and deforms the appraisal of the website’s content. Thus, it is an important vulnerability that requires the prompt implementation of CSRF protection.
Analysis of test framework with popular Web/URL scanning tools
URL scanning tools are Web applications that work like a sandbox: they run the documents received from a specific URL in their own browsers and provide an analysis report of the activities carried out by the received documents. They use signatures and anomaly detection similar to the defenses mentioned in the section titled “Motivation and Related Work” to analyze static and running code. Subsequently, they return an appraisal of the level of danger of the document activities. In this work, we make use of two URL scanners: Wepawet [18] and Jsunpack [19].
Scores of test pages
Table 20.4 shows the URL scanner scores.
We observed that the majority of our test/decoy pages were categorized as “benign” by both Wepawet and Jsunpack, which was both interesting and quite concerning, from the perspective of global CSRF defense. The only pages that were labeled as suspicious, and only by Jsunpack, were the LinkedIn and Dailymotion tests. This was because the requests embedded in these pages were made in the background, which made the processing time longer than what Jsunpack expected from its analysis.
Conclusions and future work
Many Web applications remain very vulnerable to CSRF. Moreover, most of the ones that do implement some type of CSRF protection do so on a function-by-function basis rather than as a site-wide endeavor. In other words, certain functionalities are deemed “important” and are thus protected while others are left vulnerable. Determining what is important and worth protecting is based on each site’s risk assessment model, which likely focuses on protecting the site’s users. But as the hypothetical use case of the section titled “SOP and CSRF” illustrates, the user is not the only victim of CSRF. In the context of Big Data, the most wide-spread impact of CSRF is the integrity of the conclusions drawn from aggregating a large number of noisy and/or potentially corrupted pieces of data.
The fact that not all browsers support the new origin header complicates things for developers and reduces their options for implementing pan-browser countermeasures against CSRF. Also, the presence of add-ons may make browsers vulnerable to leaking information between domains.
As mentioned in the section titled “Defenses against CSRF: Server and Browser Sides”, browser add-ons may become attack vectors if they are not properly isolated from other elements in the browser. Analyzing their implementation is part of a future work on measuring the extent of protection against CSRF attacks.
References
1. McKinsey Global Institute. Big data: The next frontier for innovation, competition and productivity. [Internet]. Available at: http://www.mckinsey.com/insights/business_technology/big_data_the_next_frontier_for_innovation; 2011.
2. International Data Corporation (IDC). Worldwide big data technology and services 2012–2015. [Internet]. Available at: http://www.idc.com/getdoc.jsp?containerId=prUS23355112; 2012.
3. Jim Yu, The importance of big data, integrity & security in enterprise SEO. [Internet]. Available at: <http://searchengineland.com/the-importance-of-big-data-integrity-and-security-enterprise-seo-143066>; 2013.
4. Barth A, Jackson C, Mitchell JC. Robust defenses for cross-site request forgery. In: Proceedings of the 15th ACM conference on computer and communications security. ACM; 2008. p. 75–88.
5. Addons.mozilla.org. DOM inspector. [Internet]. Available at: <https://addons.mozilla.org/en-us/firefox/addon/dom-inspector-6622/>; [accessed 06.13].
6. Firehost.com. Dangerous cross-site request forgery attacks up 132 percent since Q1 2012. [Internet]. Available at: <http://www.firehost.com/company/newsroom/web-application-attack-report-first-quarter-2013>; 2013 [accessed 06.13].
7. E Hacking News [EHN]-Latest IT security news. AMol NAik earned $5000 after finding CSRF vulnerability in Facebook. Hacker News. [Internet]. Available at: <http://www.ehackingnews.com/2012/08/amol-find-csrf-vulnerability-in-facebook.html>; 2012 [accessed 06.13].
8. Internet Security Auditors. Advisories [Internet]. Available at: <http://www.isecauditors.com/advisories-2013#2013-001>; 2013 [accessed 06.13].
9. Zeller W, Felten EW. Cross-site request forgeries: Exploitation and prevention. NY Times (Print) 2008;1–13.
10. Shaikh R. Defending cross site reference forgery (CSRF) attacks on contemporary web applications using a Bayesian predictive model. [Internet] 1. Available at SSRN: <http://ssrn.com/abstract=2226954 or http://dx.doi.org/10.2139/ssrn.2226954>; 2013.
11. Burns J. Cross site request forgery An introduction to a common web application weakness. Information Security Partners 2005.
12. Owasp.org. Top 10 -Top 10–OWASP. [Internet]. Available at: <https://www.owasp.org/index.php/Top_10_2013-Top_10>; 2013 [accessed 06.13].
13. Whitehat Security. Website security statistics report. [Internet]. .Available through: Whitehat Security. Available at: <https://www.whitehatsec.com/assets/WPstatsReport_052013.pdf>; [accessed 06.13].
14. Czeskis A, Moshchuk A, Kohno T, Wang HJ. Lightweight server support for browser-based CSRF protection. In: Proceedings of the 22nd International Conference on World Wide Web. International World Wide Web Conferences Steering Committee; 2013. p. 273–284.
15. Stackoverflow.com. iphone-CSRF verfication failed. Request aborted error with Pinterest in iOS-Stack Overflow. [Internet]. Available at: <http://stackoverflow.com/questions/14966016/csrf-verfication-failed-request-aborted-error-with-pinterest-in-ios>; [accessed 06.13].
16. Blogs.msdn.com. CORS for XHR in IE10-IEBlog-site home. MSDN Blog. [Internet]. Available at: <http://blogs.msdn.com/b/ie/archive/2012/02/09/cors-for-xhr-in-ie10.aspx>; 2013 [accessed 06.13].
17. Alexa.com. Dailymotion.com site info. [Internet]. Available at: <http://www.alexa.com/siteinfo/dailymotion.com>; [accessed 06.13].
18. Wepawet.iseclab.org. Wepawet » Home. [Internet]. Available at: <http://wepawet.iseclab.org/>; [accessed 06.13].
19. Jsunpack.jeek.org. jsunpack-a generic JavaScript unpacker. [Internet]. Available at: <http://jsunpack.jeek.org/>; [accessed 06.13].