七、CRLF 注入
作者：Peter Yaworski
譯者：飛龍
協(xié)議：CC BY-NC-SA 4.0
CRLF 注入是一類漏洞，在用戶設(shè)法向應(yīng)用插入 CRLF 時(shí)出現(xiàn)。在多種互聯(lián)網(wǎng)協(xié)議中，包括 HTML，CRLF 字符表示了行的末尾，通常表示為\r\n，編碼后是%0D%0A。在和 HTTP 請(qǐng)求或響應(yīng)頭組合時(shí)，這可以用于表示一行的結(jié)束，并且可能導(dǎo)致不同的漏洞，包括 HTTP 請(qǐng)求走私和 HTTP 響應(yīng)分割。
對(duì) HTTP 請(qǐng)求走私而言，它通常在 HTTP 請(qǐng)求傳給服務(wù)器，服務(wù)器處理它并傳給另一個(gè)服務(wù)器時(shí)發(fā)生，例如代理或者防火墻。這一類型的漏洞可以導(dǎo)致：
- 緩存污染，它是一種場(chǎng)景，攻擊者可以修改緩沖中的條目，并托管惡意頁(yè)面（即包含 JavaScript）而不是合理的頁(yè)面。
- 防火墻繞過(guò)，它是一種場(chǎng)景，請(qǐng)求被構(gòu)造，用于避免安全檢查，通常涉及 CRLF 和過(guò)大的請(qǐng)求正文。
- 請(qǐng)求劫持：它是一種場(chǎng)景，攻擊者惡意盜取 HTTPOnly 的 Cookie，以及 HTTP 驗(yàn)證信息。這類似于 XSS，但是不需要攻擊者和客戶端之間的交互。
現(xiàn)在，雖然這些漏洞是存在的，它們難以實(shí)現(xiàn)。我在這里引用了它們，所以你對(duì)如何實(shí)現(xiàn)請(qǐng)求走私有了更好的了解。
而對(duì)于 HTTP 響應(yīng)分割來(lái)說(shuō)，攻擊者可以設(shè)置任意的響應(yīng)頭，控制響應(yīng)正文，或者完全分割響應(yīng)來(lái)提供兩個(gè)響應(yīng)而不是一個(gè)，它在示例 #2 （Shopify 響應(yīng)分割）中演示（如果你需要 HTTP 請(qǐng)求和響應(yīng)頭的備忘錄，請(qǐng)回到“背景”一章）。
1. Twitter HTTP 響應(yīng)分割
難度：高
URL：https://twitter.com/i/safety/report_story
報(bào)告鏈接：https://hackerone.com/reports/52042
報(bào)告日期：2015.4.21
獎(jiǎng)金：$3500
描述：
2015 年 4 月，有報(bào)告稱，Twitter 存在一個(gè)漏洞，允許攻擊者通過(guò)將信息添加到發(fā)往 Twitter 的請(qǐng)求，設(shè)置任意 Cookie。
本質(zhì)上，在生成上面 URL 的請(qǐng)求之后（一個(gè) Twitter 的遺留功能，允許人們報(bào)告廣告），Twitter 會(huì)為參數(shù)reported_tweet_id返回 Cookie。但是，根據(jù)報(bào)告，Twitter 的驗(yàn)證存在缺陷，它用于確認(rèn)推文是否是數(shù)字形式。
雖然 Twitter 驗(yàn)證了換行符0x0a不能被提交時(shí)，驗(yàn)證機(jī)制可以通過(guò)將字符編碼為 UTF-8 來(lái)繞過(guò)。這么做之后，Twitter 會(huì)將字符轉(zhuǎn)換會(huì)原始的 Unicode，從而避免了過(guò)濾。這是所提供的示例：
%E5%98%8A => U+560A => 0A
這非常重要，因?yàn)閾Q行符在服務(wù)器上被解釋為這樣的東西，創(chuàng)建新的一行，服務(wù)器讀取并執(zhí)行它，這里是用于添加新的 Cookie。
現(xiàn)在，當(dāng) CRLF 攻擊允許 XSS 攻擊的時(shí)候（請(qǐng)見(jiàn) XSS 一章），它們還會(huì)更加危險(xiǎn)。這種情況下，由于 Twitter 的過(guò)濾器被繞過(guò)了，包含 XSS 攻擊的新的響應(yīng)可能返回給用戶，這里是 URL：
https://twitter.com/login?redirect_after_login=https://twitter.com:21/%E5%98%8A
%E5%98%8Dcontent-type:text/html%E5%98%8A%E5%98%8Dlocation:%E5%98%8A%E5%98%8D
%E5%98%8A%E5%98%8D%E5%98%BCsvg/onload=alert%28innerHTML%28%29%E5%98%BE
要注意%E5%E98%8A布滿了這個(gè) URL。如果我們使用了這些字符，并且實(shí)際添加了換行符，這個(gè)就是協(xié)議頭的樣子：
https://twitter.com/login?redirect_after_login=https://twitter.com:21/
content-type:text/html
location:%E5%98%BCsvg/onload=alert%28innerHTML%28%29%E5%98%BE
你可以看到，換行符允許了創(chuàng)建新的協(xié)議頭，并和可執(zhí)行的 JavaScript 一起返回：svg/onload=alert(innerHTML)。使用這個(gè)代碼，惡意用戶就能夠盜取任何無(wú)防備的受害者的 Twitter 會(huì)話信息。
重要結(jié)論
好的攻擊是觀察與技巧的組合這里，報(bào)告者
@filedescriptor了解之前的 Firefox 編碼漏洞，它錯(cuò)誤處理了編碼。對(duì)這個(gè)知識(shí)的了解就可以用于測(cè)試 Twitter 上相似的編碼來(lái)插入換行。
當(dāng)你尋找漏洞時(shí)，始終記住要解放思想，并提交編碼后的值來(lái)觀察站點(diǎn)如何處理輸入。
2. Shopify 響應(yīng)分割
難度：中
URL：v.shopify.com/last_shop?x.myshopify.com
報(bào)告鏈接：https://hackerone.com/reports/106427
報(bào)告日期：2015.12.22
獎(jiǎng)金：$500
描述：
Shopify 包含了一些隱藏功能，會(huì)在你的瀏覽器上設(shè)置 Cookie，它指向你所登錄的最后一個(gè)商店。它通過(guò)終端/last_shop?SITENAME.shopify.com來(lái)實(shí)現(xiàn)。
在 2015 年 12 月，有人發(fā)現(xiàn)，Shopify 不驗(yàn)證在調(diào)用中傳入的shop參數(shù)。所以，使用 Burp Suite，白帽子就能夠使用%0d%0a來(lái)修改請(qǐng)求，并生成協(xié)議頭返回給用戶。這里是截圖：
這里是惡意代碼：
%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20te\
xt/html%0d%0aContent-Length:%2019%0d%0a%0d%0a<html>deface</html>
這里，%20表示空格，%0d%0a是 CRLF。所以瀏覽器收到了兩個(gè)協(xié)議頭，并渲染了第二個(gè)，它能夠?qū)е潞芏嗦┒?，包?XSS。
重要結(jié)論
一定要尋找這樣的機(jī)會(huì)，其中站點(diǎn)接受你的輸入，并且將其用于返回協(xié)議頭的一部分。這里，Shopify 使用
last_shop值創(chuàng)建了 Cookie，它實(shí)際上可悲用戶克隆的 URL 參數(shù)污染。這是一個(gè)不錯(cuò)的信號(hào)，它可能存在 CRLF 注入漏洞。
總結(jié)
良好的攻擊是觀察和技巧的結(jié)合。了解如何使用編碼字符串來(lái)發(fā)現(xiàn)漏洞是一個(gè)不錯(cuò)的技巧。%0D%0A可以用于測(cè)試服務(wù)器，以及判斷他們是否存在 CRLF 漏洞。如果存在，進(jìn)一步嘗試使用 XSS 注入來(lái)組合蓋漏洞（請(qǐng)見(jiàn)第七節(jié)）。
另一方面，如果服務(wù)器不響應(yīng)%0D%0A，要考慮如何再次編碼這些字符，并測(cè)試服務(wù)器，以便觀察它是否解碼雙重編碼的字符，就像@filedescriptor所做的那樣。
一定要尋找這樣的機(jī)會(huì)，其中站點(diǎn)使用提交的值來(lái)返回一些類型的協(xié)議頭，例如創(chuàng)建 Cookie。
