Preface: The work needs, need to have a good tutorial on the relevant knowledge of web security, so writing this article, right when summed up, do not have any intention. Reading this article, I assume that the reader has the experience of writing SQL statements, or can read SQL statements
As early as 02, there are a lot of technical articles about SQL injection holes in the country, but it began in 05 years.
Now, talking about whether the SQL injection hole is a piece of the world, the domestic large and small sites have been filled with loopholes. But, the hundred secret must have a sparse, the invasion is accidental, but the security is absolutely not inevitable.
A few days ago, the internet spread of the uproar of the "drag-bank" incident to us sounded a security alarm.
When developing a Web site, you need to filter the characters passed from the page for security reasons. In general, users can invoke the contents of the database through the following interfaces: URL address bar, login interface, message board, search box, etc. This often gives hackers the opportunity to leave. Light data is compromised and heavy servers are taken down.
Now, a lot of web developers know it but do not know why, younger brother is also, so hurriedly evil, summed up as learning content. Hope for beginners can play a role.
first, SQL injection steps
A) Looking for injection point (such as: Login interface, message board, etc.)
b The user constructs the SQL statement (such as: ' or 1=1#, which will be explained later)
c to send SQL statements to the database management system (DBMS)
D The DBMS receives the request and interprets the request as a machine code instruction to perform the necessary access operations
E The DBMS accepts the returned result and processes it and returns it to the user
Because the user constructs a special SQL statement, it must return a special result (as long as your SQL statement is flexible enough).
Below, I demonstrate the following SQL injection in a concrete instance
second, SQL injection example detailed (All the above tests assume that the server does not open MAGIC_QUOTE_GPC)
1 Preliminary preparation work
To demonstrate a SQL injection vulnerability, log in to the backend administrator interface
First, create a data table for the experiment:
CREATE TABLE ' users ' (
' id ' int (one) not NULL auto_increment,
' username ' varchar not NULL,
' Password ' varchar not NULL,
' Email ' varchar not NULL,
PRIMARY KEY (' id '),
UNIQUE KEY ' username ' (' username ')
) Engine=myisam auto_increment=3 DEFAULT charset=latin1;
Add a record to test:
INSERT into Users (Username,password,email)
VALUES (' Marcofly ', MD5 (' Test '), ' marcofly@test.com ');
Next, post the source code for the login interface:
<title>sql Injection Demo </title>
<meta http-equiv= "Content-type" content= "Text/html;charset=utf-8" >
<body >
<form action= "validate.php" method= "POST" >
<fieldset >
<legend>sql Injection Demo </legend>
<table>
<tr>
<td> User name:</td>
<td><input type= "text" name= "username" ></td>
</tr>
<tr>
<td> Password:</td>
<td><input type= "text" name= "password" ></td>
</tr>
<tr>
<td><input type= "Submit" value= "submitted" ></td>
<td><input type= "reset" value= "reset" ></td>
</tr>
</table>
</fieldset>
</form>
</body>
Attached Effect chart:
When the user clicks on the Submit button, the form data is submitted to the validate.php page, and the validate.php page is used to determine if the user's input username and password are compliant (this step is critical and is often the SQL vulnerability)
The code is as follows:
<title> Login Validation </title>
<meta http-equiv= "Content-type" content= "Text/html;charset=utf-8" >
<body>
<?php
$conn = @mysql_connect ("localhost", ' root ', ') or Die ("Database connection failed!") ");;
mysql_select_db ("injection", $conn) or Die ("the database you want to select does not exist");
$name =$_post[' username '];
$pwd =$_post[' password '];
$sql = "SELECT * from Users where username= ' $name ' and password= ' $pwd '";
$query =mysql_query ($sql);
$arr =mysql_fetch_array ($query);
if (Is_array ($arr)) {
Header ("Location:manager.php");
}else{
echo "Your username or password entered incorrectly, <a href=\" login.php\ "> Please login again! </a> ";
}
?>
</body>
Note that no, we directly to the user submitted data (username and password) directly to execute, and did not implement special character filtering, you will understand that this is fatal.
Code Analysis: If the username and password match successfully, will jump to the Admin interface (manager.php), not successful, give a friendly message.
Login Successful Interface:
Prompt for login failure:
Here, the upfront work is done, and then we'll start our plays: SQL injection
2) Constructing SQL statements
After you have filled in the correct username (marcofly) and password (test), click Submit and return to our "Welcome admin" interface.
This is because the user name and password that we submitted are synthesized into the SQL query statement:
SELECT * from users where username= ' Marcofly ' and password=md5 (' test ')
Obviously, the username and password are the same as we have previously given, will certainly be able to log in successfully. But what if we enter an incorrect username or password? Obviously, it's not going to be easy. Well, that's normal, but for a Web site with a SQL injection vulnerability, you can log in successfully if you construct a special "string".
For example: In the Username input box input: ' or 1=1#, the password casually input, this time the synthesized SQL query statement is:
SELECT * from users where username= ' or 1=1# ' and password=md5 (')
Semantic analysis: "#" in MySQL is an annotation character, so that the content behind the well number will be treated as a comment by MySQL, so it will not be executed, in other words, the following two SQL statements are equivalent:
SELECT * from users where username= ' or 1=1# ' and password=md5 (')
Equivalent to
SELECT * from users where username= ' or 1=1
Because the 1=1 is always true, where the clause is all the same, further simplifying the SQL is equivalent to the following SELECT statement:
SELECT * from Users
Yes, the purpose of this SQL statement is to retrieve all the fields in the Users table
Tip: If you don't know the role of single quotes in ' or 1=1# ', you can echo the SQL statement yourself, at a glance.
See, a constructed SQL statement has such a terrible destructive power, I believe you see this, start to SQL injection has a rational understanding of it ~
Yes, SQL injection is so easy. However, it is not easy to construct a flexible SQL statement based on the actual situation. After having the foundation, oneself go to slowly fumble again.
Have you ever thought that if the data submitted by the Backstage login window were filtered out by the admin? In this way, our universal username ' or 1=1# will be unusable. But this is not to say that we have no countermeasures, and that there are more ways to deal with users and databases than that.