mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-26 06:30:37 +00:00
185 lines
12 KiB
Markdown
185 lines
12 KiB
Markdown
{% 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 %}
|
||
|
||
|
||
# SAML Огляд
|
||
|
||
**Мова маркування безпеки (SAML)** дозволяє використовувати постачальників ідентичності (IdP) для надсилання облікових даних авторизації постачальникам послуг (SP), що полегшує одноразовий вхід (SSO). Цей підхід спрощує управління кількома входами, дозволяючи використовувати один набір облікових даних на кількох веб-сайтах. Він використовує XML для стандартизованого зв'язку між IdP та SP, пов'язуючи аутентифікацію особи користувача з авторизацією послуг.
|
||
|
||
## Порівняння між SAML та OAuth
|
||
|
||
- **SAML** орієнтований на надання підприємствам більшого контролю над безпекою входу SSO.
|
||
- **OAuth** розроблений для більшої зручності використання на мобільних пристроях, використовує JSON і є спільною ініціативою таких компаній, як Google та Twitter.
|
||
|
||
# Потік аутентифікації SAML
|
||
|
||
**Для отримання додаткової інформації перегляньте повну статтю за посиланням [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/)**. Це резюме:
|
||
|
||
Процес аутентифікації SAML включає кілька етапів, як показано на схемі:
|
||
|
||
|
||
|
||
1. **Спроба доступу до ресурсу**: Користувач намагається отримати доступ до захищеного ресурсу.
|
||
2. **Генерація запиту SAML**: SP не розпізнає користувача і генерує запит SAML.
|
||
3. **Перенаправлення до IdP**: Користувач перенаправляється до IdP, запит SAML проходить через браузер користувача.
|
||
4. **IdP отримує запит**: IdP отримує запит SAML.
|
||
5. **Аутентифікація в IdP**: IdP аутентифікує користувача.
|
||
6. **Перевірка користувача**: IdP перевіряє легітимність користувача для доступу до запитуваного ресурсу.
|
||
7. **Створення відповіді SAML**: IdP генерує відповідь SAML, що містить необхідні твердження.
|
||
8. **Перенаправлення до URL ACS SP**: Користувач перенаправляється до URL служби споживання тверджень (ACS) SP.
|
||
9. **Перевірка відповіді SAML**: ACS перевіряє відповідь SAML.
|
||
10. **Доступ до ресурсу надано**: Доступ до спочатку запитуваного ресурсу надано.
|
||
|
||
# Приклад запиту SAML
|
||
|
||
Розгляньте сценарій, коли користувач запитує доступ до захищеного ресурсу за адресою [https://shibdemo-sp1.test.edu/secure/](https://shibdemo-sp1.test.edu/secure/). SP виявляє відсутність аутентифікації та генерує запит SAML:
|
||
```
|
||
GET /secure/ HTTP/1.1
|
||
Host: shibdemo-sp1.test.edu
|
||
...
|
||
```
|
||
Сирийний SAML запит виглядає так:
|
||
```xml
|
||
<?xml version="1.0"?>
|
||
<samlp:AuthnRequest ...
|
||
</samlp:AuthnRequest>
|
||
```
|
||
Ключові елементи цього запиту включають:
|
||
- **AssertionConsumerServiceURL**: Вказує, куди IdP має надіслати SAML Response після аутентифікації.
|
||
- **Destination**: Адреса IdP, куди надсилається запит.
|
||
- **ProtocolBinding**: Визначає метод передачі повідомлень протоколу SAML.
|
||
- **saml:Issuer**: Ідентифікує суб'єкт, який ініціював запит.
|
||
|
||
Після генерації SAML Request, SP відповідає з **302 перенаправленням**, направляючи браузер до IdP з SAML Request, закодованим у заголовку **Location** HTTP-відповіді. Параметр **RelayState** підтримує інформацію про стан протягом транзакції, забезпечуючи, щоб SP розпізнав початковий запит ресурсу при отриманні SAML Response. Параметр **SAMLRequest** є стиснутою та закодованою версією сирцевого фрагмента XML, що використовує стиснення Deflate та кодування base64.
|
||
|
||
|
||
# Приклад SAML Response
|
||
|
||
Ви можете знайти [повний SAML response тут](https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/). Ключові компоненти відповіді включають:
|
||
|
||
- **ds:Signature**: Цей розділ, XML Signature, забезпечує цілісність та автентичність видавця асерції. SAML response в прикладі містить два елементи `ds:Signature`, один для повідомлення та інший для асерції.
|
||
- **saml:Assertion**: Ця частина містить інформацію про особу користувача та, можливо, інші атрибути.
|
||
- **saml:Subject**: Вказує основний суб'єкт усіх заяв у асерції.
|
||
- **saml:StatusCode**: Відображає статус операції у відповідь на відповідний запит.
|
||
- **saml:Conditions**: Деталізує умови, такі як терміни дійсності асерції та вказаного постачальника послуг.
|
||
- **saml:AuthnStatement**: Підтверджує, що IdP аутентифікував суб'єкта асерції.
|
||
- **saml:AttributeStatement**: Містить атрибути, що описують суб'єкта асерції.
|
||
|
||
Після SAML Response процес включає 302 перенаправлення від IdP. Це призводить до POST-запиту до URL-адреси Assertion Consumer Service (ACS) постачальника послуг. POST-запит включає параметри `RelayState` та `SAMLResponse`. ACS відповідає за обробку та валідацію SAML Response.
|
||
|
||
Після отримання POST-запиту та валідації SAML Response, доступ надається до захищеного ресурсу, спочатку запитаного користувачем. Це ілюструється запитом `GET` до кінцевої точки `/secure/` та відповіддю `200 OK`, що вказує на успішний доступ до ресурсу.
|
||
|
||
|
||
# XML Підписи
|
||
|
||
XML Підписи є універсальними, здатними підписувати ціле XML-дерево або конкретні елементи в ньому. Вони можуть бути застосовані до будь-якого XML-об'єкта, а не лише до елементів Response. Нижче наведені ключові типи XML Підписів:
|
||
|
||
### Основна структура XML Підпису
|
||
XML Підпис складається з основних елементів, як показано:
|
||
```xml
|
||
<Signature>
|
||
<SignedInfo>
|
||
<CanonicalizationMethod />
|
||
<SignatureMethod />
|
||
<Reference>
|
||
<Transforms />
|
||
<DigestMethod />
|
||
<DigestValue />
|
||
</Reference>
|
||
...
|
||
</SignedInfo>
|
||
<SignatureValue />
|
||
<KeyInfo />
|
||
<Object />
|
||
</Signature>
|
||
```
|
||
Кожен `Reference` елемент позначає конкретний ресурс, що підписується, який можна ідентифікувати за атрибутом URI.
|
||
|
||
### Типи XML підписів
|
||
|
||
1. **Enveloped Signature**: Цей тип підпису є нащадком ресурсу, який він підписує, що означає, що підпис міститься в тій же XML структурі, що й підписаний контент.
|
||
|
||
Приклад:
|
||
```xml
|
||
<samlp:Response ... ID="..." ... >
|
||
...
|
||
<ds:Signature>
|
||
<ds:SignedInfo>
|
||
...
|
||
<ds:Reference URI="#...">
|
||
...
|
||
</ds:Reference>
|
||
</ds:SignedInfo>
|
||
</ds:Signature>
|
||
...
|
||
</samlp:Response>
|
||
```
|
||
|
||
У enveloped signature елемент `ds:Transform` вказує, що він обгорнутий через алгоритм `enveloped-signature`.
|
||
|
||
2. **Enveloping Signature**: На відміну від enveloped signatures, enveloping signatures обгортають ресурс, що підписується.
|
||
|
||
Приклад:
|
||
```xml
|
||
<ds:Signature>
|
||
<ds:SignedInfo>
|
||
...
|
||
<ds:Reference URI="#...">
|
||
...
|
||
</ds:Reference>
|
||
</ds:SignedInfo>
|
||
<samlp:Response ... ID="..." ... >
|
||
...
|
||
</samlp:Response>
|
||
</ds:Signature>
|
||
```
|
||
|
||
3. **Detached Signature**: Цей тип відокремлений від контенту, який він підписує. Підпис і контент існують незалежно, але між ними підтримується зв'язок.
|
||
|
||
Приклад:
|
||
```xml
|
||
<samlp:Response ... ID="..." ... >
|
||
...
|
||
</samlp:Response>
|
||
<ds:Signature>
|
||
<ds:SignedInfo>
|
||
...
|
||
<ds:Reference URI="#...">
|
||
...
|
||
</ds:Reference>
|
||
</ds:SignedInfo>
|
||
</ds:Signature>
|
||
```
|
||
|
||
На завершення, XML підписи забезпечують гнучкі способи захисту XML документів, кожен тип відповідає різним структурним і безпековим потребам.
|
||
|
||
|
||
## References
|
||
* [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 %}
|