You may have seen reports of an increase in .gov websites redirecting to spam or scam sites. This issue is the same as one we reported almost two years ago. Many .gov websites have open redirections that can be exploited by spammers. The example we detailed in February 2011 is actually still online, and so is the cross-site scripting (XSS) vulnerability that we found on the same page.
How did we get there?
Many websites want to warn users when they are leaving their domains. In the case of a .gov website, they want to make clear that an external domain does not carry the guarantee of being an official government website. This warning is supposed to add security for end users. Facebook also uses a warning page because links can be added by anybody and Facebook cannot guarantee the safety of those URLs.
Why are these warning being exploited?
Spammers want clean URLs to bypass URL filters and spam filters. They therefore use legitimate .gov websites to bypass security features. This warning may actually make the final URL look safer to the user by implying that the final URL has been linked and vetted, by the .gov website.
In the case of www.fmcsa.dot.gov (see our previous post), the user has only 10 seconds to read the warning before being redirected automatically. That's great for the spammer as no additional click is required to redirect the user to the spam/scam site.
These websites owners think they are adding additional security, but this decision is actually putting their users at risk. The assumption that leads to the abuse of open redirections is that the user seeing the warning has clicked on an external link on a page from the same .gov domain. Since the content on the .gov website is controlled, the external link has to be a safe link. The website creators did not think of spammers sending users directly to the warning page.
The fix
The fix is actually easy - make sure the assumption is right. This means the warning page should make sure that the redirection is legitimate - that the URL is one that has been approved.
There are a couple of way of ensuring that the redirection URL has been controlled:
Referrer
One way, not the most robust option, is to check the Referrer header to ensure the user comes from the same domain. This would stop user who clicked on a link in an e-mail, and spammers who use URL shorteners like bit.ly.
Allowlist
Another option is to store all 3rd-party URLs in an allowlist, and check against the list before making any redirection. This would prevent anybody from using the redirection with arbitrary URLs. The main downside to this approach is the overhead to manage this list every time an external URL is added or removed from the website.
Hash
The most common solution is to sign the URL. For example, replace http://www.fmcsa.dot.gov/redirect.asp?page=https://www.zscaler.com/ with http://www.fmcsa.dot.gov/redirect.asp?page=https://www.zscaler.com/&;hash=THE_HASH where THE_HASH = hash("https://www.zscaler.com" + secret). The URL is hashed with a secret key to prevent its replacement by a random address. This method is used by Facebook to guarantee the authenticity requests sent by Facebook to Facebook applications, for example.
The important takeaway for all webmasters is to understand that spammers will take advantage of any flaw in web applications. Be very careful with the assumptions you make.
How did we get there?
Many websites want to warn users when they are leaving their domains. In the case of a .gov website, they want to make clear that an external domain does not carry the guarantee of being an official government website. This warning is supposed to add security for end users. Facebook also uses a warning page because links can be added by anybody and Facebook cannot guarantee the safety of those URLs.
Why are these warning being exploited?
Spammers want clean URLs to bypass URL filters and spam filters. They therefore use legitimate .gov websites to bypass security features. This warning may actually make the final URL look safer to the user by implying that the final URL has been linked and vetted, by the .gov website.
In the case of www.fmcsa.dot.gov (see our previous post), the user has only 10 seconds to read the warning before being redirected automatically. That's great for the spammer as no additional click is required to redirect the user to the spam/scam site.
These websites owners think they are adding additional security, but this decision is actually putting their users at risk. The assumption that leads to the abuse of open redirections is that the user seeing the warning has clicked on an external link on a page from the same .gov domain. Since the content on the .gov website is controlled, the external link has to be a safe link. The website creators did not think of spammers sending users directly to the warning page.
The fix
The fix is actually easy - make sure the assumption is right. This means the warning page should make sure that the redirection is legitimate - that the URL is one that has been approved.
There are a couple of way of ensuring that the redirection URL has been controlled:
Referrer
One way, not the most robust option, is to check the Referrer header to ensure the user comes from the same domain. This would stop user who clicked on a link in an e-mail, and spammers who use URL shorteners like bit.ly.
Allowlist
Another option is to store all 3rd-party URLs in an allowlist, and check against the list before making any redirection. This would prevent anybody from using the redirection with arbitrary URLs. The main downside to this approach is the overhead to manage this list every time an external URL is added or removed from the website.
Hash
The most common solution is to sign the URL. For example, replace http://www.fmcsa.dot.gov/redirect.asp?page=https://www.zscaler.com/ with http://www.fmcsa.dot.gov/redirect.asp?page=https://www.zscaler.com/&;hash=THE_HASH where THE_HASH = hash("https://www.zscaler.com" + secret). The URL is hashed with a secret key to prevent its replacement by a random address. This method is used by Facebook to guarantee the authenticity requests sent by Facebook to Facebook applications, for example.
The important takeaway for all webmasters is to understand that spammers will take advantage of any flaw in web applications. Be very careful with the assumptions you make.
