Walking Through The Front Door: SQL Injections

Image via Wikipedia

Walking Through the Front Door

Many corporations today have become dependant upon their websites. Where once websites were simply information portals or advertisments for their owners, they have transformed into something far greater. Today companies all over the world rely on their websites to log in remotely, provide news and information to employees and shareholders, or allow customers to access services.

Too often we hear about huge data breaches in some obscure corporation that handles millions of records of Personally Identifiable Information (referred to as PII in the security world). In many cases (including the single greatest breach of credit card information to date) the perpatrators of the computer crime walk straight through the front door: the website. They do this by leveraging flaws in behind-the-scenes computer programming that makes these websites function. Not only are there large data breaches from websites with many users, but there are also many websites hacked at once, causing massive amounts of damage across the internet, especially to the internet users who can become infected by viruses from these attacks.

Some of the most damaging and serious hacking attacks come in form of SQL injection attacks. SQL injection attacks are also one of the most common attacks used against servers on the internet.

What’s a SQL injection?

A SQL injection takes advantage of vulnerabilities in the way that applications that utilize sql handle user input. Applications that create database queries (questions like: search for “something” in my web pages) with user input should ensure that the user input does not contain control characters. This ensures that queries are not modified by user input on the fly, either by accident or on purpose. If a request to the SQL server is not cleaned of dangerous characters, we can end up in a situation where a SQL injection is present.

For example:

We start out with a harmless enough request to the webserver:

READ

Google Reports Government Data Requests Reach All-Time High

SELECT * FROM DOCUMENTS WHERE name = [USER_INPUT];

This query should return all the records in a douments table with whatever name the user typed into the “search” bar. But what happens when a malicious user gets ahold of an uncleaned [USER_INPUT] string?

SELECT * FROM DOCUMENTS WHERE name = [;SELECT * FROM USERS WHERE 1=1;–];

In the above case we see that a malicious user has added some code between the brackets. The “;” ends the query started before it, which generates an error but allows the next statement to run, which will return a list of all the users in the database. The attacker has literally modified our original query with some special control characters and keywords that the SQL server understands and runs because it doesn’t know the difference between the added code and the original code. This is a SQL injection at its most basic, and many websites every day get breached by criminals utilizing this technique.

Why is this?

The short answer is that these websites suffer from programming flaws like any other computer system comprised of a large amount of code, but the more correct answer would be a lack of the implementation of best practices and the low variance of different web platforms.

For best practices coding, I highly recommend that most applications utilize something called “Parametrized” or “Prepared” SQL queries. Parametrized queries utilize programming language and/or SQL server features to improve the security and performance of your SQL-based applications. For many small implementations of SQL or non-complex applications, parametrized SQL is the way to go. Though this may add some complexity to your application, the added amount of security is incredibly useful, especially if you handle credit cards or passwords.

Your Weakest Link is Your Biggest Vulnerability

As far as the low amount of platform variance, most of the content management systems used on the web revolve around WordPress, Drupal, or Joomla!. Applications such as these often give users the opportunity to load in additional features through plug-ins or themes. These themes and plug-ins very frequently contain vulnerabilities that, while separate from the main application, allow access to the whole of the website for hackers.

READ

A Data Catalog Makes Quick Work of GDPR Compliance

Plug-ins need to be managed, frequently updated, and be untrusted. A simple search will demonstrate how many plug-ins have lead to security issues in the past — and how easy many of them are to exploit (http://packetstormsecurity.org/search/?q=wordpress+plugin&s=files) A good practice for your content management system to follow is to use the least number of plug-ins possible, or at least use plug-ins that have already been tested for vulnerabilities.

How Do I Know I’m at Risk?

Typically companies that worry about their security hire security consulting companies to test their security for them, a practice that is known as penetration testing or pentesting. These companies will attempt to find and report security issues to you.

You can also get your web developers to change the way that they create their applications to leverage SQL parametrization or you can have them audit their applications using widely available tools and guides that many hackers will be leveraging against your website. Below are just a few of the most popular tools and guides.

W3AF : http://w3af.sourceforge.net/
sqlninja : http://sqlninja.sourceforge.net/
SQLmap : http://sqlmap.sourceforge.net/
Sql Injection Guide : http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/

What Happens If I Ignore This Problem Like Everyone Else?

Ignoring the fact that you have exploitable vulnerabilities or even potentially exploitable vulnerabilities can cause you to be a victim quite easily, even if you’re a small operation without many users. Just look at these massive SQL website exploit campaigns and you can see how many sites can be turned to hosting viruses and malware in the blink of an eye:

Lizamoon Mass Injection : SQL Injection ~1,000,000 (Even popped up on iTunes)
http://isc.sans.edu/diary.html?storyid=10642

Mass Realplayer Exploit : SQL Injection ~500000
http://ddanchev.blogspot.com/2008/01/massive-realplayer-exploit-embedded.html
http://websmithrob.wordpress.com/2008/01/07/nuc8010com-real-exploit-hack-via-sql-injection/

Heartland SQL Injection : Largest Credit Card Number Theft to Date

http://www.netlib.com/blog/Data-Security-Technology/largest-data-theft-in-history.asp

http://blog.scansafe.com/journal/2009/8/17/sql-injection-cause-of-heartland-breach.html