mirror of
https://github.com/carlospolop/hacktricks
synced 2025-02-17 06:28:27 +00:00
164 lines
9.4 KiB
Markdown
164 lines
9.4 KiB
Markdown
<details>
|
||
|
||
<summary><strong>htARTE（HackTricks AWS Red Team Expert）</strong>を使って、ゼロからヒーローまでAWSハッキングを学びましょう！</summary>
|
||
|
||
HackTricksをサポートする他の方法：
|
||
|
||
- **HackTricksで企業を宣伝したい**または**HackTricksをPDFでダウンロードしたい**場合は、[**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)をチェックしてください！
|
||
- [**公式PEASS＆HackTricksスウェグ**](https://peass.creator-spring.com)を手に入れる
|
||
- [**The PEASS Family**](https://opensea.io/collection/the-peass-family)を発見し、独占的な[**NFTs**](https://opensea.io/collection/the-peass-family)のコレクションを見つける
|
||
- **💬 [Discordグループ](https://discord.gg/hRep4RUj7f)**に参加するか、[telegramグループ](https://t.me/peass)に参加するか、**Twitter**で私をフォローする🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)。
|
||
- **ハッキングトリックを共有するには、[HackTricks](https://github.com/carlospolop/hacktricks)と[HackTricks Cloud](https://github.com/carlospolop/hacktricks-cloud)のGitHubリポジトリにPRを提出してください。**
|
||
|
||
</details>
|
||
|
||
|
||
# SAML概要
|
||
|
||
**セキュリティアサーションマークアップ言語（SAML）**は、アイデンティティプロバイダー（IdP）がサービスプロバイダー（SP）に認証資格情報を送信するために利用され、シングルサインオン（SSO）を容易にします。このアプローチは、複数のログインの管理を簡素化し、複数のウェブサイトで1つの資格情報セットを使用できるようにします。ユーザーの認証とサービスの認可をリンクするために、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/)から完全な投稿を確認してください。** これは要約です：
|
||
|
||
SAML認証プロセスには、次のステップが関与します。スキーマで示されている通り：
|
||
|
||
|
||
|
||
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のAssertion Consumer Service（ACS）URLにリダイレクトされます。
|
||
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レスポンスを送信する場所を指定します。
|
||
- **Destination**: リクエストが送信されるIdPのアドレスです。
|
||
- **ProtocolBinding**: SAMLプロトコルメッセージの送信方法を定義します。
|
||
- **saml:Issuer**: リクエストを開始したエンティティを識別します。
|
||
|
||
SAMLリクエストの生成後、SPは**302リダイレクト**を返し、ブラウザをSAMLリクエストをHTTPレスポンスの**Location**ヘッダにエンコードしてIdPにリダイレクトします。**RelayState**パラメータはトランザクション全体で状態情報を維持し、SPがSAMLレスポンスを受け取った際に初期リソースリクエストを認識することを保証します。**SAMLRequest**パラメータは、生のXMLスニペットの圧縮およびエンコードされたバージョンであり、Deflate圧縮とbase64エンコーディングを使用します。
|
||
|
||
|
||
# SAMLレスポンスの例
|
||
|
||
[こちらで完全なSAMLレスポンスを見つけることができます](https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/)。レスポンスの主要なコンポーネントは次のとおりです：
|
||
|
||
- **ds:Signature**: このセクションはXML署名で、アサーションの発行者の整合性と信頼性を確保します。例のSAMLレスポンスには、メッセージ用とアサーション用の2つの`ds:Signature`要素が含まれています。
|
||
- **saml:Assertion**: この部分には、ユーザーのアイデンティティや他の属性に関する情報が含まれています。
|
||
- **saml:Subject**: アサーション内のすべてのステートメントの主題を指定します。
|
||
- **saml:StatusCode**: 対応するリクエストに対する操作のステータスを表します。
|
||
- **saml:Conditions**: アサーションの有効期間や指定されたサービスプロバイダのような条件の詳細を示します。
|
||
- **saml:AuthnStatement**: IdPがアサーションの主題を認証したことを確認します。
|
||
- **saml:AttributeStatement**: アサーションの主題を記述する属性を含みます。
|
||
|
||
SAMLレスポンスの後、プロセスにはIdPからの302リダイレクトが含まれます。これにより、サービスプロバイダのAssertion Consumer Service（ACS）URLに対するPOSTリクエストが行われます。POSTリクエストには`RelayState`および`SAMLResponse`パラメータが含まれます。ACSはSAMLレスポンスの処理と検証を担当します。
|
||
|
||
POSTリクエストを受信し、SAMLレスポンスが検証されると、ユーザーが最初にリクエストした保護されたリソースへのアクセスが許可されます。これは、`GET`リクエストを`/secure/`エンドポイントに対して行い、成功したリソースへのアクセスを示す`200 OK`レスポンスで示されます。
|
||
|
||
|
||
# XML署名
|
||
|
||
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構造内に含まれていることを意味します。
|
||
|
||
例：
|
||
```xml
|
||
<samlp:Response ... ID="..." ... >
|
||
...
|
||
<ds:Signature>
|
||
<ds:SignedInfo>
|
||
...
|
||
<ds:Reference URI="#...">
|
||
...
|
||
</ds:Reference>
|
||
</ds:SignedInfo>
|
||
</ds:Signature>
|
||
...
|
||
</samlp:Response>
|
||
```
|
||
|
||
封入署名では、`ds:Transform`要素が`enveloped-signature`アルゴリズムを介して封入されていることを指定します。
|
||
|
||
2. **包含署名**：封入署名とは対照的に、包含署名は署名されるリソースを包み込みます。
|
||
|
||
例：
|
||
```xml
|
||
<ds:Signature>
|
||
<ds:SignedInfo>
|
||
...
|
||
<ds:Reference URI="#...">
|
||
...
|
||
</ds:Reference>
|
||
</ds:SignedInfo>
|
||
<samlp:Response ... ID="..." ... >
|
||
...
|
||
</samlp:Response>
|
||
</ds:Signature>
|
||
```
|
||
|
||
3. **切り離し署名**：このタイプは、署名されるコンテンツとは別に存在します。署名とコンテンツは独立して存在しますが、両者の間にリンクが維持されます。
|
||
|
||
例：
|
||
```xml
|
||
<samlp:Response ... ID="..." ... >
|
||
...
|
||
</samlp:Response>
|
||
<ds:Signature>
|
||
<ds:SignedInfo>
|
||
...
|
||
<ds:Reference URI="#...">
|
||
...
|
||
</ds:Reference>
|
||
</ds:SignedInfo>
|
||
</ds:Signature>
|
||
```
|
||
|
||
結論として、XML署名は異なる構造とセキュリティのニーズを満たすために柔軟な方法を提供し、各タイプが異なる構造とセキュリティのニーズに対応しています。
|