原理

攻击者构造的恶意数据存储在数据库后，恶意数据被读取并进入到SQL查询语句所导致的注入
防御者可能在用户输入恶意数据时对其中的特殊字符进行了转义处理，但在恶意数据插入到数据库时被处理的数据又被还原并存储在数据库中
当Web程序调用存储在数据库中的恶意数据并执行SQL查询时，就发生了SQL二次注入

二次注入，可以概括为以下两步:

第一步：插入恶意数据
进行数据库插入数据时，对其中的特殊字符进行了转义处理，在写入数据库的时候又保留了原来的数据。

第二步：引用恶意数据
开发者默认存入数据库的数据都是安全的，在进行查询时，直接从数据库中取出恶意数据，没有进行进一步的检验的处理。

作者：Ackerzy
链接：https://www.jianshu.com/p/3fe7904683ac
来源：简书

案例(sqli-lab-less-24)

1. 最初的用户名密码：admin/admin
   

2. 界面是这样的，可以注册账号
   尝试用admin’#进行注入，失败。
   而源代码中也确实进行了转义处理，所以此处使用admin’#肯定失败
   

3. 注册账号登录后，发现页面跳转到了修改密码的功能页面
   并且修改密码界面没有验证原来的密码
   猜测Sql语句可能是：Update users set password=’xxx’ where username=’ xxx ’
   可以考虑二次注入
   

4. 注册一个名为admin’#的账号,注册成功后的数据库内容
   传入的username、password、re_password仍均被mysql_escape_string进行了转义处理，但是在数据库中还是插入了admin’#
   
   这是因为当数据写入到数据库的时候反斜杠会被移除，所以写入到数据库的内容就是原始数据，并不会在前面多了反斜杠。

5. 登录成功
   

6. 修改密码为111，提示成功
   

7. 使用admin/111，成功登录
   
   此时查看数据库，admin’#密码依旧是123456，而admin密码已经被修改为111