Closed BerserkerGaruk closed 3 years ago
EncryptedAssertion
(https://github.com/Clever/saml2/pull/190/files#diff-b5c3ea129c38e0b1e9a5bf689ecee613219886637daefa4344e041c1385e9bfcR460-R464) and then validating them (https://github.com/Clever/saml2/pull/190/files#diff-b5c3ea129c38e0b1e9a5bf689ecee613219886637daefa4344e041c1385e9bfcR469-R502).Feel free to reopen if this isn't the case.
https://github.com/Clever/saml2/blob/3546cb61fd541f219abda364c5b919633609ef3d/lib/saml2.coffee#L608-L637
saml2.js line 806 in compiled npm.
In the case of a encrypted assertion when the server receives a saml token and calls post_assert() with the token, the saml assertions conditions are checked before the code attempts to run parse_authn_response() and decode the encryption.
As the code flow never returns to this section of the code(unless I am missing something) this can cause an invalid assertion to become accepted if the SP is able to decrypt the assertion. This also means that this library might be open to replay attacks with an old timestamp as this is checked before it decrypts the assertion.