Detailed explanation of SQL secondary injection

Today I will continue to introduce Linux Operation and maintenance related knowledge , The main content of this paper is SQL The secondary injection .

disclaimer ：
The content introduced in this article is only for learning and communication , It is strictly prohibited to use the technology in the text for illegal acts , Otherwise, you will bear all serious consequences ！
Again ： It is forbidden to perform penetration tests on unauthorized equipment ！

One 、SQL The principle of secondary injection

SQL The secondary injection , It refers to some application scenarios , Let's put the SQL Injected payload Write to the target site database , Then take out the data in some actual , Which makes us write payload perform .
therefore ,SQL Secondary injection is generally divided into 2 Step , The first step is to insert malicious data into the database of the target site , The second step is even if the malicious data we insert is referenced by the target site .
SQL Implementation of secondary injection , In the first step, it is required that the malicious data we insert can be successfully written to the database of the target site , The site can escape the malicious data we write , But the data itself will not be modified , Nor will we refuse to write because of malicious data ; The second step requires that our malicious data can be extracted under certain application scenarios , And will not check the data inside its site .

Two 、SQL Introduction to the secondary injection range

We use sqli_lab Of the 24 Guan as SQL Secondary injection range , After the shooting range is opened, it is shown as follows ：

As can be seen from the above figure , The range is a login box , It also supports the function of forgetting passwords and newly registered users . After successful login, it is shown below ：

Loopholes in the range , It exists at the place where the password is modified , We open the password change php file pass_change.php, As shown below ：

Notice the red box in the above figure , The code is right curr_pass、pass and re_pass All use mysql_real_escape_string Function , But it's not true username Parameters are filtered .
username Directly spliced to the back sql In the execution statement , such , We exist where we change the password SQL Secondary injection vulnerability .

3、 ... and 、SQL Second injection practice

below , Let's do SQL The actual combat of the second injection , First , Let's register a user first admin’#, As shown below ：

At this time , We can check the current database , As shown below ：

Next , We choose to modify it admin’# User's password , As shown below ：

here , We click Reset After resetting the password , our sql Statement for ：

UPDATE users SET PASSWORD='$pass' where username='admin'# and password='$curr_pass'

You can see , The single quotation mark after our user just closes the single quotation mark before the field , and # It also filters all the contents behind . such , We actually achieved the goal of giving admin The user changes the password , The modified page is as follows ：

The completed database is as follows ：

Originality is not easy. , Reprint please explain the source ：https://blog.csdn.net/weixin_40228200