登錄科普(一)CAS與Oauth

涉及內容:CAS、SSO、Oauth2.0,token、XSS、CSRF。

名詞科普

  • Oauth2.0:Oauth是一個關于授權的開放標準網絡協議,目前的版本是2.0。
  • CAS(Central Authentication Service) 中心認證服務。
  • SSO(Single Sign On) 單點登錄。
  • token:一個主服務允許第三方訪問特定資源的令牌。
  • CSRF(Cross-site request forgery)跨站請求偽造。
  • XSS(Cross Site Scripting)跨站腳本攻擊。

在使用任何登錄框架或者傳輸標準時,如果想安全,都要基于HTTPS協議!

Oauth2.0

原理解釋

場景:你在(登錄后)瀏覽某論壇時,遇到了一篇好文章,想要分享給大家時,你需要登錄(掃碼或者登錄用戶名密碼)第三方賬戶來完成分享。
基本流程:

  1. 在點擊分享鏈接時,主服務器會直接(接口)請求第三方服務器,第三方服務器會校驗主服務器上的用戶此時是否授權給自己(第三方);
  2. 沒有授權信息,用戶登錄(掃描或者密碼)。
  3. 主服務器拿著用戶的登錄信息去第三方確認認證授權(密碼是否正確、是否授權)。
  4. 認證失敗,密碼錯誤。(重新登錄)
  5. 認證成功(確認授權),第三方認證服務會返回的授權碼。
  6. 主服務器帶著授權碼請求第三方資源服務器,第三方資源服務器會返回指定的URI(分享界面)。
  7. 用戶操作分享操作(填寫自己的話語),點擊分享按鈕完成。

在整個流程中,涉及的角色有:Resource Owner(用戶)、Resource Server、Client、Authorization Server。其中:
??認證的登錄界面是主服務器提供;
??用戶的最終操作界面(本例中為分享頁面),為第三方服務提供的界面(接口)。

【此處缺圖】

針對于用戶的授權,Oauth2.0提供了四種方式:

  • 授權碼模式(authorization code)
  • 簡化模式(implicit)
  • 密碼模式(resource owner password credentials)
  • 客戶端模式(client credentials)

因考慮到authorization code方式是最嚴謹、最廣泛、最貼近于服務器端的一種認證方式,所以只介紹著一種認證方式。

authorization code
適用場景:此類型可用于有服務端的應用,是最貼近老版本的方式。
【此處缺圖】

+--------+                               +---------------+
|        |--(A)- Authorization Request ->|   Resource    |
|        |                               |     Owner     |
|        |<-(B)-- Authorization Grant ---|               |
|        |                               +---------------+
|        |
|        |                               +---------------+
|        |--(C)-- Authorization Grant -->| Authorization |
| Client |                               |     Server    |
|        |<-(D)----- Access Token -------|               |
|        |                               +---------------+
|        |
|        |                               +---------------+
|        |--(E)----- Access Token ------>|    Resource   |
|        |                               |     Server    |
|        |<-(F)--- Protected Resource ---|               |
+--------+                               +---------------+

(A)用戶打開客戶端以后,客戶端要求用戶給予授權。
(B)用戶同意給予客戶端授權。
(C)客戶端使用上一步獲得的授權,向認證服務器申請令牌。
(D)認證服務器對客戶端進行認證以后,確認無誤,同意發放令牌。
(E)客戶端使用令牌,向資源服務器申請獲取資源。
(F)資源服務器確認令牌無誤,同意向客戶端開放資源。

說明:
Client Identifier是需要在第三方審核通過所得。
Redirection URI是成功之后,客戶端希望認證服務器跳轉到的頁面,一般來說,該頁面由客戶端提供。整個流程一共傳遞了兩次Redirection URI,是為了防止Authorization Code被別人獲取,而從第三方服務器端直接重定向。
其中access token是訪問調用第三方應用的憑證。因考慮到access token 的有效時長短,會有使用refresh token來(調用自定義接口)進行刷新并獲取新的access token。refresh token也可以有時效,一般設置為一個月。生成也很簡單,唯一的信息自定義轉碼方式即可生成。
state用于保持請求和回調的狀態,授權請求后原樣帶回給第三方。該參數可用于防止csrf攻擊(跨站請求偽造攻擊),建議第三方帶上該參數,可設置為簡單的隨機數加session進行校驗。
登錄操作是在第二步來完成的。認證服務器檢測到用戶未登錄,會跳轉到登錄頁面。


CAS講解

CAS只支持HTTPS協議。

共涉及角色有:CAS Client(下文提到的系統A等)、User、CAS Server(認證中心)。

【此處缺圖】

流程:
1)用戶訪問系統A;
2)系統A發現用戶沒有登錄,也沒有ticket,重定向到認證中心;有ticket跳轉 第7)步
3)認證中心發現用戶并未登錄,展示登錄頁面;
4)用戶登錄;
5)認證中心登錄成功,帶著生成的ticket,重定向到之前的系統A頁面;
6)系統A檢查登錄,還是未登錄,但存在ticket。系統A帶著ticket和認證中心進行校驗;
7)認證中心返回對應的用戶名;
8)系統A檢查返回的用戶名是否只有一個且不為空,若是,則返回給用戶指定的資源信息;若不是,則跳轉 第2)步

注意事項:

  1. 登錄狀態的判斷:子系統不可能每次都和認證中心進行校驗,所以需要有局部session。而認證中心生成的Session為全局Session。
  2. 登出:局部Session依附于全局Session,當全局Session注銷,局部Session也不存在;當局部Session被注銷(用戶登出),全局Session也不應該存在。
  3. 在重定向的過程中,如后續還需要二次重定向,需要獲取前端URL地址作為參數傳遞給第一次重定向的服務器。
  4. 在登錄了A系統后,服務端會存在一個TGT(ticket generated ticked),客戶端會存在一個TGC(ticket generated cookie)。TGT是票據生成票據。TGC內存了一個服務器上TGT的id。在登錄B系統時,服務器會查詢本地是否存在TGC,若存在,直接獲取該TGC。

CSRF

攻擊者盜用你的名義,執行操作。

image

從上圖可以看出,要完成一次CSRF攻擊,受害者必須依次完成兩個步驟:
1.登錄受信任網站A,并在本地生成Cookie。
2.在不登出A的情況下,訪問危險網站B。

Spring Security提供的結局方案是:Synchronizer Token Pattern


XSS

在你的頁面,(利用script的立即執行,)執行我想要執行的JS代碼。

本文中參考地址:
Oath2.0參考:微信API文檔OAuth的改變理解OAuth 2.0
CAS參考:CAS與SSO探究SSO CAS單點系列-慕課
CSRF參考:https://www.cnblogs.com/hyddd/archive/2009/04/09/1432744.html
XSS參考:http://netsecurity.51cto.com/art/201408/448305_all.htm

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。