This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "SAML Security Cheat Sheet"

From OWASP
Jump to: navigation, search
m (Validate Protocol Usage: typo)
m (Validate Protocol Processing Rules: typo)
Line 24: Line 24:
 
=Validate Protocol Processing Rules=
 
=Validate Protocol Processing Rules=
  
*This is another common area for security gaps simply because of the vast number of steps to assert. Processing a SAML response is an expensive operation but all steps must be validated.
+
This is another common area for security gaps simply because of the vast number of steps to assert. Processing a SAML response is an expensive operation but all steps must be validated.
Validate AuthnRequest processing rules. Refer to [http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf SAML Core] (3.4.1.4) for all AuthnRequest processing rules. This step will help counter the following attacks:
+
*Validate AuthnRequest processing rules. Refer to [http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf SAML Core] (3.4.1.4) for all AuthnRequest processing rules. This step will help counter the following attacks:
 
** Man-in-the-middle (6.4.2)
 
** Man-in-the-middle (6.4.2)
 
* Validate Response processing rules. Refer to [http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf SAML Profiles] (4.1.4.3) for all Response processing rules. This step will help counter the following attacks:
 
* Validate Response processing rules. Refer to [http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf SAML Profiles] (4.1.4.3) for all Response processing rules. This step will help counter the following attacks:

Revision as of 20:33, 9 June 2015

The Web Browser SSO Profile with Redirect/POST bindings is the most common SSO implementation. The checklist will focus primarily on this profile.

Validate Message Confidentiality and Integrity

  • TLS 1.2 is the most common solution to guarantee message confidentiality and integrity. Refer to SAML Security (section 4) for additional information. This step will help counter the following attacks:
    • Eavesdropping 7.1.1.1
    • Theft of User Authentication Information 7.1.1.2
    • Theft of the Bearer Token 7.1.1.3
    • Message Deletion 7.1.1.6
    • Message Modification 7.1.1.7
    • Man-in-the-middle 7.1.1.8
  • A digitally signed message with a certified key is the most common solution to guarantee message integrity and authentication. Refer to SAML Security (section 4) for additional information. This step will help counter the following attacks:
    • Man-in-the-middle 6.4.2
    • Forged Assertion 6.4.3

Validate Protocol Usage

This is a common area for security gaps - see Google SSO vulnerability (AVANTSSAR 2008) for a real life example. Their SSO profile was vulnerable to a Man-in-the-middle attack from a malicious SP (Service Provider). The SSO Web Browser Profile is most susceptible to attacks from trusted partners. This particular security flaw was exposed because the SAML Response did not contain all of the required data elements necessary for a secure message exchange. Following the SAML Profile usage requirements for AuthnRequest (4.1.4.1) and Response (4.1.4.2) will help counter this attack. The AVANTSSAR team suggested the following data elements should be required:

  • AuthnRequest(ID, SP); An AuthnRequest must contain and ID and SP. Where ID is a string uniquely identifying the request and an SP identifies the Service Provider that initiated the request. Furthermore, the request ID attribute must be returned in the response (InResponseTo="<requestId>"). InResponseTo helps guarantee authenticity of the response from the trusted IdP. This was one of the missing attributes that left Google's SSO vulnerable.
  • Response(ID, SP, IdP, {AA} K -1/IdP); A Response must contain all these elements. Where ID is a string uniquely identifying the response. SP identifies the recipient of the response. IdP identifies the identity provider authorizing the response. {AA} K -1/IdP is the assertion digitally signed with the private key of the IdP.
  • AuthAssert(ID, C, IdP, SP); An authentication assertion must exist within the Response. It must contain an ID, a client (C), an identity provider (IdP), and a service provider (SP) identifier.

Validate Protocol Processing Rules

This is another common area for security gaps simply because of the vast number of steps to assert. Processing a SAML response is an expensive operation but all steps must be validated.

  • Validate AuthnRequest processing rules. Refer to SAML Core (3.4.1.4) for all AuthnRequest processing rules. This step will help counter the following attacks:
    • Man-in-the-middle (6.4.2)
  • Validate Response processing rules. Refer to SAML Profiles (4.1.4.3) for all Response processing rules. This step will help counter the following attacks:
    • Stolen Assertion (6.4.1)
    • Man-in-the-middle (6.4.2)
    • Forged Assertion (6.4.3)
    • Browser State Exposure (6.4.4)

Validate Binding Implementation

  • For an HTTP Redirect Binding refer to SAML Binding (3.4). To view an encoding example, you may want to reference RequestUtil.java found within Google's reference implementation.
  • For an HTTP POST Binding refer to SAML Binding (3.5). The caching considerations are also very important. If a SAML protocol message gets cached, it can subsequently be used as a Stolen Assertion (6.4.1) or Replay (6.4.5) attack.

Validate Security Countermeasures

Revisit each security threat that exists within the SAML Security document and assert you have applied the appropriate countermeasures for threats that may exist for your particular implementation. Additional countermeasures considererd should include:

  • Prefer IP Filtering when appropriate. For example, this countermeasure could have prevented Google's initial security flaw if Google provided each trusted partner with a separate endpoint and setup an IP filter for each endpoint. This step will help counter the following attacks:
    • Stolen Assertion (6.4.1)
    • Man-in-the-middle (6.4.2)
  • Prefer short lifetimes on the SAML Response. This step will help counter the following attacks:
    • Stolen Assertion (6.4.1)
    • Browser State Exposure (6.4.4)
  • Prefer OneTimeUse on the SAML Response. This step will help counter the following attacks:
    • Browser State Exposure (6.4.4)
    • Replay (6.4.5)

Need an architectural diagram? The SAML technical overview contains the most complete diagrams. For the Web Browser SSO Profile with Redirect/POST bindings refer to the section 4.1.3. In fact, of all the SAML documentation, the technical overview is the most valuable from a high-level perspective.

Authors and Primary Editors

Other Cheatsheets

OWASP Cheat Sheets Project Homepage