The Open Web Application Security Project (OWASP) has released their top 10 web security risks and number 10 is unvalidated redirects and forwards. This problem is caused by allowing untrusted data from a URL to decide the user’s destination page.
This security risk can be used in combination with social engineering for malicious purposes such as tricking the user into downloading malware, redirecting to a phishing site, or using forwards to gain access to unauthorized pages. The malicious URL is able to gain the user’s trust because the original site’s name appears in the URL.
Defining the Problem
Here’s an example of a typical requirement for a website to illustrate how this risk could be misused. Let’s assume a website needs to be able to forward or redirect a user to another internal page or external site while recording the click or requiring the user to log in. For example:
The main concern with this redirect is that it is using a parameter, ‘url’ in this case, to decide the destination. While this example may be harmless, someone could easily use the redirect feature to send out a different link:
Several large companies have already been the target of similar phishing attacks using this kind of exploit including Google, AOL and eBay. For example, eBay was targeted with a phishing attack with a link similar to:
OWASP outlines unvalidated redirects and forwards as follows:
It should be noted however that Google does not consider URL redirection to be a serious exploit by stating in their vulnerabilities rewards program:
“We recognize that the address bar is the only reliable security indicator in modern browsers; consequently, we hold that the usability and security benefits of a small number of well-designed and closely monitored redirectors outweigh their true risks.”
Detection & Prevention
As the OWASP definition states, detecting this problem should be relatively easy. Any code that uses redirects or forwards should be reviewed. A simple global file search in the site’s directory for code that can redirect or forward a user should reveal all possible vulnerabilities. For example, a site that uses PHP would utilize the header function for redirection.
A simpler, although probably not as thorough, method would be to spider the site to search for redirects (300 – 307 HTTP code). There are companies that provide open redirect detection services.
In either case, if a parameter decides the destination as in previous examples it should be inspected. OWASP has three simple steps to prevent open redirects or forwards:
1. Avoid using redirects or forwards.
2. Don’t use user input to determine the destination.
3. If destination parameters can’t be avoided, ensure that the supplied value is valid and authorized for the user.
While it may not be possible to completely avoid using redirects or forwards, they should not use unvalidated data. There are several approaches to prevent using unvalidated data:
– Create a whitelist of allowed pages or external sites (blacklists should not be used).
– Only allow internal redirects or forwards in appropriate circumstances.
– Use a dictionary to map values to valid pages or sites (e.g. home -> home.php).
– Verify the referrer of the link if reported.
– Disable unused redirects.
– Scan and ignore all http requests for the unused redirect.
While there are other possible phishing scams, open redirectors create the possibility for people with malicious intent to gain the trust of a user who might click on the link. They can and have been used to trick users into revealing their passwords and downloading malware.
Like most other security concerns, a layered security approach should be taken. If redirects or forwards are needed, detecting and securing open redirects and forwards should be fairly easy with a few different options listed above.