According to the New York times, thieves were able to capture the names, account numbers, e-mail addresses and transaction histories of more than 200,000 Citi customers, using the Citigroup customer web site. This isn’t the first time a financial institution has had its data compromised. What is so alarming about this particular security breach was how simply the web site was exploited. The article explains how the thieves were able to get at the data:
In the Citi breach, the data thieves were able to penetrate the bank’s defenses by first logging on to the site reserved for its credit card customers. Once inside, they leapfrogged between the accounts of different Citi customers by inserting vari-ous account numbers into a string of text located in the browser’s address bar.
Citigroup made a basic mistake, that surprisingly, is often made by web developers — yes, I’ve made this mistake before, but was lucky to have it caught by QA before going to production. When developing a multi-tenant web-based application that will serve up data to multiple customers, it’s important to make sure those customers can’t access one another’s data. Data needs to be sequestered and accessible to only it’s owner. This blunder is common enough that it’s known as “failure to restrict URL access to data” and is number eight on the OWASP list of top ten web site vulnerabilities.
What can we learn from Citigroups experience?
One security expert familiar with the investigation wondered how the hackers could have known to breach security by focusing on the vulnerability in the browser. “It would have been hard to prepare for this type of vulnerability,” he said.
While I understand that Citigroup needs to protect itself by not revealing too much, this security probably should have worded the vulnerability differently. It is quite possible to prepare for this type of vulnerability, but it requires a significant amount of testing throughout the web-based application for this specific vulnerability. Each and every page needs to be tested for cross-customer leakiness, and that takes a considerable amount of time. Believe me, it’s time well spent.
The expertise behind the attack, according to law enforcement officials and security experts, is a sign of what is likely to be a wave of more and more sophisticated breaches by high-tech thieves hungry for credit card numbers and other confidential information.
The fact that this vulnerability was exploited using a web scraper shows how long this type of vulnerability has been around. Most web developers, including myself, have built a script to scrape a web site at some point in their career. Before APIs were as ubiquitous as they are now, this is how we often pulled data from a web site (with the site owner’s permission, of course.) This breach exploited one of the most common vulnerabilities using web scraping techniques, both of which have been around since the web came into existence. These hackers have been around since the old school days, which makes them all the more sophisticated and dangerous.
A good web development team will know how to build safeguards into their web-based applications to protect against the most common vulnerabilities. It is a well known fact that most web site breaches exploit vulnerabilities in the web-based application itself (i.e. SQL injection, cross site scripting). But, even the best web developers are prone to overlook these vulnerabilities and should have their applications tested thoroughly by a QA team trained in finding them. And if the web-based application is going to be handling personal data of a sensitive nature, a security scan should be performed by both a security expert and an automated scanning process.
As web developers we are often entrusted with building web-based applications that will handle sensitive data for multiple customers. Our responsibility to our clients is to educate our clients about online application security and convince them to allot enough budget to develop and deliver a product that puts security first. Often times these exploits can be traced back to a web development process that was rushed or under-funded. The responsibility should not fall entirely on the web developer given the constraints a client will often impose. Ultimately, it’s the client’s responsibility to make security a priority and hire qualified web developers. If web developers and their clients don’t discuss security during a project, were just going to see more and more breaches like this one.
What can you do to protect your web site or web-based application from security breaches?
- Review the OWASP Top Ten Application Security Risks and thoroughly test your web-based application for each vulnerability.
- Hire a security expert to carefully review your online applications. Then task a web developer with working alongside the security expert and implementing their findings.
- Monitor your server logs for any unusual activity. If you are not sure what to look for in the server logs, sign up with a third-party service, like Scout, that can monitor the logs for you.
- Do regular vulnerability scans of your web sites and online applications. Again, there are third-party services, like McAfee SECURE, that can do this for you. If you handle credit card data, your processing company will require you to do this (if they haven’t already).
- If you are handling credit card data, consider using a third-party company, like PayPal, with the tools and services to help secure credit card and other information using their web services so you don’t have to.
Photo credit: pylbug
