• Home
• About
• Contact
• Applied Trust

The Barking Seal

• Enlightening the Confused Deputy

  09Mar
  Author: zack Categories: Infrastructure, Security Comments: 0

  
  One of the most interesting (in other words, “dangerous”) vulnerabilities that almost every existing web application falls victim to is cross-site request forgery (CSRF – “sea-surf”). CSRF is a type of malicious attack vector whereby unauthorized commands are transmitted from a user that the website trusts. It is an example of the confused deputy problem. This is different than the widely-known cross-site scripting (XSS) in that CSRF exploits the trust that a site has in the user’s browser, and XSS exploits the trust a user has for a particular web site.

  The simplest way to understand this vulnerability is with an example. Assume there is a stock trading website, S-trade, that anyone who signs up for an account can access. This site has functionality available for every account – including things like logging in, logging out, transferring money, purchasing stock, etc. Our hero in the scenario is Bob. Bob trusts S-trade to make his trades and keeps a portion of his portfolio there. Malice is our villain. Malice is not interested in trading stocks or other portfolio tasks, only wreaking havoc. Bob and Malice both have accounts on S-trade with basic functionality. S-trade uses all of the standard security measures meant to authenticate and protect users. There is session management in place, data sent to and from the site is encrypted, and strong password policies are enforced. These do not bother Malice one bit. All Malice must do is get Bob to click on a specially crafted link while Bob is logged in to F-trade (i.e. Bob’s cookies and session IDs have not expired). The specially crafted link can take advantage of any functionality that already exists in the application, but to keep things simple we’ll use the logout functionality as an example. When logged in, both Bob and Malice’s sessions use the same logout code. If you right-click on the link to logout, you might get something like this for URL location:

  https://www.s-trade.com/session.php?action=logout

  This section of code will undoubtedly check to see if the user is logged in or if the session has timed out. Once it determines if the session is valid, it will do whatever the rest of the code accomplishes. If Malice could get Bob to click the link above, it would log Bob out of his session, just like if Bob had clicked “Logout” himself. There are many ways for Malice to mask this link to Bob.

  Malice can embed it in her own HTML page on her domain with an iframe that runs when the HTML is loaded:

  <iframe src=” https://www.s-trade.com/session.php?action=logout “>

  As long as Bob is logged in, this code will run.

  Malice could also use traditional email phishing techniques to hook Bob on the line.

  Now, logging Bob out might only be a minor inconvenience, but you can see the power behind this vulnerability. If there were similar functionality that made a stock purchase or withdrew money, Bob’s account could really be put in jeopardy. If the site has other OWASP vulnerabilities in place in addition to this, Bob is really screwed. CSRF hooks right in to a lot of the most common and dangerous attacks.

  The problem here is that no other checks are done to prove that the user requesting this action is Bob. All it checks for is if Bob recently logged in on this machine. Web sites need to start going to further lengths to prove requests are generated by the authenticated user. There are five major steps needed to prevent CSRF attacks:

  1. Require authentication in GET and POST parameters, not just cookies.
  2. Check the HTTP “Referer” header and make sure it comes from S-trade (the Referer header can always be forged, but this small step will do some amount of good).
  3. Further limit the lifetime of authentication cookies.
  4. Require queries which cause transactions to include a one-time token.
  5. Eliminate all XSS vulnerabilities.

  With large, existing applications, CSRF can be hard to mitigate completely, but organizations that are planning to build new web applications should wire protection against this right into the code from the get go. This sort of attack is only going to get more and more common and proactive prevention is crucial.

  
  Tags: cross-site request forgery, cross-site scripting, csrf, Security, XSS