Cross-Site Request Forgery (CSRF)

From Embedded Lab Vienna for IoT & Security
Revision as of 17:49, 22 October 2024 by NKirnbauer (talk | contribs) (NKirnbauer moved page Cross-Site-Request Forgery (CSRF) to Cross-Site Request Forgery (CSRF))
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

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.


File Inclusion

Local File Inclusion (LFI)

Local File Inclusion (LFI) is a type of Cross-Site Request Forgery (CSRF) attack in which an attacker injects malicious code into a vulnerable web application to gain access to sensitive information stored in the web server's local file system. The attacker is able to execute arbitrary code on the server by exploiting the application's security vulnerabilities. The malicious code is then used to download and modify web application files, steal privileged information, or even execute malicious code on the server.

Remote File Inclusion (RFI)

Remote File Inclusion (RFI) is a type of attack where an attacker tricks a web server into including a malicious file from a remote server. The malicious file may contain code to steal data, modify data, or launch other attacks on the vulnerable web server. It can also allow the attacker to gain access to sensitive information, such as user credentials and other sensitive data.

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.

Same-Origin Policy

Another possibility for preventing Cross-Site Request Forgery is the Same-Origin Policy, which is a security measure implemented by web browsers to restrict malicious activity from websites by preventing cross-site requests. This policy means that a web browser will only allow a web page to access resources from the same origin (domain, protocol, and port) as the page itself. By restricting access to resources from the same origin, the Same-Origin Policy helps to ensure that only the intended website can access the resources and prevent malicious attempts to hijack the user's session.

References