With a real-world example:
Open Redirect/URL Redirection:
Un-validated redirects and forwards are possible when a web application accepts untrusted input that could cause the web application to redirect the request to a URL contained within untrusted input.
· Redirect and Forward Difference:
In redirect response, code is 302, and response “Location” header set to new URL. So in redirect domain is totally different. But in forwarding domain is the same so the application will use the same request attributes and headers.
· Different ways to perform Open Redirect
This is a website where URL parameter is redirected to test.com. There are some ways how we can try to manipulate URL parameter to bypass Open redirect:
1. By using special char like @,/, & and provide redirected domain at last
2. By using special char like @,/, & and provide redirected domain after URL
3. By encoding these special char and provide them as mentioned in the above URL.
4. By using parameter pollution
I have mentioned some of the basic ideas to bypass whitelisting in open redirection, there can be many more.
· Consequences of open redirect
1. Redirect victims to malicious/phishing websites:
In the below example URL parameter is not getting checking and the website is redirecting the user to any of the url. Therefore, when the attacker provides http://attackercontrolled.com/ in the URL parameter, the application will redirect the legit user to attacker-controlled domain.
An attacker can host a spoofed website on this portal and can capture user credentials which the attacker can use later to impersonate the victim or can take over his account.
2. Can execute js payload :
So if URL parameter is not getting sanitized properly we can easily execute XSS as well
3. Helps to misuse Oauth functionality
While login into any website through Facebook and Google, we are redirected through these sites. If anyhow attacker can manipulate open redirection then he can misuse it in near future.
Often hackers redirect legit users to harmful or malicious sites, and if open redirect combines with other vulnerabilities, it can be riskier.
· Attacker craft a payload by using the malicious domain in the url parameter and sends it to the victim
· Legit user receives the link since the link is of legit website he visits the link, the DOM on the application process the parameter and redirect the user to the malicious domain
· Now attacker can easily carry out the phishing attack on the user since he was redirected to a domain of the attacker’s choice
Exploitation: The application has DOM-based functionality and we have to redirect the user to outside the application domain.
For more information about DOM or DOM based XSS, please check my previous blog.
As I mentioned application has DOM to redirect the user to the previous page, so first, we have to search where the application is using redirection based on the DOM. While checking the source code of the application I saw the below code snippet.
After looking at this js snippet it is clear that “url” parameter is not getting validated properly. So when we click on the “back” button application directly redirects users to the value mentioned in the Url.
So I tried some of the different combinations to bypass the open redirect
(i) combining with URL and “url” with “/” and checking the response for the same request on burp
We got 400 error, it gave us “Invalid ID” .
(ii) Now lets pass another parameter in the URL named as “url” with an arbitrary domain and let see what happens
We got 200 OK in response and we succeed to forward the request to google.
· Avoid using redirects and forwards.
· If the user input is allowed, ensure that the supplied URL value is valid and appropriate for the application. This can be implemented by maintaining a whitelist of URLs on the server.
· Implement an intermediate disclaimer page that provides the user with a clear warning that they are leaving the current site.