Example of sql injection vulnerability in php sql Injection vulnerability fix
- 2020-12-16 05:53:17
- OfStack
When developing a web site, you need to filter the characters passed from the page for security reasons. Typically, users can invoke the contents of the database through the following interfaces: URL address bar, login interface, message board, search box, and so on. This often leaves the door open for hackers. At least the data is compromised, at least the server is taken down.
1. Steps for SQL injection
a) looking for injection points (e.g., login interface, message board, etc.)
b) the user constructs the SQL statement (e.g., 'or 1=1#, as explained later)
c) sends the sql statement to the database management system (DBMS)
d) DBMS receives the request and interprets the request as a machine code instruction to perform the necessary access operations
e) DBMS accepts the returned result, processes it, and returns it to the user
Because the user constructed a special SQL statement, it must return a special result (as long as your SQL statement is flexible).
Next, I'll demonstrate SQL injection in a concrete example
2. Details of SQL injection example (the above tests assume that magic_quote_gpc is not enabled)
1) Preliminary preparation
To demonstrate the vulnerability injection via SQL, login to the background administrator interface
First, create a table of data for the experiment:
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 1 record for testing:
INSERTINTO users (username,password,email)
VALUES('MarcoFly',md5('test'),'marcofly@test.com');
Next, paste the source code of the login interface:
<html>
<head>
<title>Sql Injection of 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 of demo </legend>
<table>
<tr>
<td> User name: </td>
<td><inputtype="text" name="username"></td>
</tr>
<tr>
<td> The secret Code: </td>
<td><inputtype="text" name="password"></td>
</tr>
<tr>
<td><inputtype="submit" value=" submit "></td>
<td><inputtype="reset" value=" reset "></td>
</tr>
</table>
</fieldset>
</form>
</body>
</html>
When the user clicks the submit button, the form data is submitted to the ES59en.php page, which is used to determine whether the user entered a username and password that meets the requirements (this step is crucial and is often the site of the SQL vulnerability).
The code is as follows:
<html>
<head>
<title> Login authentication </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 are selecting 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 " You typed your username or password incorrectly, <a href="Login.php"> Please log in again! </a>";
}
?>
</body>
</html>
Notice that we took the data that the user submitted (username and password) and executed it directly, without implementing special character filtering, which, as you'll see in a moment, can be deadly.
Code analysis: if the user name and password match successfully, it will jump to the administrator operation interface (ES71en.php). If not, a friendly prompt message will be given.
At this point, the preliminary work has been done, and the next stage will be our major play: SQL injection
2) Construct SQL statement
After filling in the correct user name (marcofly) and password (test), click Submit and the "Welcome Administrator" interface will be returned to us.
Because based on the user name and password we submitted, the result of the synthesis into the SQL query looks like this:
select * from users where username='marcofly' andpassword=md5('test')
Obviously, the username and password are exactly the same as the one we gave you before, so you can log in successfully. But what if we enter an incorrect username or password? Obviously, I can't log in. Well, normally that's true, but for sites with the SQL injection vulnerability, a special "string" can be constructed to successfully log in.
For example: enter :' or 1=1# in the user name input box, and enter the password casually, then the synthesized SQL query is:
select * from users where username='' or 1=1#' and password=md5('')
Semantic analysis: "#" in mysql is an annotation, so that the content after the hashtag will be treated as the annotation content by mysql, so that 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('')
Is equivalent to
select *from users where username='' or 1=1
Since 1=1 is always true, that is, where clause is always true. After further simplification of sql, it is equivalent to the following select statement:
select * from users
Yes, the purpose of the sql statement is to retrieve all the fields in the users table
Tip: If you don't know the use of single quotes in 'or 1=1#, use the sql statement yourself.
See, a structured sql statement can be so terrible destructive, Believe you see this, start to sql injection to have a rational understanding of it
Yes, SQL injection is that easy. However, it is not so easy to construct a flexible sql statement based on the actual situation. After having a foundation, oneself go to grope slowly again.
Ever wonder what happens when all the data submitted through the background login window is filtered out by the administrator? In this case, our universal username 'or 1=1# will not work. But that's not to say we don't have a solution, because there are more ways for users to interact with databases.