---

sso打法/手段思考

运营角度

sso 的建设、系统接入改造毕竟是需要成本的 既然目标使用了 sso 那么说明对很大程度上是说明有不小的公司规模

社工

1. 目标员工的在使用sso的账号通常要么为工号要么为员工姓名缩写甚至手机号
2. 可以从员工在互联网侧泄露的信息入手，例如微博、抖音、小红书、社工库，搜集目标公司人员的相关信息构造字典进一步利用

有意开白的接口

实际我接触的公司业务中的 sso，可能收敛了 oa 系统在 sso 后面，比如你访问 oa，自动 302 到 sso 系统 但是实际上该 oa 系统有不少 api 是单独开白访问的，不需要经过 sso

举个例子买的云上销售数据分析服务要从 oa 系统某个接口拉数据同步，它咋自动走 sso 认证？ 所以后台在 sso 配置中单独对该 oa 的部分路径比如 api，比如静态资源进行了放行

那么当攻击者对这些 api 接口的漏洞进行利用时，其实就是绕过了 sso 的认证撕开了口子

直接访问,直接 302 到 sso

访问开白的 api，不会被重定向到 sso

开发角度

从系统实现上看

前面提到了sso 的建设、系统接入改造是需要成本的 那么自建的情况下，开发人员往往是会从开源社区中寻求解决方案 比如比较成熟的，cas，或者 spring+shiro 这种形式,这种就是看框架漏洞利用面 如果纯自己实现那么可能就会出现各种奇奇怪怪的漏洞点

找回密码等功能点的逻辑漏洞

常规的注入、未授权访问、前端校验就和正常登录点一样测

多身份源

较大的企业，其 sso 系统登录时支持的认证来源也会比较丰富 这些不同渠道的认证账密也是一个利用的思路 比如你在内网域里，想控 sso，就可以通过拿域管账号的方式去控 sso

otp/mfa

除了手机验证码外，可能业务会自己开发 otp 的应用，甚至一键扫码进行登陆 往往自研的系统都搭配自研的 otp 应用 如果自研的 otp 应用本身安全性不到位，也会存在被攻击的点，比如攻击者反编译后伪造 token，或者重放 token

还有些终端的场景，比如控了机器，抓浏览器账号密码，发现有 mfa，有账号密码就是登录不了 这种情况可以尝试抓 cookie，通过 cookie 去调用 api 去关自己账号的 mfa，然后登录上去在自己绑定,完成敏感操作

钓鱼角度

跳转参数

很多sso是登录sso跳转到子站点的功能逻辑

例如如下跳转特定业务url

• https://sso.test.com/tologin?redirect=https://evil.com/

当redirect参数跳转url无校验时，我们可以将其改为自己的域名构造恶意链接钓鱼 从而获取目标的sso cookie，登陆特定业务

三方iam认证 钓鱼

sso 是需要存认证数据的，当企业人员规模特别大的时候，就会考虑一个叫 iam 的业务

可以这么理解，sso 负责登录、注册、密码找回这些具体功能点实现，iam 负责认证账号、密码这些具体数据 当然有的iam 业务做的比较大，sso 的功能都包了进去

常见的 iam 国内比如 authing、派拉、雪诺、竹云 国外就是 okta、auth0

一方面从这些厂商产品角度出发，可以挖掘厂商产品的漏洞 另一方面，企业员工在用这些第三方业务认证时常常会忘记密码，这时，忘记密码的邮件是由第三方业务的官方域名发给企业员工的邮箱或者 im 上的，这里就可以尝试购买与厂商类似的域名发钓鱼邮件

例如: authing,他本身发邮件用的域名就是 .co 官方的看上去都感觉像是钓鱼邮件的后缀

我找了个类似authing的域名，然后用ewomail进行搭建,格式如下，钓了波公司里的人，上钩率很高。

---

剩下几个案例就放个拓扑吧，具体图不放了,码不好打