Understanding SQL Injections: Website Security Failure Case Study

The Forensic team at Foregenix are used to getting cases involving SQL Injections through the door – in fact, not only is SQLi one of the ‘oldest’ tricks in the book, it is still one of the most common attacks seen.

How Poor Website Security Practices Lead to SQL Injection Attacks

This is largely down to the following factors:

• Website forms are very common, and often are not coded properly.
• Hacking tools used to find weaknesses in such forms are easily available online.
• Even inexperienced hackers can cause harm.
• They are appealing attacks to hackers due to the level of possible access
  • A web code weakness can reveal root level access of web servers. From there, attacks on other servers within the network can be carried out.

What Happened?

In a recent case, several examples of bad practice came together in a single case that resulted in an online business getting hacked.

Firstly, the payment input form on the website was poorly coded, leading to hackers easily being able to perform an SQL Injection. This could have been prevented early on by a securely coded form and by implementing a Web Application Firewall that is able to detect and prevent SQL Injection attacks.

Secondly the website was protected using a simple, weak password. We generally recommend two-factor authentication - or if passwords are the only option, that they should be long and complex, containing as many different types of characters as possible (uppercase, lowercase, punctuation etc). In this case, a password that consisted of an everyday 5-letter word, a capital letter and a single number was implemented. It is estimated that this would take a couple of minutes – at most – to brute force. (Read more about Brute Force Attacks & password best practice.)

Finally, the payment process employed by the company was an old school “store and forward” method. Card data collected through the insecure input form was stored and accessed by employees through admin accounts (using the weak credentials) within the website’s backend, then manually input through a PDQ machine. Card Data Scanning would have alerted this as a risk.

What was put at risk?

The number of credit cards exposed due to this chain of bad practice was within the region of 35,000 to 40,000. The potential liability cost for this amount of data loss would reach the six-figure mark in GBP/USD/EUR easily.

We understand that in the grand scheme of things, Web Developers often put security towards the end of their to-do list. This is why we encourage Web Developers to reach out to a security specialist that can assess the risk and educate them and their clients to the very real danger of a data breach and the subsequent cost of an investigation that could have a catastrophic affect on their business.

Please contact us to find out how we can help you protect you clients' online businesses with effective security.