摘要

目前有許多的惡意攻擊都是以網(wǎng)站及其用戶作為目標(biāo)，本文將簡(jiǎn)要介紹在 Web 服務(wù)器一側(cè)的安全加固和測(cè)試方法。

點(diǎn)擊劫持（Clickjacking）

點(diǎn)擊劫持,clickjacking 是一種在網(wǎng)頁中將惡意代碼等隱藏在看似無害的內(nèi)容（如按鈕）之下，并誘使用戶點(diǎn)擊的手段，又被稱為界面?zhèn)窝b（UI redressing）。例如用戶收到一封包含一段視頻的電子郵件，但其中的“播放”按鈕并不會(huì)真正播放視頻，而是被誘騙進(jìn)入一個(gè)購物網(wǎng)站。

針對(duì)點(diǎn)擊劫持攻擊，開放Web應(yīng)用程序安全項(xiàng)目(Open Web Application Security Project ,OWASP)(非營(yíng)利組織，其目的是協(xié)助個(gè)人、企業(yè)和機(jī)構(gòu)來發(fā)現(xiàn)和使用可信賴軟件) 提供了一份指引，《Defending_with_X-Frame-Options_Response_Headers》 。

X-Frame-Options HTTP 響應(yīng)頭是用來給瀏覽器指示允許一個(gè)頁面可否在 frame 標(biāo)簽 或者 object 標(biāo)簽中展現(xiàn)的標(biāo)記。網(wǎng)站可以使用此功能，來確保自己網(wǎng)站的內(nèi)容沒有被嵌到別人的網(wǎng)站中去，也從而避免了點(diǎn)擊劫持 (clickjacking) 的攻擊。DENY:表示該頁面不允許在 frame 中展示，即便是在相同域名的頁面中嵌套也不允許。SAMEORIGIN:表示該頁面可以在相同域名頁面的 frame 中展示。ALLOW-FROM uri:表示該頁面可以在指定來源的 frame 中展示。配置如下:

//HAProxy
http-response set-header X-Frame-Options:DENY
//Nginx
add_header X-Frame-Options "DENY";
//Java
response.addHeader("x-frame-options","DENY");

跨站腳本 Cross-site scripting (XSS)

跨站腳本通常指的是通過利用開發(fā)時(shí)留下的漏洞，注入惡意指令代碼（JavaScript/Java/VBScript/ActiveX/Flash/HTML等）到網(wǎng)頁，使用戶加載并執(zhí)行攻擊者惡意制造的程序。攻擊者可能得到更高的權(quán)限、私密網(wǎng)頁、會(huì)話和cookie等各種內(nèi)容。目前有兩種不同的 HTTP 響應(yīng)頭可以用來防止 XSS 攻擊，它們是：

• X-XSS-Protection
• Content-Security-Policy

X-XSS-Protection

HTTP X-XSS-Protection 響應(yīng)頭是Internet Explorer，Chrome和Safari的一個(gè)功能，當(dāng)檢測(cè)到跨站腳本攻擊 (XSS)時(shí)，瀏覽器將停止加載頁面。配置選項(xiàng)：0 禁止XSS過濾。1 啟用XSS過濾（通常瀏覽器是默認(rèn)的）。 如果檢測(cè)到跨站腳本攻擊，瀏覽器將清除頁面（刪除不安全的部分）。mode=block 啟用XSS過濾, 如果檢測(cè)到攻擊，瀏覽器將不會(huì)清除頁面，而是阻止頁面加載。report=reporting-URI 啟用XSS過濾。 如果檢測(cè)到跨站腳本攻擊，瀏覽器將清除頁面并使用 CSP report-uri 指令的功能發(fā)送違規(guī)報(bào)告。參考文章《The misunderstood X-XSS-Protection》:

//HAProxy
http-response set-header X-XSS-Protection: 1;mode=block
//Nginx
add_header X-Xss-Protection "1; mode=block" always;;

瀏覽器支持情況：

Content-Security-Policy

內(nèi)容安全性政策(Content Security Policy,CSP)就是一種白名單制度，明確告訴客戶端哪些外部資源（腳本／圖片／音視頻等）可以加載和執(zhí)行。瀏覽器可以拒絕任何不來自預(yù)定義位置的任何內(nèi)容，從而防止外部注入的腳本和其他此類惡意內(nèi)容。設(shè)置 Content-Security-Policy Header：

//HAProxy:
http-response set-header Content-Security-Policy:script-src https://www.google-analytics.com;https://q.quora.com
//Nginx
add_header Content-Security-Policy-Report-Only "script-src https://www.google-analytics.com https://q.quora.com";

MIME-Sniffing

MIME-Sniffing（主要是Internet Explorer）使用的一種技術(shù)，它嘗試猜測(cè)資源的 MIME 類型（也稱為 Content-Type 內(nèi)容類型）。這意味著瀏覽器可以忽略由 Web 服務(wù)器發(fā)送的 Content-Type Header，而不是嘗試分析資源（例如將純文本標(biāo)記為HTML 標(biāo)簽），按照它認(rèn)為的資源（HTML）渲染資源而不是服務(wù)器的定義（文本）。雖然這是一個(gè)非常有用的功能，能夠糾正服務(wù)器發(fā)送的錯(cuò)誤的 Content-Type，但是心懷不軌的人可以輕易濫用這一特性，這使得瀏覽器和用戶可能被惡意攻擊。例如，如通過精心制作一個(gè)圖像文件，并在其中嵌入可以被瀏覽器所展示和執(zhí)行的HTML和t代碼。《Microsoft Developer Network:IE8 Security Part V: Comprehensive Protection》：

