CSRF

CSRF - The hidden menace
Cross Site Request Forgery (also known as XSRF, CSRF, Sea Surf, Session Riding, and Cross Site Reference Forgery) is an attack that tricks the victim into taking some action on the vulnerable application without the victim’s knowledge. This can happen when the victim visits a webpage that contains a malicious request, which then performs the chosen action on behalf of the victim.
CSRF attack can be carried out in different ways. The attack could be done using a HTML IMG Tag or a specially crafted URL embedded into the Target application. This works for sure since the victim will be logged into the application. Another way of doing it is to host a site/blog and influence the victim to visit the site. This site in turn would contain the malicious request. This might not work always as users may not be currently logged into the target system when the exploit is tried.
How CSRF works?
The CSRF attack exploits the browsers feature of sending the session cookie along with every POST/GET HTTP request to the target application. An adversary identifies a URL on a website like a banking application that performs some functions like purchase, fund transfer or bill pay or any transaction or updation. The adversary posts the particular URL onto a web page on which they have control. When the victim visits the webpage the URL is trigged (via an Image Request). The browser sends the authenticated cookie for the particular website along with the request.
For example: - one user, Jane, might be browsing a chat forum where another user, Dan, has posted a message. Suppose that Dan has crafted an HTML image element that references a feature/Webpage on Jane’s bank’s website (rather than an image file),
e.g.,
If Jane’s bank keeps her authentication information in a cookie, and if the cookie hasn’t expired, then Jane’s browser’s attempt to load the image will submit the withdrawal form with her cookie, thus authorizing a transaction without Jane’s approval. In the above example Jane’s web browser is mislead into withdrawing amount from Jane’s account for Dan.
Who is Vulnerable?
As seen in the attack above, Web applications that perform actions based on input from authenticated users without insisting the user to authorize the specific action are at risk.
CSRF attacks are more likely to be carried out on applications that are transaction oriented like online banking, e-Commerce Sites etc.. Applications or WebPages that implement only simple query/retrieval features are in general not susceptible to CSRF attacks, as they do not perform any transaction or updations on the user’s behalf. Today, most web applications rely solely on automatically submitted credentials such as session cookies, basic authentication credentials, source IP addresses, SSL certificates.
Applications that allow posting of user content like forums, messages etc. are often vulnerable to CSRF attacks. For example, a specially crafted message(embedded image request) on a message forum may compromise the account details of other users viewing message.
Applications that use persistent cookies are also vulnerable to CSRF attacks, since the users are "always logged in". Users could trigger an action on the target application when they visit another blog/site that contains a specially crafter URL of the target application.
XSS and CSRF Combined
XSS (Cross Site Scripting) attack happens when the adversary sends a malicious code to the application, usually in the form of script, to other end user. An adversary can use XSS to send malicious script to an unexpected user. XSS vulnerabilities are not necessarily required for a CSRF attack to work, although any application with XSS vulnerability is compromised to CSRF. When building defenses against CSRF attacks, focus should also be on fixing XSS vulnerabilities in the application since such flaws can be used to get around most CSRF defenses. XSS and CSRF together is a deadly cocktail.
The CSRF Attack in news
According to public reports, Google Gmail contained CSRF vulnerability. This vulnerability was reported on July 2007. Gmail provides email filters that allow users to sort and forward mail, this feature was found to be vulnerable to CSRF. To carry this attack victim must be logged in GMail. Victim must visit a malicious web page: most likely scenarios are clicking an external link from an incoming message. The malicious web site/email forges a POST request to GMail’s ‘Create Filter’ wizard, which will build a filter which forwards incoming messages to a mail recipient owned by the attacker. Since user is already authenticated, session cookie is passed along with the forged request and the GMail filter gets implemented.
Yahoo also contained CSRF vulnerability. This vulnerability was reported on October 2007. It was possible to add or delete in the yahoo calendar entries from a malicious site. The specially crafted HTML on a malicious site adds a task and an event to the victim’s calendar.
Countering CSRF
As we have seen in an earlier article on Session Riding, the things that do not work in fixing CSRF are,
Using POST instead of GET: The adversary could generate forged POST requests without user interaction, similar to GET.
Implementing confirmation pages: They only make the CSRF attack a 2-step process. Where the confirmation request carries all the details for placing the order, the adversary could as well skip the first step and directly use the second link to place the order.
The better known solution to prevent a CSRF attack is the usage of secret tokens alongwith each transaction made on the application.
Secret token - Use Hidden Fields
If all sensitive/transaction URLs contain some token with the page, the server can distinguish between submissions that come from pages supplied by the server (which are safe). A transaction without the token should not be allowed. The challenge is to setup the server to keep track of the token, and to setup all forms to contain a hidden field.
Here we take a simple example using ASP, showing how to implement a secret token. In an Online shopping application, a user places an order for an iPod. The application calls the transact.asp page - http://safeshop.com/transact.asp
The transact.asp page:-
Sets a Random Token at ServerDim token = md5(uniqid(rand(),transact))
Sets a Session Variable for this token at ServerSession("token") = token //Server remembers this across pages
In addition, sets an HTML Hidden variable with this token
Sends Form with other input Fields back to the browser.
The user enters the Form Fields and Clicks Submit Button. The transact.asp page calls the transactConfirm.asp page
Now even if the attacker tries to Forge a HTTP POST Request, he will need the token value to post a successful request.
A slight modifications to HTML hidden field token, is using the Session Token as the Anti-CSRF Token.
Secret token - Use Session Tokens
The CSRF attack exploits the browsers feature of sending the session cookie alongwith every POST/GET HTTP request to the target application. Due to cross-domain rules of the browser a session cookie used by a browser would not be directly available to the on the attackers domain. So effectively the session cookie value itself will be secret. Therefore, applications can read the session cookie using JavaScript and then add to URLs, forms or the body of a POST request. The application should check at the server side that the session cookie value that the browser sends in the header is the same as the session cookie in the request. Here the session cookie is used as the random and unique token for each request.