WEB 安全攻防是個龐大的話題，有各種不同角度的探討和實踐，即使只討論防護的物件，也有諸多不同的方向，包括但不限于：WEB 服務器、資料庫、業務邏輯、敏感資料等等，除了這些我們慣常關注的方面，WEB 安全還有一個重要的元素——網站的使用者，

他們通常是完全沒有 IT 知識的普通用戶，網站方可以做點什么，以增加對這些普通用戶的保護呢？以前較被忽略的步驟是：正確設定頁面的回應頭 (Response Headers) ，這類加入安全相關回應頭的做法，往往是為了保護客戶端／使用者的安全，減少使用者落入黑客的 WEB 陷阱的可能，

這里我們介紹一些較為常用的，和安全相關的回應頭，當然，WEB 應用應該根據自己的實際情況部署和設定，并非盲目地一股腦地全部招呼上，

一、X-Frame-Options -- 打破框框

從 2008 年開始，研發人員發現一種利用視覺誤導，引誘使用者行為的可能，這種做法后來被命名為點擊劫持 (Click Jacking) ，

攻擊者的通常做法是，在自己的頁面里通過框架（iframe）的形式，包含一個不屬于它本站的頁面，下面的示例代碼里包含的就是 【163 郵箱】的設定頁，而由黑客控制的父級頁面本身可以是任何內容，它通過精確調整自己頁面的內容和 iframe 的坐標及大小，再通過 CSS 的 opacity 透明度設定，把用戶內容所在的 iframe 透明度設定為全透明，

以下為示例代碼：

<style>
   .iframe{opacity: 0.4;}
  body { background: url(./sales.png) no-repeat fixed top;
  }   
</style>
</head>
<body>
<iframe src="https://m.reg.163.com/?email=1/#/email" width="100%" height="600px"  frameBorder="0"  scrolling="no"allowtransparency="true">
</iframe>

得到的效果如下圖：

(點擊查看大圖)

請注意我們為了示例效果，特意設定了透明度僅僅為 {opacity:0.4;} ，保持頁面上能隱約看到 163 郵箱的內容，但如果CSS代碼設定為 {opacity:0;} ，163 郵箱的內容就會消弭于眼前，只留下這張促銷圖片，但訪問者點到相應位置時，依然會觸發對163郵箱的請求，這個就是點擊劫持的原理，

早期 WEB 開發者應對這個問題的處理，是用 JavaScript 實作的，一般是判斷當前 window 物件和 parent 物件是否一致，如果不一致，就執行“破框”跳轉，但這個方式并不可靠！因為各種原因，客戶端有可能禁止了 JavaScript 執行或代碼被繞過，這樣“破框”代碼就失效了，在人們日益認識到這種攻擊方式的危害性后，為統一解決這個問題，制定互聯網規范的機構出手了，解決方案就是：

RFC7034
「 HTTP Header Field X-Frame-Options 」
https://tools.ietf.org/html/rfc7034

即引入了一個新的 HTTP 回應頭，現在主流常用瀏覽器已全部支持這一回應頭，具有這個回應頭的資源，可以拒絕自己被非法站點的以下標簽參考：

iFrame 標簽
Frame 標簽
Object 標簽
Applet 標簽
Embed 標簽

這個頭有三種選項，對應如下：

三種選項	具體含義
X-Frame-Options: DENY	完全不能被嵌入到 iframe、frame 等標簽中
X-Frame-Options: SAMEORIGIN	只能被同源頁面嵌入到 iframe 或者 frame 中
X-Frame-Options: ALLOW-FROM https://example.com/	只能被指定的 URI 嵌入到 iframe 或 frame 中

所以顯然，上面 163 郵箱的頁面，就沒有回傳這個回應頭，存在一定的劫持風險，如果加入這個回應頭，我們的模擬頁面，將無法像上圖那樣直接把 163 郵箱的內容嵌進來，

這個回應頭的弊端：

某些早期瀏覽器可能不支持；
對確實需要嵌入很多第三方資源的復雜頁面不適用，

二、X-Content-Type-Options -- IE你別瞎猜猜了

WEB 服務器回傳的資源包括各種，如圖片、HTML 頁面、JavaScript 腳本、CSS 腳本、純文本、二進制檔案等，瀏覽器對資源的解讀和渲染呈現方式，滲透攻擊時有可能被利用，比如一個允許互動的站點，往往允許上傳圖片、mp3 檔案，甚至允許上傳純文本檔案，但往往不允許上傳 JavaScript 腳本檔案和 HTML 檔案，因為后者借助 JavaScript 日益強大的功能，能做的壞事實在有點多，

