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