SQL injection for penetration testing (1)

The previous article is about brute force cracking of penetration testing. Today, I will explain the knowledge of SQL injection.

What is SQL injection

SQL injection means that the web application does not judge the validity of the user input data or filters it is not strict. The attacker can add additional SQL statements to the end of the pre-defined query statement in the web application without the administrator’s knowledge Under the circumstance of realizing illegal operation, in order to deceive the database server to perform unauthorized arbitrary query, thereby further obtaining corresponding data information.

Here is a PHP SQL statement code as an example

$SQL = “select * from’a field’ where id = $id”;

Since the parameter id here can be controlled, and this id will be queried in the database, some people with bad intentions can attack by splicing SQL statements.

Conditions required to generate SQL injection

SQL injection requires two conditions

1. The parameters we pass to the backend are controllable

2. The parameter content will be brought to the database for query

Verify whether there is SQL injection

Take this code as an example $SQL = “select * from’a field’ where id = $id”;

The parameter we can control here is the id parameter, so when we enter 1′. At this time, the content of the query statement is

select * from’a field’ where id = 1’

Because there is a single quotation mark behind, such a statement does not conform to the database syntax specification, so an error will be reported, so as to determine whether there is SQL injection there.

Classification of SQL injection

SQL injection is divided into many types, including joint injection, Boolean injection, error injection, time injection, stack injection, secondary injection, wide byte injection, cookie injection, etc. Of course, the principles of these injections are the same, as mentioned above. In the next article, the author will also write out all these injection and combination examples.

SQL injection defense

Option One

Using pre-compiled technology

INSERT INTO MyGuests (firstname, lastname, email) VALUES(?, ?, ?)

Using pre-compiled SQL statements, the semantics of SQL statements will not be unchanged. When the prepared statement is created, the specified SQL statement is sent to the DBMS, and the work of parsing, checking, compiling, etc. is completed, so the attacker cannot change the structure of the SQL statement, just assign the value to? ,followed by? This variable is passed to the SQL statement. Of course, there are some operations that bypass certain security protections through pre-compilation. You can search for them if you are interested.

Option II

Strictly control data types

In strongly typed languages ​​such as java and c, there is generally no digital injection, because when receiving the user input id, the code will generally do a data type conversion of int id, if we input a string, then this In this case, the program will report an error. However, in languages ​​such as PHP and ASP that do not emphasize the processing of data types, generally the codes that we see to receive ID are the following codes.

$id = $_GET[‘id’];

$SQL = “select * from’a field’ where id = $id;”;

Such a code attacker can perform SQL injection by constructing id parameters and using joint queries and other techniques. If we add a function to check the numeric type is_numeric() here, we can prevent numeric injection.

third solution

Escape special characters

Numerical injection can be prevented by checking the data type, but the character type cannot, so what should be done? The best way is to escape the special characters. For example, in MySQL, we can escape “‘”, which prevents some malicious attackers from closing the statement. Of course, we can also escape special characters through some security functions. Such as addslashes(), etc., but these functions are not done once and for all, and attackers can also bypass them in some special ways.



There are no reviews yet.

Be the first to review “SQL injection for penetration testing (1)”

Your email address will not be published. Required fields are marked *