天天看點

10.圖靈學院-----阿裡/京東/滴滴/美團整理----安全驗證篇

一、什麼是認證和授權?如何設計一個權限認 證架構?

認證: 就是對系統通路者的身份進行确認。 使用者名密碼登入、 二維碼登入、手機短信登入、指紋、刷臉。。。

授權:就是對系統通路者的行為進行控制。授權通常是在認證之後,對系統内的使用者隐私資料進行保護。背景接口通路權限、前台控件的通路權限。

RBAC模型: 主體 -》 角色 -》 資源 -》通路系統的行為。

認證和授權也是對一個權限認證架構進行擴充的兩個主要的方面。

二、Cookie和Session有什麼差別?

三、如果沒有Cookie,Session還能進行身份 驗證嗎?

當伺服器tomcat第一次接收到用戶端的請求時,會開辟一塊獨立的session空間,建立一個session對象,同時會生成一個session id,通過響應頭的方式儲存到用戶端浏覽器的cookie當中。以後用戶端的每次請求,都會在請求頭部帶上這個session id,這樣就可以對應上服務端的一些會話的相關資訊,比如使用者的登入狀态。如果沒有用戶端的Cookie,Session是無法進行身份驗證的。

當服務端從單體應用更新為分布式之後,cookie+session這種機制要怎麼擴充?

1、session黏貼: 在負載均衡中,通過一個機制保證同一個用戶端的所有請求都會轉發到同一個tomcat執行個體當中。問題: 當這個tomcat執行個體出現問題之後,請求就會被轉發到其他執行個體,這時候使用者的session資訊就丢了。

2、session複制: 當一個tomcat執行個體上儲存了session資訊後,主動将session 複制到叢集中的其他執行個體。問題: 複制是需要時間的,在複制過程中,容易産生session資訊丢失。

3、session共享: 就是将服務端的session資訊儲存到一個第三方中,比如Redis。

四、什麼是CSRF攻擊?如何防止?

CSRF: Cross Site Requst Forgery 跨站請求僞造 一個正常的請求會将合法使用者的session id儲存到浏覽器的cookie。這時候,如果使用者在浏覽器中打來另一個tab頁, 那這個tab頁也是可以獲得浏覽器的cookie。黑客就可以利用這個cookie資訊進行攻擊。

攻擊過程:

1、某銀行網站A可以以GET請求的方式發起轉賬操作。 www.xxx.com/transfor.do?accountNum=100&money=1000 accountNum表示目标賬戶。這個請求肯定是需要登入才可以正常通路的。

2、攻擊者在某個論壇或者網站上,上傳一個圖檔,連結位址是 www.xxx.com/transfer.do?accountNum=888&money=10000 其中這個accountNum就是攻擊者-自己的銀行賬戶。

3、如果有一個使用者,登入了銀行網站,然後又打開浏覽器的另一個tab頁,點選了這個圖檔。這時,銀行就會受理到一個帶了正确cookie的請求,就會完成轉賬。使用者的錢就被盜了。

CSRF方式方式:

1、盡量使用POST請求,限制GET請求。POST請求可以帶請求體,攻擊者就不容易僞造出請求。

2、将cookie設定為HttpOnly : respose.setHeader(“SetCookie”,“cookiename=cookievalue;HttpOnly”)。

3、增加token;

在請求中放入一個攻擊者無法僞造的資訊,并且該資訊不存在于cookie當中。

這也是Spring Security架構中采用的防範方式。

五、什麼是OAuth2.0協定?有哪幾種認證方 式?什麼是JWT令牌?和普通令牌有什麼區 别?

OAuth2.0是一個開放标準,允許使用者授權第三方應用程式通路他們存儲在另外的服務提供者上的資訊,而不需要将使用者名和密碼提供給第三方應用或分享他們資料的所有内容。

OAuth2.0協定的認證流程,簡單了解,就是允許我們将之前的授權和認證過程交給

一個獨立的第三方進行擔保。

OAuth2.0協定有四種認證方式:

1、授權碼模式

10.圖靈學院-----阿裡/京東/滴滴/美團整理----安全驗證篇

2、簡化模式

10.圖靈學院-----阿裡/京東/滴滴/美團整理----安全驗證篇

3、密碼模式

10.圖靈學院-----阿裡/京東/滴滴/美團整理----安全驗證篇

4、用戶端模式

10.圖靈學院-----阿裡/京東/滴滴/美團整理----安全驗證篇

在梳理OAuth2.0協定流程的過程中,其實有一個主線,就是三方參與者之家的信任程度。

普通令牌: b9f2eaa1-8715-4f03-86c7-06bf757a5f7c

普通令牌隻是一個随機的字元串,沒有特殊的意義。這就意味着,當客戶帶上令牌去通路應用的接口時,應用本身無法判斷這個令牌是否正确,他就需要到授權伺服器上去判斷令牌是否有效。在高并發場景下,檢查令牌的網絡請求就有可能成為一個性能瓶頸。

改良的方式就是JWT令牌。将令牌對應的相關資訊全部備援到令牌本身,這樣資源伺服器就不再需要發送請求給授權伺服器去檢查令牌了,他自己就可以讀取到令牌的授權資訊。JWT令牌的本質就是一個加密的字元串!!

JWT令牌:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJhdWQiOlsic2FsYXJ5Il0sInVzZXJfbmFtZSI6ImFkbWluIiwic2NvcGUiOlsiYWxsIl0sImV4cCI6MTYxNjY3MjM3OCwiYXV0aG9yaXRpZXMiOlsibW9iaWxlIiwic2FsYXJ5Il0sImp0aSI6ImI1MDg2OWE0LTIzZmEtNDg2Yy1hZGJlLTljNTlmMjRiMDY4YSIsImNsaWVudF9pZCI6ImMxIn0.tJ5d7RBKPj8d6w7826OqS6_2pDf_ZXvwkJHMO2uPVAg

六、什麼是SSO?與OAuth2.0有什麼關系?

七、如何設計一個開放授權平台?

繼續閱讀