3.11.1 Protection From Assertion Injection Attacks

Before · SP 800-63C

After · SP 800-63C-4

Protection From Assertion Injection Attacks

Before · SP 800-63C

After · SP 800-63C-4

An assertion injection attack in the context of a federated protocol consists of an attacker attempting to force an RP to accept or process an assertion or assertion reference in order to gain access to the RP or deny a legitimate subscriber access to the RP. The attacker does this by taking an assertion or assertion reference and injecting it into a vulnerable RP. A successful attacker can trick an RP into binding the attacker’s session to the federated identifier in the assertion. The attacker’s assertion could be either stolen from a legitimate subscriber or manufactured to perpetrate the attack.

Protection from assertion injection attacks is recommended at all FALs and required at FAL2 and above. In all cases, the RP needs to take reasonable steps to prevent an attacker from presenting an injected assertion or assertion reference based on the nature of the RP software, the capabilities of the federation protocol in use, and the needs of the overall system. Both [OIDC] and [SAML] provide mechanisms for assertion injection protection, including nonces sent from the RP during the request, RP authentication for back-channel communications, and methods for the RP to start the federation transaction and track its state throughout the process. Different mechanisms provide different degrees of protection and are applicable in different circumstances. While the details of specific protections will vary based on the federation protocol and technology in use, common best practices can be used to limit the attack surface, such as:

• Back channel assertion presentation, which prevents an RP from accepting assertions outside of a direct response from the IdP (see Sec. 4.11.1 )
• Using an unguessable value to tie the unauthenticated session at the RP with the request to the back channel, which prevents an attacker from injecting an assertion reference from one session to another
• Requiring the RP to authenticate to the IdP during an assertion request to prevent the attacker from faking a request from the RP to begin a federation process
• Prohibiting IdP-initiated federation processes to prevent the RP from accepting unsolicited assertions and assertion references from the IdP, though this prohibition does not include processes in which an external party (e.g., the IdP or a federation authority) signals the RP to start a federation process with the IdP, allowing the RP to begin the federation transaction and securely await a response within that transaction
• Using a signed front channel response from the IdP with an RP-provided nonce covered by the signature, which prevents the attacker from injecting an assertion reference from one session to another
• Using platform APIs for front-channel communication, as opposed to HTTP redirects

Assertion injection attacks are particularly dangerous when combined with phishing attacks because the attacker can either trick the subscriber into generating a valid assertion for the attacker to inject into the attacker’s session, or the attacker can trick the subscriber into injecting the attacker’s assertion into the subscriber’s session at the RP.