Summary of SQL injection principle

Today, a friend asked me a question: Why SQL injection to add single quotation marks, this time I can not answer at the moment, blame himself to blame the theory is too vegetable, but go back to think carefully, think this problem is quite simple.

The first thing you should understand is the purpose of SQL injection: Add a single quotation mark is to let the background SQL statement execution time error, so that we can initially determine the single quotation marks are placed in the SQL statement executed, but the execution of the statement because there is a single quotation mark and error, here I am a bit wordy, laugh.

To defend against this single quote attack, the server has 3 ways:

1. Filter or replace single quotes – this is the general procedure

2, the single quote escape-so-called escape is to make it a normal character, and do not have the execution function, PHP commonly used addslashes () function to complete this function

3, set the server to not allow the detonation or burst 404 Not Found

Here's a detailed introduction to the Fundamentals of SQL injection

What is SQL injection?

In the case of a foreigner, SQL injection is described as follows:

SQL injection is a code injection technique, used to attack Data-driven applications, in which malicious SQL statements AR e inserted into a entry field for execution (e.g. to dump the database contents to the attacker). SQL injection must exploit a security vulnerability in an application's software, for example when user input is either I ncorrectly filtered for string literal escape characters embedded in SQL statements or user input was not strongly typed an D unexpectedly executed. SQL injection is mostly known as a attack vector for websites and can be used to attack any type of SQL database.

SQL Injection (SQLI) is considered one of the top Web application vulnerabilities of ten and by the Open Web APPL Ication Security Project. In SQLI is rated the number one attack on the OWASP top ten.

There is five main sub-classes of SQL injection:

1:classic SQLI

2:blind or inference SQL injection

3:database Management system-specific SQLI

4:compounded SQLI

5:the Storm Worm is one representation of compounded SQLI

Ah, in fact, these descriptions I also do not understand, strange can only blame their own English did not seriously learn Ah!

Next, look at the instance code

1: Permission Bypass

statement = "SELECT * from users WHERE name = '" + userName + "';"

Do you think this statement has SQL injection?

The answer is: there is SQL injection

If we submit in the Web:

' or ' 1 ' = ' 1

So, the SQL query logic looks like this:

SELECT * from users WHERE name = ' OR ' 1 ' = ' 1 ';

SELECT * from users WHERE name = ' OR ' 1 ' = ' 1 '--';

If these SQL queries are placed in the code for permission validation, then the code will explode permission bypass.

2: Multi-statement execution

For example: In the Web, we submit a SQL query to the name variable:

A ';D ROP TABLE users; SELECT * from UserInfo WHERE ' t ' = ' t

That's what it looks like in the full SQL code:

SELECT * from users WHERE name = ' A ';D rop TABLE users; SELECT * from UserInfo WHERE ' t ' = ' t ';

The result of this SQL statement is that the users table is deleted and the contents of the UserInfo table are fully displayed!

Tips:

mysql_query()function does not allow the this for security reasons. This prevents attackers from injecting entirely separate queries, but doesn ' t stop them from modifying queries.

This means the most perfect, I did not translate, afraid of translation error, hehe!

3: Data type not validated

For example, the SQL statement would be:

Statement: = "SELECT * from userinfo WHERE id =" + A_var + ";"

This a_var is the normal logic for int data < Although user-submitted data is recognized by the server as a character or string >

But what if hacker submits the following payload,sql statement execution results?

1;drop TABLE Users

So, our SQL statement will look like this:

SELECT * from UserInfo WHERE id=1;drop TABLE users;

The result of SQL execution is: the users table is deleted!

In fact, to think carefully, this place is still a multi-statement execution, but the crux of the problem is that programmer did not check the type of data submitted by the user strictly.

4:sql Blind Note

The following is the science of SQL Blind Note:

Blind SQL injection is used when a Web application was vulnerable to an SQL injection but the results of the injection are Not visible to the attacker. The page with the vulnerability is not being one, displays data but would display differently depending on the results of A logical statement injected into the legitimate SQL statement called for that page. This type of attack can become time-intensive because a new statement must is crafted for each bit recovered. There is several tools that can automate these attacks once the location of the vulnerability and the target information has been established.

For example:

The server-side SQL query is this:

SELECT * FROM bookreviews WHERE id = ' Value (id) ';

However, we can turn it into this:

SELECT * from bookreviews WHERE ID = ' 1 ' and ' 1 ' = ' 1 ';

