sa-token/sa-token-doc/sso/sso-check-domain.md

3.1 KiB
Raw Blame History

SSO整合-配置域名校验


1、Ticket劫持攻击

在前面章节的 SSO-Server 示例中,配置项 sa-token.sso.allow-url=* 意为配置所有允许的Client端授权地址不在此配置项中的URL将无法单点登录成功

为了方便测试,上述代码将其配置为*,但是,在生产环境中,此配置项绝对不能配置为 * ,否则会有被 Ticket 劫持的风险

假设攻击者根据模仿我们的授权地址巧妙的构造一个URL

http://sa-sso-server.com:9000/sso/auth?redirect=https://www.baidu.com/

当不知情的小红被诱导访问了这个URL时它将被重定向至百度首页

sso-ticket-jc

可以看到,代表着用户身份的 Ticket 码也显现到了URL之中借此漏洞攻击者完全可以构建一个URL将小红的 Ticket 码自动提交到攻击者自己的服务器,伪造小红身份登录网站

2、防范方法

造成此漏洞的直接原因就是SSO-Server认证中心没有对 redirect地址 进行任何的限制,防范的方法也很简单,就是对redirect参数进行校验如果其不在指定的URL列表中时拒绝下放ticket

我们将其配置为一个具体的URL

sa-token: 
	sso: 
        # 配置允许单点登录的 url 
        allow-url: http://sa-sso-client1.com:9001/sso/login
# 配置允许单点登录的 url 
sa-token.sso.allow-url=http://sa-sso-client1.com:9001/sso/login

再次访问上述链接:

sso-feifa-rf

域名没有通过校验,拒绝授权!

3、配置安全性参考表

配置方式 举例 安全性 建议
配置为* * 禁止在生产环境下使用
配置到域名 http://sa-sso-client1.com/* 不建议在生产环境下使用
配置到详细地址 http://sa-sso-client1.com:9001/sso/login 可以在生产环境下使用

4、疑问为什么不直接回传 Token而是先回传 Ticket再用 Ticket 去查询对应的账号id

Token 作为长时间有效的会话凭证,在任何时候都不应该直接暴露在 URL 之中(虽然 Token 直接的暴露本身不会造成安全漏洞,但会为很多漏洞提供可乘之机)

为了不让系统安全处于亚健康状态Sa-Token-SSO 选择先回传 Ticket再由 Ticket 获取账号id且 Ticket 一次性用完即废,提高安全性。