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
Top Github Contributions
Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Showing posts with label OWASP. Show all posts
Showing posts with label OWASP. Show all posts
Thursday, March 17, 2016
Tuesday, March 1, 2016
Insecure Direct Object Reference 101
As a web developer have you ever gone through a Code Review or used the OWASP Top 10 and gotten to the "Insecure Indirect Object Reference" and wondered, what does that mean?
Well, Adam Logue recently posted a blog about a real world example of Insecure Direct Object Reference going bad.
The blog talks about a vulnerability they discovered on TGI friday's mobile website. There was an HTTP GET request getting sent to the TGI Friday server that passed a parameter (in bold below) called 'acctid'.
GET /alchemy-master/ws/TgifAccountActivity.asmx/AccountActivity?stoken=8970853507518770&acctid=123213123
This 'acctid' was an account id of the user and could be used to redeem for free food at the restaurant. Thus all an attacker had to do was replace their account id with some other user's account id, and then instead of redeeming their own points, they would be redeeming somebody else's points. Thus FREE FOOD! And this is a great example of an Insecure Direct Object Reference. Poor programming.
Here are 2 ways this could've been prevented if you were the web developer writing the code.
a.) Check access. Before committing those changes to the database, confirm ... does the account id match the user logged in? If no, deny.
b.) Use indirect object references. In this example, let's say the user logged in has 3 gift card account numbers (1=43554345, 2=344234, 3=4444422). Instead of passing the actual account numbers as query string parameters (43554345, 344234, 4444422) pass indirect/mapped references such as the numbers 1,2,or 3 ... and then when you get to the database unmap and determine that gift card 1=43554345 , 2=344234, and 3=4444422. This way the attacker could only inject the numbers 1,2, or 3 which all belong to this user, and thus the attacker could not inject an account number of another user.
More about neonprimetime
Top Blogs of all-time
Top Github Contributions
Copyright © 2015, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Well, Adam Logue recently posted a blog about a real world example of Insecure Direct Object Reference going bad.
The blog talks about a vulnerability they discovered on TGI friday's mobile website. There was an HTTP GET request getting sent to the TGI Friday server that passed a parameter (in bold below) called 'acctid'.
GET /alchemy-master/ws/TgifAccountActivity.asmx/AccountActivity?stoken=8970853507518770&acctid=123213123
This 'acctid' was an account id of the user and could be used to redeem for free food at the restaurant. Thus all an attacker had to do was replace their account id with some other user's account id, and then instead of redeeming their own points, they would be redeeming somebody else's points. Thus FREE FOOD! And this is a great example of an Insecure Direct Object Reference. Poor programming.
Here are 2 ways this could've been prevented if you were the web developer writing the code.
a.) Check access. Before committing those changes to the database, confirm ... does the account id match the user logged in? If no, deny.
b.) Use indirect object references. In this example, let's say the user logged in has 3 gift card account numbers (1=43554345, 2=344234, 3=4444422). Instead of passing the actual account numbers as query string parameters (43554345, 344234, 4444422) pass indirect/mapped references such as the numbers 1,2,or 3 ... and then when you get to the database unmap and determine that gift card 1=43554345 , 2=344234, and 3=4444422. This way the attacker could only inject the numbers 1,2, or 3 which all belong to this user, and thus the attacker could not inject an account number of another user.
More about neonprimetime
Top Blogs of all-time
Top Github Contributions
Copyright © 2015, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Subscribe to:
Posts (Atom)