【基础漏洞】CRLF注入

• CRLF 是什么

• 漏洞说明

• 漏洞复现

• 环境搭建

• 复现过程

• 漏洞危害

• Payload

• 修复建议

CRLF 是什么

CRLF 是回车换行（Carriage Return Line Feed）的缩写，它是一种控制字符序列，用于表示文本文件或数据流中的换行符。

简单来说，就是编程语言中常见的rn

• CR代表r，URL 编码后是%0d
• LF代表n，URL 编码后是%0a

在 HTTP 协议使用 CRLF 序列来分隔 HTTP 头部中的各个字段，表示一个完整的行，每个 HTTP 头部字段通常以 CRLF 结尾，HTTP 头和 Body 通常以 2 个 CRLF 结尾，以便在协议中进行正确的解析和处理，如下图：

漏洞说明

CRLF 注入（也称为 HTTP 换行注入）是一种 Web 应用程序中的安全漏洞，它允许攻击者在 HTTP 响应中插入任意的换行符和回车符（CRLF），从而可能导致恶意行为。

简单来说，当我们传输rn到服务器时，服务器可能被欺骗，把rn当成换行回车处理，从而给rn后面的内容当成新的 header 头或者 body 内容返回。

漏洞常见点： 输入的内容会被当作响应 HTTP 头中的值，如跳转。

[!TIP]

该漏洞现在很少见了，我也只在很早挖 ASRC 的时候遇到过一次。

漏洞复现

环境搭建

本来说直接用 vulhub 的，但是看了一下有问题，所以微调了一下。

docker pull vulhub/nginx:1
docker run -it -d --name vulnginx --rm -p 80:80 vulhub/nginx:1
docker exec -it vulnginx /bin/bash
sed -i '/location / {/a         return 302 https://$host$uri;' /etc/nginx/conf.d/default.conf
exit
docker restart vulnginx

目的是把所有 http 定位到 https 中，测试是否生效

复现过程

1: 添加 header 头

http://internal.gm7.org/111111%0d%0aSet-Cookie:%20user=admin

2: 控制 HTML 内容

http://internal.gm7.org/111111%0d%0a%0d%0a<h1>123</h1>

[!NOTE]

注：此处不会造成 XSS，因为 302 的优先级高于 body 解析渲染。

漏洞危害

• 任意 URL 跳转
• 反射 XSS
• Session 固定

总的来说，就是可控响应 HTTP 头以及响应的 Body 内容。

Payload

我常用的 payload，共 91 条，点击下载^[1]

修复建议

• 字符过滤： 在设置 HTTP 响应头之前，对输入的数据进行字符过滤，删除或转义回车、换行和其他特殊字符，例如 %0d、%0a、%0D、%0A。确保只允许标准的换行符 n，并拒绝其他非法字符。
• 参数合法性校验： 对输入的参数进行合法性校验，确保参数符合预期的格式和规范。使用正则表达式或其他验证方法来检查参数是否包含非法字符或模式，并拒绝不符合要求的参数。
• 参数长度限制： 对输入的参数设置长度限制，防止过长的参数导致缓冲区溢出或其他安全问题。根据应用程序的需求，定义适当的参数长度上限，并验证输入参数是否超出限制。

参考资料

- END -