如無意外，服務器端回傳的每個資源的回應頭里，一般都帶有 content-type 這個回應頭：

HTTP/1.1 200 OK
Content-Length: 3587
Content-Type: image/png
Date: Wed, 20 Mar 2019 09:40:16 GMT
Last-Modified: Tue, 19 Mar 2019 20:01:14 GMT
Server: Microsoft-IIS/7.5

回傳的這個 Content-Type 頭，一般是自動的，如服務器會根據 URL 后綴對應的檔案型別自動選擇；如不是自動的，則可能是程式員在代碼層設定的，兩種情況均有可能，這個回應頭在較為罕見的情況下，也可能缺失，也可能和實際情況不匹配，而比較早期的瀏覽器，尤其是 IE，會出于“好心”，不但在沒有 Content-Type 頭的時候會主動檢測回應的內容，甚至在已有 Content-Type 頭的時候，也會根據回傳的資料體內容，判斷里面有沒有 HTML 代碼特征，如果有，回傳的內容會直接被認定為 HTML 型別，而不顧實際的 Content-Type 頭的型別設定，

如以下例子：

HTTP/1.1 200 OK 
Content-Length: 108 
Date: Thu, 26 Jun 2008 22:06:28 GMT 
Content-Type: text/plain; 

<html> 
<body bgcolor="#AA0000"> 
This page renders as HTML source code (text) in IE8. 
</body> 
</html>

就會被早期一些的 IE 判定為 HTML 內容，最后以 HTML 方式被渲染呈現出來，盡管服務器端已經指定 Content-Type:text/plain; —— 這會導致一定的安全隱患，因為很多有互動功能的服務器，都會允許上傳某些型別的“無害”檔案，如圖片和 mp3 等，如果在上傳的圖片內，巧妙地嵌入一定的 HTML 和 JavaScript 代碼，最后能被渲染為 HTML 檔案，顯然會打破同源限制，產生安全隱患，

所以從 IE8 某個版本開始引入了 X-Content-Type-Options 這個新的回應頭，如果這個回應頭的值為 nosniff ，中文直譯即「別嗅探」，就是告訴瀏覽器端，不要再主動猜測檔案的型別了，以服務器端回傳為準，后來 Chrome 等瀏覽器也支持這個回應頭，

HTTP/1.1 200 OK 
Content-Length: 108 
Date: Thu, 26 Jun 2008 22:06:28 GMT 
Content-Type: text/plain;
X-Content-Type-Options: nosniff

這個回應頭的弊端：

某些早期瀏覽器不支持，

三、HTTP Strict Transport Security (HSTS) -- 不加密不舒服斯基

隨著 WEB 傳遞的敏感資訊越來越多，加密傳輸 HTTPS 也逐漸超越常規 HTTP，正越來越成為互聯網上各大站點的首選傳輸協議，甚至像谷歌公司，從 2018 年中推出的 Chrome 68 版開始，就對所有 HTTP 訪問提示安全警告了，以下參考自谷歌公司的宣告：

過去幾年中，我們一直主張站點采用 HTTPS，以提升其安全性，去年的時候，我們還通過將更大的 HTTP 頁面標記為‘不安全’以幫助用戶，

但通常使用者在瀏覽器里輸入域名時，都是不帶協議部分的，比如直接輸入 www.tcxa.com.cn ，由瀏覽器補齊前面缺失的協議部分，變成完整的 URL: http://www.tcxa.com.cn ，瀏覽器默認加入的協議，總是 HTTP 的！對那些同時提供 HTTP 和 HTTPS 服務，但希望訪問者優先使用 HTTPS 服務的站點來說，這種處理就不太符合他們的本意了，

為解決這個問題，標準制定機構2012 年又發布了一份：

RFC 6797
https://tools.ietf.org/html/rfc6797

這套機制就是 HTTP 嚴格傳輸安全回應頭 (HTTP Strict Transport Security，簡稱 HSTS) ，

