Execution After Redirect ('EAR')
ID |
php.execution_after_redirect |
Severity |
low |
Resource |
Other |
Language |
Php |
Tags |
CWE:698, NIST.SP.800-53 |
Description
Execution after redirect ('EAR') occurs when web application logic allows further processing of a request after an HTTP redirect is intended.
In such scenarios, subsequent code execution could inadvertently expose sensitive information or bypass access controls, posing a security risk.
Rationale
Execution After Redirect vulnerabilities typically arise when programmers assume that code execution halts after an HTTP redirect.
In reality, most web frameworks allow further execution after a redirect unless explicitly stopped. This can lead to security weaknesses, such as subsequent actions that should be conditional upon the redirect.
Example of an insecure implementation:
<?php
// Simulating authentication check
if (!isset($_SESSION['authenticated'])) {
header("Location: login.php"); // Redirecting to login
// No exit or die() here, execution continues!
}
echo "Sensitive content that should not be shown after redirect.";
// Further actions that could be misused
deleteUserAccount(); // Example of unintended function execution
?>In this example, the header("Location: login.php") is intended to redirect unauthorized users, but because there is no exit; or die();, the script continues executing. If the browser does not follow the redirect immediately or an attacker manipulates the request, unintended operations could be performed.
Remediation
To remediate this vulnerability, ensure that the code logic explicitly stops processing after an HTTP redirect
Secure example:
<?php
// Secure authentication check
if (!isset($_SESSION['authenticated'])) {
header("Location: login.php");
exit; // Ensuring script execution stops after redirect
}
// Safe content execution
echo "Welcome to your dashboard!";
?>By properly terminating execution with exit;, the risk of unintended code execution after a redirect is eliminated, making the application more secure.