mirror of
https://github.com/carlospolop/hacktricks
synced 2024-12-26 13:03:37 +00:00
169 lines
8.6 KiB
Markdown
169 lines
8.6 KiB
Markdown
<details>
|
|
|
|
<summary><strong>Aprenda hacking AWS do zero ao herói com</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
|
|
|
Outras maneiras de apoiar o HackTricks:
|
|
|
|
* Se você deseja ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF** Confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
|
|
* Adquira o [**swag oficial PEASS & HackTricks**](https://peass.creator-spring.com)
|
|
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
|
|
* **Junte-se ao** 💬 [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-nos** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
|
* **Compartilhe seus truques de hacking enviando PRs para os** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repositórios do github.
|
|
|
|
</details>
|
|
|
|
|
|
# Visão Geral do SAML
|
|
|
|
A **Security Assertion Markup Language (SAML)** permite que provedores de identidade (IdP) sejam utilizados para enviar credenciais de autorização para provedores de serviços (SP), facilitando o logon único (SSO). Essa abordagem simplifica o gerenciamento de vários logins, permitindo 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** é direcionado a fornecer às empresas maior controle sobre a segurança de 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, confira a postagem completa 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:
|
|
|
|
|
|
|
|
1. **Tentativa de Acesso ao Recurso**: O usuário tenta acessar um recurso protegido.
|
|
2. **Geração de Solicitação SAML**: O SP não reconhece o usuário e gera uma Solicitação SAML.
|
|
3. **Redirecionamento para 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 de Resposta SAML**: O IdP gera uma Resposta SAML contendo as assertivas necessárias.
|
|
8. **Redirecionamento para a URL ACS do SP**: O usuário é redirecionado para a URL do Serviço de Consumidor de Assertivas (ACS) do SP.
|
|
9. **Validação da Resposta SAML**: O ACS valida a Resposta SAML.
|
|
10. **Acesso ao Recurso Concedido**: 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
|
|
...
|
|
```
|
|
O pedido SAML bruto se parece com isto:
|
|
```xml
|
|
<?xml version="1.0"?>
|
|
<samlp:AuthnRequest ...
|
|
</samlp:AuthnRequest>
|
|
```
|
|
Os principais elementos desta solicitação incluem:
|
|
- **AssertionConsumerServiceURL**: Especifica para onde o IdP deve enviar a Resposta SAML pós-autenticação.
|
|
- **Destination**: O endereço do IdP para o qual a solicitação é enviada.
|
|
- **ProtocolBinding**: Define o método de transmissão de mensagens do protocolo SAML.
|
|
- **saml:Issuer**: Identifica a entidade que iniciou a solicitação.
|
|
|
|
Após a geração da Solicitação SAML, o SP responde com um **redirecionamento 302**, direcionando o navegador para o IdP com a Solicitação SAML codificada no cabeçalho **Location** da resposta HTTP. O parâmetro **RelayState** mantém as informações de estado durante a transação, garantindo que o SP reconheça a solicitação de recurso inicial ao receber a Resposta SAML. O parâmetro **SAMLRequest** é uma versão comprimida e codificada do trecho XML bruto, utilizando compressão Deflate e codificação base64.
|
|
|
|
|
|
# Exemplo de Resposta SAML
|
|
|
|
Você pode encontrar uma [resposta SAML completa aqui](https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/). Os principais componentes da resposta incluem:
|
|
|
|
- **ds:Signature**: Esta seção, uma Assinatura XML, garante a integridade e autenticidade do emissor da declaração. A resposta SAML no exemplo contém dois elementos `ds:Signature`, um para a mensagem e outro para a declaraçã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 afirmaçã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 Declaração e o Provedor de Serviço especificado.
|
|
- **saml:AuthnStatement**: Confirma que o IdP autenticou o sujeito da Declaração.
|
|
- **saml:AttributeStatement**: Contém atributos que descrevem o sujeito da Declaração.
|
|
|
|
Após a Resposta SAML, o processo inclui um redirecionamento 302 do IdP. Isso leva a uma solicitação POST para o URL do Serviço de Consumidor de Declarações (ACS) do Provedor de Serviços. A solicitação POST inclui os parâmetros `RelayState` e `SAMLResponse`. O ACS é responsável por processar e validar a Resposta SAML.
|
|
|
|
Após receber a solicitação POST e validar a Resposta SAML, o acesso é concedido ao recurso protegido inicialmente solicitado pelo usuário. Isso é ilustrado com uma solicitação `GET` para o endpoint `/secure/` e uma resposta `200 OK`, indicando acesso bem-sucedido ao recurso.
|
|
|
|
|
|
# Assinaturas XML
|
|
|
|
As Assinaturas XML são versáteis, capazes de assinar uma árvore XML inteira ou elementos específicos dentro dela. Elas podem ser aplicadas a qualquer Objeto XML, não apenas elementos de Resposta. Abaixo estão os principais tipos de Assinaturas XML:
|
|
|
|
### Estrutura Básica da Assinatura XML
|
|
Uma Assinatura XML consiste nos elementos essenciais conforme mostrado:
|
|
```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, o que significa 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**: Em contraste com as assinaturas envelopadas, as 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 Separada**: Este tipo é separado do conteúdo que assina. A assinatura e o conteúdo existem independentemente, 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, as 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/)
|