這個回應頭里，最重要的一個引數項叫 max-age （單位為秒），這個引數指的是，如果你上一次用 HTTPS 訪問過該站點，下次再來訪問，如果兩次訪問的間隔時間沒有超過這個 max-age 的設定，第二次訪問該站點時，瀏覽器就會直接強制以 HTTPS 協議訪問了，這背后的邏輯是，第一次訪問站點的時候，有針對性的攻擊應該還不會發生，重點是防護后續的訪問，所以后續的訪問需要被強制升級為 HTTPS 協議，這個回應頭需要在 HTTPS 流量里才有效，在 HTTP 流量里回傳這個頭并沒有作用，

以下是站點 https://www.github.com 回傳的部分回應頭摘錄——順便一提，前面介紹的 X-Frame-Options 和 X-Content-Type-Options 回應頭也都出現在 github 里：

HTTP/1.1 200 OK
Cache-Control: max-age=0, private, must-revalidate
Content-Encoding: gzip
Server: GitHub.com
Strict-Transport-Security: max-age=31536000; includeSubdomains; preload
Expect-CT: max-age=2592000, report-uri="https://api.github.com/_private/browser/errors"
Transfer-Encoding: chunked
......
Vary: Accept-Encoding
X-Content-Type-Options: nosniff
X-Frame-Options: deny
......

其中 Strict-Transport-Security 回應頭里， max-age 的值很大，這個 31536000 秒，其實等于 365 天，也就是一整年的時間，意思是除非前后兩次訪問 github 的時間超過一年，否則每次訪問 github，都會被強制使用 HTTPS， includeSubdomains 選項代表這個策略涵蓋 github 所有的子域名，

還可以手工強制 HSTS，方式是在 Chrome 瀏覽器地址欄內，輸入

chrome://net-internals/#hsts，

來到如下圖的配置界面：

在「Add HSTS domain」里，手工加入需要強制使用 HTTPS 的域名，在「Query HSTS/PKP domain」里，則可以查詢某個域名對這個回應頭的設定，

這個回應頭的弊端：

某些早期瀏覽器不支持；
如果 HTTPS 站點出現問題，導致無法訪問， max-age 又設得過大，會導致使用者完全無法回退到訪問 HTTP 站點，

四、瀏覽器兼容性

這些回應頭基本上都是在客戶端腳本越來越強大的 Web 2.0 時代之后才出現的，每種瀏覽器對它們的支持也各異，情況非常復雜混亂，所以使用前也需要評估目標人群的瀏覽器使用場景，

各種瀏覽器對這些回應頭的兼容性，可以查詢以下站點：

https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers

如我們本篇提到的第一個回應頭 X-Frame-Options 的兼容性情況如下：

可以看到瀏覽器分電腦和手機版，電腦版里列出了從哪個版本的瀏覽器開始支持這個回應頭，而且幾個不同的選項值也略有差異，

五、這些回應頭打哪兒來的？！

上面的一切看起來都很美好啦，但問題是：這些回應頭難道是憑空出現的嗎？ 要怎么得到它們呢？一般的 WEB 服務器自身都支持回應頭自定義設定，同時，各種 WEB 開發代碼也可以通過編程的方式，實作更靈活的回應頭回傳和設定，WEB 開發代碼較為復雜，無法囊括，我們大致介紹一下各種 WEB 服務器對這個功能的支持，

1. APACHE

例如，可以在Apache組態檔 httpd.conf 中添加以下配置，限制只有同源頁面才可以嵌入iframe：

Headeralways append X-Frame-OptionsSAMEORIGIN

重啟 apache 使其生效，其他的回應頭也同理，關于Apache Header 指令的詳細用法：

http://httpd.apache.org/docs/current/mod/mod_headers.html#header

2. NGINX

例如，可以在 Nginx 組態檔 nginx.conf 中的「server」背景關系內，添加以下配置，限制只有同源頁面才可以嵌入 iframe：

add_header X-Frame-Options"SAMEORIGIN";

重啟 Nginx 服務使其生效，其他的回應頭也類似同理，關于Nginx add_header 指令的詳細用法：

http://nginx.org/en/docs/http/ngxhttpheaders_module.html

3. IIS

在 WEB 站點對應的 web.config 中添加配置：

<system.webServer>
	<httpProtocol>
	<customHeaders>
		<add name="X-Frame-Options" value="https://www.cnblogs.com/tcxa/p/SAMEORIGIN" />**
	</customHeaders>
	</httpProtocol>

   ...

</system.webServer>

如果不習慣改組態檔，可以使用圖形控制臺，如下選擇網站對應的「HTTP 回應標頭」：