SAML Basics
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Мова маркування безпеки (SAML) дозволяє використовувати постачальників ідентичності (IdP) для надсилання облікових даних авторизації постачальникам послуг (SP), що полегшує одноразовий вхід (SSO). Цей підхід спрощує управління кількома входами, дозволяючи використовувати один набір облікових даних на кількох веб-сайтах. Він використовує XML для стандартизованого спілкування між IdP та SP, пов'язуючи аутентифікацію особи користувача з авторизацією послуг.
SAML орієнтований на надання підприємствам більшого контролю над безпекою входу SSO.
OAuth розроблений для більшої зручності використання на мобільних пристроях, використовує JSON і є спільною ініціативою таких компаній, як Google та Twitter.
Для отримання додаткової інформації перегляньте повну статтю за посиланням https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/. Це резюме:
Процес аутентифікації SAML включає кілька етапів, як показано на схемі:
Спроба доступу до ресурсу: Користувач намагається отримати доступ до захищеного ресурсу.
Генерація запиту SAML: SP не розпізнає користувача і генерує запит SAML.
Перенаправлення до IdP: Користувач перенаправляється до IdP, запит SAML проходить через браузер користувача.
IdP отримує запит: IdP отримує запит SAML.
Аутентифікація в IdP: IdP аутентифікує користувача.
Перевірка користувача: IdP перевіряє легітимність користувача для доступу до запитуваного ресурсу.
Створення відповіді SAML: IdP генерує відповідь SAML, що містить необхідні твердження.
Перенаправлення до URL ACS SP: Користувач перенаправляється до URL служби споживання тверджень (ACS) SP.
Перевірка відповіді SAML: ACS перевіряє відповідь SAML.
Доступ до ресурсу надано: Доступ до спочатку запитуваного ресурсу надано.
Розгляньте сценарій, коли користувач запитує доступ до захищеного ресурсу за адресою https://shibdemo-sp1.test.edu/secure/. SP виявляє відсутність аутентифікації та генерує запит SAML:
Сирийний SAML запит виглядає так:
Ключові елементи цього запиту включають:
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 тут. Ключові компоненти відповіді включають:
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 сервісу споживання асерцій (ACS) постачальника послуг. POST-запит включає параметри RelayState та SAMLResponse. ACS відповідає за обробку та валідацію SAML Response.
Після отримання POST-запиту та валідації SAML Response, доступ надається до захищеного ресурсу, спочатку запитаного користувачем. Це ілюструється запитом GET до кінцевої точки /secure/ та відповіддю 200 OK, що вказує на успішний доступ до ресурсу.
XML підписи є універсальними, здатними підписувати ціле XML-дерево або конкретні елементи в ньому. Їх можна застосовувати до будь-якого XML об'єкта, а не лише до елементів Response. Нижче наведені ключові типи XML підписів:
XML підпис складається з основних елементів, як показано:
Кожен Reference елемент позначає конкретний ресурс, що підписується, який можна ідентифікувати за атрибутом URI.
Enveloped Signature: Цей тип підпису є нащадком ресурсу, який він підписує, що означає, що підпис міститься в тій же XML структурі, що й підписаний контент.
Приклад:
У enveloped signature елемент ds:Transform вказує, що він обгорнутий через алгоритм enveloped-signature.
Enveloping Signature: На відміну від enveloped signatures, enveloping signatures обгортають ресурс, що підписується.
Приклад:
Detached Signature: Цей тип відокремлений від контенту, який він підписує. Підпис і контент існують незалежно, але між ними підтримується зв'язок.
Приклад:
На завершення, XML підписи забезпечують гнучкі способи захисту XML документів, кожен тип відповідає різним структурним і безпековим потребам.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
