sign and/or encrypt SAML assetions, hack MITM

[Peter Schober]

jehan.procaccia at tem-tsp.eu <jehan.procaccia at tem-tsp.eu> [2024-02-21 10:35 CET]:
> we have a Service Provider who asked us not to encrypt SAML assertion in
> order for the SSO workflow to succeed
[...]
> However there is a serious security hack possible in that case, we can
> intercept the http flows with BURP as a proxy acting as a Man In The Middle
> by removing the signature xml elements

As you've noted, authenticity (the sender is legitimate) and integrity
(the message hasn't been tempered with) come from the IDP *signing*
the message.

> where did we missed something ?

The SP probably shouldn't accept unsigned assertions?

> 1) on the IDP (4) => force signed assertions , what is the default
> behaviour, where is it set ?

The IDP signs by default, but the SAML Response, not the Assertion
within the Response. Nothing to do here.

> 2) in the Metadata of the SP (/**WantAssertionsSigned="true") *

Again, this is actually telling the IDP "This SP has a bug and cannot
process signed Responses, please sign the Assertion instead".

Setting this it's not necessary to signal to the IDP "please sign, I
don't like to be sent SAML Responses/Assertions without any
authenticity/integrity at all" as that should be the norm, not
something you need explicit signalling for.

> 3) in the SP code implementation, it should verifiy the signature and hence
> sees that the NameID value modification by the MITM broke the signature.

Did you say you removed the signature? Nothing broken, then?

> Moreover, which certificate should sign ?

The key the IDP publishes for that purpose, usually via its metadata?

> A) it it up to the IDP to sign SAML with it's private key and SPs readding
> the IDP public key (from emtadata) verify the signature
> 
> B) or the IDP sign the assertion with the public key of the SP (from
> metadata again) and verify with it's private key ?

A. B is for encrypting data to the SP using the SP's public key.

> finnaly it is safe not to encrypt SAML assertions as long a
> signatures are well verified ?

I think you'll find that most would avoid making blanket statements
calling something "safe" (meaning "secure") within IT/cryptography.

Without a doubt encryption does make certain attacks on SAML WebSSO
(or XML-based protocols) more difficult and it will prevent other
kinds of attacks completely, AFAIK.

So definitively encrypting Responses/Assertions is safer/more secure,
it's widely supported (depending on whether you work more in
vendor-world or more in the open source or academic community) and
clearly the better choice -- assuming there even is a choice.
If the SP doesn't support it your only choice often comes down to not
using that SP's services. And whether that's an actual choice you have
possibly mostly depends on your relationship with your own management
and/or IT security / risk management team(s).

I have no numbers to back this up but I think almost everyone in this
community here will have encountered SPs that don't support encryption
at some point and will be (or has been) using them with encryption
turned off. I.e., I don't expect you'll find that management will
abstain from using/buying a certain service because the SAML SP
implementation involved doesn't support xmlenc.

HTH,
-peter