Today there was a
Krebs article on Spammers abusing .gov domains. The main focus of the article is on urls like the one below, which he referred to as "open redirects", that take a
url as a parameter and redirect the user to that url.
http://www.mywebsite.com/redirectaspx?url=www.evilwebsite.com
I thought it was worth talking a bit more about this situation. The OWASP Top 10, a very popular list of the top 10 web vulnerabilities that web developers should look for and remediate, describes this as an
Unvalidated Redirect. Since it's listed in the OWASP Top 10, this is something that for example
PCI compliance standards require be checked for an remediated immediately if identified. (E.g. PCI DSS says
"6.5.1 through 6.5.10 were current with industry best practices when this version of PCI DSS was published. However, as industry best practices for vulnerability management are updated (for example, the OWASP Guide, SANS CWE Top 25, CERT Secure Coding, etc.), the current best practices must be used for these requirements.").
There are a few scenarios I can envision where developers may need a "redirect" parameter ...
1.)
Login Page Returns - If the website you're building has an area where you login, and you try to get to a page but you're not logged in yet or your session expired. As a developer you redirect the user to the login page, but you want a "url" parameter that can return the user back to the page they were on after successfully authenticating.
2.)
Workflow Navigation - If the website has a complicated workflow or user flow through the site and you need to know which page to go to next you might need a url parameter. For example if you need to go from a product page, to a shopping cart page, to a checkout page, to a receipt page, but you can go back and forth and perhaps inject upsell pages, etc.
3.)
Click Tracking - If you are sending a user to another website (perhaps for an advertisment, or to a 3rd party, etc.) and you want to be able to track who clicked thru or how many times a page was clicked to in order to collect revenue or track analytics, then you might want a centralized "redirect" page that takes a url, records all the analytics/statistics, and then redirects to the final location.
Having a url parameter like above for any reason in which you are not validating can actually create multiple security concerns such as ...
1.)
Impact Trust - User are getting security education from their companies. They have been trained to hover over hyperlinks before they click. Users generally are looking at one thing, the primary domain name. If they see www.mywebsite.com , and it's spelled correctly, then they'll trust it. The problem with unvalidated redirects is that the primary domain is your good one, www.mywebsite.com, so a user hovers and trusts it, but when they click they are actually taken to an untrusted evil site.
2.)
Phishing - A common practice is for an attacker to clone or make a copy of your website and host it on their own website. For example, they might make a copy of www.mywebsite.com (copy the pages, images, styles, content, etc.) and host it on another similar url such as www.my-website.com. Then they'll use your vulnerable redirect page
http://www.mywebsite.com/redirectaspx?url=www.my-website.com
Then they send it in an email saying 'Urgent, Please re-enter your credentials". The user sees the email, hovers over the link, see's that it's from the trusted www.mywebsite.com , clicks it and ends up on the evil website (www.my-website.com) that looks identical (cloned) to the trusted site. The only difference is that hyphen in the url. The user doesn't notice the hyphen since everything else looks identical, so the user enters their username & password, and since the user is actually on the attacker website ,the attacker has just stolen the user credentials.
3.)
Install Malware - Similar to the phishing example, if the attacker can get the user to hover over the trusted url, but be redirected to the attacker's website, the attacker can write javascript or some plugin code on their evil site that installs malware onto the user's workstation. And the user really did nothing wrong, because they thought they were clicking on the trusted website link.
This issue can be fixed by web developers with a few simple methods ...
1.)
Eliminate User Controlled Redirects - The obvious solution is to eliminate url parameters that are editable by the user. For example, don't use query strings or cookies but instead use server-side session variables, database tables, or some other area that prevents a user from even modifying the value.
2.)
Url Maps - If the parameter cannot be eliminated, then another option is creating url maps. Basically if you have a database table or similar that holds all possible urls that can be redirected, and each is given an identifier
1 - http://www.google.com
2 - http://www.ebay.com
3 - http://www.amazon.com
Then you use the identifier (1,2,3) to redirect such as
http://www.mywebsite.com/redirectaspx?url=2
Then the user would get redirected to www.ebay.com because the url #2 is chosen. And this way the attacker can only inject urls that you control and allow (1,2, or 3) and cannot inject any evil urls.
3.)
Domain Whitelisting - Another valid solution besides url mapping is to whitelist domains. Thus you have a database table or regular expression that every url is run through BEFORE the redirect actually occurs.
Sample Regex: (?i)^http(s|)\:\\\\www\.(mywebsite|google|ebay|amazon)\.com
On the server-side you would take the url that was passed into the parameter, and valiate is matches the whitelist or regular expression prior to redirecting. This way again an attacker can only enter in a url that matches the ones you allow and everything else is blocked. PLEASE NOTE this also applies to same-origin redirects. Even if your parameter is just redirecting to relative paths, you should also perform whitelisting or validation to ensure a.) That the attacker hasn't found a way to redirect away from your origin b.) That the attacker hasn't found a way to upload a new page to your website and redirect to that new page.
Thus Krebs article was very relevant to a common issue that impacts many websites and web developers. Please take the time to check for these types of vulnerabilities, take them seriously, and remediate them.
u>More about neonprimetime
Top Blogs of all-time
- pagerank botnet sql injection walk-thru
- DOM XSS 101 Walk-Through
- php injection ali.txt walk-thru
Top Github Contributions
- Qualys Scantronitor 2.0
Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.
