嘶吼RoarTalk|SAML IDP 签名密钥?,为什么我们需要多个


嘶吼RoarTalk|SAML IDP 签名密钥?,为什么我们需要多个
文章图片
SAML是一种目前应用非常广泛的单点登录协议 , 如果你运行SAML服务器并与许多其他站点集成 , 那么几乎可以肯定你使用的是不安全的设置 。 SAML安全面临的最大威胁不是怪异的XML边缘案例或黑客窃取你的签名密钥 , 而是低质量的第三方实现 , 这允许你的用户登录到你认为他们无法访问的应用程序 。 要确保SAML断言只适用于正确的应用程序 , 请为每个应用程序或服务提供者使用惟一的签名密钥 。
这个问题并不是SAML独有的 , 签名的JWT和其他SSO的使用(比如OIDC中的使用)也可能遇到类似的问题 , 即缺少令牌验证 。
SAML是如何工作的?
从较高的层次上讲 , SAML是一种登录用户的方式 , 它使用两个系统之间的浏览器内部通信 , 否则它们之间不能相互通信 。 当用户想要登录到他们最喜欢的SaaS时 , SaaS应用程序(SP或服务提供商)会将一些关于登录请求的数据发送到你的IDP 。 这包括诸如惟一请求ID和数据(如你试图访问的原始页面)之类的内容 。 理论上 , 身份验证请求可以指定IDP应该返回哪种类型的用户名和名称之类的字段 , 但实际上这会被忽略 。 这些请求也可以签名 , 但实际上在SP旋转其密钥时 , 大多数情况都会使事情中断 。 安全性几乎没有好处 , 因为在任何现代系统中 , SAML交换都是通过TLS进行的 。
嘶吼RoarTalk|SAML IDP 签名密钥?,为什么我们需要多个
文章图片
一旦你的IDP接收到身份验证请求 , IDP将验证你是否已登录(可能是密码、可能是客户端证书) , 然后签署一个断言 。 断言是SP将验证并用于登录你的内容 。 然后 , 你的IDP将此断言发送回SP 。 SP验证密码签名 , 验证该断言是否应该发送到特定的SP , 并提取相关的用户名和其他字段 。 现在 , 你可以看所有你想看的图片了!
那个签名秘钥听起来很吓人!你的本能可能是不惜一切代价保护该密钥 。 密钥值得保护 , 但是对你的SAMLIDP安全最大的可信威胁不是拥有你的SAML服务器的攻击者 。
攻击SAML的方法
攻击SAML的方法有很多!尽管独特的签名密钥可以解决其中的一些问题 , 但这并不是万能的 。
受众限制问题(Audiencerestrictionissue)
这是我在这篇文章中关注的问题 , 稍后我将更详细地讨论它 。 不出意料 , 惟一签名密钥解决了这类问题 。
IDP签名密钥被盗
确实 , 能够访问你的IDP的人可以获得签名密钥的副本 , 并以任何人的身份登录到与你集成的任何网站 。 如果这是你所关心的威胁 , 则仅提供签名预言的硬件支持的密钥是正确的防御措施 。
XML和XML安全库
如果可以的话 , 你应该使用一个内存安全的库 。 也就是说 , 这对第三方的断言验证没有实际影响 , 而且如果使用惟一签名密钥 , 你的安全状态也不会改变 。
XML处理问题
XML安全性是本世纪初出现的一种内联签名格式 , 当时没有人提出要求 , 需要它的人也更少 。 但用的人多了 , 问题就出现了 , 这些问题包括 , 忽略用户名中的XML注释、签名格式本身忽略对XML解析器有影响的注释 , 以及不检查你验证的签名是否实际覆盖了你信任的所有数据 。
你可以通过使用惟一的签名密钥来减小这些问题的影响范围 。 你只需要关心单个应用程序的内部权限 , 而不是允许用户登录任何与你集成的服务(授权与否) 。
嘶吼RoarTalk|SAML IDP 签名密钥?,为什么我们需要多个
文章图片
解决方案
嘶吼RoarTalk|SAML IDP 签名密钥?,为什么我们需要多个
文章图片
核心问题是缺乏受众限制验证 , 换句话说 , SP没有检查断言是否针对它 。 SAML的设计思想是你的IDP将只有一个签名密钥 , 你可以将它分发给与你集成的每个人 。 考虑到SAML的学术背景 , 它应该是一个合作协议 , 组织之间密切合作 。 现代企业SAML忽略了所有这些有趣的特性 , 因为它们是巨大的安全和配置噩梦 。