hacktricks/pentesting-web/saml-attacks/saml-basics.md

{% hint style="success" %}
Learn & practice AWS Hacking:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
Learn & practice GCP Hacking: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)

<details>

<summary>Support HackTricks</summary>

* Check the [**subscription plans**](https://github.com/sponsors/carlospolop)!
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Share hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.

</details>
{% endhint %}


# Visão Geral do SAML

**Security Assertion Markup Language (SAML)** permite que provedores de identidade (IdP) sejam utilizados para enviar credenciais de autorização para provedores de serviço (SP), facilitando o single sign-on (SSO). Essa abordagem simplifica a gestão de múltiplos logins ao permitir que um único conjunto de credenciais seja usado em vários sites. Ela utiliza XML para comunicação padronizada entre IdPs e SPs, vinculando a autenticação da identidade do usuário com a autorização do serviço.

## Comparação entre SAML e OAuth

- **SAML** é voltado para fornecer às empresas maior controle sobre a segurança do login SSO.
- **OAuth** é projetado para ser mais amigável para dispositivos móveis, usa JSON e é um esforço colaborativo de empresas como Google e Twitter.

# Fluxo de Autenticação SAML

**Para mais detalhes, consulte o post completo em [https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/](https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/)**. Este é um resumo:

O processo de autenticação SAML envolve várias etapas, conforme ilustrado no esquema:

![https://epi052.gitlab.io/notes-to-self/img/saml/saml-flow.jpg](https://epi052.gitlab.io/notes-to-self/img/saml/saml-flow.jpg)

1. **Tentativa de Acesso ao Recurso**: O usuário tenta acessar um recurso protegido.
2. **Geração da Solicitação SAML**: O SP não reconhece o usuário e gera uma Solicitação SAML.
3. **Redirecionamento para o IdP**: O usuário é redirecionado para o IdP, com a Solicitação SAML passando pelo navegador do usuário.
4. **IdP Recebe a Solicitação**: O IdP recebe a Solicitação SAML.
5. **Autenticação no IdP**: O IdP autentica o usuário.
6. **Validação do Usuário**: O IdP valida a legitimidade do usuário para acessar o recurso solicitado.
7. **Criação da Resposta SAML**: O IdP gera uma Resposta SAML contendo as afirmações necessárias.
8. **Redirecionamento para a URL ACS do SP**: O usuário é redirecionado para a URL do Serviço Consumidor de Afirmações (ACS) do SP.
9. **Validação da Resposta SAML**: O ACS valida a Resposta SAML.
10. **Acesso ao Recurso Concedido**: O acesso ao recurso inicialmente solicitado é concedido.

# Exemplo de Solicitação SAML

Considere o cenário em que um usuário solicita acesso a um recurso seguro em [https://shibdemo-sp1.test.edu/secure/](https://shibdemo-sp1.test.edu/secure/). O SP identifica a falta de autenticação e gera uma Solicitação SAML:
```
GET /secure/ HTTP/1.1
Host: shibdemo-sp1.test.edu
...
```
A solicitação SAML bruta se parece com isto:
```xml
<?xml version="1.0"?>
<samlp:AuthnRequest ...
</samlp:AuthnRequest>
```
Key elements of this request include:
- **AssertionConsumerServiceURL**: Especifica onde o IdP deve enviar a SAML Response após a autenticação.
- **Destination**: O endereço do IdP para o qual a solicitação é enviada.
- **ProtocolBinding**: Define o método de transmissão das mensagens do protocolo SAML.
- **saml:Issuer**: Identifica a entidade que iniciou a solicitação.

Following the SAML Request generation, the SP responds with a **302 redirect**, directing the browser to the IdP with the SAML Request encoded in the HTTP response's **Location** header. The **RelayState** parameter maintains the state information throughout the transaction, ensuring the SP recognizes the initial resource request upon receiving the SAML Response. The **SAMLRequest** parameter is a compressed and encoded version of the raw XML snippet, utilizing Deflate compression and base64 encoding.


# SAML Response Example

You can find a [full SAML response here](https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/). The key components of the response include:

- **ds:Signature**: Esta seção, uma Assinatura XML, garante a integridade e autenticidade do emissor da asserção. A SAML response no exemplo contém dois elementos `ds:Signature`, um para a mensagem e o outro para a asserção.
- **saml:Assertion**: Esta parte contém informações sobre a identidade do usuário e possivelmente outros atributos.
- **saml:Subject**: Especifica o sujeito principal de todas as declarações na asserção.
- **saml:StatusCode**: Representa o status da operação em resposta à solicitação correspondente.
- **saml:Conditions**: Detalha condições como o tempo de validade da Asserção e o Provedor de Serviço especificado.
- **saml:AuthnStatement**: Confirma que o IdP autenticou o sujeito da Asserção.
- **saml:AttributeStatement**: Contém atributos que descrevem o sujeito da Asserção.

Following the SAML Response, the process includes a 302 redirect from the IdP. This leads to a POST request to the Service Provider's Assertion Consumer Service (ACS) URL. The POST request includes `RelayState` and `SAMLResponse` parameters. The ACS is responsible for processing and validating the SAML Response.

After the POST request is received and the SAML Response is validated, access is granted to the protected resource initially requested by the user. This is illustrated with a `GET` request to the `/secure/` endpoint and a `200 OK` response, indicating successful access to the resource.


# XML Signatures

XML Signatures are versatile, capable of signing an entire XML tree or specific elements within it. They can be applied to any XML Object, not just Response elements. Below are the key types of XML Signatures:

### Basic Structure of XML Signature
An XML Signature consists of essential elements as shown:
```xml
<Signature>
<SignedInfo>
<CanonicalizationMethod />
<SignatureMethod />
<Reference>
<Transforms />
<DigestMethod />
<DigestValue />
</Reference>
...
</SignedInfo>
<SignatureValue />
<KeyInfo />
<Object />
</Signature>
```
Cada elemento `Reference` significa um recurso específico sendo assinado, identificável pelo atributo URI.

### Tipos de Assinaturas XML

1. **Assinatura Envelopada**: Este tipo de assinatura é um descendente do recurso que assina, significando que a assinatura está contida na mesma estrutura XML que o conteúdo assinado.

Exemplo:
```xml
<samlp:Response ... ID="..." ... >
...
<ds:Signature>
<ds:SignedInfo>
...
<ds:Reference URI="#...">
...
</ds:Reference>
</ds:SignedInfo>
</ds:Signature>
...
</samlp:Response>
```

Em uma assinatura envelopada, o elemento `ds:Transform` especifica que está envelopada através do algoritmo `enveloped-signature`.

2. **Assinatura Envelopante**: Contrastando com assinaturas envelopadas, assinaturas envelopantes envolvem o recurso sendo assinado.

Exemplo:
```xml
<ds:Signature>
<ds:SignedInfo>
...
<ds:Reference URI="#...">
...
</ds:Reference>
</ds:SignedInfo>
<samlp:Response ... ID="..." ... >
...
</samlp:Response>
</ds:Signature>
```

3. **Assinatura Destacada**: Este tipo é separado do conteúdo que assina. A assinatura e o conteúdo existem de forma independente, mas uma ligação entre os dois é mantida.

Exemplo:
```xml
<samlp:Response ... ID="..." ... >
...
</samlp:Response>
<ds:Signature>
<ds:SignedInfo>
...
<ds:Reference URI="#...">
...
</ds:Reference>
</ds:SignedInfo>
</ds:Signature>
```

Em conclusão, Assinaturas XML fornecem maneiras flexíveis de proteger documentos XML, com cada tipo atendendo a diferentes necessidades estruturais e de segurança.

## Referências
* [https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/](https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/)

{% hint style="success" %}
Learn & practice AWS Hacking:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
Learn & practice GCP Hacking: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)

<details>

<summary>Support HackTricks</summary>

* Check the [**subscription plans**](https://github.com/sponsors/carlospolop)!
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Share hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.

</details>
{% endhint %}