Difference between revisions of "Cross-Site-Request Forgery (CSRF)"

From Embedded Lab Vienna for IoT & Security
Jump to navigation Jump to search
Line 27: Line 27:


* https://owasp.org/www-community/attacks/csrf
* https://owasp.org/www-community/attacks/csrf
* https://cheatsheetseries.owasp.org/cheatsheets/Cross Site_Request_Forgery_Prevention_Cheat_Sheet.html
* https://cheatsheetseries.owasp.org/cheatsheets/CrossSite_Request_Forgery_Prevention_Cheat_Sheet.html
* https://owasp.org/www-community/Anti_CRSF_Tokens_ASP-NET
* https://owasp.org/www-community/Anti_CRSF_Tokens_ASP-NET

Revision as of 16:23, 21 November 2021


Cross-Site-Request Forgery (CSRF)

Cross-Site Request Forgery, also known as CSRF or XSRF, is an attack where a malicious website, email message, web application, or blog causes an unwanted web browser action on a trusted site where a user is currently authenticated. The consequences of a CSRF attack depend on the extent to which the vulnerable application is hit. In the simplest case, attackers use CSRF attacks to cause a target system to perform available and malicious functions through the target's browser without the target user's knowledge. This function is usually not known to the victim until after it occurs.

A CSRF vulnerability allows an attacker to force an authenticated, logged-in user to perform an important action without the user's consent or knowledge. This way leaves no trace of the attacker from the web application's point of view. The reason for this is, the fake request contains all the victim's information and comes from the same IP address as a real request from the victim. As a consequence, any application that allows a user to send or update data is a potential target for an attacker.

The important thing to remember about CSRF is that these attacks only work if the victim is logged into the target website. This may be a complication for attackers, but many websites allow users to click something like "Stay logged in," which makes the attacker's job easier.

Prevention

To detect this vulnerability, one checks that each link and form is protected with an unpredictable "secret" token. Alternatively, one can have the user reconfirm the request, e.g., by re-authenticating or entering CAPTCHA. Here, one can focus on links and forms that actually trigger a state-changing function, as these are the most important targets for CSRF. Multi-step transactions should also be examined, as they can be equally vulnerable. An attacker can easily trigger a sequence of fake requests by using multiple tags or even JavaScript.

To prevent CSRF, each input page should contain a token. The token should be unpredictable, secret and unique for each session, or better for each form, and checked by the server. CSRF tokens should be generated on the server-side. Generally, per-request tokens are more secure than per-session tokens as the time range for an attacker to exploit the stolen tokens is minimal.

  • The preferred method to embed the token is a hidden input field. This way the token value is transferred in the body of the request and not in the URL, which otherwise facilitates spying.
  • Such a token can also be written directly into the URL or passed as a URL parameter. However, by doing that we fix one security flaw by creating a new one. This approach carries the risk that the URL falls into the hands of the attacker and thus the secret token is compromised.
  • Active reconfirmation from the user, in the form of re-authentication, CAPTCHA input, etc. can also protect against CSRF.

Generally, it is recommended to use built-in or existing CSRF implementations for CSRF Protection. OWASP also advises to research if the framework used in your project has an option to achieve CSRF Protection, since many Frameworks have built-in implementations for these types of attacks.

References