What is SQL injection?

Question

Can someone explain SQL injection? How does it cause vulnerabilities? Where exactly is the point where SQL is injected?

Duplicate

http://stackoverflow.com/questions/332365/xkcd-sql-injection-please-explain
Too many to list (Google link)

Answer 1

read up on Parameterized Queries

Answer 2

There are plenty of resources on the web - just google it:

http://en.wikipedia.org/wiki/SQL_Injection is a good starting point.

Answer 3

This seems easy to find using a google search.

The first 2 results pretty much explain it all I think.

Answer 4

I found this paper to be an extremely good read about SQL injection techniques (link is to PDF): Advanced SQL Injection In SQL Server Applications.

Despite the title saying "Advanced", it's quite readable even if you don't have much knowledge about SQL injection.

Answer 5

Stop SQL Injection Attacks Before They Stop You

Answer 6

Check these articles:

• SQL Injection Walkthrough
• Preventing SQL Injection Attacks
• SQL Injection Cheat Sheet

Answer 7

To get some general background check out the Wikipedia article on SQL Injection.

In short SQL injection attacks can leave you vulnerable to all manor of database data theft and destruction. The exact details of what can be done to your system depend on the details of the system itself.

Any time you pass input from your users to your database you have a potential injection point. Web applications are often lacking in the this regard, as new programmers often do not understand the risks of handling input from users, and web applications are attacked by very smart people you never thought would find your program.

Answer 8

This is SQL injection.

Answer 9

The point where SQL is injected is any point that your application accepts input from the user.

Whether this becomes a dangerous vulnerability for your web application depends on whether this input is later used as part of an SQL query without properly checking its type and escaping it if necessary.

Without proper escaping, some SQL code 'injected' by the user could be executed by the SQL engine as SQL code, rather than a simple string or value.

Answer 10

SQL Injection occurs when the user of an application is able to affect the meaning of database query. This often occurs when arbitary strings from user input are concatenated to create SQL which is fed to the database. For example lets say we had the following code (in PHP, but the same holds true for any language), which might be used to handle a user login.

$sql = "SELECT  FROM users WHERE username='".$_GET['username']."' AND password='".$_GET['password']."'";

The harm is done when the user enters something like

administrator'; --

... for the username. Without proper encoding the query becomes:

SELECT * FROM users WHERE username='administrator'; -- AND password=''

The issue here is that the ' in the username closes out the username field then the -- starts a SQL comment causing the database server to ignore the rest of the string. The net result is the user can now log in as the administrator without having to know the password. SQL Inection can also be used to execute UPDATE, DELETE or DROP queries and really damage the database.

SQL Injection can be prevented by using parameterised queries, or applying your language/toolkit's escaping functions (such as mysql_real_escape_string() in PHP).

Once you understand SQL Injection you'll get the joke behind this cartoon.

Answer 11

Can someone explain SQL injecton?

SQL injection happens when you interpolate some content into a SQL query string, and the result modifies the syntax of your query in ways you didn't intend.

It doesn't have to be malicious, it can be an accident. But accidental SQL injection is more likely to result in an error than in a vulnerability.

The harmful content doesn't have to come from a user, it could be content that your application gets from any source, or even generates itself in code.

How does it cause vulnerabilities?

It can lead to vulnerabilities because attackers can send values to an application that they know will be interpolated into a SQL string. By being very clever, they can manipulate the result of queries, reading data or even changing data that they shouldn't be allowed to do.

Example in PHP:

$password = $_POST['password'];
$id = $_POST['id'];
$sql = "UPDATE Accounts SET PASSWORD = '$password' WHERE account_id = $id";

Now suppose the attacker sets the POST request parameters to "password=xyzzy" and "id=account_id" resulting in the following SQL:

UPDATE Accounts SET PASSWORD = 'xyzzy' WHERE account_id = account_id

Although I expected $id to be an integer, the attacker chose a string that is the name of the column. Of course now the condition is true on every row, so the attacker has just set the password for every account. Now the attacker can log in to anyone's account -- including privileged users.

Where exactly is the point where SQL is injected?

It isn't SQL that's injected, it's content that's interpolated ("injected") into a SQL string, resulting in a different kind of query than I intended. I trusted the dynamic content without verifying it, and executed the resulting SQL query blindly. That's where the trouble starts.

SQL injection is a fault in the application code, not typically in the database or in the database access library or framework. The remedy for SQL injection follows the FIEO practices:

• Filter Input: verify that the content is in a format you expect, instead of assuming. For example, apply a regular expression, or use a data type coercion like the intval() function.
• Escape Output: in this case "output" is where the content is combined with the SQL string. When interpolating strings, avoid imbalanced quotes by using a function that escapes literal quote characters and any other characters that may be string boundaries.

Answer 12

SQL injection is where a malicious user will put SQL into input fields to try and run the SQL on your server.

The #1 advice that I adhere to is to use parameterized stored procedures rather than building raw SQL in code.

Stored Procedure parameters don't get executed, making them safe in most cases.

Answer 13

You will like this article from code project ; )

Summary

• Encrypt sensitive data.
• Access the database using an account with the least privileges necessary.
• Install the database using an account with the least privileges necessary.
• Ensure that data is valid.
• Do a code review to check for the possibility of second-order attacks.
• Use parameterised queries.
• Use stored procedures.
• Re-validate data in stored procedures.
• Ensure that error messages give nothing away about the internal architecture of the application or the database.

Answer 14

CWE

CWE has many other exploits to look into as well.

Answer 15

This question has been answered many times on StackOverflow, but it's an important topic for everyone to know about, so I'm not going to vote to close this question.

Here are links to some of my past answers on this topic:

• What is SQL Injection?
• How do I protect this function from SQL injection?
• Are Parameters really enough to prevent Sql injections?
• Is SQL injection a risk today?

I also gave a presentation at the MySQL Conference this month, and my slides are online:

• SQL Injection Myths & Fallacies

Answer 16

SQL injection is when things that're supposed to be data are treated as SQL code unwillingly.

For instance, if you were to do

mysql_query("SELECT * FROM posts WHERE postid=$postid");

Normally it'd get you the post with a given id, but assume that $postid is set to the string 10; DROP TABLE posts --; all of a sudden, the actual query you're sending is

mysql_query("SELECT * FROM posts WHERE postid=10; DROP TABLE posts --");

This is quite a problem, as you'd be losing your entire posts table due to a malicious user - oh dear.

The easiest way to prevent this is to use prepared statements, for instance through PDO or MySQLi.

The equivalent example in PDO would then be

$statement = $db->prepare('SELECT * FROM posts WHERE postid = :postid');
$statement->bindValue(':postid', $postid);
$statement->execute();

Doing this ensures that the database system knows that $postid is to be treated as data and not code, and will thus be handled appropriately.