mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-01-10 12:13:17 -08:00
Translated ['src/README.md', 'src/banners/hacktricks-training.md', 'src/
This commit is contained in:
Translator
@@ -4,40 +4,39 @@
|
||||
|
||||
## API Gateway
|
||||
|
||||
### Basic Information
|
||||
### 基本情報
|
||||
|
||||
AWS API Gateway is a comprehensive service offered by Amazon Web Services (AWS) designed for developers to **create, publish, and oversee APIs on a large scale**. It functions as an entry point to an application, permitting developers to establish a framework of rules and procedures. This framework governs the access external users have to certain data or functionalities within the application.
|
||||
AWS API Gatewayは、開発者が**大規模にAPIを作成、公開、管理する**ために設計された、Amazon Web Services（AWS）が提供する包括的なサービスです。これはアプリケーションへの入り口として機能し、開発者がルールと手順のフレームワークを確立することを許可します。このフレームワークは、外部ユーザーがアプリケーション内の特定のデータや機能にアクセスする方法を管理します。
|
||||
|
||||
API Gateway enables you to define **how requests to your APIs should be handled**, and it can create custom API endpoints with specific methods (e.g., GET, POST, PUT, DELETE) and resources. It can also generate client SDKs (Software Development Kits) to make it easier for developers to call your APIs from their applications.
|
||||
API Gatewayは、**APIへのリクエストがどのように処理されるべきかを定義**することを可能にし、特定のメソッド（例：GET、POST、PUT、DELETE）とリソースを持つカスタムAPIエンドポイントを作成できます。また、開発者がアプリケーションからAPIを呼び出しやすくするためのクライアントSDK（ソフトウェア開発キット）を生成することもできます。
|
||||
|
||||
### API Gateways Types
|
||||
### API Gatewayの種類
|
||||
|
||||
- **HTTP API**: Build low-latency and cost-effective REST APIs with built-in features such as OIDC and OAuth2, and native CORS support. Works with the following: Lambda, HTTP backends.
|
||||
- **WebSocket API**: Build a WebSocket API using persistent connections for real-time use cases such as chat applications or dashboards. Works with the following: Lambda, HTTP, AWS Services.
|
||||
- **REST API**: Develop a REST API where you gain complete control over the request and response along with API management capabilities. Works with the following: Lambda, HTTP, AWS Services.
|
||||
- **REST API Private**: Create a REST API that is only accessible from within a VPC.
|
||||
- **HTTP API**: OIDCやOAuth2などの組み込み機能とネイティブCORSサポートを備えた、低遅延でコスト効果の高いREST APIを構築します。以下と連携します：Lambda、HTTPバックエンド。
|
||||
- **WebSocket API**: チャットアプリケーションやダッシュボードなどのリアルタイムユースケースのために、持続的な接続を使用してWebSocket APIを構築します。以下と連携します：Lambda、HTTP、AWSサービス。
|
||||
- **REST API**: リクエストとレスポンスを完全に制御できるREST APIを開発し、API管理機能を提供します。以下と連携します：Lambda、HTTP、AWSサービス。
|
||||
- **REST API Private**: VPC内からのみアクセス可能なREST APIを作成します。
|
||||
|
||||
### API Gateway Main Components
|
||||
### API Gatewayの主なコンポーネント
|
||||
|
||||
1. **Resources**: In API Gateway, resources are the components that **make up the structure of your API**. They represent **the different paths or endpoints** of your API and correspond to the various actions that your API supports. A resource is each method (e.g., GET, POST, PUT, DELETE) **inside each path** (/, or /users, or /user/{id}.
|
||||
2. **Stages**: Stages in API Gateway represent **different versions or environments** of your API, such as development, staging, or production. You can use stages to manage and deploy **multiple versions of your API simultaneousl**y, allowing you to test new features or bug fixes without affecting the production environment. Stages also **support stage variables**, which are key-value pairs that can be used to configure the behavior of your API based on the current stage. For example, you could use stage variables to direct API requests to different Lambda functions or other backend services depending on the stage.
|
||||
- The stage is indicated at the beggining of the URL of the API Gateway endpoint.
|
||||
3. **Authorizers**: Authorizers in API Gateway are responsible for **controlling access to your API** by verifying the identity of the caller before allowing the request to proceed. You can use **AWS Lambda functions** as custom authorizers, which allows you to implement your own authentication and authorization logic. When a request comes in, API Gateway passes the request's authorization token to the Lambda authorizer, which processes the token and returns an IAM policy that determines what actions the caller is allowed to perform. API Gateway also supports **built-in authorizers**, such as **AWS Identity and Access Management (IAM)** and **Amazon Cognito**.
|
||||
4. **Resource Policy**: A resource policy in API Gateway is a JSON document that **defines the permissions for accessing your API**. It is similar to an IAM policy but specifically tailored for API Gateway. You can use a resource policy to control who can access your API, which methods they can call, and from which IP addresses or VPCs they can connect. **Resource policies can be used in combination with authorizers** to provide fine-grained access control for your API.
|
||||
- In order to make effect the API needs to be **deployed again after** the resource policy is modified.
|
||||
1. **リソース**: API Gatewayにおけるリソースは、**APIの構造を構成する要素**です。これらは**APIの異なるパスやエンドポイント**を表し、APIがサポートするさまざまなアクションに対応します。リソースは各メソッド（例：GET、POST、PUT、DELETE）**の各パス内**（/、または/users、または/user/{id}）です。
|
||||
2. **ステージ**: API Gatewayのステージは、開発、ステージング、または本番など、APIの**異なるバージョンや環境**を表します。ステージを使用して、**APIの複数のバージョンを同時に管理および展開**でき、新機能やバグ修正を本番環境に影響を与えずにテストできます。ステージはまた、**ステージ変数**をサポートしており、現在のステージに基づいてAPIの動作を構成するために使用できるキーと値のペアです。たとえば、ステージ変数を使用して、ステージに応じてAPIリクエストを異なるLambda関数や他のバックエンドサービスに向けることができます。
|
||||
- ステージはAPI GatewayエンドポイントのURLの最初に示されます。
|
||||
3. **オーソライザー**: API Gatewayのオーソライザーは、リクエストが進行する前に呼び出し元のアイデンティティを確認することによって、**APIへのアクセスを制御する**役割を担います。**AWS Lambda関数**をカスタムオーソライザーとして使用でき、独自の認証および認可ロジックを実装できます。リクエストが来ると、API Gatewayはリクエストの認証トークンをLambdaオーソライザーに渡し、トークンを処理して呼び出し元が実行できるアクションを決定するIAMポリシーを返します。API Gatewayは、**AWS Identity and Access Management (IAM)**や**Amazon Cognito**などの**組み込みオーソライザー**もサポートしています。
|
||||
4. **リソースポリシー**: API Gatewayのリソースポリシーは、**APIへのアクセス権限を定義する**JSONドキュメントです。これはIAMポリシーに似ていますが、API Gateway専用に調整されています。リソースポリシーを使用して、誰がAPIにアクセスできるか、どのメソッドを呼び出せるか、どのIPアドレスやVPCから接続できるかを制御できます。**リソースポリシーはオーソライザーと組み合わせて使用することができ、APIに対する細かいアクセス制御を提供します。**
|
||||
- リソースポリシーが変更された後、APIは**再展開する必要があります**。
|
||||
|
||||
### Logging
|
||||
### ロギング
|
||||
|
||||
By default, **CloudWatch Logs** are **off**, **Access Logging** is **off**, and **X-Ray tracing** is also **off**.
|
||||
デフォルトでは、**CloudWatch Logs**は**オフ**、**アクセスロギング**は**オフ**、**X-Rayトレース**も**オフ**です。
|
||||
|
||||
### Enumeration
|
||||
### 列挙
|
||||
|
||||
> [!TIP]
|
||||
> Note that in both AWS apis to enumerate resources (**`apigateway`** and **`apigatewayv2`**) the only permission you need and the only read permission grantable is **`apigateway:GET`**, with that you can **enumerate everything.**
|
||||
> リソースを列挙するための両方のAWS API（**`apigateway`**および**`apigatewayv2`**）では、必要な唯一の権限であり、付与可能な唯一の読み取り権限は**`apigateway:GET`**です。これにより、**すべてを列挙できます。**
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="apigateway" }}
|
||||
|
||||
```bash
|
||||
# Generic info
|
||||
aws apigateway get-account
|
||||
@@ -78,11 +77,9 @@ aws apigateway get-usage-plan-key --usage-plan-id <plan_id> --key-id <key_id>
|
||||
###Already consumed
|
||||
aws apigateway get-usage --usage-plan-id <plan_id> --start-date 2023-07-01 --end-date 2023-07-12
|
||||
```
|
||||
|
||||
{{#endtab }}
|
||||
|
||||
{{#tab name="apigatewayv2" }}
|
||||
|
||||
```bash
|
||||
# Generic info
|
||||
aws apigatewayv2 get-domain-names
|
||||
@@ -124,49 +121,43 @@ aws apigatewayv2 get-models --api-id <id>
|
||||
## Call API
|
||||
https://<api-id>.execute-api.<region>.amazonaws.com/<stage>/<resource>
|
||||
```
|
||||
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
## Different Authorizations to access API Gateway endpoints
|
||||
## API Gateway エンドポイントにアクセスするための異なる認証
|
||||
|
||||
### Resource Policy
|
||||
### リソースポリシー
|
||||
|
||||
It's possible to use resource policies to define who could call the API endpoints.\
|
||||
In the following example you can see that the **indicated IP cannot call** the endpoint `/resource_policy` via GET.
|
||||
リソースポリシーを使用して、誰が API エンドポイントを呼び出すことができるかを定義することが可能です。\
|
||||
以下の例では、**指定された IP は** GET を介してエンドポイント `/resource_policy` を呼び出すことができません。
|
||||
|
||||
<figure><img src="../../../images/image (256).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### IAM Authorizer
|
||||
### IAM 認証
|
||||
|
||||
It's possible to set that a methods inside a path (a resource) requires IAM authentication to call it.
|
||||
パス内のメソッド（リソース）が呼び出すために IAM 認証を必要とするように設定することが可能です。
|
||||
|
||||
<figure><img src="https://lh3.googleusercontent.com/GGx-kfqNXu6zMqGidnO8_eR88fYPpJG-wNuBBnedAJntiRUEPTEScl7OvWthGYRiI_msYCdC6oBFvJc827Tb4-4UogxpOyrEXyst-8IDzP9DC2NOtXSY7w58L0baCAcBQjSyvBhJREvWWCtiboNYPSKuEw=s2048" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
When this is set you will receive the error `{"message":"Missing Authentication Token"}` when you try to reach the endpoint without any authorization.
|
||||
|
||||
One easy way to generate the expected token by the application is to use **curl**.
|
||||
これが設定されると、認証なしでエンドポイントにアクセスしようとすると、エラー `{"message":"Missing Authentication Token"}` が返されます。
|
||||
|
||||
アプリケーションが期待するトークンを生成する簡単な方法は、**curl** を使用することです。
|
||||
```bash
|
||||
$ curl -X <method> https://<api-id>.execute-api.<region>.amazonaws.com/<stage>/<resource> --user <AWS_ACCESS_KEY>:<AWS_SECRET_KEY> --aws-sigv4 "aws:amz:<region>:execute-api"
|
||||
```
|
||||
|
||||
Another way is to use the **`Authorization`** type **`AWS Signature`** inside **Postman**.
|
||||
別の方法は、**Postman**内で**`Authorization`**タイプ**`AWS Signature`**を使用することです。
|
||||
|
||||
<figure><img src="../../../images/image (168).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Set the accessKey and the SecretKey of the account you want to use and you can know authenticate against the API endpoint.
|
||||
|
||||
Both methods will generate an **Authorization** **header** such as:
|
||||
使用したいアカウントのaccessKeyとSecretKeyを設定すると、APIエンドポイントに対して認証できます。
|
||||
|
||||
どちらの方法も、次のような**Authorization** **header**を生成します:
|
||||
```
|
||||
AWS4-HMAC-SHA256 Credential=AKIAYY7XU6ECUDOTWB7W/20220726/us-east-1/execute-api/aws4_request, SignedHeaders=host;x-amz-date, Signature=9f35579fa85c0d089c5a939e3d711362e92641e8c14cc571df8c71b4bc62a5c2
|
||||
```
|
||||
他の場合では、**Authorizer**が**不適切にコーディング**されている可能性があり、**Authorizationヘッダー**内に**何でも**送信することで**隠されたコンテンツを見ることができる**かもしれません。
|
||||
|
||||
Note that in other cases the **Authorizer** might have been **bad coded** and just sending **anything** inside the **Authorization header** will **allow to see the hidden content**.
|
||||
|
||||
### Request Signing Using Python
|
||||
|
||||
### Pythonを使用したリクエスト署名
|
||||
```python
|
||||
|
||||
pip install requests
|
||||
@@ -193,111 +184,104 @@ response = requests.get(url, auth=awsauth)
|
||||
print(response.text)
|
||||
|
||||
```
|
||||
### カスタム Lambda 認証者
|
||||
|
||||
### Custom Lambda Authorizer
|
||||
|
||||
It's possible to use a lambda that based in a given token will **return an IAM policy** indicating if the user is **authorized to call the API endpoint**.\
|
||||
You can set each resource method that will be using the authoriser.
|
||||
与えられたトークンに基づいて、**IAM ポリシーを返す** Lambda を使用することが可能であり、ユーザーが **API エンドポイントを呼び出す権限があるかどうかを示します**。\
|
||||
認証者を使用する各リソースメソッドを設定できます。
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Lambda Authorizer Code Example</summary>
|
||||
|
||||
<summary>Lambda 認証者コード例</summary>
|
||||
```python
|
||||
import json
|
||||
|
||||
def lambda_handler(event, context):
|
||||
token = event['authorizationToken']
|
||||
method_arn = event['methodArn']
|
||||
token = event['authorizationToken']
|
||||
method_arn = event['methodArn']
|
||||
|
||||
if not token:
|
||||
return {
|
||||
'statusCode': 401,
|
||||
'body': 'Unauthorized'
|
||||
}
|
||||
if not token:
|
||||
return {
|
||||
'statusCode': 401,
|
||||
'body': 'Unauthorized'
|
||||
}
|
||||
|
||||
try:
|
||||
# Replace this with your own token validation logic
|
||||
if token == "your-secret-token":
|
||||
return generate_policy('user', 'Allow', method_arn)
|
||||
else:
|
||||
return generate_policy('user', 'Deny', method_arn)
|
||||
except Exception as e:
|
||||
print(e)
|
||||
return {
|
||||
'statusCode': 500,
|
||||
'body': 'Internal Server Error'
|
||||
}
|
||||
try:
|
||||
# Replace this with your own token validation logic
|
||||
if token == "your-secret-token":
|
||||
return generate_policy('user', 'Allow', method_arn)
|
||||
else:
|
||||
return generate_policy('user', 'Deny', method_arn)
|
||||
except Exception as e:
|
||||
print(e)
|
||||
return {
|
||||
'statusCode': 500,
|
||||
'body': 'Internal Server Error'
|
||||
}
|
||||
|
||||
def generate_policy(principal_id, effect, resource):
|
||||
policy = {
|
||||
'principalId': principal_id,
|
||||
'policyDocument': {
|
||||
'Version': '2012-10-17',
|
||||
'Statement': [
|
||||
{
|
||||
'Action': 'execute-api:Invoke',
|
||||
'Effect': effect,
|
||||
'Resource': resource
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
return policy
|
||||
policy = {
|
||||
'principalId': principal_id,
|
||||
'policyDocument': {
|
||||
'Version': '2012-10-17',
|
||||
'Statement': [
|
||||
{
|
||||
'Action': 'execute-api:Invoke',
|
||||
'Effect': effect,
|
||||
'Resource': resource
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
return policy
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
Call it with something like:
|
||||
呼び出すには、次のようにします：
|
||||
|
||||
<pre class="language-bash" data-overflow="wrap"><code class="lang-bash"><strong>curl "https://jhhqafgh6f.execute-api.eu-west-1.amazonaws.com/prod/custom_auth" -H 'Authorization: your-secret-token'
|
||||
</strong></code></pre>
|
||||
|
||||
> [!WARNING]
|
||||
> Depending on the Lambda code, this authorization might be vulnerable
|
||||
> Lambdaコードによっては、この認証が脆弱である可能性があります
|
||||
|
||||
Note that if a **deny policy is generated and returned** the error returned by API Gateway is: `{"Message":"User is not authorized to access this resource with an explicit deny"}`
|
||||
**拒否ポリシーが生成されて返される**場合、API Gatewayから返されるエラーは次のとおりです：`{"Message":"User is not authorized to access this resource with an explicit deny"}`
|
||||
|
||||
This way you could **identify this authorization** being in place.
|
||||
この方法で、**この認証**が存在することを**特定**できます。
|
||||
|
||||
### Required API Key
|
||||
### 必要なAPIキー
|
||||
|
||||
It's possible to set API endpoints that **require a valid API key** to contact it.
|
||||
**有効なAPIキー**が必要なAPIエンドポイントを設定することができます。
|
||||
|
||||
<figure><img src="../../../images/image (88).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
It's possible to generate API keys in the API Gateway portal and even set how much it can be used (in terms of requests per second and in terms of requests per month).
|
||||
API GatewayポータルでAPIキーを生成し、使用量（リクエスト毎秒およびリクエスト毎月の観点から）を設定することも可能です。
|
||||
|
||||
To make an API key work, you need to add it to a **Usage Plan**, this usage plan mus be added to the **API Stage** and the associated API stage needs to have a configured a **method throttling** to the **endpoint** requiring the API key:
|
||||
APIキーを機能させるには、**使用プラン**に追加する必要があります。この使用プランは**APIステージ**に追加され、関連するAPIステージにはAPIキーを必要とする**エンドポイント**に対して**メソッドスロットリング**が設定されている必要があります：
|
||||
|
||||
<figure><img src="../../../images/image (198).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
## Unauthenticated Access
|
||||
## 認証されていないアクセス
|
||||
|
||||
{{#ref}}
|
||||
../aws-unauthenticated-enum-access/aws-api-gateway-unauthenticated-enum.md
|
||||
{{#endref}}
|
||||
|
||||
## Privesc
|
||||
## 権限昇格
|
||||
|
||||
{{#ref}}
|
||||
../aws-privilege-escalation/aws-apigateway-privesc.md
|
||||
{{#endref}}
|
||||
|
||||
## Post Exploitation
|
||||
## ポストエクスプロイテーション
|
||||
|
||||
{{#ref}}
|
||||
../aws-post-exploitation/aws-api-gateway-post-exploitation.md
|
||||
{{#endref}}
|
||||
|
||||
## Persistence
|
||||
## 永続性
|
||||
|
||||
{{#ref}}
|
||||
../aws-persistence/aws-api-gateway-persistence.md
|
||||
{{#endref}}
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user