Don’t trust the client

Citigroup Hacked

I was recently came across this article about a successful hacking attempt made on Citigroup. In a nutshell the hackers logged into a Citigroup related website and simply changed the query string to access other user’s account data.

For example let’s say I just logged into my citicard account and I see this in the browser bar:

http://www.somecitisite.com/Account/Home?accountNumber=1234

Since I’m legitimately logged in my account number is probably “1234” . All the hackers did was change the “1234” above to something like “5678” to see user “5678”s data.

http://www.somecitisite.com/Account/Home?accountNumber=5678

Write a script to automate that process and parse the response into a table somewhere and you’ve just stolen your self a lot of credit card information.

Let’s be completely honest the above hack is extremely simple, even someone with very limited computer knowledge could likely pull this off. Go ahead and Google “facepalm” for an accurate illustration. This all brings up an interesting point:

Don’t trust the client

I would say that most web deveopers out there wouldn’t fall for the simple query string example that destroyed Citi’s “security”. But consider another example:

  • Developer makes page to display secure information
  • Developer needs sensitive data if that page is posted back
  • Developer realizes that information shouldn’t go in the address bar so where should it go?
    • Bad idea, in a hidden field like:
<input type="hidden" name="AccountNumber" value="1234">

 

 

The above case is almost identical to the citicard case, the client is able to manipulate “trusted” infomation.

Here is another twist on the above example:

  • Developer makes a page to display credit card information with a drop down on it used for selecting an account for modification.
  • User enters information into the form and chooses the account to modify from the drop down list
  • List looks something like this:
<select name="account">
  <option value="1234">Account 1234</option>
  <option value="4321">Account 4321</option>
</select>

This is no more secure than any of the other examples because a user can ALWAYS POST whatever data they want back to the server. Here I am doing this in the Firefox extension Firebug on the Amazon.com order page:

amazonhack

Luckily for Amazon the only one that is going to be upset if I change this value (assuming they don’t check) is me when my package gets shipped to FakeValue.

An even better tool for messing around with POST data is another Firefox extension called Tamper Data which basically does the same thing but makes POST values easier to manipulate. Firebug does a better job of illustrating what is actually going on for demonstration purposes.

Leave a Reply

Your email address will not be published. Required fields are marked *

Proudly powered by WordPress | Theme: Cute Blog by Crimson Themes.