What is Execution After Redirect (EAR) (CWE-698)?

TL;DR: Execution After Redirect (EAR) is a vulnerability where web applications continue executing code after sending a redirect, leading to potential security risks. Fixing this involves ensuring proper exit after redirects.

What is Execution After Redirect (EAR)?

Execution After Redirect (EAR) (CWE-698) is a type of vulnerability where web applications send a redirect to another location but continue executing additional code after the redirect. As defined by the MITRE Corporation under CWE-698, and classified by the OWASP Foundation as not directly mapped…

Quick Summary

Execution After Redirect (EAR) vulnerabilities can lead to unintended behavior such as unauthorized access or execution of untrusted commands. This issue is critical because it undermines the integrity and security of web applications.

Jump to: Quick Summary · Execution After Redirect (EAR) Overview · How Execution After Redirect (EAR) Works · Business Impact of Execution After Redirect (EAR) · Execution After Redirect (EAR) Attack Scenario · How to Detect Execution After Redirect (EAR) · How to Fix Execution After Redirect (EAR) · Framework-Specific Fixes for Execution After Redirect (EAR) · How to Ask AI to Check Your Code for Execution After Redirect (EAR) · Execution After Redirect (EAR) Best Practices Checklist · Execution After Redirect (EAR) FAQ · Vulnerabilities Related to Execution After Redirect (EAR) · References · Scan Your Own Site

Execution After Redirect (EAR) Overview

What

Execution After Redirect (EAR) occurs when a web application sends a redirect but continues executing additional code after the redirect has been sent.

Why it matters

This can lead to unintended behavior, such as unauthorized access or execution of untrusted commands. It undermines the integrity and security of web applications.

Where it occurs

It typically occurs in web applications that do not properly exit after sending a redirect.

Who is affected

Web application developers and users are at risk if this vulnerability exists in their systems.

Who is NOT affected

Systems with proper control flow scoping and secure coding practices are not vulnerable to EAR.

How Execution After Redirect (EAR) Works

Root Cause

The root cause of EAR is the web application sending a redirect but continuing to execute code after the redirect has been sent, leading to unintended behavior or security vulnerabilities.

Attack Flow

1. The attacker sends a request to the web application.
2. The application processes the request and decides to send a redirect response.
3. Instead of exiting, the application continues executing additional code that should not occur after the redirect is sent.
4. This can lead to unauthorized access or execution of untrusted commands.

Prerequisites to Exploit

• The attacker must be able to trigger a scenario where the web application sends a redirect but does not properly exit after sending it.

Vulnerable Code

def process_request(request):
    if request.path == '/login':
        response = HttpResponse(status=302)
        response['Location'] = '/home'
        return response

    # Additional code that should not execute after the redirect is sent.
    print("Executing additional actions...")

Secure Code

def process_request(request):
    if request.path == '/login':
        response = HttpResponse(status=302)
        response['Location'] = '/home'
        return response

    # Ensure no further code executes after sending the redirect.

Business Impact of Execution After Redirect (EAR)

Confidentiality

• Unauthorized access to sensitive data may occur if additional actions are executed after a redirect.

Integrity

• Critical system configurations can be modified by executing untrusted commands after a redirect.

Availability

• Services can be disrupted due to unintended execution paths leading to denial-of-service conditions.

Real-world business consequences:

• Financial losses from unauthorized transactions.
• Compliance penalties for data breaches.
• Reputation damage from security incidents.

Execution After Redirect (EAR) Attack Scenario

1. The attacker sends a request to the web application’s login endpoint.
2. The application processes the request and decides to send a redirect response to /home.
3. Instead of exiting, the application continues executing additional code that should not occur after the redirect is sent.
4. This can lead to unauthorized access or execution of untrusted commands.

How to Detect Execution After Redirect (EAR)

Manual Testing

• Review the application’s control flow logic for proper exit after sending a redirect.
• Check if any actions are executed after the redirect response has been sent.

Automated Scanners (SAST / DAST)

• Static analysis can identify code patterns where redirects are followed by additional actions.
• Dynamic testing can simulate attacks to detect actual vulnerabilities in runtime scenarios.

PenScan Detection

PenScan’s scanner engines such as ZAP, Nuclei, Wapiti, Nikto, SSLyze, Dalfox, and Nmap can be used to detect EAR vulnerabilities.

False Positive Guidance

A false positive may occur if the code pattern looks risky but is actually safe due to context a scanner cannot see. Ensure that any detected patterns are reviewed manually for actual vulnerability.

How to Fix Execution After Redirect (EAR)

• Ensure proper exit after sending a redirect.
• Use secure coding standards and best practices to prevent unintended execution paths.
• Regularly review application logic to identify and fix EAR vulnerabilities.

Framework-Specific Fixes for Execution After Redirect (EAR)

Python/Django

def process_request(request):
    if request.path == '/login':
        response = HttpResponse(status=302)
        response['Location'] = '/home'
        return response

    # Ensure no further code executes after sending the redirect.

How to Ask AI to Check Your Code for Execution After Redirect (EAR)

Execution After Redirect (EAR) Best Practices Checklist

✅ Ensure proper exit after sending a redirect. ✅ Use secure coding standards to prevent unintended execution paths. ✅ Regularly review application logic for EAR vulnerabilities.

Execution After Redirect (EAR) FAQ

How does Execution After Redirect (EAR) work in web applications?

Execution After Redirect (EAR) occurs when a web application sends a redirect to another location but continues executing additional code, potentially leading to unintended behavior or security vulnerabilities.

Can you provide an example of vulnerable code for Execution After Redirect (EAR)?

Vulnerable code includes sending a redirect and then performing actions that should not occur after the redirect has been sent.

What are the business impacts of Execution After Redirect (EAR) vulnerabilities?

Business impacts include unauthorized access to sensitive data, modification of critical system configurations, and potential disruption of services.

How can I detect Execution After Redirect (EAR) in my application?

Detection involves manual code review for control flow issues and automated scanning with tools like PenScan’s scanner engines.

What are the best practices to prevent Execution After Redirect (EAR)?

Best practices include ensuring proper exit after sending a redirect, using secure coding standards, and regularly reviewing application logic.

How can I fix an existing Execution After Redirect (EAR) vulnerability?

Fixing EAR involves modifying code to ensure that no actions are performed after the redirect is sent, thus preventing unintended execution paths.

Vulnerabilities Related to Execution After Redirect (EAR)

References

• MITRE
• NVD

Scan Your Own Site

Manual code review catches what you know to look for. An automated scan catches what you didn’t. Scan your own website using PenScan to find Execution After Redirect (EAR) and other risks before an attacker does.