This is the tenth and final in a series of posts on the OWASP Top Ten
Redirection scripts (called Transfers in .NET) do play a very useful role in modern web application architectures today. OAuth for instance, relies on browsers being bounced from a resource request to a login screen, and then back to the resource. This is often achieved by using redirection scripts.
But it's unlikely you've ever seen the fleeting 302 response that signifies to your browser that it's being redirected. It's exactly this type of script though that can be used by a hacker to either escalate their privilege or phish for unsuspecting users.
Let's say we have a redirection script on our plunger website:
The 'target' variable should be the URL we are redirecting users to. We're wrapping all links on our website in this redirection script, so that we can track when our users click on links and where they go off to. Great! We're tracking our users' behaviour on our website, our marketing department love our geekyness!
Along comes our hacker though, and writes a spam email to some of our users which contains a link. When our scrupulous users look over the link in the email (which appears to have come from our CEO regarding a once in a lifetime opportunity to own a golden plunger) they see the following:
Well that looks legitimate
Our redirection script likely doesn't make use of any of the parameters the hacker has added to the URL ('secureoffertoken','jresp','price' or 'openjs'), in fact that's rather the point. The additional parameters make it look legitimate, and the fact that the link starts with the hostname of our webserver makes it even more legitimate.
But hidden on the end, way past where any mere mortal would normally bother to check (and is possibly contracted out of the hover-over tool-tip anyway) is the actual destination of this URL… evil.com.
Once there, the hacker could display a page that closely resembles ours and that asks users for their login credentials, it could install plugins or (to be fair) pretty much do anything they want with our users browser. Probably not what we want for our valuable users, after all it's our reputation that will be tarred, not the hackers!
So how do you guard against this type of attack
- Don't use redirects if you don't have to. It seems obvious, but if there is another way of achieving the redirection without needing the browser to do it for you, then probably that should be a preference.
- Don't use URLs as the target for a redirection. If you changed the URL to a page name (i.e. target=logout or target=payment) then behind the scenes your script can translate that into "oh, they want the payment page, it's over here..". This means an attacker can't give you an arbitrary link to redirect off to.
- Validate all redirections. Sometimes you have no choice but to include a redirection script, and adding in a parameter is just too cumbersome given the size of your site. In this case you should add in some protections to make sure that the redirections are only going to hosts you approve of, and are permitted at their authenticated session level.
Th-Th-Th-Th-That's all folks!
Thanks for joining me on this series of posts on the OWASP Top Ten. Hopefully you've found it useful and interesting to briefly look at web services through the eyes of a hacker, and now understand the simple steps you can take to ensure your projects are better protected.
If any of these topics affected you or your business, then please do comment below or tweet me!
Join the conversation on Twitter: @OWASP #OWASPtop10 #Redirects
(Editor's note: we acknowledge the cool work being performed by the great people at The OWASP Foundation and by those involved in the OWASP Top Ten Project that inspired these posts. Jonathan Jenkyn's full series on the OWASP Top Ten can be conveniently accessed and enjoyed via the hyperlinks below)
1st post - Injection
2nd post - Broken Authentication and Session Management
3rd post - Cross Site Scripting (XSS)
4th post - Insecure Direct Object References
5th post - Security Misconfiguration
6th post - Sensitive Data Exposure
7th post - Missing Function Level Access Control
8th post - Cross-Site Request Forgery (CSRF)
9th post - Using Components with Known Vulnerabilities
10th post - Unvalidated Redirects and Forwards