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

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

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

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

如何實施：

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

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

軟件WAF（如ModSecurity）：

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

以Nginx為例：

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

WAF的優(yōu)缺點：

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

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

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

如何實施：

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

示例（一個非常嚴格的策略）：

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

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

配置方法：

在Nginx中配置（推薦，在服務器層面統(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）：

如果應用直接由Tomcat服務，可以寫一個簡單的Filter來添加響應頭。

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的標桿。即使攻擊者成功注入了腳本，瀏覽器也不會執(zhí)行它。
• 缺點：如果您的老應用大量使用了內聯(lián)腳本和樣式，啟用嚴格的CSP會導致網(wǎng)站功能損壞。此時需要采用逐步實施策略：先只設置Content-Security-Policy-Report-Only頭，瀏覽器只會報告違規(guī)行為而不會阻止執(zhí)行，您根據(jù)報告逐步調整策略，直到?jīng)]有違規(guī)后再切換到強制模式。

方案三：配置其他安全相關的HTTP響應頭

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

X-Content-Type-Options: nosniff

• 作用：阻止瀏覽器對響應內容類型進行嗅探（MIME-sniffing），強制瀏覽器使用Content-Type頭中定義的類型來渲染內容。可以防止將文本文件誤當作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 標志

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

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

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

總結與行動建議（服務器層面）

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

短期方案（第一周）：

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

重要提示：

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

從長遠看，一旦有了時間，仍然應該推動實施輸出編碼這一根本解決方案。

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

最新評論