静态分析应用安全【免费下载链接】gixyNginx configuration static analyzer项目地址https://gitcode.com/gh_mirrors/gi/gixy点击查看免费下载本篇技术指南围绕 gixyNginx 配置静态分析器内置的http_splitting检测插件展开讲解 HTTP SplittingHTTP 拆分/注入漏洞的形成原理、在 Nginx 配置中的典型触发场景、真实攻击请求示例以及如何在编写配置时规避该风险。读完本文你将掌握如何识别哪些 Nginx 变量可能携带\r/\n理解 gixy 是如何在静态层面推导变量可控字符集合的并能对照测试用例写出安全的rewrite、return、add_header、proxy_set_header、proxy_pass指令。什么是 HTTP Splitting 漏洞HTTP Splitting 是一类因输入数据校验不当而引发的注入类漏洞。攻击者若能向 Nginx 构造的请求或响应中注入换行符\n0x0A或回车符\r0x0D就可以改变 HTTP 消息的结构注入到请求中可拆分出额外的请求HTTP Request Splitting通常用于攻击 Nginx 后端的 Web 应用注入到响应中可拆分出伪造的响应头/响应体HTTP Response Splitting通常用于攻击应用的使用者如配合缓存投毒、XSS 等。其根因在于Nginx 的部分指令在把变量值拼入请求行、请求头或响应头时并不对值中的 CRLF 做编码或校验默认假定配置作者清楚自己引入的变量是安全的。一旦变量值来自用户可控的输入如 URL 中的路径片段且中间缺少过滤攻击者便获得了注入的机会。gixy 的http_splitting插件正是针对这类问题设计的静态检测器其检测逻辑实现在 gixy/plugins/http_splitting.py插件声明summary Possible HTTP-Splitting vulnerability.严重级别为HIGH检测范围覆盖rewrite、return、add_header、proxy_set_header、proxy_pass五类指令见源码第 24 行。自查清单如何在配置中发现风险点在人工审计 Nginx 配置时应始终关注以下三类信号负责构造请求/响应的指令中使用的变量rewrite、return、add_header、proxy_set_header、proxy_pass等指令会把变量值直接写入请求或响应若变量可能包含 CRLF即构成注入面$uri与$document_uri变量这两个变量保存的是URL 解码后的规范化路径值。攻击者可以发送%0d%0a这类百分号编码Nginx 在解码后得到真实的\r\n并存入$uri因此只要$uri/$document_uri出现在上述指令中就应高度警惕从排除型字符区间正则组中提取的变量例如(?Pmyvar[^.])。这类正则只排除了点号却没有排除换行符从 URL 解码后的路径中匹配到的值天然可以携带 CRLF属于典型的高危变量来源。这一自查逻辑与插件源码的审计流程一一对应http_splitting.audit()对指令参数调用compile_script()拆出每个变量再通过Variable.can_contain()判断变量是否可能包含\n或\rgixy/core/variable.py。漏洞示例从排除型正则到注入响应头下面是一段存在漏洞的 Nginx 配置从正则捕获组中提取$action变量并将其拼入add_headerserver { listen 80 default; location ~ /v1/((?action[^.]*)\.json)?$ { add_header X-Action $action; return 200 OK; } }这里的捕获组[^.]*只排除了点号$action可以从 URL 解码后的路径中匹配到任意字符——包括换行符。攻击者构造如下请求即可在响应中注入自定义头GET /v1/see%20below%0d%0ax-crlf-header:injected.json HTTP/1.0 Host: localhost HTTP/1.1 200 OK Server: nginx/1.11.10 Date: Mon, 13 Mar 2017 21:21:29 GMT Content-Type: application/octet-stream Content-Length: 2 Connection: close X-Action: see below x-crlf-header:injected OK从响应可以看出攻击者成功添加了x-crlf-header: injected响应头。这一结果由多个条件叠加促成add_header对传入的变量值不做编码或校验默认作者了解后果源码层面即插件将add_header列入检测指令的原因请求路径在进入 location 匹配前已被规范化并 URL 解码%0d%0a还原为真实的\r\n$action来自排除型区间[^.]*的捕获组其值最终为see below\r\nx-crlf-header:injected该值被拼入add_header X-Action后\r\n使 Nginx 将后续内容当作新的响应头行解析注入生效。对应地仓库测试用例 rewrite_extract_fp.conf 中rewrite ^/proxy/(a|b)/(?path\W*)$ http://storage/$path redirect;同样复现了排除型正则捕获组 变量拼入指令的检测场景。gixy 如何静态判定变量可能包含 CRLFgixy 的检测并不运行真实请求而是通过符号化推导变量的字符集合。其核心链路如下脚本拆解compile_script()gixy/core/variable.py用正则EXTRACT_RE把指令参数拆成字符串字面量与变量交替的列表例如http://$foo:$bar会被拆成字面量http://、变量$foo、字面量:、变量$bar边界与正则分析Variable.can_contain(char)依次检查边界集合boundary、正则捕获组regexp和依赖变量depends。若变量来源于(?action[^.]*)其正则值[^.]*的可包含字符集就包含了\n与\r从而判定can_contain(\n)为真依赖追踪通过set $p $2;这类指令中转的变量会记录依赖关系providers属性会递归收集产生该变量的所有上游指令location、rewrite 等用于在报告中给出完整的证据链——对应测试 proxy_from_location_var_var.conf 与 proxy_from_location_var_var_var.conf服务端/客户端方向区分插件代码中server_side directive.name.startswith(proxy_)对proxy_pass/proxy_set_header这类发往后端的请求构造指令只报告可能包含\n的情况而rewrite/return/add_header这类作用于响应或重定向的指令\r同样危险CR 可单独拆分响应行因此\r也会被报告。真实测试用例哪些配置会被报警仓库 tests/plugins/simply/http_splitting/ 目录下汇集了大量正反用例可直接验证插件的判定边界。典型命中配置包括# $uri 未解码前的规范化值可携带 %0d%0a 解码结果 —— 命中 add_header X-Uri $uri;# 排除型正则 [^/] 允许换行符$1 可控 —— 命中 location ~* ^/test/([^/])/ { proxy_pass http://10.10.10.10/$1; }# 排除型正则 [^.]* 允许换行符且经 $p 中转 —— 命中 location ~ /proxy/(a|b)/(\W*)$ { set $p $2; proxy_pass http://storage/$p; }# $document_uri 拼入请求头 —— 命中 proxy_set_header X-Original-Uri $document_uri;# $uri 拼入 rewrite —— 命中 rewrite ^ http://some$uri;反例不会报警则验证了插件的克制return 403;无变量、return 301 https://some$request_uri;return_request_uri_fp.conf$request_uri保持原始未解码形式攻击者注入的%0d%0a不会还原成 CRLF、location ~ /proxy/(a|b)/(\W*)$中set $p $1;引用的是仅含a|b的捕获组proxy_from_location_var_var_fp.conf字符集安全、以及引用未解析变量的 dont_report_not_resolved_var_fp.conf。这些用例说明 gixy 依赖变量的来源与字符集做出判定而非机械地见到$uri就报警。如何修复与规避针对上述风险建议按优先级采取以下措施优先使用安全的变量在重定向、拼请求/响应头等场景用$request_uri替代$uri/$document_uri。$request_uri是客户端发送的原始未解码请求 URI其中的%0d%0a保持百分号编码形态不会还原为真实 CRLF从源头杜绝注入收紧正则排除区间在正则捕获组中显式排除空白与换行。例如将/some/(?action[^/])改为/some/(?action[^/\s])使\n/\r无法进入捕获变量原英文文档中的写法[^/]结尾缺一个)是笔误实际应闭合捕获组仅在你完全清楚后果时校验$uri对必须使用$uri的场景可考虑增加额外的校验逻辑如拒绝含控制字符的请求但务必理解这属于业务层防御Nginx 本身不会替你做编码误用可能引入新的绕过。修复后可用 gixy 复检确认运行gixy nginx.conf或通过gixy --help查看参数若输出中不再出现http_splitting相关 HIGH 级别告警则说明 CRLF 注入面已消除。插件的完整检测指令集合与判定优先级可直接查阅 gixy/plugins/http_splitting.py更丰富的正反配置样例见 tests/plugins/simply/http_splitting/ 目录。小结HTTP Splitting 是 Nginx 配置中容易被忽视的高危问题add_header/proxy_set_header/rewrite/return/proxy_pass拼接未经过滤的变量配合$uri的 URL 解码行为与排除型正则捕获组即可让攻击者在请求或响应中注入任意 CRLF 内容。gixy 通过 gixy/core/variable.py 中的字符集推导能力静态还原出每个变量的可包含字符从而在部署前发现隐患。日常编码中坚持用$request_uri代替$uri、正则排除区间加上\s、审慎校验$uri三条原则即可从配置层面彻底消除该类漏洞。赞分享静态分析应用安全【免费下载链接】gixyNginx configuration static analyzer项目地址https://gitcode.com/gh_mirrors/gi/gixy点击查看免费下载相关推荐Gixy项目解析Nginx配置中alias指令的路径遍历风险与防护Gixy项目解析Nginx配置中alias指令的路径遍历风险与防护 前言 在Nginx服务器的配置过程中alias指令是一个常用但容易被错误配置的指令。本文静态分析应用安全10分钟越狱老设备palera1n完整操作指南10分钟越狱老设备palera1n完整操作指南 你的 iPhone 7 停在 iOS 15 再也动不了却还想要 Sileo 和 tweak——palera1CLI固件10分钟跑通大麦抢票脚本从克隆到空跑只需6条命令10分钟跑通大麦抢票脚本从克隆到空跑只需6条命令 开票瞬间已抢完三个字比你的手指先到一步。开源项目 ticket purchase 把选城市、挑场次、选GUI 自动化RPA上一篇RomM 前端架构深度解析Vue 3 单页应用如何驱动自托管 ROM 管理与游玩平台下一篇终极指南如何用Bezier.js打造流畅动画与图形效果创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 gixy 之 HTTP Splitting 漏洞检测：Nginx 配置中 CRLF 注入的风险分析与防护实践
静态分析应用安全【免费下载链接】gixyNginx configuration static analyzer项目地址https://gitcode.com/gh_mirrors/gi/gixy点击查看免费下载本篇技术指南围绕 gixyNginx 配置静态分析器内置的http_splitting检测插件展开讲解 HTTP SplittingHTTP 拆分/注入漏洞的形成原理、在 Nginx 配置中的典型触发场景、真实攻击请求示例以及如何在编写配置时规避该风险。读完本文你将掌握如何识别哪些 Nginx 变量可能携带\r/\n理解 gixy 是如何在静态层面推导变量可控字符集合的并能对照测试用例写出安全的rewrite、return、add_header、proxy_set_header、proxy_pass指令。什么是 HTTP Splitting 漏洞HTTP Splitting 是一类因输入数据校验不当而引发的注入类漏洞。攻击者若能向 Nginx 构造的请求或响应中注入换行符\n0x0A或回车符\r0x0D就可以改变 HTTP 消息的结构注入到请求中可拆分出额外的请求HTTP Request Splitting通常用于攻击 Nginx 后端的 Web 应用注入到响应中可拆分出伪造的响应头/响应体HTTP Response Splitting通常用于攻击应用的使用者如配合缓存投毒、XSS 等。其根因在于Nginx 的部分指令在把变量值拼入请求行、请求头或响应头时并不对值中的 CRLF 做编码或校验默认假定配置作者清楚自己引入的变量是安全的。一旦变量值来自用户可控的输入如 URL 中的路径片段且中间缺少过滤攻击者便获得了注入的机会。gixy 的http_splitting插件正是针对这类问题设计的静态检测器其检测逻辑实现在 gixy/plugins/http_splitting.py插件声明summary Possible HTTP-Splitting vulnerability.严重级别为HIGH检测范围覆盖rewrite、return、add_header、proxy_set_header、proxy_pass五类指令见源码第 24 行。自查清单如何在配置中发现风险点在人工审计 Nginx 配置时应始终关注以下三类信号负责构造请求/响应的指令中使用的变量rewrite、return、add_header、proxy_set_header、proxy_pass等指令会把变量值直接写入请求或响应若变量可能包含 CRLF即构成注入面$uri与$document_uri变量这两个变量保存的是URL 解码后的规范化路径值。攻击者可以发送%0d%0a这类百分号编码Nginx 在解码后得到真实的\r\n并存入$uri因此只要$uri/$document_uri出现在上述指令中就应高度警惕从排除型字符区间正则组中提取的变量例如(?Pmyvar[^.])。这类正则只排除了点号却没有排除换行符从 URL 解码后的路径中匹配到的值天然可以携带 CRLF属于典型的高危变量来源。这一自查逻辑与插件源码的审计流程一一对应http_splitting.audit()对指令参数调用compile_script()拆出每个变量再通过Variable.can_contain()判断变量是否可能包含\n或\rgixy/core/variable.py。漏洞示例从排除型正则到注入响应头下面是一段存在漏洞的 Nginx 配置从正则捕获组中提取$action变量并将其拼入add_headerserver { listen 80 default; location ~ /v1/((?action[^.]*)\.json)?$ { add_header X-Action $action; return 200 OK; } }这里的捕获组[^.]*只排除了点号$action可以从 URL 解码后的路径中匹配到任意字符——包括换行符。攻击者构造如下请求即可在响应中注入自定义头GET /v1/see%20below%0d%0ax-crlf-header:injected.json HTTP/1.0 Host: localhost HTTP/1.1 200 OK Server: nginx/1.11.10 Date: Mon, 13 Mar 2017 21:21:29 GMT Content-Type: application/octet-stream Content-Length: 2 Connection: close X-Action: see below x-crlf-header:injected OK从响应可以看出攻击者成功添加了x-crlf-header: injected响应头。这一结果由多个条件叠加促成add_header对传入的变量值不做编码或校验默认作者了解后果源码层面即插件将add_header列入检测指令的原因请求路径在进入 location 匹配前已被规范化并 URL 解码%0d%0a还原为真实的\r\n$action来自排除型区间[^.]*的捕获组其值最终为see below\r\nx-crlf-header:injected该值被拼入add_header X-Action后\r\n使 Nginx 将后续内容当作新的响应头行解析注入生效。对应地仓库测试用例 rewrite_extract_fp.conf 中rewrite ^/proxy/(a|b)/(?path\W*)$ http://storage/$path redirect;同样复现了排除型正则捕获组 变量拼入指令的检测场景。gixy 如何静态判定变量可能包含 CRLFgixy 的检测并不运行真实请求而是通过符号化推导变量的字符集合。其核心链路如下脚本拆解compile_script()gixy/core/variable.py用正则EXTRACT_RE把指令参数拆成字符串字面量与变量交替的列表例如http://$foo:$bar会被拆成字面量http://、变量$foo、字面量:、变量$bar边界与正则分析Variable.can_contain(char)依次检查边界集合boundary、正则捕获组regexp和依赖变量depends。若变量来源于(?action[^.]*)其正则值[^.]*的可包含字符集就包含了\n与\r从而判定can_contain(\n)为真依赖追踪通过set $p $2;这类指令中转的变量会记录依赖关系providers属性会递归收集产生该变量的所有上游指令location、rewrite 等用于在报告中给出完整的证据链——对应测试 proxy_from_location_var_var.conf 与 proxy_from_location_var_var_var.conf服务端/客户端方向区分插件代码中server_side directive.name.startswith(proxy_)对proxy_pass/proxy_set_header这类发往后端的请求构造指令只报告可能包含\n的情况而rewrite/return/add_header这类作用于响应或重定向的指令\r同样危险CR 可单独拆分响应行因此\r也会被报告。真实测试用例哪些配置会被报警仓库 tests/plugins/simply/http_splitting/ 目录下汇集了大量正反用例可直接验证插件的判定边界。典型命中配置包括# $uri 未解码前的规范化值可携带 %0d%0a 解码结果 —— 命中 add_header X-Uri $uri;# 排除型正则 [^/] 允许换行符$1 可控 —— 命中 location ~* ^/test/([^/])/ { proxy_pass http://10.10.10.10/$1; }# 排除型正则 [^.]* 允许换行符且经 $p 中转 —— 命中 location ~ /proxy/(a|b)/(\W*)$ { set $p $2; proxy_pass http://storage/$p; }# $document_uri 拼入请求头 —— 命中 proxy_set_header X-Original-Uri $document_uri;# $uri 拼入 rewrite —— 命中 rewrite ^ http://some$uri;反例不会报警则验证了插件的克制return 403;无变量、return 301 https://some$request_uri;return_request_uri_fp.conf$request_uri保持原始未解码形式攻击者注入的%0d%0a不会还原成 CRLF、location ~ /proxy/(a|b)/(\W*)$中set $p $1;引用的是仅含a|b的捕获组proxy_from_location_var_var_fp.conf字符集安全、以及引用未解析变量的 dont_report_not_resolved_var_fp.conf。这些用例说明 gixy 依赖变量的来源与字符集做出判定而非机械地见到$uri就报警。如何修复与规避针对上述风险建议按优先级采取以下措施优先使用安全的变量在重定向、拼请求/响应头等场景用$request_uri替代$uri/$document_uri。$request_uri是客户端发送的原始未解码请求 URI其中的%0d%0a保持百分号编码形态不会还原为真实 CRLF从源头杜绝注入收紧正则排除区间在正则捕获组中显式排除空白与换行。例如将/some/(?action[^/])改为/some/(?action[^/\s])使\n/\r无法进入捕获变量原英文文档中的写法[^/]结尾缺一个)是笔误实际应闭合捕获组仅在你完全清楚后果时校验$uri对必须使用$uri的场景可考虑增加额外的校验逻辑如拒绝含控制字符的请求但务必理解这属于业务层防御Nginx 本身不会替你做编码误用可能引入新的绕过。修复后可用 gixy 复检确认运行gixy nginx.conf或通过gixy --help查看参数若输出中不再出现http_splitting相关 HIGH 级别告警则说明 CRLF 注入面已消除。插件的完整检测指令集合与判定优先级可直接查阅 gixy/plugins/http_splitting.py更丰富的正反配置样例见 tests/plugins/simply/http_splitting/ 目录。小结HTTP Splitting 是 Nginx 配置中容易被忽视的高危问题add_header/proxy_set_header/rewrite/return/proxy_pass拼接未经过滤的变量配合$uri的 URL 解码行为与排除型正则捕获组即可让攻击者在请求或响应中注入任意 CRLF 内容。gixy 通过 gixy/core/variable.py 中的字符集推导能力静态还原出每个变量的可包含字符从而在部署前发现隐患。日常编码中坚持用$request_uri代替$uri、正则排除区间加上\s、审慎校验$uri三条原则即可从配置层面彻底消除该类漏洞。赞分享静态分析应用安全【免费下载链接】gixyNginx configuration static analyzer项目地址https://gitcode.com/gh_mirrors/gi/gixy点击查看免费下载相关推荐Gixy项目解析Nginx配置中alias指令的路径遍历风险与防护Gixy项目解析Nginx配置中alias指令的路径遍历风险与防护 前言 在Nginx服务器的配置过程中alias指令是一个常用但容易被错误配置的指令。本文静态分析应用安全10分钟越狱老设备palera1n完整操作指南10分钟越狱老设备palera1n完整操作指南 你的 iPhone 7 停在 iOS 15 再也动不了却还想要 Sileo 和 tweak——palera1CLI固件10分钟跑通大麦抢票脚本从克隆到空跑只需6条命令10分钟跑通大麦抢票脚本从克隆到空跑只需6条命令 开票瞬间已抢完三个字比你的手指先到一步。开源项目 ticket purchase 把选城市、挑场次、选GUI 自动化RPA上一篇RomM 前端架构深度解析Vue 3 单页应用如何驱动自托管 ROM 管理与游玩平台下一篇终极指南如何用Bezier.js打造流畅动画与图形效果创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考