SAML Raider入门指南

本文描述的所有攻击方法不需要很多工具就能够实现。不过通常情况下，Burp Suite的SAML Raider插件就能对常见情况进行测试。 [出自:jiwo.org]

检测

如前所述，签名可能出现在SAML消息中的不同位置并且覆盖消息的各个部分。通过保留消息内容，向其中增加新的内容，同时修改剩余部分的结构，我们可以构造出一个新的消息，从技术上讲这个新消息仍然是合法签名的，但是可能被SAML库解析为包含了已签名的关键内容，事实上这个关键内容并不存在。 每当服务提供方进行验证时，有一定的机率验证失败或者进行了不正确的验证，这都给了我们绕过签名验证的机会。打开Burp的拦截功能，捕获SAML请求，然后尝试对这些请求内容进行转换。每一次尝试都要根据一个新的、有效的登录动作来完成，因为通常会有一个Nonce阻止我们重复发送相同的请求。 对于重复测试，按照下面这样设置Burp的Proxy，更方便：

签名是否必需？

SAML标准要求所有经过非安全信道（如用户的浏览器）进行传输的消息都要有数字签名。不过，如果消息通过安全信道（如SSL/TLS反向通道）进行传输的话，签名就不是必需的。因此，我们发现SAML使用者在签名存在时，就进行验证；如果签名被删除，就跳过验证。软件基本上假设我们已经检查了来自非安全信道的消息已完成签名，然而并非如此。

所带来的影响是，我们能够直接删除签名，并篡改响应，就好像这里没有签名一样。SAML Raider插件可以很容易完成该测试。

签名是否得到验证？

XML签名的验证极其复杂，因为XML签名标准预期在签名验证之前会进行一系列的转换和规范化步骤（e.g.会忽略多余的空白符）。这使得如果没有一个功能齐全的XML签名库在背后做支撑，那么验证签名就极其困难。影响如下：

1.开发者并非普遍理解签名验证的原理；

2.一些中间组件，如web应用防火墙（WAF），不知道签名是否有效；

3.签名库可能存在一些配置选项，如允许的规范化方法列表，这些选项对开发者来说毫无意义。

实现签名标准很困难，并且签名标准自身也存在晦涩难解的特性，这就导致了我们现在看到的问题。 首先，测试一个签名是否有效是很简单的。改变已完成签名内容中的某些数据，看看是否导致中断。

签名是来自正确的签名者吗？

另外一个绊脚石就是接收方是否验证了签名者的身份。我们无法看到这一步是否正确，但是SAML Raider插件可以很轻松的做到。

将签名证书复制到SAML Raider的证书存储区：

保存之后对此证书进行自签名，所以现在我们便有了一个相同证书的自签名副本。

这时我们就可以使用这个自签名证书对原始请求进行再签名，可以对整个消息进行签名，或者只对签断言部分签名。

你能够辨别采用这两种选项那个更好，或者两种方式都试一下。

对响应的正确部分进行签名？

XSW攻击原理

SAML标准所允许的签名存在的位置仅有两处：

1.签名位于标签中，对标签及其子节点进行签名；

2.签名位于标签中，对标签及其子节点进行签名。

SAML标准对允许签名存在的位置以及允许被签名的内容都有具体的描述。

然而没有人为了使用SAML就完整地实现复杂的XML签名机制。该标准是通用的，标准的实现以及为此所开发的软件库也是如此。因此，就有了以下的“职责分离”：

1.XML签名库根据XML验证标准验证签名，它允许从任何地方签名任何内容；

2.SAML库期望XML签名库告诉它响应消息是否有效。

在两个组件之间往往缺少相关规则去规定哪些内容必须签名的。结果就是，我们经常可以对文档的不同部分进行签名，而在接收方看来签名依然有效。

通过复制文档的签名部分，并保证签名数据指向这些副本，我们可以将XML签名库验证的内容和SAML库需要的内容分开。

自动化进行XSW攻击

SAML Raider插件可以进行自动化攻击。

尝试下拉菜单中的每一个选项，点击“Apply XSW”发送请求数据。如果没有出现错误，就改变SAML XML中所有的用户名或者其他用户标识符然后重复这个动作。

SAML Raider的局限性

尽管SAML Raider插件可以对常见的情况进行测试，但我们仍然有必要对此进行更深层次的理解：

1.生成一个将针对XML Schema进行验证的响应（需要在可能包含xs:any的元素中隐藏影子副本（shadow copy))；

2.当Response和Assertion都被签名和验证时，如何绕过验证；

3.在非SAML上下文中绕过XML签名，如在使用WS-Security扩展的SOAP Endpoints中。

手动XSW

如果SAML Raider插件自带的选项都不起作用，你可以尝试手动测试方法：

1.对Base64编码的内容解码以获取SAML响应XML；

2.检查签名的标签是否包含被签名元素的ID；

3.复制文档中其他部分被签名的内容（一般情况下，放在标签的末尾是可以的；如果还要验证XML Schema，那就放在不会破坏XML Schema的位置）；

4.从XML签名中删除副本，将其保留在原始文档中。这是有必要的，因为XML封装签名标准去掉了将被验证的签名。在原始文档中，这就是所包含的签名，所以我们必须将其从副本中删除）；

5.改变原始签名内容的ID为其他值（如改变其中一个字母）；

6.改变原始断言的内容；

7.对以上内容重新进行Base64编码，将其放回请求中，然后再提交请求。

如果签名验证指向副本，那么你所做的上述改动将被忽略。在实际操作过程中，如果服务器严格限制了请求时间，你应该快速地完成这些步骤。

SAML渗透测试检查表

1.SAML响应通过浏览器了吗？

2.响应内容是否被签名了？如果没有签名，尝试改变其内容。

3.如果删除签名数据，响应内容是否被接受？

4.如果我们使用其他证书重新进行签名，响应内容是否被接受？

5.使用SAML Raider自带的8种转换方式生成的结果是否被接受？

6.如果你更改此类响应，更改后的响应是否被接受？

7.是否遇到了上文所述的SAML Raider的局限性？如果是，你需要尝试手动测试方法。