It’s not uncommon for web developers to use redirects for various functions on a website. For instance, after a user fills out a registration form, the user is redirected to the URL they were the last visiting. This functionality is convenient for users so that they can return to what they were doing, but if used improperly, this redirection functionality can be used by cyber attackers in phishing campaigns.
Redirecting Users Using URL Query Strings
URL redirects are normally used bypassing the previous page or location in a query string variable. The following URL is an example of what a redirection would look like when a user clicks on a “Sign Up” link that takes them to a registration form :
mysite.com/registration?redirect=mysite.com/homepage
In the above URL, the user is sent to the registration page but the “redirect” query string variable contains the URL “mysite.com/homepage.” As an observer (and possible attacker), you can assume that after the registration form is filled out, you are then redirected to the web application’s home page. An attacker would test this theory by signing up on the registration page and observing the redirect in a browser and server responses.
Using This Functionality for Phishing
The goal for an attacker during a phishing attack is to gain information from the user. Attackers use many forms of phishing, but the main way attackers gain access to user credentials or private information is to trick users into clicking a link from an email that takes them to an attacker-controlled web page. This web page looks and feels like an official site, and if the targeted user does not realize the domain is not the official one, they can be tricked into sending information to an attacker. This information could be sensitive private data, financial data or credentials that give an attacker access to a private system.
For example, an attacker might trick a user into clicking a link in an email that brings the targeted user to a page that looks like PayPal. The attacker will steal the PayPal logo, CSS and JavaScript files, and the PayPal homepage layout to trick users into sending the attacker their PayPal credentials. PayPal was one of the first sites targeted by attackers that use the stolen account to steal money or product from a vendor.
The PayPal phishing attack worked well for years, but corporations have trained users to identify these attacks. Training has made it more difficult for attackers to be successful with emails that contain links to phishing sites. Email filters and cybersecurity applications that detect phishing attacks have also made it more difficult for attackers.
Many DNS-based web filters and email cybersecurity applications detect links in an email message and filter quarantine if the message contains a domain flagged as a risk. When web developers have open redirections, attackers can use the web application to evade phishing filters and trick users into thinking the link is safe.
As an example, “mysite.com” could be a site where users log in to their account and get access to documents stored on the web servers. A link to the website would look like this in an email message:
<a href=”mysite.com”>Click here</a>
When you hover a mouse over this link, the “mysite.com” link will display. Users see this link and will trust to click it and be brought to the “mysite.com” domain in a browser. Any cybersecurity email filters will allow the email to reach your recipient’s inbox, and DNS-based web filters won’t block the site.
With open URL redirections on “mysite.com”, an attacker can send the following link in an email:
<a href=”mysite.com/signin?redirect=attackersite.com”>Click here</a>
The above email is a simplified version of what the attack link would look like, but you can see that now the redirect sends the user to “attackersite.com” after the user signs into the application. This trick works because users trained to detect phishing sites see the safe site and click the link. It also evades some cybersecurity email filters, and DNS-based content filters would still see the safe “mysite.com” as the accessed site. The user is not redirected until after they open the original site in a browser.
In this example, the attacker would create a page that looked exactly like the official “mysite.com” site. The page could ask the user to log in again and trick users into giving up credentials by showing a message that their original login attempt was unsuccessful. The attacker could trick the user into entering sensitive information such as a social security number or credit card number. If the user does not notice that the URL in the browser changed, then the attacker could phish numerous data points from the user.
Protecting Your Site from Being Used as a Phishing Site
Open URL redirection issues are luckily easy to fix. The best way to stop your site from becoming a vector for phishing is to use a whitelist of acceptable URLs that can be used in the redirection functionality. For most websites, the redirect is expected to send the user to another page on the local domain. For the “mysite.com” example, any redirections should be sent to a page on “mysite.com” after the user fills out the registration form.
The web developer can solve this problem by adding a whitelist to the available URL redirections. If the domain or URL does not match the whitelist, the user can be redirected to the home page on the local “mysite.com” domain. Another option is to add a prefix to a page added to the redirection query string variable that matches the local domain. Then, use only page names in redirection URLs and add your site domain as a prefix. An attacker who adds a malicious URL to the query string would then send users to a URL that would fail.
If a whitelist is not possible, a second strategy is to create an interstitial page. The interstitial would display before the user is redirected. The page displays a message telling users that they are being redirected to a URL that is not located in the local domain. Users would then know that they are no longer located on the “mysite.com” domain when they access the attacker’s site.
For any future development, developers should be sure that open redirection is not an issue that could lead to phishing. Whitelisting and being aware of possible phishing attacks using your site will help eliminate some cybersecurity risks for your users.
