Introduction
This is part 3 of my series Secure your ASP.NET Applications. In this article, I will describe what exactly Cross Site Request Forgery (CSRF) is and how hacker exploit it and how we can prevent from CSRF attack.
Background
You can read my previous article of this series from:
- Secure your ASP.NET applications from SQL Injection
- Secure your ASP.NET applications from XSS Attack
Cross Site Request Forgery (CSRF)
Cross Site Request Forgery is also known as one click attack, sea surf and session riding and abbreviated as CSRF. CSRF attack is kind of security exploit attack in which attacker uses the authentication of the victim on victim's browser.
Cross-Site Request Forgery (CSRF) is an attack where a malicious site sends a request to a vulnerable site where the user is currently logged in . (Definition from - ASP.NETt) .
What Can This Attack Do
- It can perform Actions/Proxy Requests for attacker from Victim's browsers.
How Is It Exploited
- Image link/ any link in email, on any website or on any blog .
- CSRF can be done using Cross Site Scripting.
- Malicious website can perform action using your authentication.
1. Image Link/Any Link In Email Or In Any Website
- A user logs into website www.examplewebsite.com, using forms authentication.
- Server authenticates user and response from the server includes authentication cookie.
- Without logging out, user visited a malicious website. That malicious website may contain malicious image link, post action to site user is logged in, malicious script or Ajax call which will be totally hidden from visitor. This is the "cross site" part of CSRF attack.
- User will click the image or any button (filling forms and clicking submit), then browser will happily send the authentication cookie for the request because post request is like (www.examplewebsite.com/account/delete) .
- Request will run on server with the user's authentication and can perform any action, user is allowed to do.
This attack is tough to catch, and becomes worse when attacker does the post from AJAX. The victim will even not have to perform any action. This attack can breach even SSL because malicious user can send HTTPS request too like "https://examplewebsite.com/account/delete" .
2. XSS Can Also Be Used To do CSRF Attack
To learn XSS and prevention from it, please see my last article of this series.
- If any website contains comment section, malicious user can inject script to comment section.
- When an authenticated admin will log in and visit that page where malicious user injected the script, that will execute and as a result action will be performed according to the script .
As a result of the above script, the user having id four will get deleted .
How To Prevent CSRF
For All Websites
- Make ensure your get requests are only used to retrieve data/resource .
- Never perform action on get requests. HTTP specifications also depict that one should not perform an action on get requests. (www.examplewebsite.com/account/delete/id=4)
POSTS/PUT/DELETE can also be forged. To prevent those, make requests unique and non-repeatable.
For ASP.NET Web Forms
ViewStateUserKey = Session.SessionID then viewstate will act as a form token - Protect
SessionID using Hashing and Encryption
- Use SSL to prevent sniffing of
SessionID and ViewState
- Either create a
BasePage and add the following code in that and check ViewState for forms and inherit all the pages from this base page.
ViewState is maintained optionally by ASP.NET,you can maintain view state optionally on page or on any control. Viewstate can be used as a CSRF defense, as it is very difficult for an attacker to forge a valid Viewstate. It is not impossible to forge a valid Viewstate since it is feasible that parameter values could be obtained or guessed by the attacker. However, if the current session ID is added to the ViewState, it then makes each Viewstate unique, and thus immune to CSRF.
To use the ViewStateUserKey property within the Viewstate to protect against spoofed post backs. Add the following in the OnInit virtual method of the Page-derived class (This property must be set in the Page.Init event).
protected override OnInit(EventArgs e) {
base.OnInit(e);
if (User.Identity.IsAuthenticated)
ViewStateUserKey = Session.SessionID; }
The following keys the Viewstate to an individual using a unique value of your choice.
(Page.ViewStateUserKey)
This must be applied in Page_Init because the key has to be provided to ASP.NET before Viewstate is loaded. This option has been available since ASP.NET 1.1. [References from OWASP].
For ASP.NET MVC
- Use
AntiForgeryTokens
- Use SSL to prevent sniffing of
AntiForgeryTokens
Basically, the idea behind this token is to generate a token for forms and validate this token at the server side before performing the action. To achieve this, we will have to create a toke in View of ASP.NET MVC and this token will be verified at the Action of our controller of MVC.
Generate Token on View
Use @Html.AntiForgeryToken() in your forms to generate token.
@using (Html.BeginForm())
{
@Html.AntiForgeryToken();
<fieldset>
Select a file <input type="file" name="file" />
<input type="submit" value="Upload" />
</fieldset>
}
Validate Toke on Action of your controller
Use [ValidateAntiForgeryToken()] on your action.
I hope you liked this article and that it will help you out to make your application more secure .
References
