In cyberspace, vulnerabilities exist in multiple types and forms and this is what makes them hard to track, test, and fix. For through-and-through API security, it’s crucial to have awareness of all the famous and unfamiliar threats.
One such threat/vulnerability is Open redirect. Responsible for the execution of XSS payloads and phishing, this security loophole category of extensive web application vulnerability needs the undivided attention of AppSec security experts.
Definition of a Redirect
If unattended and unprotected, redirects are prone to redirect attacks. Knowledged malicious actors or attackers can exploit them and use them as a means to misguide the user/client/visitor.
What is an Open Redirection
It is a redirect, generated by the client, which isn’t valid or filtered properly. Such redirects are unsafe and leave scope for attackers.
There are certain traits defining safe and unsafe redirect usage. For instance, encrypted websites redirecting clients only to a fixed URL is considered a safe practice while websites allowing clients to define or specific redirect destination is not considered safe. Such redirects are known as open redirects.
In addition, if a redirection uses user-defined parameters, it can also be called safe. But if the same redirect doesn’t feature filtered or validated inputs then it becomes unsafe as there is a possibility of an attacker inserting malicious content into the input.
To sum up, developers using dynamic redirects must consider them untrusted by default and enforce strong security measures. If that’s not happening, the threat attacker will have a chance to divert the redirect to a corrupted/risky site.
Speaking of its classification, Open Redirect OWASP Top 10 2013 list position was A10. Netsparker calls this threat of medium danger.
Let’s understand the concept using an open redirect vulnerability example.
Say, you own a domain name test.com. To exploit users of your domain, a skilled threat actor can create a URL as mentioned below.
Redirection on visiting a link
being a response header, it may leak the location-related details of the newly generated resources.
As you can conclude from the above, if the user fails to spot any malicious content present in the URL, the results could be severe.
Adding the JS-based checks/validations instead of server-side restrictions to your pages makes your web pages more prone to redirect attacks because the attacker can always disable them from the client-side.
Ways Open Redirections Coule be Taken in Use by Threat Actors
There could be multiple methods of exploitation through it, such as:
Sending the Victim to Risky/Malicious sites
It's a very common practice. What happened during the phishing scam is a part of this attack. The threat actorr generally uses an exploited browser or a CSRF attack prone page as its aid in this case.
When such content seems to be offered by a trusted resource, people fall into the trap. The most common example of an attack happening this way is a corrupted bank/financial service site redirecting visitors to a page featuring CSRF exploit.
Verified/considerably-reliable websites featuring open redirect endpoints act as a platform for attackers to carry out phishing attacks. Using them, attackers will introduce malicious links on a trustworthy site or can forward phishing emails featuring a corrupt URL. Matching a lot with the original one, these e-mails will redirect the end-user to the wrong/risky URL.
As the attackers work heavily to disguise the authentic site and use encoded parameters that are extremely lengthy, recognising them could be tough many times. This is why phishing attacks succeed most of the time. It’s so strong that even the sites with well-established authentication flow are likely to be its victims.
It is used against internal entities and is only achievable when redirection takes place on the internal host. SSRF often gets paired with path traversal and when this happens, threat actors can gain internal access.
Token Theft Scenario
One not-to-forget use case of open directs is stealing user tokens. This possibility occurs in an SSO-based application featuring open redirection. Token theft attack lets attackers enter a system like verified users and use them to carry out session hijacking and many other attacks.
Measures to prevent open redirects
Unverified user input processing is the main cause why open directs become available for exploitation. Here, the concerned input is URL query strings. To reduce the incidences and impact of this vulnerability, the below-mentioned preventive techniques work best.
Make sure user-driven or defined data is used in the least possible quantity within a URL. Whenever such data is used, proper sanitization should be done. For more details, we recommend referring to this Cheat Sheet by OWASP.
Creating a whitelist of all the allowed redirect locations and redirecting other to a default URL is a good open redirect prevention methodology.
One viable approach to deal with the vulnerability is creating a distinct ID for every redirect target. Doing so makes URLs free from user-controllable names.
API security experts also suggest choosing an appropriate referrer-policy header so that referrer URL exposure is limited and token leak risks are less than before.
One must keep the use of forwards/redirects limited and completely secured.
When accepting user-created URLs is crucial, it’s wise to ask for a short URL name or token. This attribute should be completely mapped out on the server-side.