Grey H@t - Cross-site Request Forgery


Published on

This is a presentation that was given to the Grey H@t club at Georgia Tech. It covers the basics of cross-site request forgery - what it is, how it works, what the risks are, and how to defend against it.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Grey H@t - Cross-site Request Forgery

  1. 1. THE CROSS-SITE ATTACKS There are three flavors of cross-site scripting attacks (one of which leverages another, so the argument can be made that there are only two) 1) Cross-Site Scripting – Leverages insufficient validation of a web-based application to cause visitors to certain URLs to run scripts they do not intend to. Recall that there are two types of XSS – reflected and persistent. Reflected refers to the malicious script being referenced in a URL parameter, whereas persistent refers to the HTML that loads the malicious script being permanently stored on the server. XSS is most commonly used to scraping of data from a page / resource. 2) Cross-Site Request Forgery – Leverages a user’s current state of authentication with a web-based application to execute commands the user does not intend to. XSRF is most commonly used to get the server to do something unintended. 3) Cross-Site History Manipulation – Leverages CSRF to infer information about a user authenticated to a web-based application. The information that can be disclosed is commonly sensitive.
  2. 2. THE IMPORTANCE OF CROSS-SITE ATTACKS As more and more sensitive operations are placed onto the internet, the potential impact of web-application based exploitation continues to grow as well. Fifteen years ago the world-wide web would hardly be considered for accessing highly sensitive operations such as banking and financial management. This is hardly the case today (how many of you have checked your bank accounts using your phone or other internet-connected device today?) XSS can be used to scrape information that you shouldn’t have access to, and XSRF can leverage that data to submit requests that you don’t want being submitted using your state of authentication with the web application. Thus, XSS and XSRF are commonly used hand-in-hand to do some serious damage. If you are developing systems that are web-facing and contain sensitive information / perform sensitive attacks it is crucial that you mitigate both XSS and XSRF attacks on your application.
  3. 3. CROSS-SITE SCRIPTING (REFLECTED) Bob Mallory In reflected XSS, Mallory gets Bob’s browser to request a URL that contains a value that will be “reflected” on the resulting page – the goal of malicious XSS being to have this reflected value somehow send sensitive information to Mallory. For instance, if took a parameter via query string and dropped it on the page without cleaning it, Mallory could send a URL to Bob that had the malicious link in it.<scri pt%20type=‘text/javascript’%20src=‘http://m’></script>
  4. 4. CROSS-SITE SCRIPTING (PERSISTENT) Bob Mallory In persistent XSS, Mallory is able to have a value “baked in” to the web application, and thus when users navigate to pages that contain the value, the script executes as expected. A common location to see this happen is online forums, where users are able to post valid HTML to show others and the values get persisted on the server. If Mallory was to write a post that simply contained the proper script, anyone that viewed the post could be hit.
  5. 5. CROSS-SITE SCRIPTING EXAMPLE Sansomega (or YOU!) Sansomega Let us see a quick example of how reflected cross-site scripting can be used to harvest potentially sensitive data. I have set up a quick scraping demo via Google Gruyere. To see how the same- origin policy affects data exfiltration, try the ajax link first. Attempt to use AJAX and GET to exfiltrate Use img and GET to exfiltrate
  6. 6. THE SAME ORIGIN POLICY As per Wikipedia – “In computing, the same origin policy is an important security concept for a number of browser-side programming languages, such as JavaScript. The policy permits scripts running on pages originating from the same site to access each other's methods and properties with no specific restrictions, but prevents access to most methods and properties across pages on different sites.” As seen in the previous example (the AJAX one) the same origin policy presents a hurdle for data exfiltration via XSS – an AJAX request could not be submitted to a URL that was not owned the domain of the currently served page. To put this in lay men’s terms, we could not submit an AJAX request to because the site that the AJAX request was originating from was http://google-
  7. 7. CROSS-SITE REQUEST FORGERY As per Wikipedia “Cross-site request forgery, also known as a one-click attack or session riding and abbreviated as CSRF (sometimes pronounced sea-surf[1]) or XSRF, is a type of malicious exploit of a website whereby unauthorized commands are transmitted from a user that the website trusts.[2] Unlike cross-site scripting (XSS), which exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in a user's browser.” Cross-site request forgery is also known as CSRF, XSRF, “sea surf,” session riding, cross-site reference forgery, and hostile linking. Where XSS can hurt (you may disclose plenty of sensitive information via XSS), in this day and age privacy is hardly expected anymore. XSRF, on the other hand, can be incredibly damaging to your financials, your interwebz reputation, or anything else that is hooked into the world-wide web.
  8. 8. HOW DOES XSRF WORK? (GENERAL IDEA) Cross-site request forgery relies on the fact that the target (Alice) is currently authenticated to a system that the attacker (Mallory) would like to tamper with. The most common analogy that can be found on the web is that of online banking. Let’s run through an example of how an insecurely designed sensitive application could be vulnerable. 1) Alice logs into and checks her balance. She then opens up another tab and starts browsing 2) allows its customers to transfer money at the drop of a hat, and the page that does this uses a query string for parameter passing. Thus, if Alice used the web interface to transfer fifty dollars to Bob, the page that would be requested would be 3) The developers of think that this is safe, as they are making sure that the individual specified in the “from” field is currently authenticated with their application on the server side. Thus, no one but Alice can submit this request.
  9. 9. HOW DOES XSRF WORK? (GENERAL IDEA) (2) Granted that manipulating application state via GET requests is a web-dev 101 DONTDOTHIS, how can the attacker possible forge a request if they aren’t authenticated as Alice? They can get Alice to submit the request unknowingly, which is the reason that XSRF is commonly referred to as “session riding,” – the attacker is piggy-backing on an authenticated session of their target. 4) Mallory, knowing that Alice is a SlashDot fanatic, and also knowing that SlashDot allows for images to be posted in comments (almost positive this is incorrect, but roll with me here), posts the same comment in every article that she thinks Alice might read. The image that she keeps posting is not, in fact, an image, but is instead the following: <img src=‘’/> 5) When Alice visits any of the pages that contain this “image” on them, as per the proper operating procedure of browsers, her browser will request the image’s url. As the browser can not know that the url does not point to an actual image until the request is returned, the same-origin policy can not apply here.
  10. 10. HOW DOES XSRF WORK? (GENERAL IDEA) (3) 6) Because the application developers allowed server-state manipulation via GET requests and only relied on server-side session state as authentication of requests, this attack would work very easily. As can be seen in this example, the name XSRF comes from the following: Cross-site: A URL is requested from a site outside the requested URL’s domain. Request forgery: A request is made using the authentication of an unwitting individual
  11. 11. HOW DOES XSRF WORK? (VISUAL) Bob Mallory 1) Bob is authenticated to 2) Mallory somehow (commonly via social engineering) gets Bob to visit a website that has her XSRF attack in it. For this example, let us say that site is, and that the XSRF attack is an iframe that auto-posts to, submitting a request to transfer money from Bob to Mallory. 3) Bob requests the site that Mallory wants him to. 4) The page is sent back to Bob’s browser and thus rendered. 5) A request is sent (unbeknownst to Bob) to to transfer money from Bob to Mallory. The application checks to see that the individual trying to initiate the transfer is authenticated as Bob, which checks out to be true, and thus the transaction is made. (2) (3) (4) (5)
  12. 12. SO LET’S JUST USE POST INSTEAD OF GET! Hey now, that’s a great idea! If the example that we ran through used POST instead of GET, then the attack that we looked at wouldn’t have worked! Let’s just change that over and clean our hands of this whole mess! HTTP GET requests can most commonly be detected by the presence of a query string at the end of a URL. A GET request is not supposed to modify any server state! Ex: HTTP POST requests are requests that are sent to the server with details placed within the request itself – thus a URL will not tell anything about the sent data in a POST request. Images, CSS references, and other objects that are placed on a page can not be retrieved using post requests (they must use get requests). Thus, the attack vector that we just discussed would not work if the money transfer was done via POST instead of GET. So that’s it then, right? GET -> POST -> ??? -> Profit?
  13. 13. EH…..
  14. 14. POST MAY BE A DETERRENT… But it certainly is not a mitigation. Simple links can no longer be used to exploit the XSRF vulnerability, nor can AJAX be used on another site to submit a POST request, but synchronous requests can still be forged to foreign domains with a little JS-fu. For instance, have a hidden form on your own site that submits when a user navigates to the given page. The user will experience a full post-back but will likely have no idea what actually happened (aside from the fact that they will end up on the page that you posted to). To lower suspicions even further, you could throw this in an iframe and keep any visible redirection from even occurring. Bottom line here is that simply changing protocols from GET to POST is insufficient for mitigating XSRF vulnerabilities.
  15. 15. XSRF MITIGATION There are a handful of ways to mitigate XSRF, and the following approaches assume that the developers have already taken into account the fact that only POST requests are supposed to change server state. 1) Supply a “key” with any forms that your web site contains. A hidden field can be placed within a form that has a randomly generated “key.” Upon receiving a POST request, the server will check to see if the key that was submitted alongside the POST was in fact the one that was issued to the given user. If it is not, the request can be discarded. As there are no legitimate reasons (aside from improper programming) for the keys not to match, receiving keys that do not match can be considered for an alert that your site is “under attack.” This can also be done with URLs instead of only forms. 2) Checking that the HTTP referrer of the submitted request is that of your own site. In XSRF, the request will be submitted from a site that is not yours, and as such the HTTP referrer will reflect this. If the HTTP referrer of a submitted request does not match your domain, then this too can be considered for an alert that your site is “under attack.”
  16. 16. XSRF AND XSS – BFFS FOREVER Hey Chris, what’s that thing that you said earlier about XSS and XSRF, something about them getting along really well?
  17. 17. WHY IS THIS? If you’re experienced with XSS and XSRF, please don’t shout this out. Let us assume that the developers of have taken the necessary steps to ensure that their application is no longer vulnerable to XSRF, but they haven’t gotten around to patching all of their XSS holes. Recall that XSS allows us to scrape otherwise hidden information off of a given page, and to insert whatever we want onto the page as well. How would this be a problem for a site that is protected against XSRF but not XSS?
  18. 18. RUH ROH! STILL VULNERABLE TO XSRF! The mitigations that we previously discussed for XSRF are broken if the site is still vulnerable to XSS! 1) XSS can be used to scrape tokens off of the site and send them to Mallory, thus circumventing the token-based XSRF mitigation. 2) XSS allows the attacker (nearly) full control over the contents of a page. If that’s so then why don’t we just launch our XSRF attack from within the XSS-vulnerable page itself, thus circumventing HTTP referrer checking mitigation.
  19. 19. PRACTICAL XSRF APPLICATION Given the current state of security on the web, what are the chances that there exists a web site that transfers money like the one in the example? I’m guessing there may actually be one, but I doubt it’s very big. That being said, what is XSRF commonly used for? 1) Changing router / firewall settings – Chances are that most home routers require you to be locally connected to access the router control panel. This gives a false sense of security, because why put an additional password on your router interface if you have to be authenticated with your WPA2-secured wifi network to access it? Well, if XSRF is crafted correctly a target could take down his entire firewall without even knowing it (XSRF initiates from the client’s browser, and thus is within the authentication realm of the local network). 2) Poking at intranet sites – Chances are that large companies have an intranet that is only accessible if you’re on the company’s network. The attacker may not be, but the target (if they open the wrong page on their work machines) is readily authenticated, thus with carefully crafted XSRF an attacker can poke around a company’s intranet without compromising any account credentials. 3) Really anything in which an attacker can get an authenticated individual to execute a request of the attacker’s choosing.
  20. 20. QUESTIONS / COMMENTS Let’s hear em!