對于老舊項目，從服務(wù)器或中間件層面進(jìn)行加固是一個非常務(wù)實且高效的短期解決方案。

這可以在不修改或極少修改代碼的情況下，立即提升系統(tǒng)的安全水位。

方案一：部署Web應(yīng)用防火墻（WAF）—— 最快速、最有效的臨時方案

WAF是位于Web應(yīng)用程序之前的防護(hù)屏障，通過檢查所有流入的HTTP/HTTPS流量來識別和阻擋惡意攻擊，包括XSS、SQL注入等。

如何實施：

云WAF（首選，最快部署）：

• 如果您的應(yīng)用已經(jīng)部署在云上（如阿里云、騰訊云、AWS），這些平臺都提供托管的WAF服務(wù)。
• 操作：只需將您的域名CNAME解析到云WAF提供的地址上，流量就會先經(jīng)過WAF的清洗再到達(dá)您的服務(wù)器。
• 優(yōu)點：無需安裝任何軟件，分鐘級上線，自帶最新的攻擊規(guī)則庫，有圖形化界面方便管理黑白名單和查看攻擊日志。

軟件WAF（如ModSecurity）：

• 如果服務(wù)器是自建的，可以在您的Web服務(wù)器（如Nginx、Apache）前部署一個反向代理服務(wù)器，
• 并安裝開源的WAF軟件，最著名的是 ModSecurity 及其規(guī)則集 OWASP Core Rule Set (CRS)。

以Nginx為例：

• 編譯Nginx時加入modsecurity模塊。
• 下載OWASP CRS規(guī)則集。
• 在Nginx配置中啟用ModSecurity并加載CRS規(guī)則，CRS規(guī)則中就包含專門檢測XSS的規(guī)則。
• 優(yōu)點：免費(fèi)，高度可定制。
• 缺點：部署和配置有一定技術(shù)復(fù)雜度，需要自行維護(hù)規(guī)則更新。

WAF的優(yōu)缺點：

• 優(yōu)點：立即生效，防護(hù)全面（不止XSS），幾乎無需修改應(yīng)用代碼。
• 缺點：可能存在誤攔（需要調(diào)整規(guī)則）或繞過（但現(xiàn)代WAF規(guī)則庫非常強(qiáng)大），是一種“緩解”措施而非“修復(fù)”措施。

方案二：配置嚴(yán)格的內(nèi)容安全策略（CSP）響應(yīng)頭—— 現(xiàn)代瀏覽器的強(qiáng)力武器

CSP是一個HTTP響應(yīng)頭，它告訴瀏覽器只允許執(zhí)行或加載來自哪些源的資源，從而極大地減少XSS成功后的危害。

如何實施：

在您的Web服務(wù)器（如Tomcat、Nginx、Apache）的配置中，或者在一個簡單的Servlet Filter中，為所有響應(yīng)添加Content-Security-Policy頭。

示例（一個非常嚴(yán)格的策略）：

Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none';

• default-src 'self': 默認(rèn)所有資源（腳本、圖片、樣式等）只能從當(dāng)前域名加載。
• script-src 'self': 腳本只能從當(dāng)前域名加載。這會禁止所有內(nèi)聯(lián)腳本（如<script>...</script>和onclick=...）執(zhí)行，而XSS攻擊往往依賴于內(nèi)聯(lián)腳本。
• object-src 'none': 完全禁止<object>, <embed>, <applet>等插件，這些也是攻擊向量。

配置方法：

在Nginx中配置（推薦，在服務(wù)器層面統(tǒng)一管理）：

# 在server塊中添加
server {
    listen 80;
    server_name yourdomain.com;
    
    # 添加CSP頭
    add_header Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none';" always;
    
    location / {
        proxy_pass http://your_tomcat_app;
    }
}

修改后重啟Nginx：sudo nginx -s reload

在Tomcat的web.xml中配置（使用Filter）：

如果應(yīng)用直接由Tomcat服務(wù)，可以寫一個簡單的Filter來添加響應(yīng)頭。

