Let’s scramble the word here to get the meaning. URL (Uniform Resource Locator) means to locate the resource in the web world in a uniform way and Redirection means redirecting to another source. What’s there in using this vulnerability on a web application. An attacker can gain the trust of a user. For example, the attacker will make a phishing attempt by sending a trusted website link to the user. Users will think it is from a known website which they trust when the user clicks the URL. They land up in the attacker’s plot. An attacker can do anything with it. Like requesting personal information to many.
As I’ve already stated that this is a vulnerability(weakness) in the web application. To secure the application there are numerous ways. Let’s see from the code standpoint first.
Never Trust user-controlled data – Parameter based
The application will have the functionality to accept user input to process. For example, to navigate the user to his profile settings in another domain internally usually in single sign-on authentication (SSO). Now, the URL redirect function will be called in the code to complete this function. But, the application doesn’t know that the request coming is from a legitimate user or an illegitimate user. Failing to validate this input. The function will redirect the application to user-supplied input.
Some of the functions which does this url redirect are:
Java
response.sendRedirect("http://www.example.com");
PHP
<?php
header("Location: http://www.example.com");
exit;
?>
ASP .NET
Response.Redirect("~/login/account.aspx")
Note: ASP .NET MVC 1 & 2 websites are vulnerable to this redirection attack. It is best to use MVC 3. Refer (https://docs.microsoft.com/en-us/aspnet/mvc/overview/security/preventing-open-redirection-attacks)
Session restoration:
Application will have functionality to restore the user activity or land on last page user used. It is to give the user-friendly environment.
https://example.com/login?returnUrl=/account
This can be tricked during penetration testing. The functionality works like once the user logs in again, land him on the same page which he used before session expiry. Now, the analyst can trick by providing an external domain in the place of the account and check whether the application does redirect or not. If it does then the application is vulnerable
https://example.com/login?returnUrl=https://www.demosite.com
DOM Based
Javascipt can acquire data directly from web browser. Lets see javascripts sinks first. If you hit the below url in the browser, the browser will not send the #scores to application. Because, #scores was already available to the browser and it can be taken using javascript.
If the application uses below code. Then it would lead to open redirect.
window.location = window.location.hash.substr(1)
How attacker can know this feature. Manual validation is needed to identify. Burp will report the combination of javascript sinks and redirect functions.
Attacker can use this to craft the link to redirect it to his site by phish attempt.
https://example.com/#https://www.demosite.com
So, it is much needed to check the javascript manually to find this vulnerability rather than checking the HTTP traffic alone. Because this type of DOM-based attribute is not seen in normal Burp HTTP traffics.
Preventive Measures:
- Always validate the request from the client before processing it. It is far better to have internal check than trusting external tools to do the work which can be taken for additional security.
- If possible, have direct links in the code hardcoded.
- Have the list of internal domain url and refer it from the request identifier. Then pass the relevant url from application after checking the user role. In this way we are blocking user supplied url and also validating the user role whether authorized to view the requested information or not.
- Application should use redirection function with appending the value after domain.
- Ultimately application knows where to redirect. So, when the request comes from the user, a function can be used to match the value with list of redirect urls. If everything matches then it can append only the user value to the redirect url and issue it to client.
- Restrict javascript URI such as javascript:alert(1) because it may lead to XSS attack.
- Use of regex is suggested at max that this function is needed to allowed. Filter the values and process clean requests alone.
Detection in SIEM logs
- Check for the HTTP status codes 3xx in logs such as Web application firewall, Next-generation firewall, and application logs which as collected as a business priority.
- Do a gap time analysis to statistical view to understand the frequency of connection redirected to the landing page. How often it occurs?
- Review the HTTP methods such as ( GET, POST, etc ) with the 3xx to confirm the possible actions of malicious requests.
- Check the CSP ( content security policy ) in logs, where third-party applications are trusted by the organization or not?
- Check your vulnerability scanner results whether the application has any code flaws and yet to be fixed.
- Inspect the external communicated URL ( https://example.com/#https://www.demosite.com ), Threat level with virus total, urlscan.io, Shoud i click , etc.
- Monitor your WAF traffic closely, which can indicate if a site has tampered with or not.
- If your organization is using RASP ( Runtime Application Self-Protection ), check the Unvalidated Redirects logs and check whether it is blocked or allowed.
- Validate the HTTP headers hostnames using publicly available threat intel such as ( Virustotal etc ).
- Map and detect the request originating internal IP address and check the connection is established only from one Ip address or multiple.
- If the site is legitimate and still a request is made to the malicious site, sandbox the legitimate site and review the source codes to find any malicious websites which can be hiding in encoded format also.
Also Read : URL Forward – Prevention and Detection of Malicious Forwards