SELECT * from bookreviews WHERE ID = ' 1 ' and ' 1 ' = ' 2 ';

If and 1=1 returns to the normal page and the and 1=2 returns an error page, then we say that this Web page < Of course the background page > there is a SQL blind, the exact point is based on the Boolean type of SQL Blind <boolean-based sqlbi>.

What time-based Sqlbi, error-based Sqlbi, here is no longer elaborate.

5: Two injections

Definition of two injections:

Second Order SQL injection occurs when submitted values contain malicious commands that is stored rather than executed IM mediately. In some cases, the application may correctly encode a SQL statement and store it as valid SQL. Then, another part of this application without controls to protect against SQL injection might execute that stored SQL STA Tement. This attack requires more knowledge for how submitted values is later used. Automated Web application security scanners would not easily detect this type of SQL injection and could need to be manually instructed where to check for evidence the it is being attempted.

Concrete example also see:

http://zone.wooyun.org/content/3565

6:16 binary conversion to protect against SQL injection attacks

This is not a good description, I give a few examples, we should understand:

Concrete example also see:

Http://www.cnblogs.com/mincyw/archive/2011/02/10/1950733.html

Instance code:

File:test.php

<?php

Include_once ("dosql.php");

#

# Put your own database information here. I ' m using my log file ' s data.

#

$host = "Myhost";

$USR = "MyUser";

$pwd = "MyPassword";

$db = "MyDatabase";

$mysqli = new Mysqli ($host, $usr, $pwd, $db);

if ($mysqli->connect_errno) {

echo "Failed to connect to MySQL: (". $mysqli->connect_errno. ") " . $mysqli->connect_error;

Exit

}

echo "SQL injection-plain\n";

$sql = "SELECT * from log where log_id= ' 2 ' or 1=1; #‘";

$res = Dosql ($sql);

foreach ($res [0] as $k = + $v) {

echo "res[$k] = $v \ n";

}

echo "\n\nsql injection = hexadecimal\n";

$sql = "SELECT * from log where Log_id=unhex ('". Bin2Hex ("2 ' or 1=1; #") . "‘)";

$res = Dosql ($sql);

foreach ($res [0] as $k = + $v) {

echo "res[$k] = $v \ n";

}

Exit

?>

File:dosql.php

<?php

################################################################################

# Dosql (). Do the SQL command.

################################################################################

function Dosql ($sql)

{

Global $mysqli;

$cmd = "INSERT into log (Date,entry) values (now (), Unhex ('"). Bin2Hex ($sql). "‘))";

$res = $mysqli->query ($cmd);

$res = $mysqli->query ($sql);

if (! $res) {

$ary = Debug_backtrace ();

if (Isset ($ary [1])) {$a = $ary [1][' line '];}

else if (isset ($ary [0])) {$a = $ary [0][' line '];}

else {$a = "???";}

echo "ERROR @". $a.  " : (" . $mysqli->errno. ") \ n". $mysqli->error. "\ n";

echo "SQL = $sql \ n";

Exit

}

if (Preg_match ("/insert/i", $sql)) {return $mysqli->insert_id;}

if (Preg_match ("/delete/i", $sql)) {return null;}

if (!is_object ($res)) {return null;}

$cnt =-1;

$ary = Array ();

$res->data_seek (0);

while ($row = $res->fetch_assoc ()) {

$cnt + +;

foreach ($row as $k = + $v) {$ary [$cnt] [$k] = $v;}

}

return $ary;

}

This outputs:

SQL Injection-plain

RES[LOG_ID] = 1

Res[date] = 2015-03-25 10:40:18

Res[entry] = Show full columns from log

SQL injection = hexadecimal

RES[LOG_ID] = 2

Res[date] = 2015-03-25 10:40:18

Res[entry] = select * FROM log ORDER by title ASC

Take a good look at yourself!

Tips:

Note that the PLAIN SQL injection actually works-the first record was returned and not the second. But with the hexadecimal put in the correct record is returned. Thus, by using the Bin2Hex and Unhex commands you no longer has to worry about SQL injection attacks.

Additionally, overall, the usage of Bin2Hex and Unhex requires less time-to-execute than any of the other methods.

This is not to say so you shouldn ' t does checks of whatever you get back from the browser before you put it on to the data Base. This isn ' t a magic wand that'll fix everything that have ever been wrong with your database or programs. It does though, make it and so does not has to worry about the kinds of SQL injections presented at the beginning of this W Ebpage. Those it would stop.

Finish

Summary of SQL injection principle