：過濾器+包裝器+CSP+輸出編碼)
我處理項目里那個搜索框變成按鈕的Bug才真正理解XSS不是文檔里的一句名詞而是能在幾分鐘內把Cookie、頁面內容、用戶操作全部劫走的入口。當時用Spring Boot做的后臺管理系統(tǒng)前端同學隨手往標題欄輸入了一段帶尖括號的內容頁面上直接把標簽渲染成了DOM那一刻所有人都意識到我們的接口對代碼注入基本是裸奔。這篇文章就記錄我當時從零搭建的過濾器請求包裝器輸出編碼CSP響應頭四層XSS防御方案全流程可復現(xiàn)相關代碼都直接貼在章節(jié)里適合正在用Spring Boot開發(fā)接口、后臺系統(tǒng)或者前后端分離項目的開發(fā)者參考。我記得很清楚最開始想得很簡單在Controller里對每個參數(shù)做replace把所有尖括號去掉不就行了結果寫完發(fā)現(xiàn)自己掉進了一個巨大的坑接口一多參數(shù)一雜漏掉一個字段就前功盡棄而且replace方案對大小寫混寫、HTML實體編碼、屬性內聯(lián)事件根本防不住。后面逐步演化成一套組合方案核心思路就一句話不能把安全邏輯散落在業(yè)務代碼里要用統(tǒng)一的入口做清洗再在出口做編碼最后用瀏覽器安全策略兜底。1. 理解XSS攻擊的實際場景防御方案的設計起點1.1 三類XSS攻擊與真實業(yè)務映射在做方案之前我先花了一晚上把項目里可能出現(xiàn)XSS的位置全過了一遍這時候才發(fā)現(xiàn)哪里會被打比怎么防御更重要。存儲型XSS最容易出現(xiàn)在后臺系統(tǒng)的評論、公告、商品描述這類入口攻擊者把腳本寫進數(shù)據(jù)庫頁面渲染時自動執(zhí)行反射型XSS則集中在搜索框、URL參數(shù)、跳轉參數(shù)這類需要回顯的地方攻擊者構造一個惡意鏈接引誘用戶點擊參數(shù)里的腳本跟著請求進入后端再原樣返回頁面DOM型XSS稍微隱蔽一點攻擊邏輯完全在前端JavaScript里運轉比如從location.hash里取參數(shù)拼進DOM后端甚至看不到完整攻擊載荷。從實際問題來看如果業(yè)務還在用服務端渲染模板Thymeleaf、JSP反射型和存儲型是重災區(qū)如果業(yè)務已經是前后端分離后端只提供JSON接口那么攻擊者主要盯的是JSON請求體里的字段這些數(shù)據(jù)被前端取走后如果直接插入頁面同樣形成存儲型XSS。Spring Boot本身沒有內置一個一鍵防XSS開關加上很多團隊默認我們只返回JSON不會渲染HTML這個認知錯位就是漏洞的溫床。防御方案要從這個真實風險出發(fā)而不是從我覺得別人應該不會這么傳出發(fā)。1.2 兩個常被忽略的隱蔽攻擊入口第一個隱蔽入口是HTTP請求頭。服務端記錄日志、客服系統(tǒng)展示用戶設備信息、管理后臺展示訪客IP歸屬都可能把User-Agent、Referer、X-Forwarded-For原樣展示在頁面上。攻擊者只要把腳本放在UA里管理員一看日志就中招這種場景在小團隊里非常常見因為大家默認請求頭是瀏覽器生成的不會有惡意內容。第二個隱蔽入口是文件上傳后的內容展示。很多系統(tǒng)上傳Excel導入數(shù)據(jù)之后把每一行的內容回顯到頁面上這些內容是團隊自己上傳的潛意識里覺得安全但Excel單元格里完全能寫入img srcx onerroralert(1)導入后再一展示就觸發(fā)。我在方案里把這些隱蔽入口也納入清洗范圍標準很簡單只要數(shù)據(jù)要從后端流向用戶瀏覽器就必須經過統(tǒng)一的輸出編碼或輸入清洗沒有任何字段可以豁免。2. 用過濾器與請求包裝器構建統(tǒng)一入口防線2.1 為什么選Filter而不是攔截器第一版方案我沒考慮攔截器因為Spring的HandlerInterceptor依賴Spring MVC的HandlerMapping這意味著靜態(tài)資源、非Controller路徑、部分異常處理路徑根本不會進入攔截器。而Servlet的Filter位于整個請求處理鏈的最前端Container加載它的時候請求還沒有被映射到任何Controller這個位置決定了它可以用統(tǒng)一的方式處理所有進來的請求無論是動態(tài)接口、靜態(tài)資源還是表單提交。我用的實現(xiàn)方式是自定義一個XssFilter在web應用啟動時注入到過濾器鏈的最前面通過Order(Ordered.HIGHEST_PRECEDENCE)保證它先于其他過濾器執(zhí)行。Filter的核心作用不是自己完成所有清洗而是把原始請求包裝成一個安全請求對象后續(xù)的Controller、Service拿到的都是經過處理后的數(shù)據(jù)。這樣業(yè)務代碼完全不用關心XSS防御新增接口也不會因為忘記過濾而留漏洞這是方案能長期維持的根本原因。2.2 請求包裝器的完整實現(xiàn)過濾器本身很薄真正干活的是HttpServletRequestWrapper。包裝器覆蓋了getParameter、getParameterValues、getParameterMap這幾個最常見的參數(shù)讀取入口做到無論代碼里用哪種方式取參數(shù)得到的都是清洗后的值。先看基礎版本public class XssHttpServletRequestWrapper extends HttpServletRequestWrapper { public XssHttpServletRequestWrapper(HttpServletRequest request) { super(request); } Override public String getParameter(String name) { return XssCleanUtil.clean(super.getParameter(name)); } Override public String[] getParameterValues(String name) { String[] values super.getParameterValues(name); if (values null) { return null; } String[] cleanValues new String[values.length]; for (int i 0; i values.length; i) { cleanValues[i] XssCleanUtil.clean(values[i]); } return cleanValues; } Override public MapString, String[] getParameterMap() { MapString, String[] parameterMap super.getParameterMap(); MapString, String[] cleanMap new HashMap(parameterMap.size()); for (Map.EntryString, String[] entry : parameterMap.entrySet()) { String[] values entry.getValue(); String[] cleanValues new String[values.length]; for (int i 0; i values.length; i) { cleanValues[i] XssCleanUtil.clean(values[i]); } cleanMap.put(entry.getKey(), cleanValues); } return cleanMap; } }這里有一個在IndexPage描述不太清楚但實際非常關鍵的細節(jié)getParameterMap返回的Map通常是不可修改的內部視圖直接修改會報異常所以必須復制一份新Map。我在第一版踩過這個坑后來才改成復制的方式。2.3 JSON請求體清洗的第三種方案上面包裝器解決的是查詢參數(shù)和表單字段但現(xiàn)代接口大量使用Content-Type: application/jsonRequestBody通過getInputStream()讀取這個時候Filter處理起來就麻煩很多。這個問題的根源在于請求流只能讀一次而Controller的RequestBody也需要讀流兩邊會沖突。在我的實際項目里我采用的方案是對getInputStream()做緩存包裝包裝器第一次初始化時把請求體完整讀出來清洗一遍后存到內存里之后Controller再讀的時候讀的是清洗后的緩存流。這樣處理完整保留了原有的JSON結構又保證了防腐邏輯的統(tǒng)一。示例代碼如下public class XssBodyRequestWrapper extends HttpServletRequestWrapper { private final String cleanBody; public XssBodyRequestWrapper(HttpServletRequest request) throws IOException { super(request); String rawBody request.getReader().lines() .collect(Collectors.joining(System.lineSeparator())); this.cleanBody XssCleanUtil.cleanBody(rawBody); } Override public BufferedReader getReader() throws IOException { return new BufferedReader(new StringReader(cleanBody)); } Override public ServletInputStream getInputStream() throws IOException { byte[] bytes cleanBody.getBytes(StandardCharsets.UTF_8); ByteArrayInputStream byteArrayInputStream new ByteArrayInputStream(bytes); return new ServletInputStream() { Override public boolean isFinished() { return byteArrayInputStream.available() 0; } Override public boolean isReady() { return true; } Override public void setReadListener(ReadListener readListener) { // 保持Servlet InputStream接口完整性 } Override public int read() { return byteArrayInputStream.read(); } }; } }這里還有個容易忽略的要點當請求體經過清洗后如果包裹的接口調用方用了流式讀取那么必須確保返回的ServletInputStream不是null而且在getInputStream()被調用過之后能正常工作否則會出現(xiàn)IllegalStateException。我最后上線前把所有接口都回歸了一遍確保getInputStream情況正常。2.4 清洗引擎的設計與依賴選型清洗引擎是這套方案最重要的部分。我曾經嘗試自己寫正則表達式來替換script、javascript:、onerror等關鍵詞實踐證明這是一條死胡同攻擊者只需使用scrscriptipt、大小寫混寫、HTML實體編碼、反斜杠變體就能繞過正則。最終我引入了Jsoup的clean方法它通過白名單機制只保留顯式允許的標簽和屬性其它全部剔除這里重點說下常用配置。dependency groupIdorg.jsoup/groupId artifactIdjsoup/artifactId version1.16.2/version /dependencypublic class XssCleanUtil { private static final Whitelist WHITELIST Whitelist.relaxed() .addProtocols(a, href, http, https) .addProtocols(img, src, http, https); public static String clean(String value) { if (value null || value.isEmpty()) { return value; } return Jsoup.clean(value, WHITELIST); } public static String cleanBody(String body) { if (body null || body.isEmpty()) { return body; } // JSON字符串里嵌套的HTML標簽、屬性都會被清洗同時保留JSON結構 return Jsoup.clean(body, WHITELIST); } }使用Jsoup需要注意的一個實際問題Whitelist.relaxed()會保留很多標簽和屬性如果業(yè)務場景是純文本內容我更建議直接使用Whitelist.none()這意味著所有HTML標簽都會被剝除只留下純文本如果業(yè)務里確實需要富文本編輯器的內容就需要配合addAttributes、addProtocols做細粒度配置比如只允許img的src使用http和https協(xié)議禁止javascript:偽協(xié)議。項目里的富文本場景我單獨走了一條豁免路徑后面在常見問題里細講。3. 出口防線與瀏覽器安全策略CSP與輸出編碼3.1 Content-Security-Policy響應頭的配置入口清洗不是萬能的攻擊者還可能通過其它渠道把危險內容投放到頁面所以必須在瀏覽器端劃定安全邊界。CSP內容安全策略是一種由服務器下發(fā)的策略指令它明確告訴瀏覽器哪些來源的腳本可以執(zhí)行、哪些來源的資源可以加載。一旦策略生效即使頁面里被注入了script標簽瀏覽器也會拒絕執(zhí)行。在Spring Boot里添加CSP響應頭最常見的方式是擴展WebSecurityConfigurerAdapter或使用較新的SecurityFilterChain配置在響應頭中加入Content-Security-Policy。一個敞開的初始化版本配置如下Configuration EnableWebSecurity public class SecurityConfig { Bean public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception { http.headers(headers - headers .contentSecurityPolicy(csp - csp .policyDirectives(default-src self; script-src self; img-src self data:; style-src self unsafe-inline; frame-ancestors none) ) ); return http.build(); } }注意script-src self禁止了頁面里內聯(lián)的script代碼這是最嚴格的狀態(tài)。實際項目里如果前端寫了內聯(lián)腳本或者用了老舊的第三方組件會把所有腳本執(zhí)行卡死這時候可以把這個策略改成script-src self unsafe-inline但這就留下了內聯(lián)注入的口子。更好的做法是配合隨機Nonce值每次響應生成一個隨機的Nonce只有帶這個Nonce的內聯(lián)腳本才被允許執(zhí)行。Spring Security支持直接用Nonce配置我在后續(xù)項目中也切換到了這個更高等級的模式。3.2 Thymeleaf的輸出編碼與th:text對比輸出編碼是最后一個重要環(huán)節(jié)。在Spring Boot里使用Thymeleaf做頁面渲染時th:text的默認行為就是HTML轉義比如把script轉成lt;scriptgt;瀏覽器拿到只會當普通文本展示。但總有開發(fā)為了方便直接使用th:utext或[[ ${content} ]]這兩個方式輸出的是未經轉義的HTML一旦字段內容來自用戶輸入就相當于親手為XSS鋪路。我這里給團隊定了一條鐵律凡是展示用戶可編輯內容的地方一律使用th:text禁止使用th:utext。如果確實需要讓富文本編輯器內容正常渲染就必須配合入口清洗白名單保證經過Jsoup清洗后只保留安全標簽再使用th:utext渲染因為這個內容已經是消毒后的產物。還有一個容易被忽視的隱藏問題是前后端分離架構下前端框架的插值語法默認會轉義但v-html和dangerouslySetInnerHTML這類接口是明晃晃的例外需要前端同學在項目規(guī)范里明確禁止或同樣配套清洗。3.3 Cookie安全屬性不可忽略XSS攻擊的核心目的之一是竊取登錄態(tài)Cookie而HttpOnly屬性能從源頭阻斷腳本讀取Cookie。Java后端設置Cookie時加上HttpOnly瀏覽器端JavaScript就無法通過document.cookie獲得這個值這等于在XSS陷阱上面加了個保險鎖。Spring Boot里設置HttpOnly Cookie的方式很簡單在Spring Security配置里使用http.csrf()的同時給Session Cookie加上HttpOnly、Secure屬性即可。如果使用自定義的Cookie寫入邏輯需要主動設置cookie.setHttpOnly(true)、cookie.setSecure(true)以及合理的SameSite屬性。我在項目里驗證過一個場景攻擊者已經通過某個輸入點注入了腳本但嘗試讀取會話Cookie時得到的只是一個空殼這個不起眼的屬性確實讓事故等級直接降了一檔。4. 從測試到落地驗證防御方案是否真的生效4.1 用MockMvc編寫自動化測試安全方案做完了不能靠直覺判斷應該沒問題必須用測試把每個防御點釘死。我推薦用Spring Boot自帶的MockMvc它對Filter鏈的模擬非常真實可以同時驗證輸入清洗和對響應頭的斷言。SpringBootTest AutoConfigureMockMvc class XssDefenseTests { Autowired private MockMvc mockMvc; Test void shouldCleanScriptTagInQueryParameters() throws Exception { mockMvc.perform(get(/search) .param(keyword, scriptalert(1)/script)) .andExpect(status().isOk()) .andExpect(content().string(not(containsString(script)))); } Test void shouldCleanBodyInJsonRequest() throws Exception { String json {\content\:\img srcx onerroralert(1)\}; mockMvc.perform(post(/api/comment) .contentType(MediaType.APPLICATION_JSON) .content(json)) .andExpect(status().isOk()) .andExpect(jsonPath($.content).value(not(containsString(onerror)))); } Test void shouldAddContentSecurityPolicyHeader() throws Exception { mockMvc.perform(get(/index)) .andExpect(header().string(Content-Security-Policy, containsString(script-src))); } }第一版測試跑通后我又加了一批繞過嘗試用例覆蓋大小寫混寫、HTML實體編碼、屬性事件、外鏈腳本這些常見攻擊方式。這些用例的價值不僅僅是驗證功能更是給后續(xù)維護的人傳遞一個信息這些攻擊路徑是被明確防御過的改動這部分代碼要小心。4.2 用瀏覽器開發(fā)工具做手動驗證自動化測試之外強烈建議開發(fā)者用瀏覽器開發(fā)工具手動做一輪全鏈路驗證。打開頁面的開發(fā)者工具在Console里查看是否有CSP報錯在Network面板查看響應頭里是否真的帶上了Content-Security-Policy再切換到Sources面板確認頁面源碼里script標簽是否被轉義。CSP如果配置生效即使頁面上出現(xiàn)了內聯(lián)腳本Console中也會輸出CSP拒絕執(zhí)行的明確警告這種反饋比代碼里任何日志都直觀。我常用的一組手動測試載荷在搜索框輸入scriptalert(document.domain)/script如果頁面彈窗或者出現(xiàn)CSP報錯說明防御存在缺口輸入img/srcx/onerroralert(1)測試屬性事件輸入a hrefjavascript:alert(1)test/a測試偽協(xié)議。這組載荷基本能把三種主流繞過路徑都覆蓋到。4.3 清理存量臟數(shù)據(jù)防御方案上線后數(shù)據(jù)庫里已經存在的臟數(shù)據(jù)不會自動變干凈。我習慣的做法是針對用戶可編輯的核心字段昵稱、個人簡介、評論內容寫一個一次性清理腳本把歷史數(shù)據(jù)用Jsoup的白名單機制重新清洗一遍然后再把清洗后的數(shù)據(jù)更新回庫。這個步驟很笨但非常有必要否則新方案只保護新寫入的數(shù)據(jù)存量數(shù)據(jù)一旦被翻出來展示漏洞依然存在。另外線上接口的日志也要檢查一遍確保日志系統(tǒng)沒有把包含原始攻擊載荷的請求體原樣輸出到文件。有些監(jiān)控系統(tǒng)甚至會把帶腳本的內容通過郵件報警發(fā)出來技術同事收到電子郵件打開時又中一次招。安全防御必須形成閉環(huán)從請求、存儲、輸出、日志、監(jiān)控每一個環(huán)節(jié)都要覆蓋。5. 實戰(zhàn)中的常見坑與排查經驗5.1 過濾器導致JSON請求全部失效這是這套方案上線那天最慘痛的教訓。某跨平臺系統(tǒng)采用整體過濾方案時只加了查詢參數(shù)的包裝器沒有處理請求體緩存流結果所有POST接口的RequestBody都拿到空對象前端全線報錯。排查了半個多小時才發(fā)現(xiàn)問題包裝器默認的getInputStream()直接透傳原始流Filter和Controller之間有個先后讀流順序誰先讀了后面的就是空的。這個問題的標準解法就是我在2.3節(jié)寫的XssBodyRequestWrapper把請求體緩存一次后續(xù)的讀取全部指向緩存。需要額外注意的一點是這個緩存方案會占用內存對于超大文件上傳類的接口建議直接從過濾器中排除或者設定只處理Content-Type為application/json的請求避免無謂的性能損耗。5.2 富文本與XSS防御的沖突后臺系統(tǒng)幾乎都有富文本編輯器的需求這也是最容易和過濾器爆發(fā)沖突的地方。團隊的編輯器生成的HTML里有style、class、id甚至> Spring Boot四層XSS防御實戰(zhàn)：過濾器+包裝器+CSP+輸出編碼
我處理項目里那個搜索框變成按鈕的Bug才真正理解XSS不是文檔里的一句名詞而是能在幾分鐘內把Cookie、頁面內容、用戶操作全部劫走的入口。當時用Spring Boot做的后臺管理系統(tǒng)前端同學隨手往標題欄輸入了一段帶尖括號的內容頁面上直接把標簽渲染成了DOM那一刻所有人都意識到我們的接口對代碼注入基本是裸奔。這篇文章就記錄我當時從零搭建的過濾器請求包裝器輸出編碼CSP響應頭四層XSS防御方案全流程可復現(xiàn)相關代碼都直接貼在章節(jié)里適合正在用Spring Boot開發(fā)接口、后臺系統(tǒng)或者前后端分離項目的開發(fā)者參考。我記得很清楚最開始想得很簡單在Controller里對每個參數(shù)做replace把所有尖括號去掉不就行了結果寫完發(fā)現(xiàn)自己掉進了一個巨大的坑接口一多參數(shù)一雜漏掉一個字段就前功盡棄而且replace方案對大小寫混寫、HTML實體編碼、屬性內聯(lián)事件根本防不住。后面逐步演化成一套組合方案核心思路就一句話不能把安全邏輯散落在業(yè)務代碼里要用統(tǒng)一的入口做清洗再在出口做編碼最后用瀏覽器安全策略兜底。1. 理解XSS攻擊的實際場景防御方案的設計起點1.1 三類XSS攻擊與真實業(yè)務映射在做方案之前我先花了一晚上把項目里可能出現(xiàn)XSS的位置全過了一遍這時候才發(fā)現(xiàn)哪里會被打比怎么防御更重要。存儲型XSS最容易出現(xiàn)在后臺系統(tǒng)的評論、公告、商品描述這類入口攻擊者把腳本寫進數(shù)據(jù)庫頁面渲染時自動執(zhí)行反射型XSS則集中在搜索框、URL參數(shù)、跳轉參數(shù)這類需要回顯的地方攻擊者構造一個惡意鏈接引誘用戶點擊參數(shù)里的腳本跟著請求進入后端再原樣返回頁面DOM型XSS稍微隱蔽一點攻擊邏輯完全在前端JavaScript里運轉比如從location.hash里取參數(shù)拼進DOM后端甚至看不到完整攻擊載荷。從實際問題來看如果業(yè)務還在用服務端渲染模板Thymeleaf、JSP反射型和存儲型是重災區(qū)如果業(yè)務已經是前后端分離后端只提供JSON接口那么攻擊者主要盯的是JSON請求體里的字段這些數(shù)據(jù)被前端取走后如果直接插入頁面同樣形成存儲型XSS。Spring Boot本身沒有內置一個一鍵防XSS開關加上很多團隊默認我們只返回JSON不會渲染HTML這個認知錯位就是漏洞的溫床。防御方案要從這個真實風險出發(fā)而不是從我覺得別人應該不會這么傳出發(fā)。1.2 兩個常被忽略的隱蔽攻擊入口第一個隱蔽入口是HTTP請求頭。服務端記錄日志、客服系統(tǒng)展示用戶設備信息、管理后臺展示訪客IP歸屬都可能把User-Agent、Referer、X-Forwarded-For原樣展示在頁面上。攻擊者只要把腳本放在UA里管理員一看日志就中招這種場景在小團隊里非常常見因為大家默認請求頭是瀏覽器生成的不會有惡意內容。第二個隱蔽入口是文件上傳后的內容展示。很多系統(tǒng)上傳Excel導入數(shù)據(jù)之后把每一行的內容回顯到頁面上這些內容是團隊自己上傳的潛意識里覺得安全但Excel單元格里完全能寫入img srcx onerroralert(1)導入后再一展示就觸發(fā)。我在方案里把這些隱蔽入口也納入清洗范圍標準很簡單只要數(shù)據(jù)要從后端流向用戶瀏覽器就必須經過統(tǒng)一的輸出編碼或輸入清洗沒有任何字段可以豁免。2. 用過濾器與請求包裝器構建統(tǒng)一入口防線2.1 為什么選Filter而不是攔截器第一版方案我沒考慮攔截器因為Spring的HandlerInterceptor依賴Spring MVC的HandlerMapping這意味著靜態(tài)資源、非Controller路徑、部分異常處理路徑根本不會進入攔截器。而Servlet的Filter位于整個請求處理鏈的最前端Container加載它的時候請求還沒有被映射到任何Controller這個位置決定了它可以用統(tǒng)一的方式處理所有進來的請求無論是動態(tài)接口、靜態(tài)資源還是表單提交。我用的實現(xiàn)方式是自定義一個XssFilter在web應用啟動時注入到過濾器鏈的最前面通過Order(Ordered.HIGHEST_PRECEDENCE)保證它先于其他過濾器執(zhí)行。Filter的核心作用不是自己完成所有清洗而是把原始請求包裝成一個安全請求對象后續(xù)的Controller、Service拿到的都是經過處理后的數(shù)據(jù)。這樣業(yè)務代碼完全不用關心XSS防御新增接口也不會因為忘記過濾而留漏洞這是方案能長期維持的根本原因。2.2 請求包裝器的完整實現(xiàn)過濾器本身很薄真正干活的是HttpServletRequestWrapper。包裝器覆蓋了getParameter、getParameterValues、getParameterMap這幾個最常見的參數(shù)讀取入口做到無論代碼里用哪種方式取參數(shù)得到的都是清洗后的值。先看基礎版本public class XssHttpServletRequestWrapper extends HttpServletRequestWrapper { public XssHttpServletRequestWrapper(HttpServletRequest request) { super(request); } Override public String getParameter(String name) { return XssCleanUtil.clean(super.getParameter(name)); } Override public String[] getParameterValues(String name) { String[] values super.getParameterValues(name); if (values null) { return null; } String[] cleanValues new String[values.length]; for (int i 0; i values.length; i) { cleanValues[i] XssCleanUtil.clean(values[i]); } return cleanValues; } Override public MapString, String[] getParameterMap() { MapString, String[] parameterMap super.getParameterMap(); MapString, String[] cleanMap new HashMap(parameterMap.size()); for (Map.EntryString, String[] entry : parameterMap.entrySet()) { String[] values entry.getValue(); String[] cleanValues new String[values.length]; for (int i 0; i values.length; i) { cleanValues[i] XssCleanUtil.clean(values[i]); } cleanMap.put(entry.getKey(), cleanValues); } return cleanMap; } }這里有一個在IndexPage描述不太清楚但實際非常關鍵的細節(jié)getParameterMap返回的Map通常是不可修改的內部視圖直接修改會報異常所以必須復制一份新Map。我在第一版踩過這個坑后來才改成復制的方式。2.3 JSON請求體清洗的第三種方案上面包裝器解決的是查詢參數(shù)和表單字段但現(xiàn)代接口大量使用Content-Type: application/jsonRequestBody通過getInputStream()讀取這個時候Filter處理起來就麻煩很多。這個問題的根源在于請求流只能讀一次而Controller的RequestBody也需要讀流兩邊會沖突。在我的實際項目里我采用的方案是對getInputStream()做緩存包裝包裝器第一次初始化時把請求體完整讀出來清洗一遍后存到內存里之后Controller再讀的時候讀的是清洗后的緩存流。這樣處理完整保留了原有的JSON結構又保證了防腐邏輯的統(tǒng)一。示例代碼如下public class XssBodyRequestWrapper extends HttpServletRequestWrapper { private final String cleanBody; public XssBodyRequestWrapper(HttpServletRequest request) throws IOException { super(request); String rawBody request.getReader().lines() .collect(Collectors.joining(System.lineSeparator())); this.cleanBody XssCleanUtil.cleanBody(rawBody); } Override public BufferedReader getReader() throws IOException { return new BufferedReader(new StringReader(cleanBody)); } Override public ServletInputStream getInputStream() throws IOException { byte[] bytes cleanBody.getBytes(StandardCharsets.UTF_8); ByteArrayInputStream byteArrayInputStream new ByteArrayInputStream(bytes); return new ServletInputStream() { Override public boolean isFinished() { return byteArrayInputStream.available() 0; } Override public boolean isReady() { return true; } Override public void setReadListener(ReadListener readListener) { // 保持Servlet InputStream接口完整性 } Override public int read() { return byteArrayInputStream.read(); } }; } }這里還有個容易忽略的要點當請求體經過清洗后如果包裹的接口調用方用了流式讀取那么必須確保返回的ServletInputStream不是null而且在getInputStream()被調用過之后能正常工作否則會出現(xiàn)IllegalStateException。我最后上線前把所有接口都回歸了一遍確保getInputStream情況正常。2.4 清洗引擎的設計與依賴選型清洗引擎是這套方案最重要的部分。我曾經嘗試自己寫正則表達式來替換script、javascript:、onerror等關鍵詞實踐證明這是一條死胡同攻擊者只需使用scrscriptipt、大小寫混寫、HTML實體編碼、反斜杠變體就能繞過正則。最終我引入了Jsoup的clean方法它通過白名單機制只保留顯式允許的標簽和屬性其它全部剔除這里重點說下常用配置。dependency groupIdorg.jsoup/groupId artifactIdjsoup/artifactId version1.16.2/version /dependencypublic class XssCleanUtil { private static final Whitelist WHITELIST Whitelist.relaxed() .addProtocols(a, href, http, https) .addProtocols(img, src, http, https); public static String clean(String value) { if (value null || value.isEmpty()) { return value; } return Jsoup.clean(value, WHITELIST); } public static String cleanBody(String body) { if (body null || body.isEmpty()) { return body; } // JSON字符串里嵌套的HTML標簽、屬性都會被清洗同時保留JSON結構 return Jsoup.clean(body, WHITELIST); } }使用Jsoup需要注意的一個實際問題Whitelist.relaxed()會保留很多標簽和屬性如果業(yè)務場景是純文本內容我更建議直接使用Whitelist.none()這意味著所有HTML標簽都會被剝除只留下純文本如果業(yè)務里確實需要富文本編輯器的內容就需要配合addAttributes、addProtocols做細粒度配置比如只允許img的src使用http和https協(xié)議禁止javascript:偽協(xié)議。項目里的富文本場景我單獨走了一條豁免路徑后面在常見問題里細講。3. 出口防線與瀏覽器安全策略CSP與輸出編碼3.1 Content-Security-Policy響應頭的配置入口清洗不是萬能的攻擊者還可能通過其它渠道把危險內容投放到頁面所以必須在瀏覽器端劃定安全邊界。CSP內容安全策略是一種由服務器下發(fā)的策略指令它明確告訴瀏覽器哪些來源的腳本可以執(zhí)行、哪些來源的資源可以加載。一旦策略生效即使頁面里被注入了script標簽瀏覽器也會拒絕執(zhí)行。在Spring Boot里添加CSP響應頭最常見的方式是擴展WebSecurityConfigurerAdapter或使用較新的SecurityFilterChain配置在響應頭中加入Content-Security-Policy。一個敞開的初始化版本配置如下Configuration EnableWebSecurity public class SecurityConfig { Bean public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception { http.headers(headers - headers .contentSecurityPolicy(csp - csp .policyDirectives(default-src self; script-src self; img-src self data:; style-src self unsafe-inline; frame-ancestors none) ) ); return http.build(); } }注意script-src self禁止了頁面里內聯(lián)的script代碼這是最嚴格的狀態(tài)。實際項目里如果前端寫了內聯(lián)腳本或者用了老舊的第三方組件會把所有腳本執(zhí)行卡死這時候可以把這個策略改成script-src self unsafe-inline但這就留下了內聯(lián)注入的口子。更好的做法是配合隨機Nonce值每次響應生成一個隨機的Nonce只有帶這個Nonce的內聯(lián)腳本才被允許執(zhí)行。Spring Security支持直接用Nonce配置我在后續(xù)項目中也切換到了這個更高等級的模式。3.2 Thymeleaf的輸出編碼與th:text對比輸出編碼是最后一個重要環(huán)節(jié)。在Spring Boot里使用Thymeleaf做頁面渲染時th:text的默認行為就是HTML轉義比如把script轉成lt;scriptgt;瀏覽器拿到只會當普通文本展示。但總有開發(fā)為了方便直接使用th:utext或[[ ${content} ]]這兩個方式輸出的是未經轉義的HTML一旦字段內容來自用戶輸入就相當于親手為XSS鋪路。我這里給團隊定了一條鐵律凡是展示用戶可編輯內容的地方一律使用th:text禁止使用th:utext。如果確實需要讓富文本編輯器內容正常渲染就必須配合入口清洗白名單保證經過Jsoup清洗后只保留安全標簽再使用th:utext渲染因為這個內容已經是消毒后的產物。還有一個容易被忽視的隱藏問題是前后端分離架構下前端框架的插值語法默認會轉義但v-html和dangerouslySetInnerHTML這類接口是明晃晃的例外需要前端同學在項目規(guī)范里明確禁止或同樣配套清洗。3.3 Cookie安全屬性不可忽略XSS攻擊的核心目的之一是竊取登錄態(tài)Cookie而HttpOnly屬性能從源頭阻斷腳本讀取Cookie。Java后端設置Cookie時加上HttpOnly瀏覽器端JavaScript就無法通過document.cookie獲得這個值這等于在XSS陷阱上面加了個保險鎖。Spring Boot里設置HttpOnly Cookie的方式很簡單在Spring Security配置里使用http.csrf()的同時給Session Cookie加上HttpOnly、Secure屬性即可。如果使用自定義的Cookie寫入邏輯需要主動設置cookie.setHttpOnly(true)、cookie.setSecure(true)以及合理的SameSite屬性。我在項目里驗證過一個場景攻擊者已經通過某個輸入點注入了腳本但嘗試讀取會話Cookie時得到的只是一個空殼這個不起眼的屬性確實讓事故等級直接降了一檔。4. 從測試到落地驗證防御方案是否真的生效4.1 用MockMvc編寫自動化測試安全方案做完了不能靠直覺判斷應該沒問題必須用測試把每個防御點釘死。我推薦用Spring Boot自帶的MockMvc它對Filter鏈的模擬非常真實可以同時驗證輸入清洗和對響應頭的斷言。SpringBootTest AutoConfigureMockMvc class XssDefenseTests { Autowired private MockMvc mockMvc; Test void shouldCleanScriptTagInQueryParameters() throws Exception { mockMvc.perform(get(/search) .param(keyword, scriptalert(1)/script)) .andExpect(status().isOk()) .andExpect(content().string(not(containsString(script)))); } Test void shouldCleanBodyInJsonRequest() throws Exception { String json {\content\:\img srcx onerroralert(1)\}; mockMvc.perform(post(/api/comment) .contentType(MediaType.APPLICATION_JSON) .content(json)) .andExpect(status().isOk()) .andExpect(jsonPath($.content).value(not(containsString(onerror)))); } Test void shouldAddContentSecurityPolicyHeader() throws Exception { mockMvc.perform(get(/index)) .andExpect(header().string(Content-Security-Policy, containsString(script-src))); } }第一版測試跑通后我又加了一批繞過嘗試用例覆蓋大小寫混寫、HTML實體編碼、屬性事件、外鏈腳本這些常見攻擊方式。這些用例的價值不僅僅是驗證功能更是給后續(xù)維護的人傳遞一個信息這些攻擊路徑是被明確防御過的改動這部分代碼要小心。4.2 用瀏覽器開發(fā)工具做手動驗證自動化測試之外強烈建議開發(fā)者用瀏覽器開發(fā)工具手動做一輪全鏈路驗證。打開頁面的開發(fā)者工具在Console里查看是否有CSP報錯在Network面板查看響應頭里是否真的帶上了Content-Security-Policy再切換到Sources面板確認頁面源碼里script標簽是否被轉義。CSP如果配置生效即使頁面上出現(xiàn)了內聯(lián)腳本Console中也會輸出CSP拒絕執(zhí)行的明確警告這種反饋比代碼里任何日志都直觀。我常用的一組手動測試載荷在搜索框輸入scriptalert(document.domain)/script如果頁面彈窗或者出現(xiàn)CSP報錯說明防御存在缺口輸入img/srcx/onerroralert(1)測試屬性事件輸入a hrefjavascript:alert(1)test/a測試偽協(xié)議。這組載荷基本能把三種主流繞過路徑都覆蓋到。4.3 清理存量臟數(shù)據(jù)防御方案上線后數(shù)據(jù)庫里已經存在的臟數(shù)據(jù)不會自動變干凈。我習慣的做法是針對用戶可編輯的核心字段昵稱、個人簡介、評論內容寫一個一次性清理腳本把歷史數(shù)據(jù)用Jsoup的白名單機制重新清洗一遍然后再把清洗后的數(shù)據(jù)更新回庫。這個步驟很笨但非常有必要否則新方案只保護新寫入的數(shù)據(jù)存量數(shù)據(jù)一旦被翻出來展示漏洞依然存在。另外線上接口的日志也要檢查一遍確保日志系統(tǒng)沒有把包含原始攻擊載荷的請求體原樣輸出到文件。有些監(jiān)控系統(tǒng)甚至會把帶腳本的內容通過郵件報警發(fā)出來技術同事收到電子郵件打開時又中一次招。安全防御必須形成閉環(huán)從請求、存儲、輸出、日志、監(jiān)控每一個環(huán)節(jié)都要覆蓋。5. 實戰(zhàn)中的常見坑與排查經驗5.1 過濾器導致JSON請求全部失效這是這套方案上線那天最慘痛的教訓。某跨平臺系統(tǒng)采用整體過濾方案時只加了查詢參數(shù)的包裝器沒有處理請求體緩存流結果所有POST接口的RequestBody都拿到空對象前端全線報錯。排查了半個多小時才發(fā)現(xiàn)問題包裝器默認的getInputStream()直接透傳原始流Filter和Controller之間有個先后讀流順序誰先讀了后面的就是空的。這個問題的標準解法就是我在2.3節(jié)寫的XssBodyRequestWrapper把請求體緩存一次后續(xù)的讀取全部指向緩存。需要額外注意的一點是這個緩存方案會占用內存對于超大文件上傳類的接口建議直接從過濾器中排除或者設定只處理Content-Type為application/json的請求避免無謂的性能損耗。5.2 富文本與XSS防御的沖突后臺系統(tǒng)幾乎都有富文本編輯器的需求這也是最容易和過濾器爆發(fā)沖突的地方。團隊的編輯器生成的HTML里有style、class、id甚至>