一个先前提出的问题所涉及的主题非常类似于我所理解的东西。
在我正在测试的web应用程序中,SAML是使用Keycloak代理的。SAML响应消息包含加密断言(<saml:EncryptedAssertion>
)。在加密断言是签名(<dsig:Signature>
)之前;如果删除签名,SP仍然接受用户身份验证。
我可能缺少一些关于Keycloak代理身份验证方式的知识,或者SAML流本身,但是我似乎找不到任何关于这个在线的信息,除了上面的链接问题,这个问题仍然部分没有答案。
编辑:在我看到的SAML响应中附加一个示例:
<?xml version="1.0" encoding="UTF-8"?>
<samlp:Response Destination="https://example.com/saml/SSO"
ID="0000000-000-000-000-00000000"
InResponseTo="abc123abc123abc123"
IssueInstant="2020-06-29T00:00:0000Z" Version="2.0"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://sso.example.com/auth/realms/MY-APP</saml:Issuer>
<dsig:Signature xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
<dsig:SignedInfo>
<dsig:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<dsig:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
<dsig:Reference URI="#ID_0000000-000-000-000-00000000">
<dsig:Transforms>
<dsig:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<dsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</dsig:Transforms>
<dsig:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<dsig:DigestValue>/DATA=</dsig:DigestValue>
</dsig:Reference>
</dsig:SignedInfo>
<dsig:SignatureValue>DATA==</dsig:SignatureValue>
<dsig:KeyInfo>
<dsig:KeyName>AAAAAA-AAAAA-1234567987654321234567</dsig:KeyName>
<dsig:X509Data>
<dsig:X509Certificate>CERT==</dsig:X509Certificate>
</dsig:X509Data>
<dsig:KeyValue>
<dsig:RSAKeyValue>
<dsig:Modulus>DATA==</dsig:Modulus>
<dsig:Exponent>AAAA</dsig:Exponent>
</dsig:RSAKeyValue>
</dsig:KeyValue>
</dsig:KeyInfo>
</dsig:Signature>
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</samlp:Status>
<saml:EncryptedAssertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
<xenc:EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
<xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<xenc:EncryptedKey xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
<xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p"/>
<xenc:CipherData>
<xenc:CipherValue>DATA==</xenc:CipherValue>
</xenc:CipherData>
</xenc:EncryptedKey>
</ds:KeyInfo>
<xenc:CipherData>
<xenc:CipherValue>LONG_DATA==</xenc:CipherValue>
</xenc:CipherData>
</xenc:EncryptedData>
</saml:EncryptedAssertion>
</samlp:Response>
发布于 2020-06-30 23:11:59
也不完全理解Keycloak服务,但以下是SAML响应(IdP到SP)的基础,除非IdP同意自己做一些不同的事情:
因此,要实现MITM的内容替换,MITM必须有SP的公众。因此,除非SP在互联网上传播它的公钥,否则它只会被IdP和它自己看到。此外,SP需要跳过签名检查。同样,我没有看到任何库默认情况下会这样做。
但回到你的问题..。
原始加密内容对IdP (生成内容的人)和拥有is私钥的人是可见的
一定。根据协议,IdP在线发布其SAML2元数据,以便客户端验证签名。
任何未经签名的加密消息都是不可信任的。它不应被接受。
发布于 2020-07-01 10:05:34
由于您提到您正在测试此应用程序,我建议您再尝试两种方案。您已经注意到,签名没有被SP验证,因此有可能存在用于处理IdP响应的自定义代码。
我建议您还通过从IdP向服务提供商发送一个较旧的SAML响应来测试重放攻击。由于应用程序完全依赖于加密的消息,并且不检查完整性,所以有可能重放攻击是成功的。
另一种可能是尝试一个签名包装攻击。如果您知道最初的断言是什么样子的话,这将更容易执行。如果您可以访问该信息,则值得一试。这里的想法是在不改变原始断言的情况下在响应中添加另一个断言。在某些实现中,应用程序逻辑可能假定响应中始终存在一个断言块。通过这种方式,您可以在对用户进行身份验证时使用断言块来欺骗SP。
请参阅这篇关于XML签名包装攻击的文章。https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final91.pdf
https://security.stackexchange.com/questions/233957
复制相似问题