Example of sql injection vulnerability in php SQL injection vulnerability repair

Example of sql injection vulnerability in php SQL injection vulnerability repair_PHP tutorial

WBOY

Release： 2016-07-13 10:39:58

Original

932 people have browsed it

When developing a website, for security reasons, it is necessary to filter the characters passed from the page. Usually, users can call the content of the database through the following interfaces: URL address bar, login interface, message board, search box, etc. This often leaves opportunities for hackers to take advantage of. At worst, the data may be leaked, and at worst, the server may be taken down.

1. Steps of SQL injection

a) Find injection points (such as login interface, message board, etc.)

b) Users construct SQL statements by themselves (such as: ' or 1=1#, which will be explained later)

c) Send the sql statement to the database management system (DBMS)

d) DBMS receives the request, interprets the request into machine code instructions, and performs the necessary access operations

e) DBMS accepts the returned results, processes them, and returns them to the user

Because the user constructs a special SQL statement, special results must be returned (as long as your SQL statement is flexible enough).

Below, I will demonstrate SQL injection through an example

2. Detailed explanation of SQL injection examples (the above tests assume that magic_quote_gpc is not enabled on the server)

1) Preparatory work

First, let’s demonstrate the SQL injection vulnerability and log in to the backend administrator interface

First, create a data table for testing:

Copy the code The code is as follows:

CREATETABLE `users` (

`id`int(11) NOT NULL AUTO_INCREMENT,

`username`varchar(64) NOT NULL,

`password`varchar(64) NOT NULL,

`email`varchar(64) NOT NULL,

PRIMARYKEY (`id`),

UNIQUEKEY `username` (`username`)

)ENGINE=MyISAM AUTO_INCREMENT=3 DEFAULT CHARSET=latin1;

Add a record for testing:

Copy code The code is as follows:

INSERTINTO users (username, password, email )

VALUES('MarcoFly',md5('test'),'marcofly@test.com');

Next, paste the source code of the login interface:

Copy code The code is as follows:

Sql injection Demo

Sql injection demonstration
🎜>
;td>

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 name and password entered by the user meet the requirements (this step is crucial and often This is where the SQL vulnerability lies)

The code is as follows:

Copy the code

The code is as follows:

$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");

}else{

Echo "Your username or password input is wrong, & lt; a href =" login.php "& gt; please log in! & Lt;/a & gt;" ";

}

Did you notice that we directly submit the data (user name and password) ) is executed directly without filtering special characters. You will understand later that this is fatal.
Code analysis: If the username and password match successfully, it will jump to the administrator operation interface (manager.php). If it fails, a friendly prompt message will be given.
At this point, the preliminary work has been done, and now we will start our highlight: SQL injection
2) Construct SQL statement

After filling in the correct username (marcofly) and password (test), click Submit, and you will be returned to our "Welcome Administrator" interface.

Because the username and password we submitted are synthesized into the SQL query statement and look like this:

Copy code The code is as follows:

select * from users where username='marcofly' andpassword=md5('test')

Obviously, the username and password are the same as those we gave before, and we will definitely be able to log in successfully. But what if we enter a wrong username or password? Obviously, we will definitely not be able to log in. Well, this is the case under normal circumstances, but for websites with SQL injection vulnerabilities, as long as a special "string" is constructed, you can still log in successfully.
For example: enter: ' or 1=1# in the user name input box, and enter the password as you like. The synthesized SQL query statement at this time is:

Copy code The code is as follows:

select * from users where username='' or 1=1#' and password= md5('')

Semantic analysis: "#" is a comment character in mysql, so the content after the pound sign will be regarded as comment content by mysql, so it will not be executed. In other words, the following two sql statements are equivalent :

Copy code The code is as follows:

select * from users where username='' or 1=1#' and password= md5('')

is equivalent to

Copy code The code is as follows:

select *from users where username='' or 1=1

Because 1=1 is always true, that is, the where clause is always true, after further simplifying the sql , equivalent to the following select statement:

Copy code The code is as follows:

select * from users

Yes, the function of this sql statement is to retrieve all fields in the users table
Tips: If you don’t know the function of the single quotes in ' or 1=1#, you can echo the sql statement yourself, and it will be clear at a glance .
See, a constructed SQL statement can have such terrible destructive power. I believe that after seeing this, you will begin to have a rational understanding of SQL injection~
Yes, SQL injection It's that easy. However, it is not so easy to construct flexible SQL statements according to the actual situation. After you have the basics, you can slowly explore on your own.
Have you ever thought about what if the data submitted through the background login window are filtered out by the administrator with special characters? In this case, our universal username' or 1=1# cannot be used. But this does not mean that we have no countermeasures. We must know that there is more than one way for users to interact with the database.