【学习笔记】SQL注入的“特殊战场”——不同场景与二阶注入
- 2026-04-17 10:46:20
【学习笔记】SQL注入的“特殊战场”——不同场景与二阶注入
前六篇我们聚焦于URL参数、搜索框等“显性注入点”，但现实中，SQL注入可能藏在更隐蔽的地方： Cookie里的sessionid； HTTP Header中的User-Agent； 用XML/JSON格式传递的参数； 甚至“第一次注入，第二次触发”的二阶注入。 PortSwigger原路径将这些称为“上下文相关的SQL注入”——注入点的位置和环境，直接决定了Payload的写法和绕过技巧。 PortSwigger原路径重点讲解了4类非传统注入点，我们用“实战+绕过”拆解： 场景：某网站的Cookie中存储用户身份：Cookie: session=12345。应用逻辑： 注入方法：修改Cookie为' OR 1=1--，让SQL变成： ✅ 触发条件：应用直接从Cookie中取数据拼SQL，未过滤。 场景：应用记录用户访问日志，把User-Agent存入数据库： 注入方法：修改User-Agent为' OR (SELECT 1)--，让SQL变成： ✅ 触发条件：应用未过滤Header中的特殊字符（如'、;）。 场景：某网站的“订单提交”功能用XML传参： 目标：绕过WAF过滤（WAF拦截'、OR等关键字）。 PortSwigger实验Payload（用XML实体编码）： S是S的十六进制编码（WAF不认识，但XML解析后会还原成S）； 最终SQL变成： ✅ 成功绕过WAF，触发SQL注入！ PortSwigger原路径将二阶注入（Second-order SQLi）定义为：“第一次注入的数据被存储，第二次使用时才触发注入”。就像你把“炸弹”埋在数据库里，等有人“碰”它时才爆炸。 原理：两次查询的“时间差” 第一次请求：用户输入恶意数据（比如注册用户名' OR 1=1--），应用将其存入数据库（未执行）； 第二次请求：应用从数据库取出该数据，拼接到SQL中执行——此时注入生效！ 场景：某网站的“用户注册”功能，注册时用username和password，登录时用username查询： 注册时，应用执行：INSERT INTO users (username, password) VALUES ('$username', '$password'); 登录时，应用执行：SELECT * FROM users WHERE username = '$username' AND password = '$password'; 目标：用二阶注入登录administrator账号（无需密码）。 步骤： 注册用户名为' OR username='administrator'--，密码随便填（比如123）； 应用将' OR username='administrator'--存入users表的username字段； 登录时，输入刚才的用户名和密码，应用执行： WAF过滤了'，怎么办？ 二阶注入没反应？ PortSwigger原路径指出，特殊场景注入的根源是“所有用户输入（包括Cookie、Header、XML）都被当成SQL代码”，防御方法： 全输入点过滤：不仅过滤URL参数，还要过滤Cookie、Header、XML/JSON中的数据； 参数化查询（终极方案）：不管是第一次插入还是第二次查询，都用?占位符（同第一篇）； 二阶注入专项防御：存储数据时严格转义（比如mysqli_real_escape_string()），取出数据时再次验证。 小问题：你在测试中遇到过“Cookie注入”吗？是用Burp Suite的“Cookie Editor”修改的吗？欢迎评论区分享！ 下期预告：我们将进入SQL注入的“终点”——防御篇，从代码层到架构层，彻底解决SQL注入问题。 （注：文中实验均基于PortSwigger Web Security Academy靶场，原文链接：https://portswigger.net/web-security/sql-injection）
声明：文中涉及到的技术和工具，仅供学习使用，禁止从事任何非法活动，如因此造成的直接或间接损失，均由使用者自行承担责任。
一、开篇：当注入点不在“输入框”时
二、特殊场景1：注入点在“非参数位置”
1. Cookie注入（最常见）
SELECT * FROM users WHERE session_id = '12345';SELECT * FROM users WHERE session_id = '' OR 1=1--';2. Header注入（User-Agent/Referer）
INSERT INTO logs (ip, user_agent) VALUES ('1.2.3.4', 'Mozilla/5.0');INSERT INTO logs (ip, user_agent) VALUES ('1.2.3.4', '' OR (SELECT 1)--');3. XML编码绕过（PortSwigger靶场实战）
<order><productId>1</productId><quantity>1</quantity></order>
应用逻辑：解析XML后拼接SQL：SELECT * FROM orders WHERE product_id = '1' AND quantity = '1';<order><productId>1' SELECT 1--</productId><quantity>1</quantity></order>
SELECT * FROM orders WHERE product_id = '1' SELECT 1--' AND quantity = '1';三、特殊场景2：二阶注入（First insert, then execute）
PortSwigger靶场实战：注册时的“隐藏炸弹”
SELECT * FROM users WHERE username = '' OR username='administrator'--' AND password = '123';四、常见坑点与绕过技巧（PortSwigger原路径强调）
检查数据存储时是否被转义（比如
'被变成\'）→ 用CHAR()函数（CHAR(39)是'）；检查第二次查询是否真的用了该数据（比如登录时才查询，而不是注册后立即查询）。
用十六进制编码（MySQL）：
' OR 1=1--→0x27204f5220313d312d2d（需配合UNHEX()）；用双写绕过：
' OR 'OR' 1=1--（WAF拦截OR，但双写后放行）。
五、防御：如何覆盖“特殊场景”？
六、互动与预告
本文来自网友投稿或网络内容，如有侵犯您的权益请联系我们删除，联系邮箱：wyl860211@qq.com 。
