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.
No comments:
Post a Comment