Cross Site Request Forgery (CSRF)
ID |
php.cross_site_request_forgery |
Severity |
high |
Resource |
Authentication |
Language |
Php |
Tags |
CWE:352, NIST.SP.800-53, OWASP:2013:A8, PCI-DSS:6.5.1 |
Description
Cross-Site Request Forgery (CSRF) is a security vulnerability that occurs when a malicious actor tricks a user’s browser into performing unwanted actions on a trusted web application where the user is authenticated. It primarily exploits the trust that a web application has in an authenticated user’s browser.
It can lead to unauthorized actions being executed in a web application on behalf of the user, potentially compromising personal data, making unauthorized transactions, or performing administrative operations.
Rationale
CSRF exploits the trust that a web application has in the user’s browser. Essentially, the attacker crafts a request that the user’s browser sends to a web server where the user is authenticated.
The key vulnerability is the application’s inability to verify that the request originated from its own legitimate web pages and intentionally made by the user, rather than from a malicious site. This is why CSRF protections typically involve adding unique tokens to forms that the server can verify came from its own pages.
If the vulnerable application does not have the necessary protection, the attacker can execute arbitrary actions on the user’s behalf.
<?php
session_start();
// Check if the user is logged in
if (!isset($_SESSION['user_id'])) {
die('Access denied');
}
// Assuming the form is submitted using a POST request
if ($_SERVER['REQUEST_METHOD'] === 'POST') {
$new_email = $_POST['email'];
// Update the user's email in the database (simplified for this example)
// In a real scenario, this should include validation and parameterized queries to prevent SQL Injection
$query = "UPDATE users SET email = '$new_email' WHERE id = '{$_SESSION['user_id']}'";
mysqli_query($connection, $query);
echo "Email address updated successfully!";
}
?>
A malicious attacker could craft a page that automatically submits a request to http://example.com/update_email.php
with a changed email address on behalf of an authenticated user. Here’s how the malicious HTML page may look:
<html>
<body>
<form action="http://example.com/update_email.php" method="POST">
<input type="hidden" name="email" value="attacker@example.com" />
</form>
<script>
// Automatically submit the form when the page loads
document.forms[0].submit();
</script>
</body>
</html>
If the victim visits this malicious page while logged into example.com
, their email address is unknowingly updated to attacker@example.com
.
Remediation
The most common protection strategy against CSRF is to use anti-CSRF tokens, to ensure that requests are originated from the legitimate user. The token should be generated on the server backend, and included in every form or request to the backend.
Additional protection techniques that do not seclude the need for anti-CSRF token:
-
Validate Referer Header: In some cases, checking the
Referer
orOrigin
headers can provide another layer of protection, ensuring that the request originates from the same site. -
Force User Interaction: Force significant actions to require additional confirmation steps, like re-authentication or other forms of verification.
-
SameSite Cookie Attribute: Use the
SameSite
attribute for cookies to prevent them from being sent in cross-site requests.
Implementing these strategies in your applications will significantly reduce the risk of CSRF attacks.
Some PHP known CSRF protection libraries are csrf-magic and CSRF-Protector-PHP.
References
-
CWE-352 : Cross-Site Request Forgery (CSRF)
-
OWASP - Top 10 2021 Category A01 : Broken Access Control.
-
Cross-Site Request Forgery Prevention Cheat Sheet, in OWASP Cheat Sheet Series.