Consider, for instance, the case of a picture-sharing web service which hosts pictures uploaded by anonymous users. An attacker could upload a specially crafted JPEG file that contained script content, and then send a link to the file to unsuspecting victims. When the victims visited the server, the malicious file would be downloaded, the script would be detected, and it would run in the context of the picture-sharing site. This script could then steal the victim’s cookies, generate a phony page, etc.

//HAProxy
http-response set-header X-Content-Type-Options: nosniff
//Nginx
add_header X-Content-Type-Options "nosniff" always;

SSL Strip Man-in-The-Middle Attack

中間人攻擊中攻擊者與通訊的兩端分別創(chuàng)建獨(dú)立的聯(lián)系，并交換其所收到的數(shù)據(jù)，使通訊的兩端認(rèn)為他們正在通過一個(gè)私密的連接與對(duì)方直接對(duì)話，但事實(shí)上整個(gè)會(huì)話都被攻擊者完全控制。例如，在一個(gè)未加密的Wi-Fi 無線接入點(diǎn)的接受范圍內(nèi)的中間人攻擊者，可以將自己作為一個(gè)中間人插入這個(gè)網(wǎng)絡(luò)。強(qiáng)制用戶使用HTTP嚴(yán)格傳輸安全（HTTP Strict Transport Security,HSTS）。 HSTS 是一套由 IETF 發(fā)布的互聯(lián)網(wǎng)安全策略機(jī)制。Chrome 和 Firefox 瀏覽器有一個(gè)內(nèi)置的 HSTS 的主機(jī)列表，網(wǎng)站可以選擇使用 HSTS 策略強(qiáng)制瀏覽器使用 HTTPS 協(xié)議與網(wǎng)站進(jìn)行通信，以減少會(huì)話劫持風(fēng)險(xiǎn)。

服務(wù)器設(shè)置下列選項(xiàng)可以強(qiáng)制所有客戶端只能通過 HTTPS 連接：

//HAProxy
http-response set-header Strict-Transport-Security max-age=31536000;includeSubDomains;preload
//Nginx
add_header Strict-Transport-Security 'max-age=31536000; includeSubDomains; preload; always;'

暴露 URL （HTTPS > HTTP Sites)

Referrer 信息被廣泛用于網(wǎng)絡(luò)訪問流量來源分析，它是眾多網(wǎng)站數(shù)據(jù)統(tǒng)計(jì)服務(wù)的基礎(chǔ)，例如 Google Analytics 和 AWStats,基于Perl的開源日志分析工具。同樣的這一特性也會(huì)很容易被惡意利用，造成用戶敏感信息泄漏，例如將用戶 SESSION ID 放在 URL 中，第三方拿到就可能看到別人登錄后的頁面內(nèi)容。2014 年，W3C 發(fā)布了 Referrer Policy 的新草案，開發(fā)者開始有權(quán)控制自己網(wǎng)站的 Referrer Policy。但是僅有 Chrome／Firefox 瀏覽器較新的版本的能夠提供支持。

Referrer-Policy選項(xiàng)列表：

• Referrer-Policy: no-referrer //整個(gè) Referer 首部會(huì)被移除。訪問來源信息不隨著請(qǐng)求一起發(fā)送。
• Referrer-Policy: no-referrer-when-downgrade //默認(rèn)選項(xiàng)
  //引用頁面的地址會(huì)被發(fā)送(HTTPS->HTTPS)，降級(jí)的情況不會(huì)被發(fā)送 (HTTPS->HTTP)
• Referrer-Policy: origin //在任何情況下，僅發(fā)送文件的源作為引用地址
• Referrer-Policy: origin-when-cross-origin //對(duì)于同源的請(qǐng)求，會(huì)發(fā)送完整的URL作為引用地址，但是對(duì)于非同源請(qǐng)求僅發(fā)送文件的源
• Referrer-Policy: same-origin //對(duì)于同源的請(qǐng)求會(huì)發(fā)送引用地址，但是對(duì)于非同源請(qǐng)求則不發(fā)送引用地址信息。
• Referrer-Policy: strict-origin //在同等安全級(jí)別的情況下，發(fā)送文件的源作為引用地址(HTTPS->HTTPS)
• Referrer-Policy: strict-origin-when-cross-origin //對(duì)于同源的請(qǐng)求，會(huì)發(fā)送完整的URL作為引用地址
• Referrer-Policy: unsafe-url //無論是否同源請(qǐng)求，都發(fā)送完整的 URL（移除參數(shù)信息之后）作為引用地址。

我們必須確保用戶從全 HTTPS 站點(diǎn)跳轉(zhuǎn)到 HTTP 站點(diǎn)的時(shí)候，沒有中間人可以嗅探出用戶實(shí)際的 HTTPS URL，Referrer Policy 設(shè)置如下：

//HAProxy
http-response set-header Referrer-Policy no-referrer-when-downgrade
//Nginx
add_header Referrer-Policy: no-referrer-when-downgrade

測(cè)試

安全研究員 Scott Helme 貢獻(xiàn)了一個(gè)非常棒的網(wǎng)站 [https://securityheaders.io/]，可以分析自己站點(diǎn)的Header(報(bào)文頭)，并提出改進(jìn)安全性的建議。示例如下（環(huán)境參數(shù)，Operating System: CentOS 7 ; haproxy 1.5.14 ; nginx 1.12.0）。

• 加固前的檢測(cè)結(jié)果

  
  
  加固前

• 加固后的檢測(cè)結(jié)果

  
  
  加固后