Full PHP vulnerability solution (5)-SQL injection attacks

SQL Injection attacks are specially crafted SQL statements submitted by attackers in the form to modify the original SQL statements. If the web program does not check the submitted data, this will cause SQL injection attacks.

General steps for SQL injection attacks:

1. Attackers can access websites with SQL injection vulnerabilities to find injection points.

2. Attackers construct injection statements, which are combined with the SQL statements in the program to generate new SQL statements.

3. The new SQL statement is submitted to the database for processing.

4. The database executes new SQL statements, triggering SQL injection attacks.

Instance

Database

 
 

  
  
Create table 'postmessage '(
  
  
'Id' int (11) not null auto_increment,
  
  
'Subobject' varchar (60) not null default ",
  
  
'Name' varchar (40) not null default ",
  
  
'Email 'varchar (25) not null default ",
  
  
'Question' mediumtext not null,
  
  
'Postdate' datetime not null default '2017-00-00 00:00:00 ′,
  
  
Primary key ('id ')
  
  
) ENGINE = MyISAM default charset = gb2312 COMMENT = 'caller's message 'AUTO_INCREMENT = 69;
  
  
Grant all privileges on ch3. * to 'sectop' @ localhost identified by '123 ′;
  
  
// Add. php insert a message
  
  
// List. php message list
  
  
// Show. php displays the message
 
 

Page http://www.netsos.com.cn/show.php? Id = 71 there may be injection points. Let's test

Http://www.netsos.com.cn/show.php? Id = 71 and 1 = 1

Back to page

Once the record is found, once not, let's look at the source code

// Show. php 12-15 lines

// Execute the mysql query statement

$ Query = "select * from postmessage where id =". $ _ GET ["id"];

$ Result = mysql_query ($ query)

Or die ("failed to execute ySQL query statement:". mysql_error ());

After the parameter id is passed in, the SQL statement combined with the preceding string is put into the database for query.

Submit and 1 = 1, and the statement becomes select * from postmessage where id = 71 and 1 = 1. Both the values before and after the statement are true and the values after and are true. The queried data is returned.

Submit and 1 = 2, the statement becomes select * from postmessage where id = 71 and 1 = 2. The value before the statement is true, the value after the statement is false, and the value after and is false. No data can be found.

Normal SQL queries have formed SQL injection attacks after the statements we have constructed. Through this injection point, we can further obtain permissions, such as using union to read management passwords, read database information, or using functions such as mysql load_file and into outfile to further penetrate.

Defense methods

Integer parameter:

Use the intval function to convert data into integers.

Function prototype

Int intval (mixed var, int base)

Var is the variable to be converted to an integer.

Base. Optional. It is the base number. The default value is 10.

Floating point parameters:

Use floatval or doubleval functions to convert Single-precision and double-precision floating-point parameters respectively.

Function prototype

Int floatval (mixed var)

Var is the variable to be converted.

Int doubleval (mixed var)

Var is the variable to be converted.

Signature parameters:

Use the addslashes function to convert a single quotation mark (') to "\", a double quotation mark ("") to "\", and a backslash (\) to "\". add the Backslash "\" to the NULL Character

Function prototype

String addslashes (string str)

Str is the string to be checked

We can fix the code vulnerability just now.

// Execute the mysql query statement

$ Query = "select * from postmessage where id =". intval ($ _ GET ["id"]);

$ Result = mysql_query ($ query)

Or die ("failed to execute ySQL query statement:". mysql_error ());

If it is character type, first determine that magic_quotes_gpc cannot be On. When it is not On, use addslashes to escape special characters.

 
 

  
  
if(get_magic_quotes_gpc())  
  
  
{  
  
  
  　 $var = $_GET["var"];  
  
  
}  
  
  
　else  
  
  
　{  
  
  
　 $var = addslashes($_GET["var"]);  
  
  
} 
 
 

Test again. The vulnerability has been fixed.