public class CSPFilter implements Filter {
    @Override
    public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) throws IOException, ServletException {
        HttpServletResponse response = (HttpServletResponse) res;
        response.setHeader("Content-Security-Policy", "default-src 'self'; script-src 'self'; object-src 'none';");
        chain.doFilter(req, res);
    }
    // ... init和destroy方法
}

然后在web.xml中配置這個Filter，映射到/*。

CSP的優(yōu)缺點：

• 優(yōu)點：極其有效，是現(xiàn)代防御XSS的標(biāo)桿。即使攻擊者成功注入了腳本，瀏覽器也不會執(zhí)行它。
• 缺點：如果您的老應(yīng)用大量使用了內(nèi)聯(lián)腳本和樣式，啟用嚴(yán)格的CSP會導(dǎo)致網(wǎng)站功能損壞。此時需要采用逐步實施策略：先只設(shè)置Content-Security-Policy-Report-Only頭，瀏覽器只會報告違規(guī)行為而不會阻止執(zhí)行，您根據(jù)報告逐步調(diào)整策略，直到?jīng)]有違規(guī)后再切換到強(qiáng)制模式。

方案三：配置其他安全相關(guān)的HTTP響應(yīng)頭

這些頭可以進(jìn)一步加固瀏覽器行為，作為輔助手段。

X-Content-Type-Options: nosniff

• 作用：阻止瀏覽器對響應(yīng)內(nèi)容類型進(jìn)行嗅探（MIME-sniffing），強(qiáng)制瀏覽器使用Content-Type頭中定義的類型來渲染內(nèi)容?？梢苑乐箤⑽谋疚募`當(dāng)作JS執(zhí)行。
• 配置（Nginx）：

add_header X-Content-Type-Options "nosniff" always;

X-Frame-Options: DENY 或 SAMEORIGIN

• 作用：禁止網(wǎng)站被嵌入到<iframe>中，防止點擊劫持（Clickjacking）攻擊。
• 配置：

add_header X-Frame-Options "SAMEORIGIN" always; # 只允許同源網(wǎng)站iframe

HttpOnly 和 Secure Cookie 標(biāo)志

作用：HttpOnly使Cookie無法通過JavaScript的document.cookie訪問，有效緩解XSS攻擊后的Cookie竊取。Secure要求Cookie只能通過HTTPS傳輸。

配置：這個通常需要在應(yīng)用代碼中設(shè)置，但如果是Tomcat，可以在context.xml中為所有Session Cookie全局配置：

<Cookie httpOnly="true" secure="true" /> <!-- 如果用了HTTPS，就設(shè)置secure="true" -->

總結(jié)與行動建議（服務(wù)器層面）

立即實施（第一天）：在Nginx/Apache配置中添加安全頭，特別是 X-Content-Type-Options 和 X-Frame-Options。這幾乎沒有風(fēng)險。

短期方案（第一周）：

• 首選：聯(lián)系云廠商或安全團(tuán)隊，部署云WAF。這是最快、最專業(yè)的緩解措施。
• 次選：如果無法用云WAF，研究部署ModSecurity。
• 中期方案（并行進(jìn)行）：配置CSP報告模式（Content-Security-Policy-Report-Only）。分析報告，了解需要調(diào)整哪些策略才能兼容現(xiàn)有應(yīng)用功能，為最終啟用強(qiáng)制CSP做準(zhǔn)備。

重要提示：

服務(wù)器配置是外部加固，相當(dāng)于給老房子安裝了防盜門和監(jiān)控（WAF+CSP），極大地增加了攻擊難度。但它不能修復(fù)房子本身結(jié)構(gòu)上的漏洞（代碼邏輯）。

從長遠(yuǎn)看，一旦有了時間，仍然應(yīng)該推動實施輸出編碼這一根本解決方案。

以上為個人經(jīng)驗，希望能給大家一個參考，也希望大家多多支持腳本之家。

最新評論