Using SQL Injection Vulnerability login background implementation method .... Reproduced

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:

Add a record for testing:

Next, paste in the source code of the login interface:

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:

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:

The equivalent of the code is as follows:
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.
Stored Procedures
Stored Procedures (Stored Procedure) are in a large database system, a set of SQL statements that perform a particular function, compiled and stored in a database, and executed by the user by specifying the name of the stored procedure and giving the parameter (if the stored procedure has parameters).
Advantages:
A) High security, preventing SQL injection and setting only certain users to use the specified stored procedure.
b) Pre-compile at the time of creation, and subsequent calls do not need to be recompiled.
c) can reduce the traffic on the network. In the stored procedure scenario, the pass-through stored procedure name is used instead of the SQL statement.
Disadvantages:
A) non-application inline code, mode trouble.
b) Change the trouble, because you want to constantly switch development tools. (There is a good side, however, that some easy-to-change rules do not need to recompile the application as a change in the stored procedure)
c) If a large number of use of stored procedures in a program system, to the time of application delivery as the user needs increase will lead to changes in data structure, then the system related problems, and finally if users want to maintain the system can be said to be difficult (eg: no vs query function).
Transfer from http://www.cnblogs.com/hongfei/archive/2012/01/12/sql-injection-tuoku.html
Using SQL Injection Vulnerability login background implementation method .... Reproduced