Principle of SQL injection vulnerability
The principle of SQL injection vulnerability is that developers do not effectively filter and judge the legitimacy of the controllable parameters entered by the attacker in the process of coding and developing web applications, resulting in the attacker taking advantage of the controllable malicious parameters into the database for execution, resulting in the arbitrary operation of malicious SQL statements on the database.
In principle, we can see that there are two key conditions causing SQL injection vulnerabilities.
1,user/The attacker can control the parameter variable, that is, the value of the parameter variable can be controlled by the user. 2,WEB The application is not strictly filtered, resulting in the attacker's malicious parameters being substituted into the database for execution, so that the parameters can be brought into the database for operation.
In principle, SQL injection is to operate the data of the database to achieve its own purpose. The common operation is to use SQL injection to obtain the administrator account and password of the current database. This is only a common attack.
Aside: the existence of SQL injection point has nothing to do with scripting language, but only with database type. Just like PHP and JAVA, why do we say that there are more webql injection vulnerabilities developed by PHP and fewer WEB injection points developed by JAVA? This is determined by the language characteristics. Due to the precompiled mechanism of JAVA language, it means that WEB sites developed based on JAVA rarely find SQL injection vulnerabilities. However, once the SQL injection vulnerability is exposed, it will not have any relationship with the language, but only with the database type, which is why it is said that the existence of SQL injection vulnerability has nothing to do with the scripting language.
Combined with a simple code case, this paper analyzes how SQL injection vulnerabilities are generated
Through the database and local URL link, we know that when $id=100000/100001, the URL
When the corresponding parameters are equal to the corresponding database id, the page displays the corresponding title and content information.
Let's look at two URL s
http://127.0.0.1:8081/test.php?id=100000 http://127.0.0.1:8081/test.php?id=100001 http://127.0.0.1:8081/ Port for url address test.php Is the file name ?id Is the variable parameter name 100000/100001 by $id Variable parameters and controllable
Combined with PHP code, draw a conclusion. When "100000" and "100001" are assigned to $id as parameters and brought into the SQL combination statement to execute the query, the SQL executed respectively is
$sql="select * from sys_article where id = $id"; $sql="select * from sys_article where id = 100000"; $sql="select * from sys_article where id = $id"; $sql="select * from sys_article where id = 100000";
Imagine what happens if the value we transmit is "100000 union select" when passing parameters? At this point, the SQL composite query statement becomes
$sql="select * from sys_article where id = 100000 union select"; there union It is divided into two or more SQL Statement to join two or more queries SELECT The result set of the statement. if union hinder select The query statement is replaced by the original one SQL When the query statement is brought into the database, you will get two select Query result set for statement (This is because the code does not SQL Combined statements for filtering, so it can be used normally union For joint query, if filtering exists, normal query operation cannot be performed normally) So we come to the conclusion, SQL The principle of injection is that the parameters of user controllable variables are controlled, and users can customize them SQL The assignment of combined statements realizes the information you want to query. As for how to find controllable variables, if there is source code, you can analyze the source code. If there is no source black box, according to URL Try to find controllable variables by guessing experiments.
Determine whether there is injection
The most primitive judgment is whether there is an injection method
and 1=1 page normal
select * from sys_article where id = 100000 and 1=1
and 1=2 page error (indicating possible SQL injection)
select * from sys_article where id = 100000 and 1=2
The principle of judging whether there is injection is the judgment principle of logical operators Or and not or and xor True or true =really True or false =really True and false =false and 1=1 Page OK give an example: select * from table_name where id = 1 and 1=1 Among them“ select * from table_name where id = 1"Yes, the result is true SQL sentence; “ and 1=1"And the result is true. This is the "true and true" above =True, return to true, and the page is normal. and 1=2 Page error give an example: select * from table_name where id = 1 and 1=2 Among them“ select * from table_name where id = 1"Yes, the result is true SQL sentence; “ and 1=2"And the result is false. This is the "true and false" above =False ", return" false ", the page is an error, and return the error information (If an error is not necessarily reported, an error message will be returned DBA For the configuration of the database, even if an error is reported, the page will not return any error log). So why not or 1=1 perhaps or 1=2 And? Let's take a look or Logical operation result of or 1 = 1 True or true = really True or false = really It is found that both results are true. In this case, it is impossible to judge whether it has an impact on the website, whether it receives data, whether there is a difference, and whether there is an injection. This is not applicable or Reasons for judgment.
The incoming characters have an impact on the page content, and there is likely to be an injection
The URL we mentioned earlier http://127.0.0.1:8081/test.php?id=100000 , what if some random code is added after the controllable variable parameters?
See the figure below:
According to the analysis principle, the random code contained in the controllable parameter of $id variable is brought into the database for the execution of SQL statements. The random code cannot be matched correctly, resulting in error reporting information. Since it is brought into the database, it indicates that the random code parameter is accepted. If it is not received, how can the web page be affected? Of course, there is the possibility of injection, so it is not necessary to directly add a pile of messy data behind the controllable variables through some specific parameters to check whether the page is affected. (this method is only one of the methods of judgment, not a hundred trial and error, but will produce this judgment method under some specific conditions, and other judgment methods will follow)
How to filter and repair SQL injection vulnerabilities
Taking the above code as an example, when the SQL injection vulnerability is known, that is, the current controllable variable is controlled. We can filter and repair the keywords of SQL injection vulnerability. If we detect keywords such as "union", "and", "exec" and "select", we will return error information; or judge the type locking of the parameters of "$id" variables. When we find the types of non "$id" variables, we will also return error prompts, which is also a way of filtering;
Another way is to install WAF software. The existing WAF software generally integrates code layers and behavior detection strategies against injection and other malicious attacks, which can also prevent SQL injection.
A general string filtering method (JAVA)
public static boolean sql_inj(String str){
String inj_str = "'|and|exec|insert|select|delete|update|count|*|%|chr|mid|master|truncate|char|declare|;|or|-|+|,";
String inj_stra[] = split(inj_str,"|");
for (int i=0 ; i < inj_stra.length ; i++ ){
if (str.indexOf(inj_stra[i])>=0){
return true;
}
}
return false;
}
What conditions should the URL address meet when judging SQL injection? -- > With parameters
Single parameter http://219.153.49.228:48105/new_ list. php? There may be injection points with id = 1 http://219.153.49.228:48105 / injection may not be possible http://219.153.49.228:48105/new_list.php may not be able to inject. Look at the packet. It is possible that the parameters are not displayed in the URL, but in the packet Multi parameter http://219.153.49.228:48105/new_list.php?id=1&x=1&page=1 such as AWVS Burst parameters id existence SQL What should be paid attention to in manual injection? http://219.153.49.228:48105/new_ list. php? Id = 1 & x = 1 & page = 1 and 1 = 1 error http://219.153.49.228:48105/new_ list. php? Id = 1 & x = 1 & page = 1 and 1 = 2 error Determine which variable parameter name is given by the injection statement http://219.153.49.228:48105/new_ list. php? Id = 1 and 1 = 1 & x = 1 & page = 1 correct http://219.153.49.228:48105/new_ list. php? Id = 1 and 1 = 2 & x = 1 & page = 1 correct What about tools? SQLMAP After all, the tool cannot judge which variable has an injection point in the case of multiple parameters like people http://219.153.49.228:48105/new_ list. php? X = 1 & page = 1 & id = 1 and 1 = 1 correct
Black box idea: filter URL s with possible vulnerabilities (with parameters), and judge the parameter values passed in