Channels ▼

Ken North

Dr. Dobb's Bloggers

SQL Injection Attacks and Data Theft

November 16, 2010

By comparison to 'SQL injection', terms such as spoof, 'smurf attack', and teardrop seem almost benign. Even 'buffer overflow', 'network sniffer', 'bypass filtering' and 'malformed headers' don't seem as ominous.

"We've got to protect against smurf attacks" might produce smiles in a meeting, but substitute 'SQL injection' for smurf and you're more likely to see serious facial expressions.

Even without knowing the details, your instincts tell you SQL injection is not as much fun as a day at Disneyland.SQL injection! SQL injection!

Hearing those words brought back memories of a summer afternoon spent getting inoculations for cholera, yellow fever, plague, hepatitis - nine vaccines altogether. No, it wasn't as much fun as an afternoon at Disneyland. And neither is SQL injection.

SQL databases are everywhere. Many are accessible from Internet connections, such as for use with web-facing applications. But even today not all database servers tied to the Internet are hardened and compliant with standards for security and regulatory compliance. Corporate SQL databases are often behind firewalls, for example. This can produce a false sense of security among database and network administrators and a dangerous belief that other data security safeguards are unnecessary. Hackers, such as those involved in Operation Get Rich or Die Tryin', have exposed the myth that a corporate firewall is sufficient for data security.

Recent surveys do not paint a picture of widespread concern for data security. In September 2009, Imperva and the Ponemon Institute released findings of a survey of IT professionals at 517 domestic and multinational companies. 55% reported that their systems protected credit card information, but not other personal identifying data such as Social Security or bank account numbers. 79% admitted to data breaches since 2005.

A September 2010 survey of members of the Professional Association for SQL Server (PASS) by Unisphere Research revealed:

· 25% don't encrypt personal identity information in databases · 18% said most of their databases are not adequately protected.

The exposure of insecure databases to a global pipe (the Internet) invites mischief, such as SQL injection attacks. By altering SQL queries, miscreants are able to penetrate vulnerable networks and databases. Because the modification of SQL queries is an effective technique for spreading malware, it's become a favored technique of cyber-criminals. SQL injection attacks can be launched with manual injection and automated injection, using tools that operate with forms and search.

SQL injection provides a channel for various types of mischief, including spurious transactions, botnets, implanting keystroke loggers and trojans, commandeering servers, arbitrary execution of code - and stealing data. In a typical scenario, hackers use SQL injection to get access to a server. Then they place malicious code or scripts on the server and it's downloaded to the web clients that browse to the infected web site.

Applications that are cavalier about how input is validated and queries are coded are particularly risky. Unfortunately the list of vulnerable software is long, including home-grown applications and packaged suites. How widespread is the SQL injection problem? By October 2008, IBM ISS was blocking 450,000 SQL attacks per day against its customers.

Undetected data theft and transaction modifications are but two results of operating with insecure databases, not safeguarding against SQL injection and not monitoring database activity. According to the Verizon 2009 Data Breach Report, third parties discover 69% of breaches instead of the organization hosting the data.

Precautions that should be taken by prudent organizations include coding standards, removal of default administrator account information, database monitoring and penetration testing. SQL injection query lists and automation tools are readily available for use by those who wish to hack your database. It's to your advantage to use those tools for penetration testing of your applications, because the hackers in the black hats are likely to use them.

There are various web sites that publish SQL injection cheat sheets, with queries for platforms such as IBM DB2, Informix, Ingres, Microsoft SQL Server, MySQL, Oracle, and PostgreSQL. If you are writing code for any of those platforms, you'd be wise to refer to cheat sheets when developing input validation code.

The list of tools that automate the process of searching for SQL vulnerabilities includes SQLMap, MultiInjector, SQLNinja, SQLBrute, Blind Sql Injection Brute Forcer version 2

Various coding practices provide an obstacle to those who would use SQL injection attacks against your database. Don't expose a user interface that enables a web client to type in query strings. Besides coding strong input validation routines that are validated with SQL injection cheat sheets, you can also be prudent about the type of query operations allowed against databases with confidential data.

Query Parameters, Stored Procedures Use the prepare-and-execute model for queries instead of supporting the execution of ad hoc queries. A prepared query is pre-compiled with parameter markers and the query executes by supplying substitution values for the parameters at run time. This type of query is better for security because it permits tighter control over input. It also provides better performance for repetitive queries.

Another solution for security was explained by "Web Databases: Fun with Guests or Risky Business?", one of my columns in Web Techniques (February 1999). It recommended using roles and doing database updates using packages or stored procedures. You can restrict what guests and other users do by giving them only execute privilege for the package or procedure.SQL databases are everywhere. Many are accessible from Internet connections, such as for use with web-facing applications. But even today not all database servers tied to the Internet are hardened and compliant with standards for security and regulatory compliance.

Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 


Dr. Dobb's TV