涉及内容: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
原理解释
场景:你在(登录后)浏览某论坛时,遇到了一篇好文章,想要分享给大家时,你需要登录(扫码或者登录用户名密码)第三方账户来完成分享。
基本流程:
- 在点击分享链接时,主服务器会直接(接口)请求第三方服务器,第三方服务器会校验主服务器上的用户此时是否授权给自己(第三方);
- 没有授权信息,用户登录(扫描或者密码)。
- 主服务器拿着用户的登录信息去第三方确认认证授权(密码是否正确、是否授权)。
- 认证失败,密码错误。(重新登录)
- 认证成功(确认授权),第三方认证服务会返回的授权码。
- 主服务器带着授权码请求第三方资源服务器,第三方资源服务器会返回指定的URI(分享界面)。
- 用户操作分享操作(填写自己的话语),点击分享按钮完成。
在整个流程中,涉及的角色有: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)步。
注意事项:
- 登录状态的判断:子系统不可能每次都和认证中心进行校验,所以需要有局部session。而认证中心生成的Session为全局Session。
- 登出:局部Session依附于全局Session,当全局Session注销,局部Session也不存在;当局部Session被注销(用户登出),全局Session也不应该存在。
- 在重定向的过程中,如后续还需要二次重定向,需要获取前端URL地址作为参数传递给第一次重定向的服务器。
- 在登录了A系统后,服务端会存在一个TGT(ticket generated ticked),客户端会存在一个TGC(ticket generated cookie)。TGT是票据生成票据。TGC内存了一个服务器上TGT的id。在登录B系统时,服务器会查询本地是否存在TGC,若存在,直接获取该TGC。
CSRF
攻击者盗用你的名义,执行操作。
从上图可以看出,要完成一次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。