Application Security Testing of the SAML protocol guidelines.

INTRODUCTION

The article describes the Application Security Testing of the SAML.
The advice in this article is based on the following:

• OWASP Web Security Testing Guide
• OWASP Application Security Verification Standard
• NIST recommendations
• Bug bounty reports
• Portswigger Academy
• Own experience.

TOOLING

Constantly update the tools.

BURP SUITE

Upgrade Burp Suite with the following extensions:

• EsPReSSO

• SAML Raider

RECON WORDLIST ENDPOINTS

/saml
/saml2
/saml/login
/saml2/login
/saml/auth
/saml2/auth
/saml/init
/saml2/init
/saml/consume
/saml2/consume
/simplesaml/module.php/core/loginuserpass.php
/simplesaml/saml2/idp

RECON WORDLIST PARAMETERS

AuthState
SAMLRequest
authenticity_token
SAMLResponse
RelayState

GUIDELINES

I. UNVERIFIED SIGNATURE

Modify the SAML response.

• The attackers can forge the ID data in the SAML response at will.

Implement the signature verification.

II. SIGNATURE STRIPPING

Modify the SAML response & remove the Signature.

• The attacker can remove the content of the signature tag or delete the whole signature to bypass the security measure.

Implement the signature verification.
Always verify the signature, even if there is no value.

III. PREDICTABLE SIGNATURE

Check if you can guess the signature.

• The attacker can forge a signature if the signing mechanism is weak or predictable.
• In the below example, the attacker could forge an assertion and obtain a valid session as an [email protected] user.

Ensure all SAML elements in the chain use strong encryption.
Consider deprecating support for insecure XMLEnc algorithms.

IV. DEFAULT KEY PAIR

Search the internet to find the secret key for the certificate in use.

• The attacker can forge messages if he knows the secret.

• It is handy to use an alias for fingerprinting the x509 certificates:

function fingerprint_x509() {
        openssl x509 -in "$1" -noout -fingerprint
}

Do not use the default key pair in the production environment.
Always generate new key pair and store the secret in a secure way.
Do not disclose the secret publicly.

V. CERTIFICATE REPLACEMENT

Inject a self-signed certificate and sign the assertion using it.

• The attacker can forge messages using self-signed certificates.

Service Provider should verify that a trusted Identity Provider signed the SAML.

VI. XML SIGNATURE WRAPPING (XSW)

Test for all eight XSW attacks using SAML Raider.

• The attacker can inject arbitrary content.

Validate the signature according to the OWASP Signature Validation.

VII. RESPONSE FORWARDING — TOKEN RECIPIENT CONFUSION

Swap the ServiceURL during login from SP1 to SP2.

• The attacker can get access to the forbidden service provider.
• For example, there are two applications (admin panel and sales).
• The attacker has access only to the sales page using normal SAML flow.
• Using the TRC technique, the attacker can change the ServiceURL to an admin panel during login to the sales application.

Service Provider should always validate the recipient value.

VIII. COMMENT INJECTION — REGISTRATION

Register the account with the comment and use the SSO.

• The attacker can hijack other users' accounts.

The detailed testing of the registration process was described in:

IX. COMMENT INJECTION — LOGIN

Register a similar account and use a comment to strip the part of it.

• The attacker can hijack other users’ accounts.

Use the canonicalized XML.

X. XXE INJECTION

Test for the XXE injection.

• Depending on the flaw found, the attacker could exploit Directory Listening, file reading, Server Side request forgery, or Denial of a Service attack.

<?xml version="1.0" encoding="UTF-8"?

Ensure that all SAML providers/consumers do proper input validation.
Disable DTD processing.

XI. XSLT INJECTION

Test for the XSLT injection.

• Depending on the flaw found, the attacker could exploit Directory Listening, file reading, Server Side request forgery, or Denial of a Service attack.

Ensure that all SAML providers/consumers do proper input validation.

XII. CREDENTIALS OVER AN UNENCRYPTED CHANNEL

Check if data is transferred via HTTP or as a parameter in the URL.

• Sensitive data may be logged by the browser, the web server, and forward or reverse proxy servers between the two endpoints.
• It could also be displayed on-screen, bookmarked, or emailed around by users.
• When any off-site links are followed, they may be disclosed to third parties via the Referer header.

Use a secure Hypertext Transfer Protocol (HTTPS).
Use an alternative mechanism for transmitting session tokens, such as HTTP cookies or hidden fields in forms that are submitted using the POST method.

XIII. PRE-ACCOUNT TAKEOVER

Register twice using SSO and with an email&password.

• The attacker could hijack an account that the user created with OAuth.
• The attacker could set a trap by registering an account using the victim’s email and waiting for the victim to log in using the OAuth method.

Email validation should be implemented.

XIV. OVERLONG EXPIRATION TIME

Check if the validation time is bigger than 5 minutes.

• The attacker could reuse the SAML Response Token.

The SAML Response Token should be rejected after 5 minutes.

XV. REUSABLE SAML Response Token

Check if you can use the same SAML Response Token twice.

• The attacker could reuse the SAML Response Token.

Each of the SAML Response Token should be single use only.

XVI. RACE CONDITION

Exchange one SAML Response Token for many session tokens.

• The malicious application could persistently maintain access to users despite deauthorizing the application.
• Creating Fake Followers, likes, and subscribers.
• Money loses in the case of single-use code coupons.

Only one SID should be gained in exchange for a single SAML Response Token .

XVII. FUZZING SAML PARAMETERS VALUES

Conduct the input validation testing in all SAML fields.

• The impact depends on the type of vulnerability detected.

payloads.txt - comprehensive wordlist for fuzzing.

Some payloads send the ICMP packets or TCP packets on port 80 when the payloads are triggered (if the potential vulnerabilities were found).

You need to start two listeners on your VPS to make them work:

Check the Input Validation Cheat Sheet from OWASP.

FINAL WORDS

The SAML protocol is not easy to implement, so ensure you do it properly.
I am sure that my article and the below references will help you do so:

• https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html
• https://workos.com/blog/fun-with-saml-sso-vulnerabilities-and-footguns
• https://www.securing.pl/en/saml-what-can-go-wrong-security-check/

Originally published at: https://karol-mazurek95.medium.com/appsec-tales-ix-oauth-5be70368ff9e