HTTP Strict Transport Security (一般簡稱爲HSTS)

HTTP Strict Transport Security (一般簡稱爲HSTS) 是一個安全功能，它告訴瀏覽器只能經過HTTPS訪問當前資源, 禁止HTTP方式。

Freebuf百科：什麼是Strict-Transport-Security?

一個網站接受一個HTTP的請求，而後跳轉到HTTPS，用戶可能在開始跳轉前，經過沒有加密的方式和服務器對話，好比，用戶輸入http://foo.com或者直接foo.com。這樣存在中間人攻擊潛在威脅，跳轉過程可能被惡意網站利用來直接接觸用戶信息，而不是原來的加密信息。網站經過HTTP Strict Transport Security通知瀏覽器，這個網站禁止使用HTTP方式加載，瀏覽器應該自動把全部嘗試使用HTTP的請求自動替換爲HTTPS請求。

咱們爲何須要開啓Strict-Transport-Security?

想一想這樣一種場景：

有的網站開啓了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字段無效。

好比，example.com/ 的響應頭含有Strict-Transport-Security: max-age=31536000; includeSubDomains。這意味着兩點：

在接下來的一年（即31536000秒）中，瀏覽器只要向example.com或其子域名發送HTTP請求時，必須採用HTTPS來發起鏈接。好比，用戶點擊超連接或在地址欄輸入 www.example.com/ ，瀏覽器應當自動將 http 轉寫成 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字段，用戶將再也不容許忽略警告。

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小時

測試

目標域名：portal.fraudmetrix.cn (這個站點不支持hsts功能) 同盾科技的風險控制管理系統(打個軟廣，同盾科技，基於大數據，專一反欺詐)。

第一次訪問：在瀏覽器地址欄鍵入：portal.fraudmetrix.cn

能夠看到:

這個域名並不在chrome瀏覽器的hsts的緩存中，也不在hsts中的preload list中(像facebook、twitter等網站已經內置在preload list中，因此每次請求這些站點的時候瀏覽器都會自動將http 轉換成htttps)，因此不會在發送請求前將http轉換成https請求。

咱們來把這個站點手動加入到chrome瀏覽器的hsts緩存中：

在未清空chrome瀏覽器歷史記錄的前提下，咱們再次訪問這個站點：

能夠看到，一個307 響應碼，這是chrome瀏覽器的內部轉換，將http轉換成https後再發送請求。

備註：爲何咱們要求在未清空chrome瀏覽器的緩存前訪問呢？

由於若是清空了chrome瀏覽器的緩存以後，咱們手動加入到hsts緩存中的域名就會被清除，也就不會看到預期的效果了。

測試2

咱們先清空chrome瀏覽器的緩存，而後在瀏覽器的地址欄中鍵入 www.alipay.com

能夠看到www.alipay.com(支付寶)這個站點並無在chrome 瀏覽器的內置的preload list中，因此第一次訪問的時候，chrome瀏覽器並不會將http轉換成https。

而是由前端的F5的負載均衡(BigIP)器將http請求重定向到https請求。

咱們繼續看看此次請求的其餘響應：

能夠看到支付寶站點服務器是支持hsts功能的，在其響應頭中插入了：Strict-Transport-Security，而且設置這個頭部的有效期，只要不手動清空緩存，那麼在這個有效期內，chrome瀏覽器都會將全部發送這個站點的http請求在內部轉換成https再發送出去。

瀏覽器在收到帶有Strict-Transport-Security響應頭的報文後，就會將這個站點加入到hsts緩存中，下次以http訪問的時候就會被自動轉換成https。

咱們這時查看如下hsts的緩存中是否是有了 www.alipay.com

正如你所見：www.alipay.com已經被加入到了chrome瀏覽器的緩存中。

這時候在未清空瀏覽器緩存的前提下再次訪問 www.alipay.com

看到了吧，熟悉的307響應碼，瀏覽器作了內部轉換，將http轉換成https。

其餘

臉書www.facebook.com是已經加入到chrome瀏覽器hsts preload list中的。

注意到沒，信息很詳細哦！

看看我大百度呢？

清空chrome瀏覽器緩存，在地址欄鍵入www.baidu.com：

很遺憾，我大百度也不在chrome hsts preload list中。

在看看此次請求中的其餘響應報文呢：

也沒有看到 Strict-Transport-Security的影子。

(轉載 github.com/BothEyes199…)