14 years of SQL injection history and still the most dangerous vulnerability

Ever since the advent of the computer, there have always been people trying to hack them. William D. Mathews of MIT discovered a flaw in the Multics CTSS password file on the IBM 7094 in 1965. John T. Draper (“Captain Crunch”) discovered that a cereal toy whistle could provide free phone calls around 1971. The Chaos Computer Club, the Cult of the Dead Cow, 2600, the infamous Kevin Mitnick, even computing godfather Alan Turing and his World War II German Enigma-cipher busting Bombe, all and more have participated in hacking computers for as long as computers have existed.

Through the 1980s and 1990s, the world began to see the advent of the personal computer with Windows, the internet, and the world wide web. Telephone lines in millions of homes began screaming with the ear-piercing tones of dial-up connections. AOL, CompuServe, Juno, and more began providing home users with information portals and gateways to the web. The information age was born; as was the age of information security (and, indeed, insecurity).

As websites began to form by the thousands per day, so did the technology behind them. Websites went from merely being static pages of text and images to dynamic web applications of custom-tailored content. HTML, CSS, and JavaScript grew into bigger and better systems for stitching content together in the browser, and the browser itself evolved, through Internet Explorer, Netscape, Firefox, Chrome, and more. PHP and Perl CGI, among others, became the languages of choice for web server scripting to real-time generate the HTML and other elements browsers would render. Structured Query Language database systems came and went, some of them stayed: Oracle, Microsoft SQL Server, but the MySQL database server became the most popular. In fact, a lot of things came and went – Dot-Com bubble, anyone? – but one thing always remained: web application security.

The (In)Security Watchmen – OWASP and Others

In December 2001, the Open Web Application Security Project (OWASP) was established as an international not-for-profit organization aimed at web security discussions and enhancements. For practically their entire existence, OWASP has kept track of perhaps every type of hack that could be done. Everything from social engineering, poor authentication systems, cross-site scripting, SQL injection, general software vulnerabilities, and more, OWASP kept track and encouraged the web community to continually secure everything as best as possible. As with the growth of the world wide web, things came and went, and with the efforts of OWASP and its participants, the hacks that were popular were no exception. However, of all types of security intrusions, almost the only one that constantly and consistently remained in the top ten were injections (usually exclusively database SQL).

An injection is defined by OWASP as “when untrusted data is sent to an interpreter as part of a command or query.” Typically, this grants an attacker unauthorized access to data within a database through a web application or grants them the ability to insert new or alter pre-existing data. This is done because, quite simply, a web application uses the user input to directly insert it into a database query without any type of sanitization.

Immediately, one thinks, Why would anyone allow unsanitized data to enter a database query? Indeed, if we had an answer for this question we would probably be receiving billion-dollar U.S. Department of Defense contracts right now.

Interlude: What Is an SQL Injection?

We want to pause before we continue further and ensure that you, our treasured readers, understand what an SQL injection is and the technical aspect behind it. For purposes of brevity and focus, we will assume from here on that you understand the concept of an SQL injection (SQLi), how it works, and basic ways to prevent it.

If not, first read the SQL injection section in Invicti Learn, the article What is SQL injection?, and the SQL injection cheat sheet, and keep an eye out for our future publications, as we continue to look into this constant security problem. It is important that you understand the technical side behind an SQL injection, as it helps to highlight the simplicity and, indeed, the absurdity of the repetition of this security vulnerability.

Resume Play: A History Lesson about SQL Injection

For nearly as long as relational databases have existed, so too have SQLi attack vectors. Or to be precise, since December 25, 1998, when Jeff Forristal, a security researcher also known as Rain Forrest Puppy, discovered it and wrote about it in Phrack 54. Since 1999, the Common Vulnerabilities and Exposures dictionary has existed to keep track of and alert consumers and developers alike of known software vulnerabilities. Since 2003, SQL injections have remained in the top 10 list of CVE vulnerabilities; 3,260 vulnerabilities between 2003 and 2011.

In 2012, a representative of Barclaycard claimed that 97% of data breaches are a result of SQL injections. In late 2011 and through early 2012, i.e. in only one month, over one million web pages were affected by the Lilupophilupop SQL injection attack. The year of 2008 saw an incredible economic disruption as a result of SQL injections. In 2009, Heartland Payment Systems was breached using an SQL injection. Even the official United Nations website in 2010 fell victim to an SQL injection attack. Then there was Sony Pictures in 2011. There was also a major breach at Yahoo! in 2012 and it was SQL injection that caused it.

All these stats (excluding, of course, the CVE count) are all within the past three years. Just three years. It is indeed absolutely no surprise that in 2011 the United States Department of Homeland Security, Mitre, and SANS institute all named SQL injections as the number one most dangerous security vulnerability. So why, after over 14 years, it is still a number one seemingly unfixable vulnerability?

