Cross-Site Request Forgery (CSRF) - Revision history

KKerbl at 14:25, 21 December 2024

2024-12-21T14:25:07Z

← Older revision		Revision as of 14:25, 21 December 2024
Line 29:		Line 29:

	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.		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.

			=== SameSite Cookies ===

			SameSite halp against CSRF attacks by controling whether cookies should be included in requests that originate from different domains, helping prevent unauthorized actions performed on behalf of an authenticated user.

			When a cookie is set with the SameSite=Strict attribute:

			The cookie is only sent with requests originating from the same site where it was initially set.
			Cross-origin requests (requests coming from a different domain) will not include these cookies, even if the user is authenticated.
			This behavior ensures that CSRF attacks relying on cross-origin requests to exploit authentication cookies are effectively blocked.

	===Same-Origin Policy===		===Same-Origin Policy===

KKerbl at 14:18, 21 December 2024

2024-12-21T14:18:47Z

← Older revision		Revision as of 14:18, 21 December 2024
Line 8:		Line 8:
	The important thing to remember about CSRF is that these attacks only work if the victim is logged into the target website. While this adds some complexity for attackers, many websites allow users to select options like "Stay logged in," simplifying the attack process.		The important thing to remember about CSRF is that these attacks only work if the victim is logged into the target website. While this adds some complexity for attackers, many websites allow users to select options like "Stay logged in," simplifying the attack process.

	For a CSRF example, visit [~~CSRF Practical Example](~~https://wiki.elvis.science/index.php?title=CSRF:_Practical_example_using_Burp_Suite_and_portswigger.net)		For a CSRF example, visit [https://wiki.elvis.science/index.php?title=CSRF:_Practical_example_using_Burp_Suite_and_portswigger.net CSRF Practical Example]


	== File Inclusion ==		== File Inclusion ==

KKerbl at 14:17, 21 December 2024

2024-12-21T14:17:48Z

← Older revision		Revision as of 14:17, 21 December 2024
Line 8:		Line 8:
	The important thing to remember about CSRF is that these attacks only work if the victim is logged into the target website. While this adds some complexity for attackers, many websites allow users to select options like "Stay logged in," simplifying the attack process.		The important thing to remember about CSRF is that these attacks only work if the victim is logged into the target website. While this adds some complexity for attackers, many websites allow users to select options like "Stay logged in," simplifying the attack process.

	For a CSRF example, visit ~~this link:~~ https://wiki.elvis.science/index.php?title=CSRF:_Practical_example_using_Burp_Suite_and_portswigger.net		For a CSRF example, visit [CSRF Practical Example](https://wiki.elvis.science/index.php?title=CSRF:_Practical_example_using_Burp_Suite_and_portswigger.net)

	== File Inclusion ==		== File Inclusion ==

KKerbl at 14:15, 21 December 2024

2024-12-21T14:15:56Z

← Older revision		Revision as of 14:15, 21 December 2024
Line 8:		Line 8:
	The important thing to remember about CSRF is that these attacks only work if the victim is logged into the target website. While this adds some complexity for attackers, many websites allow users to select options like "Stay logged in," simplifying the attack process.		The important thing to remember about CSRF is that these attacks only work if the victim is logged into the target website. While this adds some complexity for attackers, many websites allow users to select options like "Stay logged in," simplifying the attack process.

	For a CSRF example, visit this link: CSRF ~~Example~~		For a CSRF example, visit this link: https://wiki.elvis.science/index.php?title=CSRF:_Practical_example_using_Burp_Suite_and_portswigger.net

	== File Inclusion ==		== File Inclusion ==

KKerbl: /* Cross-Site-Request Forgery (CSRF) */

2024-12-21T14:15:23Z

Cross-Site-Request Forgery (CSRF)

← Older revision		Revision as of 14:15, 21 December 2024
Line 6:		Line 6:
	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.		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~~.		The important thing to remember about CSRF is that these attacks only work if the victim is logged into the target website. While this adds some complexity for attackers, many websites allow users to select options like "Stay logged in," simplifying the attack process.

			For a CSRF example, visit this link: CSRF Example

	== File Inclusion ==		== File Inclusion ==

KKerbl: /* Cross-Site-Request Forgery (CSRF) */

2024-12-21T14:13:40Z

Cross-Site-Request Forgery (CSRF)

← Older revision		Revision as of 14:13, 21 December 2024
Line 7:		Line 7:

	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.		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 ==		== File Inclusion ==

KKerbl at 14:09, 21 December 2024

2024-12-21T14:09:45Z

← Older revision		Revision as of 14:09, 21 December 2024
Line 16:		Line 16:

	== Prevention ==		== Prevention ==

			===CSRF Token===

	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 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		To prevent CSRF, each input page should contain a CSRF 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.		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.		* 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.		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===		===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.		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.

NKirnbauer: NKirnbauer moved page Cross-Site-Request Forgery (CSRF) to Cross-Site Request Forgery (CSRF)

2024-10-22T17:49:51Z

NKirnbauer moved page Cross-Site-Request Forgery (CSRF) to Cross-Site Request Forgery (CSRF)

← Older revision	Revision as of 17:49, 22 October 2024
(No difference)

RHaidl: added Same-Origin Policy

2023-01-07T10:02:46Z

added Same-Origin Policy

← Older revision		Revision as of 10:02, 7 January 2023
Line 29:		Line 29:

	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.		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 ==		== References ==
Line 35:		Line 38:
	* https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html		* https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_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
			* https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy

RHaidl: added File Inclusion section

2023-01-07T09:53:20Z

added File Inclusion section

← Older revision		Revision as of 09:53, 7 January 2023
Line 7:		Line 7:

	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.		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 ==		== Prevention ==