From the NY Times:
http://www.nytimes.com/2011/06/14/technology/14security.html?_r=1&hp
The headline says it was easy to do, but down in the story an anonymous “expert” says it was highly sophisticated. From the limited details in the story, go with the headline.
I don’t know what Citi is using or looked at the details, but here is how PHP works, and why you don’t want an inexperience programmer from India writing programs for your banking applications for $2 an hour.
As you visit a web site and go from page to page, there are three main ways information is passed from page to page (for instance that you’re logged in and who you are).
The simplest way is to use “GET” options in the URL
http://artstone.org/test.php?A=15&B=25&flavor=chocolate
GET options are highly insecure – all the visitor has to do is type over the value in the URL and they can make the page do what they want.
The second way is to use “PUT” options in the HTML that are passed to the next page: (You can see this by looking at View / Page Source in the browser)
<form method=put action=”/test.php”>
<input type=hidden name=A value=15>
<input type=hidden name=B value=25>
<input type=hidden name=flavor value=”chocolate”>
<input type-submit value=”I want chocolate!”>
While a casual visitor can’t change the value of flavor to strawberry, even an inexperienced programmer can create a “POST” request filling in whatever values they want. Servers can never depend on the input values coming only from the pages they created.
The third way is Cookies. A,B, and Flavor can be stored in a cookie in the browser – so long as you stay within the same domain (artstone.org), those values get passed from page to page. That’s the method streamingradioguide.com uses.
Passing data using cookies carries some risks, but a sophisticated programmer for a bank would be well aware of them:
– cookies can be modified within the browser by the visitor
– cookies can be stolen by a rogue web site… if a hacker gets a copy of your cookie and then visits the same web site, the web site may think it is you and let them in. For a secure web site, the cookies should not be passed without encryption and should have some secondary defense against hijacking – like a very short timeout and making sure the IP address of the user hasn’t changed (much)
– cookies can be stolen when people use public wifi hotspots
The huge problem with PHP in the beginning was that it would take anything that came in and pass it to the PHP script. Things that were stored safely in a cookie could be faked by typing them into a GET string. Variables used internally with the script could be set by passing them on the GET string. If security is important, you have to check whether the variable arrived from $_GET, $_PUT, or $_COOKIE.
The NY Times story mentions two details – that the hackers entered random account numbers in the GET string and that was enough to let them view account information. That sounds pretty easy.
How could a bank as sophisticated as Citi have a web page that gives up critical personal information without the person being logged in? The second clue from the story is that the “hole” was caused by a visitor to the credit card site jumping to the main Citi web site. Somehow the Credit Card site was “Passing” the account number to the other site in a method so simple that changing a GET paramter would fool the main server into trusting the visitor really was using that account.
Passing secure information between different domains safely gets really tricky. One of the critical rules is that one domain can’t see the cookies used by another – if you could, cookie stealing would be trivial. Any web site you visited would be able to ask for the credentials to log in to any other web site.
So lets say you have two web sites, and want to safely pass users between them without creating a hole:
The most simple method is to run everything under one domain:
http://creditcard.bankofartstone.com/
http://checking.bankofartstone.com/
the same cookie can be shared by both servers and being logged into one logs you into all of them (or could be restricted to cookie that only works on one server)
Another way would be for the servers to trust each other. If checking.bankofartstone.com gets a request and the request says “This request came from creditcard.bankofaftstone.com”, just trust it. The problem is that it also trivial to fake the “Refering URL” of where the visitor came from. Refering URL can NEVER be trusted.
A multinational bank should be using techniques 1000x more sophisticated than this…. something like passing random encrypted strings that are checked against data kept on the server so that even with a copy of the cookies, the session can’t be faked – or using techniques that talk to the server without putting any of the information in the HTML request
So go with the headline. It will probably turn out to be some 13 year old from Bulgaria with too much time on his hands. The main risk to customers is with the email address, real name and account number of the customer, someone could create a really convincing fake “phishing” email to convince you to login to your bankofartstone account, giving up your password to the kid in Bulgaria – fortunately, Google Mail and the current generation of browsers make phishing attacks against a major bank much more unilkely to be successful. But once that information is out there, computers can remember everything forever.