hacktricks/pentesting-web/saml-attacks/saml-basics.md

185 lines
11 KiB
Markdown
Raw Normal View History

{% 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)
2022-04-28 16:01:33 +00:00
<details>
2022-04-28 16:01:33 +00:00
<summary>Support HackTricks</summary>
2022-04-28 16:01:33 +00:00
* 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.
2022-04-28 16:01:33 +00:00
</details>
{% endhint %}
2022-04-28 16:01:33 +00:00
# SAML 概要
**Security Assertion Markup Language (SAML)** は、アイデンティティプロバイダー (IdP) がサービスプロバイダー (SP) に認証情報を送信するために利用され、シングルサインオン (SSO) を促進します。このアプローチは、複数のウェブサイトで単一の認証情報セットを使用できるようにすることで、複数のログインの管理を簡素化します。IdP と SP の間の標準化された通信のために XML を活用し、ユーザーのアイデンティティの認証とサービスの認可をリンクします。
## 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/) の完全な投稿を確認してください**。これは要約です:
2021-06-09 17:02:14 +00:00
SAML 認証プロセスは、スキーマに示されているように、いくつかのステップを含みます:
2021-06-09 17:02:14 +00:00
![https://epi052.gitlab.io/notes-to-self/img/saml/saml-flow.jpg](https://epi052.gitlab.io/notes-to-self/img/saml/saml-flow.jpg)
2021-06-09 17:02:14 +00:00
1. **リソースアクセスの試行**: ユーザーが保護されたリソースにアクセスしようとします。
2. **SAML リクエストの生成**: SP はユーザーを認識せず、SAML リクエストを生成します。
3. **IdP へのリダイレクト**: ユーザーは IdP にリダイレクトされ、SAML リクエストがユーザーのブラウザを通過します。
4. **IdP がリクエストを受信**: IdP は SAML リクエストを受信します。
5. **IdP での認証**: IdP はユーザーを認証します。
6. **ユーザーの検証**: IdP は要求されたリソースにアクセスするユーザーの正当性を検証します。
7. **SAML レスポンスの作成**: IdP は必要なアサーションを含む SAML レスポンスを生成します。
8. **SP の ACS URL へのリダイレクト**: ユーザーは SP のアサーションコンシューマサービス (ACS) URL にリダイレクトされます。
9. **SAML レスポンスの検証**: ACS は SAML レスポンスを検証します。
10. **リソースアクセスの許可**: 最初に要求されたリソースへのアクセスが許可されます。
2021-06-09 17:02:14 +00:00
# SAML リクエストの例
ユーザーが [https://shibdemo-sp1.test.edu/secure/](https://shibdemo-sp1.test.edu/secure/) で安全なリソースへのアクセスを要求するシナリオを考えてみましょう。SP は認証がないことを認識し、SAML リクエストを生成します:
```
2021-06-09 17:02:14 +00:00
GET /secure/ HTTP/1.1
Host: shibdemo-sp1.test.edu
...
2021-06-09 17:02:14 +00:00
```
生のSAMLリクエストは次のようになります
```xml
2021-06-09 17:02:14 +00:00
<?xml version="1.0"?>
<samlp:AuthnRequest ...
2021-06-09 17:02:14 +00:00
</samlp:AuthnRequest>
```
Key elements of this request include:
- **AssertionConsumerServiceURL**: IdPが認証後にSAMLレスポンスを送信すべき場所を指定します。
- **Destination**: リクエストが送信されるIdPのアドレス。
- **ProtocolBinding**: SAMLプロトコルメッセージの送信方法を定義します。
- **saml:Issuer**: リクエストを開始したエンティティを識別します。
2021-06-09 17:02:14 +00:00
SAMLリクエストの生成に続いて、SPは**302リダイレクト**で応答し、ブラウザをSAMLリクエストがHTTPレスポンスの**Location**ヘッダーにエンコードされているIdPに向けます。**RelayState**パラメータはトランザクション全体で状態情報を保持し、SPがSAMLレスポンスを受け取った際に最初のリソースリクエストを認識できるようにします。**SAMLRequest**パラメータは、生のXMLスニペットの圧縮およびエンコードされたバージョンで、Deflate圧縮とbase64エンコーディングを利用しています。
2021-06-09 17:02:14 +00:00
# SAML Response Example
2021-06-09 17:02:14 +00:00
You can find a [full SAML response here](https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/). The key components of the response include:
2021-06-09 17:02:14 +00:00
- **ds:Signature**: このセクションはXML署名で、アサーションの発行者の整合性と真正性を保証します。例のSAMLレスポンスには、メッセージ用とアサーション用の2つの`ds:Signature`要素が含まれています。
- **saml:Assertion**: この部分はユーザーのアイデンティティやその他の属性に関する情報を保持します。
- **saml:Subject**: アサーション内のすべてのステートメントの主要な主体を指定します。
- **saml:StatusCode**: 対応するリクエストに対する操作のステータスを表します。
- **saml:Conditions**: アサーションの有効性のタイミングや指定されたサービスプロバイダーなどの条件を詳細に説明します。
- **saml:AuthnStatement**: IdPがアサーションの主体を認証したことを確認します。
- **saml:AttributeStatement**: アサーションの主体を説明する属性を含みます。
2021-06-09 17:02:14 +00:00
SAMLレスポンスに続いて、プロセスにはIdPからの302リダイレクトが含まれます。これにより、サービスプロバイダーのアサーションコンシューマサービスACSURLへのPOSTリクエストが行われます。POSTリクエストには`RelayState`および`SAMLResponse`パラメータが含まれます。ACSはSAMLレスポンスの処理と検証を担当します。
2021-06-09 17:02:14 +00:00
POSTリクエストが受信され、SAMLレスポンスが検証されると、ユーザーが最初にリクエストした保護されたリソースへのアクセスが許可されます。これは`GET`リクエストを`/secure/`エンドポイントに送り、リソースへの成功したアクセスを示す`200 OK`レスポンスで示されます。
2021-06-09 17:02:14 +00:00
# XML Signatures
XML署名は多用途で、XMLツリー全体またはその中の特定の要素に署名することができます。レスポンス要素だけでなく、任意のXMLオブジェクトに適用できます。以下はXML署名の主要なタイプです。
### Basic Structure of XML Signature
XML署名は、以下のような基本要素で構成されています:
```xml
<Signature>
2023-07-07 23:42:27 +00:00
<SignedInfo>
<CanonicalizationMethod />
<SignatureMethod />
<Reference>
<Transforms />
<DigestMethod />
<DigestValue />
</Reference>
...
2023-07-07 23:42:27 +00:00
</SignedInfo>
<SignatureValue />
<KeyInfo />
<Object />
</Signature>
```
Each `Reference` element signifies a specific resource being signed, identifiable by the URI attribute.
### XML署名の種類
1. **包まれた署名**: このタイプの署名は、署名されるリソースの子孫であり、署名は署名されたコンテンツと同じXML構造内に含まれています。
例:
```xml
<samlp:Response ... ID="..." ... >
2023-07-07 23:42:27 +00:00
...
<ds:Signature>
<ds:SignedInfo>
...
<ds:Reference URI="#...">
2023-07-07 23:42:27 +00:00
...
</ds:Reference>
</ds:SignedInfo>
</ds:Signature>
...
</samlp:Response>
```
包まれた署名では、`ds:Transform`要素が`enveloped-signature`アルゴリズムを通じて包まれていることを指定します。
2. **包む署名**: 包まれた署名とは対照的に、包む署名は署名されるリソースを包みます。
例:
```xml
<ds:Signature>
2023-07-07 23:42:27 +00:00
<ds:SignedInfo>
...
<ds:Reference URI="#...">
2023-07-07 23:42:27 +00:00
...
</ds:Reference>
</ds:SignedInfo>
<samlp:Response ... ID="..." ... >
2023-07-07 23:42:27 +00:00
...
</samlp:Response>
</ds:Signature>
```
3. **分離署名**: このタイプは、署名するコンテンツとは別です。署名とコンテンツは独立して存在しますが、両者の間にはリンクが維持されます。
例:
```xml
<samlp:Response ... ID="..." ... >
2023-07-07 23:42:27 +00:00
...
</samlp:Response>
<ds:Signature>
2023-07-07 23:42:27 +00:00
<ds:SignedInfo>
...
<ds:Reference URI="#...">
2023-07-07 23:42:27 +00:00
...
</ds:Reference>
</ds:SignedInfo>
</ds:Signature>
```
2022-04-28 16:01:33 +00:00
結論として、XML署名はXML文書を保護するための柔軟な方法を提供し、各タイプは異なる構造的およびセキュリティニーズに応じています。
## 参考文献
* [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 %}