Open Redirect
Open Redirect
Description
Open Redirect occurs when a web application allows untrusted input to redirect users to external URLs without proper validation. This can lead to phishing attacks and loss of user trust.
Example with Scenario
Scenario: A web application uses a URL parameter to redirect users after login. An attacker can craft a malicious URL that redirects users to a phishing site.
Payloads and Test Cases
Payloads
Basic Open Redirect:
/redirect?url=http://malicious.com
URL Encoding:
/redirect?url=http%3A%2F%2Fmalicious.com
Relative Path:
/redirect?url=//malicious.com
Test Cases
Basic Open Redirect:
Payload:
/redirect?url=http://malicious.com
Test Case:
# Send payload to the server sendPayloadToServer("/redirect?url=http://malicious.com") # Verify if the application redirects to the malicious URL checkRedirection("http://malicious.com")
URL Encoding:
Payload:
/redirect?url=http%3A%2F%2Fmalicious.com
Test Case:
# Send payload to the server sendPayloadToServer("/redirect?url=http%3A%2F%2Fmalicious.com") # Verify if the application redirects to the malicious URL checkRedirection("http://malicious.com")
Relative Path:
Payload:
/redirect?url=//malicious.com
Test Case:
# Send payload to the server sendPayloadToServer("/redirect?url=//malicious.com") # Verify if the application redirects to the malicious URL checkRedirection("http://malicious.com")
Mitigation
Whitelist URLs:
Implement a whitelist of allowed URLs for redirection.
Ensure that only trusted URLs are allowed for redirection.
URL Validation:
Validate the URL parameter to ensure it points to a trusted domain.
Reject any URL that does not match the allowed patterns.
Use Relative URLs:
Use relative URLs for internal redirection to prevent external redirects.
Avoid using user-supplied input directly in redirection logic.
Security Headers:
Implement security headers like Content Security Policy (CSP) to restrict loading of external resources.
Use X-Frame-Options to prevent clickjacking attacks.
Last updated