1. 先搞清楚“Header型注入”到底在测什么以及为什么新手会觉得“不对”很多刚开始接触Web安全测试的同学在Pikachu靶场做到“Header型注入”关卡时尤其是题目里提到“不知道账号密码目录文件”第一反应往往是懵的。感觉无从下手甚至怀疑题目是不是出错了——登录都没有怎么注入这正是这个关卡设计的巧妙之处也是它和常规“GET/POST型注入”最核心的区别。它测试的不是你能否通过一个表单或URL参数去注入而是测试你对HTTP请求完整性的理解。简单来说它模拟了一个场景一个Web应用在验证了你的登录身份后会从HTTP请求的Header头部里读取一些信息比如User-Agent,X-Forwarded-For,Referer等并把这些信息不加过滤地拼接到数据库查询语句中。所以你“不知道账号密码”是正常的因为题目假设你已经通过了某种形式的认证比如靶场里可能内置了一个默认会话进入了某个用户后台页面。攻击的入口点从这一刻起就转移到了你浏览器发送的每一个HTTP请求的Header字段里。这个关卡的核心价值在于让你意识到SQL注入的风险点远不止于用户直接输入的表单。任何来自客户端、可被用户控制或篡改的数据如果被服务器信任并用于数据库查询都可能成为注入点。这对于理解真实世界中的“二次注入”、“盲注”以及某些API接口的漏洞至关重要。因此觉得“不对”是因为思维还停留在“找输入框”的阶段。现在需要把思路切换到“拦截并修改HTTP请求包”上。接下来的实操我会带你从零开始用“报错注入”的方式把它打通重点不是记住步骤而是理解每一步为什么这么做以及报错信息是如何被“挤”出来的。2. 环境准备与关键思路为什么用报错注入需要哪些工具在动手之前必须把环境和思路理清。盲目跟着步骤做一旦出错还是不会排查。2.1 靶场与工具准备Pikachu靶场确保你的Pikachu已经成功搭建并运行。通常访问http://your-ip/pikachu即可。如果还没搭建根据你的“pikachu安装教程”搜索材料无非就是PHP环境如XAMPP、PHPStudy 数据库初始化导入SQL文件那几步。搭建本身不是难点重点是跑起来后能正常访问各个漏洞模块。浏览器任何现代浏览器均可。代理工具这是必备的。因为你需要拦截并修改HTTP请求。最常用的是Burp Suite社区版免费或者OWASP ZAP。本文以Burp Suite为例因为它更普及。你需要下载安装Burp Suite。配置浏览器代理通常为127.0.0.1:8080。在Burp中安装并信任其CA证书用于拦截HTTPS流量虽然Pikachu一般是HTTP但养成好习惯。确保Burp的Proxy-Intercept是Intercept is on状态。2.2 为什么选择“报错注入”Header型注入很多时候页面不会有明显的回显比如把查询结果显示在网页上。我们称之为“盲注”场景。盲注又分布尔盲注和时间盲注但效率相对较低。“报错注入”是利用数据库执行某些特殊函数时如果参数不合法会将错误信息直接返回在页面的HTTP响应中。这相当于把“盲注”变成了“有回显的注入”效率大大提升。在MySQL中常用于报错注入的函数有updatexml(): 用于XML文档查询第二个参数格式错误时会报错并带出执行结果。extractvalue(): 同上用于XML文档查询。floor(rand(0)*2)配合count和group by触发主键重复错误。本关卡通常利用updatexml()或extractvalue()。我们的思路是将我们想获取的数据如数据库名通过concat函数拼接到一个错误的XPath路径参数中触发数据库报错从而在错误信息里看到我们想要的数据。核心Payload模型updatexml(1, concat(0x7e, (你想要执行的SQL查询语句), 0x7e), 1)解释0x7e是波浪号~的十六进制用于在报错信息中清晰地分隔出我们查询的结果。updatexml第一个和第三个参数可以是任意数字重点是第二个参数我们构造一个错误的XPath路径concat的结果数据库执行时会报错并说“XPath语法错误你的字符串是 ‘~查询结果~’”。3. 实战步骤拆解从访问页面到获取数据库名现在我们进入具体的操作流程。请严格按照顺序并理解每个环节。3.1 触发漏洞点与确认注入位置访问关卡在Pikachu首页点击“SQL-Inject” - “Header注入” - “User-Agent注入”。这里以User-Agent为例Referer和XFF原理完全相同。观察页面页面可能会显示“您的User-Agent是xxx”或者只是简单刷新。这说明服务器确实读取并可能处理了我们的User-Agent。开启拦截确保Burp Suite拦截已开启。刷新页面/点击提交在浏览器中刷新该漏洞页面。此时HTTP请求会被Burp Suite拦截下来。定位注入点在Burp的Proxy-Intercept标签页你会看到被拦截的HTTP请求。找到User-Agent请求头这一行。它大概长这样User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 ...初步测试在User-Agent的值后面添加一个单引号‘试图破坏原SQL语句。例如User-Agent: Mozilla/5.0 ... AppleWebKit/537.36‘点击Forward放行这个请求。查看结果回到浏览器观察页面。可能出现几种情况直接报错页面显示MySQL语法错误这直接证明存在SQL注入且是报错型。页面空白或异常也可能存在注入。页面正常不要灰心可能是原SQL语句构造方式不同比如用了括号。可以尝试‘或‘)‘等组合进行测试。关键点这一步的目的是确认这个Header字段的值是否被直接拼接到SQL语句中且未过滤。只要修改后页面行为正常、报错、空白与修改前不同就高度可疑。3.2 实施报错注入获取当前数据库名假设我们添加‘后页面报错了说明注入点存在。现在我们要利用报错注入函数获取信息。再次拦截请求在浏览器中再次刷新页面让Burp拦截新的请求。构造报错Payload我们将User-Agent的值替换为我们的Payload。目的是让数据库执行updatexml函数并报错在报错信息中返回当前数据库名。原始请求User-Agent: Mozilla/5.0 ...修改为User-Agent: Mozilla/5.0‘ and updatexml(1, concat(0x7e, database(), 0x7e), 1) and ’1‘’1Payload分解解释Mozilla/5.0‘闭合原SQL语句中User-Agent值可能存在的引号。and连接后续的恶意查询。updatexml(1, concat(0x7e, database(), 0x7e), 1)核心报错函数。database()是MySQL内置函数返回当前数据库名称。and ’1‘’1闭合整个语句并使and条件为真保证原查询逻辑大概能继续执行避免因语法错误导致完全无法查询。这里用‘1‘’1是为了匹配我们开头添加的单引号。放行请求并查看结果点击Forward。回到浏览器查看页面。分析结果如果注入成功页面很可能不会正常显示而是会返回一个MySQL错误信息。错误信息中应该包含类似这样的内容XPATH syntax error: ‘~pikachu~‘这里的pikachu就是database()函数执行的结果也就是当前网站使用的数据库名成功为什么这样做可行我们推测服务器端的原始SQL可能是UPDATE some_table SET some_column ‘value‘ WHERE user_id xxx AND ua ‘我们输入的User-Agent‘我们修改后语句变成了UPDATE some_table SET some_column ‘value‘ WHERE user_id xxx AND ua ‘Mozilla/5.0‘ and updatexml(...) and ’1‘’1‘数据库会按顺序执行and条件当执行到updatexml时触发错误并将错误信息包含我们查询的database()结果返回给前端。3.3 进阶信息收集获取表名、列名、数据拿到数据库名只是第一步。接下来要获取表名、列名最终拿到数据。思路完全一样只是嵌套的SQL查询语句变了。获取表名我们需要查询information_schema.tables来获取pikachu数据库下的所有表名。通常我们一次只取一个用limit子句。修改User-Agent为User-Agent: Mozilla/5.0‘ and updatexml(1, concat(0x7e, (select table_name from information_schema.tables where table_schema‘pikachu‘ limit 0,1), 0x7e), 1) and ’1‘’1limit 0,1表示从第0行开始取1行。执行后报错信息会显示第一个表名比如httpinfo。要获取第二个表改为limit 1,1依此类推。你需要遍历直到找到看起来像用户表的名称比如memberusers等。获取列名假设我们找到了表member。接下来获取它的列名。修改User-Agent为User-Agent: Mozilla/5.0‘ and updatexml(1, concat(0x7e, (select column_name from information_schema.columns where table_schema‘pikachu‘ and table_name‘member‘ limit 0,1), 0x7e), 1) and ’1‘’1同样使用limit遍历直到找到usernamepassword等关键列。获取数据假设列名为username和password。现在获取具体数据。修改User-Agent为User-Agent: Mozilla/5.0‘ and updatexml(1, concat(0x7e, (select concat(username, ‘:‘, password) from member limit 0,1), 0x7e), 1) and ’1‘’1这会将第一条记录的username和password用冒号连接起来并通过报错显示。注意updatexml函数一次最多只能返回约32个字符取决于MySQL版本。如果查询结果如group_concat所有表名过长会被截断。解决方法是使用substring或mid函数分段获取。例如updatexml(1, concat(0x7e, substring((select group_concat(table_name) from information_schema.tables where table_schema‘pikachu‘), 1, 31), 0x7e), 1)然后修改substring的第二个参数起始位置来获取下一段。4. 常见问题、排查思路与防御思考做到这里你应该已经成功利用报错注入完成了攻击链。但在实际操作中一定会遇到问题。下面是我总结的排查清单和经验。4.1 实战中可能遇到的坑及解法问题现象可能原因排查步骤页面无任何变化返回正常1. 注入点判断错误Header字段不对。2. Payload构造错误未成功闭合语句。3. 靶场环境未正确初始化或配置。1. 换一个Header字段如Referer,X-Forwarded-For尝试。2. 尝试不同的闭合方式‘,‘),‘)),“,“)等。3. 检查Burp拦截的请求是否完整是否真的修改了目标字段。4. 回Pikachu首页确认其他简单注入关卡如GET型是否能通验证环境。页面直接显示MySQL语法错误但使用报错函数后错误信息无变化1. 报错函数被WAF或靶场自身简单过滤。2. 函数名或语法写错。3. 数据库用户权限不足无法执行某些函数。1. 尝试使用extractvalue代替updatexmlPayload结构类似。2. 检查Payload中的括号、逗号、引号是否成对特别是单引号‘的闭合。3. 使用version()代替database()测试看是否能报错带出版本信息确认函数是否可用。报错信息显示“XPath syntax error”但后面是空或乱码1. 内部查询语句(select ...)执行结果为空或出错。2.concat函数连接的内容有问题。1. 单独测试内部查询语句是否正确。例如先测试select database()是否能在数据库执行。2. 确保information_schema的表名、列名拼写正确数据库名table_schema的值用引号括起来。3. 在Payload最内层查询使用limit确保有结果返回。Burp Suite无法拦截到请求1. 浏览器代理未正确设置。2. Burp的拦截未开启。3. 本地防火墙或安全软件阻止。1. 确认浏览器代理设置为127.0.0.1:8080。2. 确认BurpProxy-Intercept标签页下Intercept is on按钮是红色开启状态。3. 访问http://burp或http://127.0.0.1:8080看是否能打开Burp的证书下载页面验证代理连通性。4.2 从攻击者视角回到开发者视角如何防御通过这个实验你应该深刻理解到防御SQL注入的核心原则是永远不要信任用户输入无论它来自哪里。使用预编译语句Prepared Statements这是最有效、最根本的防御手段。通过参数化查询将用户输入的数据始终视为“数据”而非“代码的一部分”。无论是表单、URL参数还是HTTP Header都应该用此方式处理。对输入进行严格的过滤和转义如果因为某些原因不能使用预编译则必须对所有输入进行严格的检查。针对Header注入服务器端代码在读取$_SERVER[‘HTTP_USER_AGENT‘]、$_SERVER[‘HTTP_REFERER‘]等变量时应将其视为不可信数据进行转义如使用mysqli_real_escape_string或白名单过滤。最小权限原则数据库连接账户不应使用root或高权限账户。只赋予其应用所需的最小权限例如只允许查询特定表甚至禁止执行updatexml、extractvalue等危险函数。错误信息处理生产环境必须关闭PHP或应用的错误回显display_errors Off避免将详细的数据库错误信息暴露给用户。自定义统一的错误页面。4.3 关于“不知道账号密码目录文件”的最终解释现在回头看标题里的困惑答案就很清晰了这个关卡模拟的是已认证用户会话下的横向攻击。攻击者不需要知道后台登录密码他可能通过其他漏洞如会话固定、弱Cookie获得了有效会话。一旦进入应用内部那些看似“自动生成”、“不可控”的HTTP头部就成了新的、被忽视的攻击面。所以这个练习的价值在于跳出“登录框注入”的定式思维让你养成一个习惯在测试时用Burp Suite拦截下每一个请求仔细观察每一个参数、每一个Header思考它们是否被后端处理以及是否可能被篡改。安全测试很多时候就是一场关于“信任边界”的思维游戏。Header型注入就是一个经典的、关于信任边界判断的实战案例。
