In this lesson, we're going to talk about
attacks against the Security Assertion Markup Language,
also known as SAML.
SAML is an open standard for exchanging authentication
and authorization data between parties,
specifically between an identity provider
and a service provider.
SAML is widely used for single sign-on
to allow users to authenticate once
and access multiple applications without logging in again.
Just as a quick refresher,
here's how SAML works.
When you try to log in to a website
called the service provider
or SP from your browser,
the SP sends a request to a different service
that manages your login credentials
called the identity provider or IDP.
The IDP then checks if you are already logged in.
If not, it will ask you to enter your username and password.
Once you log in successfully,
the IDP creates a special message called an insertion
that says you are who you say you are.
This message is then sent back to the SP.
The SP then reads this message
and lets you access the website
without needing a separate login.
This whole process happens very quickly and securely,
making it easy for you to use different services
with just one login.
However this convenience also comes
with potential security risks that attackers can exploit.
First, let's look at a SAML token manipulation attack.
In a SAML token manipulation attack,
an attacker modifies the SAML token
to gain unauthorized access.
SAML tokens are XML-based
and contain assertions about
the user's identity and permissions.
If the tokens are not properly signed
or the signature validation is weak,
attackers can alter the token contents
to escalate privileges or impersonate another user.
A SAML request looks something like the following.
Here for example, an attacker might intercept a SAML token
and modify the user's role from user to advent.
If the service provider
does not properly validate the signature,
the attacker could then resound the token
with their own key.
For instance, we could use
a SAML manipulation tool like SAML Raider
which is a Burp Suite extension
To modify a token performing the following steps,
first, we will intercept a SAML response using Burp Suite.
Next, we will use SAML Raider to decode the token
and modify the necessary attributes
such as changing the role.
Last, we would then re-encode the token
and forward the request to the service provider.
To protect against SAML token manipulation,
we could advise our clients to always validate
the signature of the SAML token
using the identity provider's public key,
ensuring the integrity and confidentiality of SAML messages,
and to enforce strict XML validation.
Next, let's discuss SAML replay attacks.
In a SAML replay attack,
an attacker intercepts a valid token
and reuses it to gain unauthorized access.
This can happen if the service provider
does not properly check for token reuse
or does not set a token expiration time.
For example, an attacker might capture a SAML token
during a valid login session
and replay it to authenticate as the user.
The attacker captures a SAML token
using a tool like Wireshark.
After that, they then use the intercepted token
to make repeated requests to the service provider,
gaining unauthorized access without
needing the user's credentials.
To defend against SAML replay attacks,
we implement mechanisms such as using unique identifier
for each SAML token to detect
and reject replayed tokens.
We should also ensure tokens have short lifetimes.
Finally, let's look at SAML injection attacks.
In a SAML injection attack,
an attacker exploits vulnerabilities
in the application that processes SAML tokens.
By injecting malicious SAML data,
the attacker can manipulate the authentication process
to gain unauthorized access.
For example, an attacker could exploit
a vulnerable application's code,
combining user input into the SAML request
without proper validation.
The attacker could then inject malicious XML content
to alter the authentication logic.
For instance, imagine the application is programmed
to handle a SAML request like the following.
Here in this code,
we see that the user input variable is not sanitized
and that an attacker could inject
additional XML text to modify the request.
To defend against the SAML injection attacks,
always validate and sanitize user inputs,
use parameterized securities,
and enforce strict XML schema validation.
A corrected version of this code
will look something like the following.
Here we see the user input is first processed
by another function that's called StringEscapeUtilities
that strips away any illegal characters.
Then the result of the sanitation
is added to the SAML request,
making it safe for processing.
So remember SAML token manipulation attacks
involve modifying SAML tokens to escalate privileges,
SAML replay attacks use captured tokens
to gain unauthorized access,
and SAML injection attacks exploit
vulnerabilities in SAML processing.
Understanding these methods will help
you both defend against
and use these attacks in a penetration test.