What Is Cross-Site Request Forgery (XSRF/CSRF)?
Cross-Site request forgery (XSRF or CSRF) is another common attack where a malicious application influences the interaction between a client browser and a web app that trusts that browser. These attacks are possible because browsers send certain types of authentication tokens automatically with every request to a website. The attack, therefore, takes advantage of the user's previously authenticated session with the app in question.
Consider the following scenario:
1. A user signs into www.mybank.com using forms authentication. The server authenticates the user and issues a response, including an authentication cookie. The site is now vulnerable to attack because it trusts any request that it receives in which the request contains a valid authentication cookie.
2. The user now visits a malicious site, www.baddie-site.com. This site contains an HTML form that might look something like this:
<h1>Congratulations! You're a Winner!</h1>
<form action="http://www.mybank.com/api/account" method="post">
<input type="hidden" name="Transaction" value="withdraw">
<input type="hidden" name="Amount" value="1000000">
<input type="submit" value="Click to collect your prize!">
</form>Notice that the form's action posts to the vulnerable site, not to the malicious site. This is the cross-site part of CSRF.
3. The user clicks the submit button. The browser makes the request, and automatically includes the authentication cookie for the requested domain, www.mybank.com.
4. The request runs on the www.mybank.com server with the user's authentication context and can perform any action that an authenticated user is allowed to perform.
In addition to the above scenario where the user clicks the button to submit the form, the malicious site could also:
Run a script that automatically submits the form.
Send the form submission as an AJAX request.
Hide the form using CSS.
These alternative scenarios don't require any action or input from the user other than initially visiting the malicious site.
Some developers believe using HTTPS prevents CSRF attacks, but this is not true. A malicious site can send a request to https://www.mybank.com/ just as easily as it can send one to http://www.mybank.com/.
CSRF attacks are possible against web apps that use cookies for authentication because:
Browsers store cookies issued by a web app.
Stored cookies include session cookies for authenticated users.
Browsers send all of the cookies associated with a domain to the web app every request regardless of how the request to app was generated within the browser.
However, CSRF attacks aren't limited to exploiting cookies. For example, basic and digest authentication are also vulnerable. After a user signs in with basic or digest authentication, the browser automatically sends the credentials until the session ends.
End users can guard against CSRF vulnerabilities by taking precautions:
Sign off of web apps when finished using them.
Clear browser cookies periodically.
However, CSRF is fundamentally a problem with the web app, not the end user.
Prevent XSRF/CSRF
Fortunately, preventing these types of attacks is a simple process. In fact, as long as you build Razor Pages (as we cover in this course), you don't have to write any code for anti-forgery validation. Anti-forgery token generation and validation are automatically included in all Razor Pages you develop under the .NET umbrella.
Let’s Recap!
At this point, you have learned that:
Cross-site request forgery (XSRF) attacks exploit the trust relationship that exists between a client and server through the use of cookies and other authentication tokens by hijacking authenticated user sessions.
As a developer, you can easily prevent XSRF attacks when you build Razor Pages, which automatically contain anti-forgery token generation and validation.
Next we’re going to talk about open redirect attacks, which are often used in conjunction with XSS and XSRF attacks to creatively intercept private user data.
