- Você trabalha em uma **empresa de segurança cibernética**? Você quer ver sua **empresa anunciada no HackTricks**? ou você quer ter acesso à **última versão do PEASS ou baixar o HackTricks em PDF**? Confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
- 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** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo do Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo do telegram**](https://t.me/peass) ou **siga-me** no **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
- **Compartilhe suas técnicas de hacking enviando PRs para o [repositório hacktricks](https://github.com/carlospolop/hacktricks) e [hacktricks-cloud repo](https://github.com/carlospolop/hacktricks-cloud)**.
Security Assertion Markup Language (SAML) é um padrão aberto que permite que provedores de identidade (IdP) passem credenciais de autorização para provedores de serviços (SP). O que isso significa é que você pode **usar um conjunto de credenciais para fazer login em muitos sites diferentes**. É muito mais simples gerenciar um login por usuário do que gerenciar logins separados para e-mail, software de gerenciamento de relacionamento com o cliente (CRM), Active Directory, etc.
Transações SAML usam a Linguagem de Marcação Extensível (XML) para comunicações padronizadas entre o provedor de identidade e provedores de serviços. SAML é o link entre a autenticação da identidade do usuário e a autorização para usar um serviço. (De [aqui](https://www.varonis.com/blog/what-is-saml/))
OAuth é um padrão um pouco mais novo que foi co-desenvolvido pelo Google e Twitter para permitir logins na internet simplificados. OAuth usa uma metodologia semelhante ao SAML para compartilhar informações de login. **SAML fornece mais controle** às empresas para manter seus logins SSO mais seguros, enquanto **OAuth é melhor em dispositivos móveis e usa JSON**.
2. Passo 2 - O servidor onde esse recurso reside (Provedor de Serviços) não nos conhece, então ele gera uma **Solicitação SAML** para ser enviada ao Provedor de Identidade. Isso seria como chegar à Alemanha sem nosso passaporte e ser enviado de volta aos EUA para pegar nosso passaporte antes de poder entrar no país.
3. Passo 3 - Após gerar a Solicitação SAML, o SP **redireciona** para o IdP. Observação: A Solicitação SAML passa pelo nosso navegador a caminho do IdP.
4. Passo 4 - O IdP recebe a Solicitação SAML
5. Passo 4a (não ilustrado) - O IdP fornece algum meio de autenticação; um formulário de login ou algo semelhante.
6. Passo 4b (não ilustrado) - O IdP nos valida como um usuário legítimo que deve ser autorizado a acessar o recurso incluído como parte da Solicitação SAML
7. Passo 5 - O IdP cria uma **Resposta SAML**. A Resposta SAML contém as Afirmações SAML necessárias para o SP. A Afirmação geralmente inclui as seguintes informações no mínimo: Indicação de que a Afirmação é do IdP correto, um atributo **NameID** especificando quem é o usuário e uma assinatura digital. A Resposta SAML também passa pelo nosso navegador.
8. Passo 6 - O IdP **redireciona** para o URL do Serviço de Consumidor de Afirmação (ACS) do SP. O ACS é simplesmente o URL no qual o SP espera receber afirmações SAML.
9. Passo 7 - O ACS valida a Resposta SAML.
10. Passo 8 - Somos autorizados a acessar o recurso que solicitamos originalmente.
Vamos dar uma olhada mais de perto nos passos 2 e 3 descritos acima. Faremos uma solicitação ao Provedor de Serviços de exemplo para o recurso localizado em [https://shibdemo-sp1.test.edu/secure/](https://shibdemo-sp1.test.edu/secure/), que, como o nome indica, é conteúdo que requer autenticação para visualizar.
* **AssertionConsumerServiceURL**: Identifica para onde o IdP deve enviar a resposta SAML após a autenticação.
* **Destination**: Indica o endereço para o qual a solicitação deve ser enviada (IdP).
* **ProtocolBinding**: Normalmente acompanha o atributo AssertionConsumerServiceURL; define o mecanismo pelo qual as mensagens do protocolo SAML serão transmitidas.
* **saml:Issuer**: Identifica a entidade que gerou a mensagem de solicitação.
Acima, destacamos os elementos mais pertinentes da solicitação, mas detalhes sobre qualquer um dos outros elementos podem ser visualizados na [especificação principal](https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf). A solicitação acima é algo como: "Ei, por favor, autentique o usuário que me enviou esta mensagem e, em seguida, faça com que esse mesmo usuário entre em contato comigo quando vocês dois terminarem".
Com a solicitação SAML criada, o SP agora responde à nossa solicitação GET para `/secure/` com um **redirecionamento 302**. O 302 direciona nosso navegador para o IdP. A solicitação SAML é codificada no cabeçalho **Location** da resposta HTTP como parte do 302.
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>302 Found</title>
</head><body>
<h1>Found</h1>
<p>The document has moved <ahref="https://shibdemo-idp.test.edu/idp/profile/SAML2/Redirect/SSO?SAMLRequest=fZJdT4MwFIb%2FCuk9FNgmWzNIcLtwyXRkoBfemFKO0gRa7Cl%2B%2FHvZmDoTs8u2b5%2B350mXyNumY2lva7WH1x7QOh9to5AdD2LSG8U0R4lM8RaQWcHy9HbLQs9nndFWC90QJ0UEY6VWK62wb8HkYN6kgPv9Nia1tR0ySrGWZQWtdrELPDs0eVD1NB92S92ArT1ETQ%2FwkGa7vCDOeshIxQ%2Fcfyiy6n4pw4IOz3mWDZwQe6ikAWFpnu%2BIs1nH5ElUHKJgHk7mJV%2BI0I%2F4ZCZEJCK%2F9KdX3B9iiD1sFFqubExCP1i4%2FsQNwiL02WzKZvNH4mSnqa%2BlqqR6uayoHEPIbooic8exHsDgcaQhQJLlQTQ7Fpsz9Zex%2FNs3SS7bxR%2B7S3pWNLZ27G4gb9aZbqT4dNKm0e8rA9xCTAJCk%2FHK39%2BRfAE%3D&RelayState=ss%3Amem%3A39430bdac29d44586c326f12b4cb3345ffa47137a374e37cba0877e0fc79ea91">here</a>.</p>
<hr>
<address>Apache/2.2.3 (CentOS) Server at shibdemo-sp1.test.edu Port 443</address>
O parâmetro **RelayState** enviado juntamente com a solicitação SAML é uma informação de estado enviada pelo SP ao IdP para que o SP saiba quem solicitou inicialmente o recurso quando a resposta SAML retornar. A resposta SAML deve conter o mesmo valor de RelayState.
O parâmetro **SAMLRequest** é uma versão **comprimida** e **codificada** do mesmo trecho de xml bruto que vimos anteriormente. O SAML usa o algoritmo de compressão [Deflate](https://en.wikipedia.org/wiki/DEFLATE) e, em seguida, codifica o resultado em base64.
Vamos pular a parte em que o usuário se autentica no IdP e ir direto para as etapas 5 e 6 do que foi discutido no [Fluxo de Trabalho de Autenticação SAML](https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/#saml-authentication-workflow). Apenas tenha em mente que o que **vamos analisar acontece depois que o usuário se autentica no IdP.**
* **ds:Signature**: Uma [Assinatura XML](https://www.w3.org/TR/xmldsig-core1/#sec-KeyInfo) que protege a integridade e autentica o emissor da afirmação; a afirmação SAML PODE ser assinada, mas não é obrigatória. O exemplo acima contém dois elementos ds:Signature. A razão é que um é a assinatura da mensagem; o outro é a assinatura da afirmação.
* **saml:Assertion**: Contém informações sobre a identidade do usuário e potencialmente outros atributos do usuário.
* **saml:Subject**: Especifica o principal que é o assunto de todas as declarações na afirmação.
* **saml:StatusCode**: Um código que representa o status da atividade realizada em resposta à solicitação correspondente.
* **saml:Conditions**: Especifica coisas como o tempo em que uma afirmação é válida e que a afirmação é endereçada a um Provedor de Serviços específico.
* **saml:AuthnStatement**: Declara que o IdP autenticou o Sujeito da Afirmação.
* **saml:AttributeStatement**: Contém Atributos que descrevem o Sujeito da Afirmação.
O 302 leva-nos a fazer um pedido POST para o URL do Serviço de Consumidor de Afirmações do Provedor de Serviços. O corpo POST contém os parâmetros RelayState e SAMLResponse. Lembre-se de que o ACS processa e valida a Resposta SAML.
Estamos quase terminando de cobrir todos os conceitos básicos que precisamos para avançar para os testes reais! O último item que precisamos cobrir são as Assinaturas XML. Curiosamente, as Assinaturas XML podem ser usadas para **assinar uma árvore XML inteira ou elementos específicos** dentro da árvore. Já vimos anteriormente que duas Assinaturas XML separadas foram usadas em nosso exemplo de Resposta SAML. Cada assinatura foi responsável por uma parte diferente da Resposta. Nesta seção, veremos as diferentes maneiras pelas quais uma Assinatura XML pode ser incorporada a um documento XML. Algo a ser observado é que, embora nossos exemplos usem o elemento Response como o recurso a ser assinado, as Assinaturas XML podem ser aplicadas a qualquer objeto, incluindo elementos de Assertion.
De particular interesse para nós é que cada recurso a ser assinado tem seu próprio elemento Reference. O atributo URI do elemento Reference denota qual recurso é assinado por aquela assinatura específica. Ao examinarmos nosso exemplo anterior, podemos ver isso na prática.
O que vimos em nosso exemplo anterior é conhecido como uma **assinatura envelopada**. Uma assinatura envelopada é uma assinatura que é um descendente do recurso que está assinando. Podemos ver isso detalhado para nós no elemento ds:Transform do nosso exemplo.
Por fim, existem as **assinaturas desanexadas**. Uma assinatura desanexada não é nem envolvida nem é envolvida pelo recurso a ser assinado. Em vez disso, é completamente separada do recurso assinado.
A maior parte do conteúdo foi copiado de [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/)
- Você trabalha em uma **empresa de cibersegurança**? Você quer ver sua **empresa anunciada no HackTricks**? ou você quer ter acesso à **última versão do PEASS ou baixar o HackTricks em PDF**? Confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
- 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** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo do Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo do telegram**](https://t.me/peass) ou **siga-me** no **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
- **Compartilhe seus truques de hacking enviando PRs para o [repositório hacktricks](https://github.com/carlospolop/hacktricks) e [repositório hacktricks-cloud](https://github.com/carlospolop/hacktricks-cloud)**.