Low Hanging Fruit Vulnerabilities Or: By Blunder, We Learn… Or Not

In a recent study at the Goldsmiths University of London, a group of researchers came to the conclusion that our brains are hardwired such that we as humans just do not (easily) learn from our mistakes. Perhaps it is simply that developers see and are even fully cognizant of the faults in developing software, but they are mentally incapable of progressing past those recurring gaffes. Perhaps they are not seeing the proverbial forest for the trees or, specifically, they understand the technical details but not the big picture of applying that knowledge.

As far as low hanging fruit goes, SQL injections present themselves as the most likely guarantee an attacker has to easily and illegitimately gain access to a website or other SQL-backed system, simply based on the probability of success, if 14 years of historical statistics are to be believed. This is primarily because of the most obvious problem: We are still using relational SQL databases.

Were we to use NoSQL database systems such as MongoDB or CouchDB, none of these attacks would ever happen, or at least nowhere near as easily and commonplace as SQL injections. And that is not to say that NoSQL is completely and one hundred percent safe, but rather that it would immediately solve the problem of SQL injections.

But that is not the real cause, nor even a reasonably viable solution. The real reason lies in the fact that software and web application developers do indeed seem to suffer from the University of London’s conclusion, that humans cannot easily learn and adapt once they (or, by observation, others) mess up. It also probably does not help that the easiest and most common information for integrating relational SQL databases with common languages, such as PHP, almost never provide the proper and most safe methods of integration, so perhaps some of the blame also lies in a near-complete lack of valuable educational material. Combine these with overworked developers granted unreasonable deadlines or requirements, and it makes for a wicked trifecta of low-hanging fruit vulnerabilities.

Minimal Effort, Easy Reward; Exploiting a “Low Hanging Fruit” Vulnerability

By comparison, a Distributed Denial of Service attack (DDoS) requires careful coordination and leveraging hundreds to tens of thousands of compromised systems to carry out such an attack. Whereas an SQL injection attack can be accomplished on a single computer with patience, trial and error, some ingenuity, and a little luck. It really does not take much skill at all to complete an SQL injection attack. In fact, a script kiddie can do so with absolutely no understanding of SQL injections whatsoever; by using any of the free available tools. They truly are that easy.

Perhaps some SQL injection attacks result from lazy development or malpractices, but in reality, there are three big commonly repeated mistakes that allow SQL injections to occur. They include the following:

Ignorance of the Least Privilege Principle

Quite simple, yet frequently ignored, this principle simply states that a user, process, or other entity shall have only the least required privileges necessary to complete its tasks. For example, a log database table does not need DELETE or UPDATE privileges, and yet database administrators commonly grant all privileges possible to a service rather than tailor-fit the permissions to exactly only what is needed.

A Conglomeration of Sensitive Data

There is no reason to keep sensitive, personal information such as credit card numbers in the same database as your news articles. There is also no reason to store passwords in plaintext or with poor hashing techniques. If you segment and distribute your data, then your database and its contents become a far less valuable target. Would you keep all your belongings in your home, or would you keep some in your safe deposit box?

Blindly Trusting Unsanitized User Input

This is why SQL injections happen. When user input is not sanitized for potential SQL commands, an attacker has the ability to complete an SQL injection attack, amplified by the aforementioned two points. Once an attacker gains access by including unsanitized input in an SQL query, availability of sensitive data such as credit card data or personal details and unlimited privileges give them everything they could ever want to wreak havoc.

That is it. Just those three simple problems that have caused over one million web pages in under a month to become compromised, including the United Nations’ and several other high profile websites, have consistently kept SQL injections in OWASP’s top ten list. It is almost absurd, with how simple these three problems are, that SQL injections keep happening. So what can developers do?

Later in our series of SQL injection articles, we will go over more technical details of an SQL injection attack and how to protect against them. But for now, the most important point we can stress is that developers and systems administrators do not fall prey to these three problems we have mentioned. Developers need to ensure they implement the least privilege necessary for a web application’s needs, segregate or encrypt data such that a database becomes a far less valuable target, and, most importantly, always sanitize user input, especially if it is used in SQL statements! These are incredibly simple techniques that, if applied as consistently as SQL injections rank in the top ten list, can potentially eliminate SQL injections from that top ten list for the first time since it was created.

Automatically Detect SQL Injection Vulnerabilities in your Web Applications

One easy and quick way to check if your websites and web applications are vulnerable to SQL Injection is by scanning them with an automated web application security scanner such as Netsparker.

Netsparker is a false positive free web application security scanner that can be used to identify web application vulnerabilities such as SQL Injection and Cross-site scripting in your web applications and websites. Download the trial version of Netsparker to find out if your websites are vulnerable or check out the Netsparker product page for more information.