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