When can the BFF ignore "SHOULD encrypt its cookie contents"?

[aaronpk]

From the AD review:

Section 6.1.3.2, para 4: '...the BFF SHOULD encrypt its cookie contents.' Why not a MUST? Under what circumstances would it be reasonable to ignore this SHOULD?

We should either change this to a MUST, or add a sentence justifying the SHOULD.

[aaronpk]

@philippederyck I'd appreciate your insights here

[philippederyck]

This is written as a SHOULD because it is not strictly necessary to benefit from the use of a BFF. The spec focuses on an attacker model where the attacker can control the client. Malware is "out of scope", since an attacker controlling the user's machine can also circumvent all the other protections of the BFF.

That said, there appears to be this common case where the malware mainly steals credentials, and then encryption could be helpful (to hide the tokens, not to prevent session hijacking). Whether you want to implement this or not depends on the sensitivity of the application.

Making this a MUST will make the BFF pattern (slightly) harder to implement, and might cause people to shy away from it.

Does this modified text help?

Additionally, when using client-side sessions that contain access tokens, (as opposed to server-side sessions where the tokens only live on the server), the BFF SHOULD encrypt its cookie contents. While the use of cookie encryption does not affect the security properties of the BFF pattern, it does ensure that tokens stored in cookies are never written to the user's hard drive in plaintext format. This security measure helps ensure the confidentiality of the tokens in case an attacker is able to read cookies from the hard drive. Such an attack can be launched through malware running on the victim's computer. Note that while encrypting the cookie contents prevents direct access to embedded tokens, it still allows the attacker to use the encrypted cookie in a session hijacking attack.

[randomstuff]

This security measure helps ensure the confidentiality of the tokens in case an attacker is able to read cookies from the hard drive. Such an attack can be launched through malware running on the victim's computer.

The attacker can be the user as well, bypassing any restriction on the protected resource requests imposed by the the client backend.

An alternative solution to client-side session encryption is to use sender(backend)-constrained tokens.

[aaronpk]

@randomstuff This is talking about storing tokens in cookies, not storing something like a user ID. The token should already be an opaque/signed/encrypted token that is resistant to user tampering. Besides, cookies can be signed instead of encrypted, and signed cookies are also protected against the user tampering with the cookie values intentionally.

[aaronpk]

@philippederyck thank you, I think that is a good addition, I'm going to add it now and respond to the AD review, thanks.