This article mainly introduces the SQL injection vulnerability example in PHP, we must pay attention to in the development of
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. One, SQL injection steps a) find injection point (such as login interface, message board, etc.) b User constructs SQL statements (such as: ' or 1=1#, later on) C) The SQL statement is sent to the database management system (DBMS) D) dbms receives the request and interprets the request as a machine code instruction, performs the necessary access Operations E) dbms accepts the returned results and processes, returns 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 use an example to demonstrate the following SQL injection II, SQL injection instance detailed (all of the above tests assume that the server does not open MAGIC_QUOTE_GPC) 1) preparatory work To demonstrate the SQL injection vulnerability, log in to the Admin interface First, create a test data table: Code as follows: CreateTable ' users ' ( ' id ' int (one) not NULL auto_i Ncrement, ' username ' varchar () not NULL, ' password ' varchar (+) NOT NULL, ' email ' varchar ($) NOT NULL , PRIMARYKEY (' id '), UniqueKey ' username ' (' username ') ) Engine=myisam auto_increment=3 DEFAULT Charse T=latin1; Add a record for testing: Code as follows: Insertinto users (Username,password,email) VALUES (' Marcofly', MD5 (' Test '), ' marcofly@test.com '; Next, post the source code for the login interface: The following: <html> <head> <title>sql injection demo </title> <meta http-equiv= "Content-type" content= "Text/html;charset=utf-8" > </head> <body> <form action= " validate.php "method=" post "> <fieldset > <legend>sql injection demo </legend> <table> <tr> <td> username:</td> & nbsp <td><inputtype= "text" name= "username" ></td> </tr> & nbsp <tr> <td> tight code:</td> <td><inputtyp E= "text" name= "password" ></td> </tr> <tr> &NB Sp <td><inputtype= "Submit" value= "submitted" ></td> <td><inputtype = "Reset" value= "Reset" ></td> </tr> </table> </fieldset> </form > </body> </html> When the user clicks the Submit button, The form data will be submitted to the validate.php page, which is used to determine whether the user name and password entered by the user are compliant (this step is critical and often the SQL vulnerability) code is as follows: code is as follows : <html> <head> <title> Login Verification </title> <meta http-equiv= "Content-type" content= text/html; Charset=utf-8 "> </head> <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 ' andpassword= ' $pwd '"; $query =mysql_query ($sql); $arr =mysql_fetch_array ($query); if (Is_array ($arr)) { header ("Location:manager.php"); &NB Sp }else{ echo "Your username or password entered incorrectly, <a href=" login.php "> Please Login again! </a> ";  , ?> </body> </html> Notice no, we directly submit the user data (user Name 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. Here, the preliminary work is done, and then we will expand our play: SQL injection 2 to construct the SQL statement fill out the correct username (marcofly) and password (test), click Submit, will return to our "Welcome admin" interface. Because after being synthesized into a SQL query based on our user name and password we submitted: Copy code is as follows: SELECT * from Users where username= ' Marcofly ' ANDPASSW ORD=MD5 (' test ') It is obvious that the username and password are the same as the one we gave before, and we will definitely 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: Enter the username in the User name input box: ' or 1=1#, the password randomly input, this time the synthesized SQL query statement is: The code is as follows: 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 comments by MySQL, so it will not be executed, in other words, the following two SQL statements are equivalent: The code is as follows: SELECT * from Users where Username= ' or 1=1# ' and password=md5 (') is equivalent to code as follows: Select *from users where Username= ' or 1=1 Because the 1=1 is always true, where clause is all the time, further simplifying the SQL is equivalent to the following SELECT statement: The code is as follows: SELECT * from users Yes, The function 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 the ' 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, began 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.