KEMBAR78
SAML Security Cheatsheet | PDF
Scribd
Upload
189 views6 pages

SAML Security Cheatsheet

SAML Security Cheatsheet

Uploaded by

Rizki Kurniawan
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF or read online on Scribd
189 views6 pages

SAML Security Cheatsheet

SAML Security Cheatsheet

Uploaded by

Rizki Kurniawan
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF or read online on Scribd
You are on page 1/ 6
9725122, 6351 AM ‘SAML Securty - OWASP Cheat Sheet Series SAML Security Cheat Sheet Introduction ‘The Security Assertion Markup Language (SAML) is an open standard for exchanging authorization and authentication information. The Web Browser SAML/SSO Profile with Reditecl/POST bindings is one of the most common SSO implementation. This cheatsheet will focus primarily on that profile. Validate Message Confidentiality and Integrity TLS 1.2 isthe most common solution to guarantee message confidentiality and integity at the transport layer. Refer to SAML Security (section 4.2.1) for additional information. Thisstep 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 commen solution to quarantee message integity and authentication. Refer to SAML Security (section 4.3) for additional information. This step will help counter the following attacks: + Man-in-the-middle 6.4.2 + Forged Assertion6.43 ‘+ Message Modification 7.1.1.7 Assertions may be encrypted via XMLEnc to prevent disclosure of sensitive attributes post, transportation. Refer to SAML Security (section 4.2.2) for additional information. This step will help counter the follwing attacks: ‘© Theft of User Authentication Information 7.1.1.2 ‘ntps:ifcheatshectseries.owasp.orgicheatsheets/SAML_Securly_Cheat_Sheet.niml 168 9725122, 6351 AM ‘SAML Securty - OWASP Cheat Sheet Series Validate Protocol Usage This is acommon atea for security gaps - see Google SSO vulnerability for areal lfeexample. Their ‘SSO profile was vulnerable toa 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 nct 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 follawing data elements should be required: + AuthnRequest(ID, SP): An Authnkequest must contain and 10 and sP.Where 19 isa string uniquely identifying the request and an > identifies the Service Provider that initiated the request. Furthermore, the request 1D attributemust be retumed in the response (TokesponseTo="" ). ToResponseTo helps guarantee authenticity of the response from the trusted ldP. This was one of the missing attributes that eft Google's SSO wilnerable. ‘+ Response(ID, SP, liP, AA) K -1/IdP): A Response must contain all these elements. Where ID is a string uniquely identifying the response. s° identifies the recipient of the response. TaP identifies the identity provider authorizing the response. {AA} K -1/4P is the assertion digitally signed with the private key of the 14P. + AuthAssert(D, C, Id, SP): An authentication assertion must exist within the Response. Itmust contain an 1D, aclient (c) , an identity provider (14) , and a service provider (SP) identifier. Validate Signatures Vulnerabilities in SAML implementations due to XML Signature Wrapping attacks were described in 2012, On Breaking SAML: Be Whoever You Want to Be. The follewing recommendations were proposed in response (Secure SAMIL validation to prevent XML signature wrapping attacks) + Always perform schema validetion on the XMIL document prior to using it for any security related purposes: + Always use local, trusted copies of schemas for validation. + Never allow automatic download of schemas from thitd party locations. ‘If possible, inspect schemas and perform schema hardening, to disable possible wildcard type or relaxed processing statements. «Securely validate the digital signature: ‘ntps:ifcheatshectseries.owasp.orgicheatsheets/SAML_Securly_Cheat_Sheet.niml 216, 9725122, 6351 AM ‘SAML Securty - OWASP Cheat Sheet Series * Ifyou expect only one signing key, use StatickeySelector . Obtain the key directly from the identity provider, store tin local file andignore any Keytnfo eementsin the document. ‘* If you expect more than one signing key, use x589KeySelector (the JKS variant). Obtain these keys directly form the identity providers, store them in local JKS and ignore any keyInfo elements in the document. + Hyouexpect a heterogeneous signed documents (many certificates frommany dentity providers, multilevel validetion paths), implement full rust establishment model basedon PKIX and trusted roct certificates. + Avoid signature-wrapping attacks. + Never use getClenentsByTagNane to select security related elements nan XML document without prior validation «+ Always use absol.te XPath expressions to select elements, unless a hardened schemais used for validation. Validate Protocol Processing Rules This is ancther common area for security gaps simply because of the vast number of steps to assert. Processing a SAML responseis 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-he-middle (6.4.2) * Validate Response processing rules. Refer to SAML Profiles (4.1.43) for all Response processing rules. This step will hep counter the following attacks: + Stolen Assertion (6.4.1) = Manvin-the-middle (6.4.2) «Forged Assertion (6.4.3) + Browser State Exposure (6.4.4) Validate Binding Implementation ‘ntps:ifcheatshectseries.owasp.orgicheatsheets/SAML_Securly_Cheat_Sheet.niml 316, 9725122, 6351 AM ‘SAML Securty - OWASP Cheat Sheet Series * For anHTTP Redrect Binding refer to SAML Binding (3.4). To view an encodingexample, you may want to reference Requestltilava found within Google's reference implementation, © For an HTTP POST Binding refer to SAML Binding (3.5). The caching considerations ate also very important. Ifa SAML protocol message gets cached, ican subsequently be used as Stolen Assertion (6.4.1) or Replay (645) 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 considered 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 tothe section 4.1 3. Infact, ofall the SAML documentation, the technical overview is the most valuable from a high level perspective. Unsolicited Response (ie. IdP Initiated SSO) Considerations for Service Providers Unsolicited Response is inherently less secure by design due to the lack of CSRF protection. However, itis supported by many due to the backwards compatibility feature of SAML 1.1. The ‘ntps:ifcheatshectseries.owasp.orgicheatsheets/SAML_Securly_Cheat_Sheet.niml 46, 9725122, 6351 AM ‘SAML Securty - OWASP Cheat Sheet Series general security recommendation is tonot support this type of authentication, but if it must be enabled, the following steps (in additional to everything mentioned above) shouldhelp you secure this flow: + Follow the validation process mentioned in SAML Profiles (section 4.7.5), This step will help counter the following attacks: + Replay (6.1.2) ‘+ Message Insertion (6.13) « Ifthe contract of the Relaystate parameter is aURL, make sure the URL is validated and explicitly on an allow list. This step will help counter the following attack: ‘© Open Redirect ‘+ Implement proper replay detection either at the response or assertion level. This will help counter the following attack: + Replay (6.1.2) Identity Provider and Service Provider Considerations ‘The SAML protocol is rarely the vector of choice, though it's important to have cheatsheets to make sure that this is robust. The various endpoints are more targeted, so how the SAML token is generated and how it is consumed are both important in practice. Identity Provider (IdP) Considerations Validate X.509 Certificate for algorithm compatibility, strength of encryption, export restrictions '* Validate Strong Authentication options for generating the SAML token ‘+ IDP validation (which IDP mints the token) ‘+ Use/Trust Root CAs whenever possible + Synchronize to a common Internet timesource '* Define levels of assurance for identity verification + Prefer asymmetric identifiers for identity assertions over personally identifiable information (e.g. SSNs, etc) ‘+ Sign each individual Assertion or the entire Response element ‘ntps:ifcheatshectseries.owasp.orgicheatsheets/SAML_Securly_Cheat_Sheet.niml 56 9725122, 6351 AM ‘SAML Securty - OWASP Cheat Sheet Series ‘Service Provider (SP) Considerations + Validating session state for user Level of granularity in setting authorization context when consuming SAML token (do you use groups, roles, attributes) «+ Ensure each Assertion or the entire Response element is signed © Validate Signatures + Validate if signed by authorized IDP ‘* Validate IDP certificates for expiration and revocation against CRL/OCSP + Validate NotBefore and NotOnorAfter + Validate Recipient attribute ** Define criteria for SAML logout + Exchange assertions only over secure transports, «Define criteria for session management «Verify user identities obtained from SAML ticket assertions whenever possible. Input Validation Just becalise SAML is a security protocol does nat mean that input validation goes away. + Ensure that all SAML providers/consumers do proper input validation. Cryptography Solutions relying cryptographic algorithms need to follow the latest developments in cxyptoanalysis. «+ Ensue all SAML elements in the chain use strong encryption + Consider deprecating support for insecure XMLEne algorithms ‘ntps:ifcheatshectseries.owasp.orgicheatsheets/SAML_Securly_Cheat_Sheet.niml 66

You might also like