They’re simple, highly exploitable, and when done ‘correctly’, can be deadly…or at least incredibly costly for an organization. They’ve been used in hundreds of thousands of attacks and have cost companies and organizations millions – at this point billions – in lost or stolen funds as well as other breach costs.
The nightmare exploit in question? SQL injection (SQLi) attacks. They’re one of the most common vulnerabilities found on the web; attacks are easy to carry out and can be highly valuable: One little piece of injected code and the organization’s entire database could be used to spoof identities, tamper with existing data, allow the complete disclosure – or complete deletion – of all system data, and give the hacker full administrative access to the server.
Hackers have gotten more advanced over time, developing automation tools used to scour the web in search of sites vulnerable to SQLi attacks, but organizations have put their focus – and resources – on negating against other types of attacks, allowing hackers to focus in on more easily exploited vulnerabilities.
When it comes to SQLi attacks, history has done a great job of repeating itself. In 2009, the Heartland Payment Systems breach that leaked 130 million credit card numbers was accomplished through SQL injection. The group of hackers responsible for the Heartland breach, led by Albert Gonzalez, also masterminded attacks on Dave & Busters, OfficeMax, Boston Market, Barnes & Noble, and several other businesses – all confronted by SQL injection attacks.
And we still have yet to learn from our history of insecurity, it appears. Just in the last few weeks, two sites have been burdened by SQLi attacks, both leveraged by the same hacker. First, the web TV service Boxee.tv was exploited in mid-March, and an 800 MB database file containing names, 172,000 e-mail addresses, message histories and easily-cracked passwords for more than 158,000 forum users was dumped online.
Yesterday, the same hacker exploited an SQL vulnerability on BigMoneyJobs.com, a large job seeker site, exposing the PII (personally identifiable information) of over 36,000 users, including home addresses, emails, site registration info and plaintext passwords.
Though it’s been widely reported on and warned about, most organizations have yet to fully understand the impact of SQLi attacks on their business structure. A newly released Global Threat Intelligence Report from the NTT Innovation Institute offers tangible proof, through case studies, of the real damage that can be done through improperly sanitized databases.
The report highlighted a prolonged SQL injection attack on an unnamed financial institution, which ended up costing them a total of $196,000 in charges related to the breach. Had they been employing an automated tool dedicated to source code analysis and static application security testing, the report stated, the attack wouldn’t have occurred in the first place.
Top 5 Best Practices for SQL Injection Prevention:
#5: Adopt a principle of least privilege, allowing employees, customers, partners, etc. only the minimal amount of access to organizational
#4: Whitelist validation for all input fields to allow the authorization of only the inputs you define
#3: Create parameterized queries using bound, typed parameters as opposed to dynamic SQL statements
#2: Always code with the famous Microsoft mantra in mind: All Input Is Evil Until Proven Otherwise
#1: Be proactive: Review your current code for instances of SQL injection vulnerabilities – and constantly and consistently check new code for the same.
Static Application Security Testing, or SAST, is the best proactive approach to preventing SQL injection and when integrated in the development build cycle, can prevent them before they’re ever released into the world.
To learn more, read our How-To Guide On Visualizing & Effectively Removing Your Vulnerabilities here.