本文作者：討厭自己明明不甘平凡，卻又不好好努力.周常見
本文鏈接：https://www.cnblogs.com/you-men/p/13387316.html
為什么要配置HTTP響應頭?
不知道各位有沒有被各類XSS攻擊、點擊劫持 (ClickJacking、 frame 惡意引用等等方式騷擾過，百度聯盟被封就有這些攻擊的功勞在里面。為此一直都在搜尋相關防御辦法，至今效果都不是很好，最近發現其實各個瀏覽器本身提供了一些安全相關的響應頭，使用這些響應頭一般只需要修改服務器配置即可，不需要修改程序代碼，成本很低。至于具體的效果只能是拭目以待了，但是感覺還是有一定的效果的。
而這些HTTP響應頭在我們部署 Nginx 的時候經常會被忽略掉，個人感覺這是一個比較嚴重的“疏忽”，加上還是很有必要的，如果有條件最好是部署一個適合自己站點的X-Content-Security-Policy響應頭。
點擊劫持
# 點擊劫持（ClickJacking）是一種視覺上的欺騙手段。大概有兩種方式，
# 一是攻擊者使用一個透明的iframe，覆蓋在一個網頁上，然后誘使用戶在該頁面上進行操作，此時用戶將在不知情的情況下點擊透明的iframe頁面；
# 二是攻擊者使用一張圖片覆蓋在網頁，遮擋網頁原有位置的含義;
X-Frame-Options響應頭
X-Frame-Options HTTP 響應頭是微軟提出來的一個HTTP響應頭，主要用來給瀏覽器指示允許一個頁面可否在 <frame>, <iframe> 或者 <object> 中展現的標記。網站可以使用此功能，來確保自己網站的內容沒有被嵌到別人的網站中去，也從而避免了點擊劫持(ClickJacking{注1}) 的攻擊。
使用X-Frame-Options有三個值
# DENY
# 表示該頁面不允許在frame中展示,即使在相同域名的頁面中嵌套也不允許
# SAMEORIGIN
# 表示該頁面可以在相同域名頁面的frame中展示
# ALLOW-FROM url
# 表示該頁面可以在指定來源的frame中展示
如果設置為 DENY，不光在別人的網站 frame 嵌入時會無法加載，在同域名頁面中同樣會無法加載。另一方面，如果設置為SAMEORIGIN，那么頁面就可以在同域名頁面的 frame 中嵌套。
PS：目前發現這個HTTP響應頭會帶來的問題就是百度統計中的“熱點追蹤(頁面點擊圖）”功能會失效，這也說明百度統計的“熱點追蹤(頁面點擊圖）”使用的是 frame 嵌入引用網頁的形式，這時候大家可以使用 X-Frame-Options 的ALLOW-FROM uri來指定百度統計域名為可 frame 嵌入域名即可。具體在Nginx里可以采用如下的方式添加響應頭
# add_header X-Frame-Options:ALLOW-FROM https://tongji.baidu.com;
# add_header X-Frame-Options:SAMEORIGIN;
X-Content-Type-Options響應頭
互聯網上的資源有各種類型，通常瀏覽器會根據響應頭的Content-Type字段來分辨它們的類型。例如：text/html代表html文檔，image/png是PNG圖片，text/css是CSS樣式文檔。然而，有些資源的Content-Type是錯的或者未定義。這時，某些瀏覽器會啟用MIME-sniffing來猜測該資源的類型，解析內容并執行。
例如，我們即使給一個html文檔指定Content-Type為text/plain，在IE8-中這個文檔依然會被當做html來解析。利用瀏覽器的這個特性，攻擊者甚至可以讓原本應該解析為圖片的請求被解析為JAVAScript。在Nginx里通過下面這個響應頭可以禁用瀏覽器的類型猜測行為：
# X-Content-Type-Options HTTP 消息頭相當于一個提示標志，被服務器用來提示客戶端一定要遵循在 Content-Type 首部中對 MIME 類型 的設定，
# 而不能對其進行修改。這就禁用了客戶端的 MIME 類型嗅探行為，換句話說，也就是意味著網站管理員確定自己的設置沒有問題。
# X-Content-Type-Options響應頭的缺失使得目標URL更易遭受跨站腳本攻擊。
# add_header X-Content-Type-Options: nosniff;
這個響應頭的值只能是nosniff, 可用于IE8+和Chrome
IE的行為受X-Content-Type-Options的影響，如果Web應用沒有返回Content-Type，那么IE9、IE11將拒絕加載相關資源。
# 如果服務器發送響應頭 “X-Content-Type-Options: nosniff”，則 script 和 styleSheet
# 元素會拒絕包含錯誤的 MIME 類型的響應。這是一種安全功能，有助于防止基于 MIME 類型混淆的攻擊。
X-Content-Security-Policy響應頭
W3C 的 Content Security Policy，簡稱 CSP。顧名思義，這個規范與內容安全有關，主要是用來定義頁面可以加載哪些資源，減少 XSS 的發生。
Chrome 擴展已經引入了 CSP，通過 manifest.json 中的 content_security_policy 字段來定義。一些現代瀏覽器也支持通過響應頭來定義 CSP。下面我們主要介紹如何通過響應頭來使用 CSP，Chrome 擴展中 CSP 的使用可以參考 Chrome 官方文檔。
# HTTP 響應頭Content-Security-Policy允許站點管理者控制用戶代理能夠為指定的頁面加載哪些資源。
# 除了少數例外情況，設置的政策主要涉及指定服務器的源和腳本結束點。
# Content-Security-Policy響應頭的缺失使得目標URL更易遭受跨站腳本攻擊。
瀏覽器兼容性
# 早期的 Chrome 是通過 X-WebKit-CSP 響應頭來支持 CSP 的，而 firefox 和 IE 則支持 X-Content-Security-Policy，
# Chrome25 和 Firefox23 開始支持標準的 Content-Security-Policy
如何使用
# 要使用 CSP，只需要服務端輸出類似這樣的響應頭就行了：
Content-Security-Policy: default-src 'self'
# default-src 是 CSP 指令，多個指令之間用英文分號分割；'self' 是指令值，多個指令值用英文空格分割。目前，有這些 CSP 指令：
從上面的介紹可以看到，CSP 協議可以控制的內容非常多。而且如果不特別指定 'unsafe-inline' 時，頁面上所有 inline 樣式和腳本都不會執行；不特別指定 'unsafe-eval'，頁面上不允許使用 new Function，setTimeout，eval 等方式執行動態代碼。在限制了頁面資源來源之后，被 XSS 的風險確實小不少。
當然，僅僅依靠 CSP 來防范 XSS 是遠遠不夠的，不支持全部瀏覽器是它的硬傷。不過，鑒于低廉的開發成本，加上也沒什么壞處。
StrictTransportSecurity響應頭
什么是StrictTransportSecurity?
一個網站接受一個HTTP的請求，然后跳轉到HTTPS，用戶可能在開始跳轉前，通過沒有加密的方式和服務器對話，比如，用戶輸入http://foo.com或者直接foo.com。這樣存在中間人攻擊潛在威脅，跳轉過程可能被惡意網站利用來直接接觸用戶信息，而不是原來的加密信息。網站通過HTTP Strict Transport Security通知瀏覽器，這個網站禁止使用HTTP方式加載，瀏覽器應該自動把所有嘗試使用HTTP的請求自動替換為HTTPS請求。
為什么要開啟
有的網站開啟了https，但為了照顧用戶的使用體驗（因為用戶總是很賴的，一般不會主動鍵入https，而是直接輸入域名, 直接輸入域名訪問，默認就是http訪問）同時也支持http訪問，當用戶http訪問的時候，就會返回給用戶一個302重定向，重定向到https的地址，然后后續的訪問都使用https傳輸,這種通信模式看起來貌似沒有問題，但細致分析，就會發現種通信模式也存在一個風險，那就是這個302重定向可能會被劫持篡改，如果被改成一個惡意的或者釣魚的https站點，然后，你懂得，一旦落入釣魚站點，數據還有安全可言嗎？
對于篡改302的攻擊，建議服務器開啟HTTP Strict Transport Security功能，這個功能的含義是：
當用戶已經安全的登錄開啟過htst功能的網站 (支持hsts功能的站點會在響應頭中插入：Strict-Transport-Security) 之后，支持htst的瀏覽器(比如chrome. firefox)會自動將這個域名加入到HSTS列表，下次即使用戶使用http訪問這個網站，支持htst功能的瀏覽器就會自動發送https請求（前提是用戶沒有清空緩存，如果清空了緩存第一次訪問還是明文，后續瀏覽器接收到服務器響應頭中的Strict-Transport-Security，就會把域名加入到hsts緩存中，然后才會在發送請求前將http內部轉換成https），而不是先發送http，然后重定向到https，這樣就能避免中途的302重定向URL被篡改。進一步提高通信的安全性。
上面是我自己的理解，下面是owasp中文站點關于hsts的描述：
HSTS的作用是強制客戶端（如瀏覽器）使用HTTPS與服務器創建連接。服務器開啟HSTS的方法是，當客戶端通過HTTPS發出請求時，在服務器返回的超文本傳輸協議響應頭中包含Strict-Transport-Security字段。非加密傳輸時設置的HSTS字段無效。
比如，https://example.com/ 的響應頭含有Strict-Transport-Security: max-age=31536000; includeSubDomains。這意味著兩點：
在接下來的一年（即31536000秒）中，瀏覽器只要向example.com或其子域名發送HTTP請求時，必須采用HTTPS來發起連接。比如，用戶點擊超鏈接或在地址欄輸入 http://www.example.com/ ，瀏覽器應當自動將 http 轉寫成 https，然后直接向 https://www.example.com/ 發送請求。
在接下來的一年中，如果 example.com 服務器發送的TLS證書無效，用戶不能忽略瀏覽器警告繼續訪問網站。
HSTS可以用來抵御SSL剝離攻擊。SSL剝離攻擊是中間人攻擊的一種，由Moxie Marlinspike于2009年發明。他在當年的黑帽大會上發表的題為“New Tricks For Defeating SSL In Practice”的演講中將這種攻擊方式公開。SSL剝離的實施方法是阻止瀏覽器與服務器創建HTTPS連接。它的前提是用戶很少直接在地址欄輸入https://，用戶總是通過點擊鏈接或3xx重定向，從HTTP頁面進入HTTPS頁面。所以攻擊者可以在用戶訪問HTTP頁面時替換所有https://開頭的鏈接為http://，達到阻止HTTPS的目的。
HSTS可以很大程度上解決SSL剝離攻擊，因為只要瀏覽器曾經與服務器創建過一次安全連接，之后瀏覽器會強制使用HTTPS，即使鏈接被換成了HTTP
另外，如果中間人使用自己的自簽名證書來進行攻擊，瀏覽器會給出警告，但是許多用戶會忽略警告。HSTS解決了這一問題，一旦服務器發送了HSTS字段，用戶將不再允許忽略警告。
0×03. Strict-Transport-Security的一些不足
用戶首次訪問某網站是不受HSTS保護的。這是因為首次訪問時，瀏覽器還未收到HSTS，所以仍有可能通過明文HTTP來訪問。解決這個不足目前有兩種方案，一是瀏覽器預置HSTS域名列表，google Chrome、Firefox、Internet Explorer和Spartan實現了這一方案。二是將HSTS信息加入到域名系統記錄中。但這需要保證DNS的安全性，也就是需要部署域名系統安全擴展。截至2014年這一方案沒有大規模部署。
由于HSTS會在一定時間后失效（有效期由max-age指定），所以瀏覽器是否強制HSTS策略取決于當前系統時間。部分操作系統經常通過網絡時間協議更新系統時間，如Ubuntu每次連接網絡時，OS X Lion每隔9分鐘會自動連接時間服務器。攻擊者可以通過偽造NTP信息，設置錯誤時間來繞過HSTS。解決方法是認證NTP信息，或者禁止NTP大幅度增減時間。比如windows 8每7天更新一次時間，并且要求每次NTP設置的時間與當前時間不得超過15小時
X-XSS-Protection響應頭
顧名思義，這個響應頭是用來防范XSS的。最早我是在介紹IE8的文章里看到這個，現在主流瀏覽器都支持，并且默認都開啟了XSS保護，用這個header可以關閉它。它有幾種配置：
0：# 禁用XSS保護；
1：# 啟用XSS保護；
1; # mode=block：啟用XSS保護，并在檢查到XSS攻擊時，停止渲染頁面（例如IE8中，檢查到攻擊時，整個頁面會被一個#替換）；
# HTTP X-XSS-Protection 響應頭是 Internet Explorer，Chrome 和 Safari 的一個特性，
# 當檢測到跨站腳本攻擊 (XSS)時，瀏覽器將停止加載頁面。
# X-XSS-Protection響應頭的缺失使得目標URL更易遭受跨站腳本攻擊。
# 瀏覽器提供的XSS保護機制并不完美，但是開啟后仍然可以提升攻擊難度，總之沒有特別的理由，不要關閉它。
Nginx配置方法如下
# add_header X-Xss-Protection: 1;
# add_header X-Xss-Protection: mod=block;
實際案例
Google+
使用功能了這幾個文本提到的響應頭
# x-content-type-options: nosniff
# x-frame-options: SAMEORIGIN
# x-xss-protection: 1; mode=block
# strict-transport-security: max-age=631138519
# x-frame-options: SAMEORIGIN
# x-xss-protection: 1; mode=block
PayPal
# X-Frame-Options: SAMEORIGIN
# Strict-Transport-Security: max-age=14400
配置了詳細的CSP,關閉了XSS保護
strict-transport-security: max-age=60
x-content-type-options: nosniff
x-frame-options: DENY
x-xss-protection: 0
content-security-policy: default-src *;script-src https://*.facebook.com http://*.facebook.com https://*.fbcdn.net http://
