背景介绍：

本文来自国外一位来自印度名叫Neh Patel的安全研究员，过去的2-3周，他一直在微软网站上寻找有效漏洞，但只是找到一些P4和P5级的漏洞。在测试了50-70个子域后，他发现了一个不同的子域（该子域只面向高级客户功能），因为该子域的功能大部分是付费的，说不定其它白帽子会很少探索这些功能。

这位白帽小哥首先测试了所有未付费的功能，不出所料，没有任何有用的收获，稍适休息后，白帽小哥考虑从最流行的“主机头注入”和其它一些非功能测试开始。

什么是CRLF？

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

什么是CRLF注入？

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

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

故事开始～

故事从发送了第一个Payload开始：

/%0D%0A%20Set-Cookie:whoami=thecyberneh so main URL :- https://subDomain.microsoft.com/%0D%0A%20Set-Cookie:whoami=thecyberneh

没有获得任何类型的 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=thecyberneh”解析为路径，而不是Payloads。

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

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

https://subDomain.microsoft.com/abcxyzabcxyz

服务器返回了“404 Not Found”，并带有 HTML 响应“We are sorry, the page you requested cannot be found. The URL may be misspelled or the page you’re looking for is no longer available”

所以可以得出结论：

1、如果路径不存在，服务器将返回“404 Not found”

2、当尝试使用Payloads时，服务器返回“400 Bad Request”

那么接下来就是绕过保护，触发有效的Payloads！

白帽小哥尝试了不同的Payloads：

%0D%0A%20Set-Cookie:whoami=thecyberneh

%20%0D%0ASet-Cookie:whoami=thecyberneh

%0A%20Set-Cookie:whoami=thecyberneh

%2F%2E%2E%0D%0ASet-Cookie:whoami=thecyberneh

同样还是获得“400 Bad Request”，所以需要一些不同的东西，因为大多数防火墙会阻止通用和基本的Payloads。

经过一些研究，白帽小哥获得了一些独特的编码–GBK编码。

编码与防火墙绕过：

Payload responsible for CRLF injection is :- 嘍嘊

在获得上面的Payload后，白帽小哥为 CRLF 注入制作了一个新的Payload和 URL：

BeforeURL Encoding
Main Payload:- 嘍嘊

AfterURL Encoding
嘍 :- %E5%98%8D
嘊 :- %E5%98%8A
完整Payload如下：

https://subDomain.microsoft.com/%E5%98%8D%E5%98%8ASet-Cookie:crlfinjection=thecyberneh

再次尝试，Boom！

成功收到响应，标头：Set-Cookie: crlfinjection=thecyberneh

因为可以用 CRLF 注入做很多事情，所以白帽小哥并没有着急报告漏洞，并尝试与其它漏洞进行组合。

从CRLF到XSS：

从上图可以看到请求和响应标头末尾有一个空行（请求中的第 13 行和响应中的第 20 行）

所以当时服务器在默认情况下，应该正在发送下面这样的响应：

所以如果想要实现 XSS，必须在响应的正文部分插入 Javascript Payloads，因为 Javascript 可以在正文中呈现，那么构造的响应结构应该是下面这样：

HEADERS 意味着必须制作有效的Payloads，强制服务器在Payloads结束后发送一个空行，以便Payloads之后的标头将解析为垃圾或忽略它们。

PAYLOAD_XSS 为我们制作的 XSS 有效Payloads

白帽小哥插入了一个像“喽嘊”这样的CRLF Payload（URL编码为 %E5%98%8D%E5%98%8A ），但没有获得预期的单个空行，因此白帽小哥插入了Payloads两次，成功收到了服务器响应的一个空行。

预期获得的回复结构：

实际响应：

了解绕过防火墙的有效Payloads：

为了绕过防火墙，需要将Payloads进行一些编码：

"<" 变 嘼
">" 变 嘾

为了编码后的URL能够有效执行，最终的Payloads是这样的：

ENCODING

“<” –> 嘼 –> %E5%98%BC
“>” –> 嘾 –> %E5%98%BE
https://subDomain.microsoft.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

输入Payloads后，成功获得了弹窗：

白帽小哥提交了该漏洞，随后他使用 shell 脚本创建了一个自动化工具，该工具会检查子域列表上的 CRLF，运行该工具后，白帽小哥从微软网站获得了另一个子域的另一处CRLF。

就这样，白帽小哥获得了总共 6000 美元的赏金奖励和微软名人堂致谢。
更多微软案例
希望本篇文章能够对你有所收获～