Ukranian - Ht
HackTricks Training Twitter Linkedin Sponsor

SAML Basics

Вивчайте хакінг AWS від нуля до героя з htARTE (HackTricks AWS Red Team Expert)!

Інші способи підтримки HackTricks:

Огляд 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/. Це короткий огляд:

Процес аутентифікації 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/. SP виявляє відсутність аутентифікації та генерує запит SAML:

GET /secure/ HTTP/1.1
Host: shibdemo-sp1.test.edu
...

Сировинний запит SAML виглядає наступним чином:

<?xml version="1.0"?>
<samlp:AuthnRequest ...
</samlp:AuthnRequest>

Ключові елементи цього запиту включають:

  • AssertionConsumerServiceURL: Вказує, куди IdP повинен надсилати відповідь SAML після аутентифікації.

  • Destination: Адреса IdP, на яку надсилається запит.

  • ProtocolBinding: Визначає метод передачі повідомлень протоколу SAML.

  • saml:Issuer: Визначає сутність, яка ініціювала запит.

Після генерації запиту SAML SP відповідає з 302 перенаправленням, спрямовуючи браузер до IdP з запитом SAML, закодованим у заголовку Location відповіді HTTP. Параметр RelayState зберігає інформацію про стан протягом транзакції, забезпечуючи, що SP впізнає початковий запит ресурсу при отриманні відповіді SAML. Параметр SAMLRequest - це стислена та закодована версія сирого XML уривка, використовуючи стиснення Deflate та кодування base64.

Приклад відповіді SAML

Ви можете знайти повну відповідь SAML тут. Основні компоненти відповіді включають:

  • ds:Signature: Цей розділ, підпис XML, забезпечує цілісність та автентичність видачі тверджень. Відповідь SAML у прикладі містить два елементи ds:Signature, один для повідомлення та інший для твердження.

  • saml:Assertion: Ця частина містить інформацію про ідентичність користувача та, можливо, інші атрибути.

  • saml:Subject: Вказує головну тему всіх висловлювань у твердженні.

  • saml:StatusCode: Представляє статус операції у відповідь на відповідний запит.

  • saml:Conditions: Деталізує умови, такі як часові рамки дії твердження та вказаний постачальник послуг.

  • saml:AuthnStatement: Підтверджує, що IdP аутентифікував суб'єкта твердження.

  • saml:AttributeStatement: Містить атрибути, що описують суб'єкт твердження.

Після відповіді SAML процес включає 302 перенаправлення від IdP. Це призводить до POST-запиту до URL Служби споживача тверджень (ACS) постачальника послуг. POST-запит включає параметри RelayState та SAMLResponse. ACS відповідає за обробку та перевірку відповіді SAML.

Після отримання POST-запиту та перевірки відповіді SAML надається доступ до захищеного ресурсу, який спочатку запитав користувач. Це показано за допомогою запиту GET до кінцевої точки /secure/ та відповіді 200 OK, що підтверджує успішний доступ до ресурсу.

Підписи XML

Підписи XML є універсальними, здатними підписувати весь XML-дерево або конкретні елементи всередині нього. Їх можна застосовувати до будь-якого об'єкта XML, а не лише елементів відповіді. Нижче наведено ключові типи підписів XML:

Основна структура підпису XML

Підпис XML складається з основних елементів, як показано:

<Signature>
<SignedInfo>
<CanonicalizationMethod />
<SignatureMethod />
<Reference>
<Transforms />
<DigestMethod />
<DigestValue />
</Reference>
...
</SignedInfo>
<SignatureValue />
<KeyInfo />
<Object />
</Signature>

Кожен елемент Reference позначає конкретний ресурс, який підписується, ідентифікований за атрибутом URI.

Типи XML-підписів

  1. Вкладений підпис: Цей тип підпису є нащадком ресурсу, який він підписує, що означає, що підпис міститься в тій же структурі XML, що і підписаний вміст.

Приклад:

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

У вкладеному підписі елемент ds:Transform вказує, що він є вкладеним за допомогою алгоритму enveloped-signature.

  1. Обгортковий підпис: У відмінності від вкладених підписів, обгорткові підписи обгортають підписуваний ресурс.

Приклад:

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

  1. Відокремлений підпис: Цей тип є окремим від вмісту, який він підписує. Підпис та вміст існують незалежно, але зберігається посилання між ними.

Приклад:

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

Загалом, XML-підписи надають гнучкі способи захисту XML-документів, кожен тип відповідає різним структурним та безпековим потребам.

Посилання

PreviousSAML AttacksNextServer Side Inclusion/Edge Side Inclusion Injection

Last updated