mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-01-10 04:05:09 -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
|
||||
### Informations de base
|
||||
|
||||
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 est un service complet proposé par Amazon Web Services (AWS) conçu pour les développeurs afin de **créer, publier et superviser des API à grande échelle**. Il fonctionne comme un point d'entrée pour une application, permettant aux développeurs d'établir un cadre de règles et de procédures. Ce cadre régit l'accès que les utilisateurs externes ont à certaines données ou fonctionnalités au sein de l'application.
|
||||
|
||||
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 vous permet de définir **comment les requêtes à vos API doivent être traitées**, et il peut créer des points de terminaison API personnalisés avec des méthodes spécifiques (par exemple, GET, POST, PUT, DELETE) et des ressources. Il peut également générer des SDK clients (kits de développement logiciel) pour faciliter l'appel de vos API depuis leurs applications.
|
||||
|
||||
### API Gateways Types
|
||||
### Types de passerelles API
|
||||
|
||||
- **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** : Créez des API REST à faible latence et rentables avec des fonctionnalités intégrées telles que OIDC et OAuth2, et un support natif CORS. Fonctionne avec les éléments suivants : Lambda, backends HTTP.
|
||||
- **WebSocket API** : Créez une API WebSocket utilisant des connexions persistantes pour des cas d'utilisation en temps réel tels que des applications de chat ou des tableaux de bord. Fonctionne avec les éléments suivants : Lambda, HTTP, services AWS.
|
||||
- **REST API** : Développez une API REST où vous avez un contrôle total sur la requête et la réponse ainsi que sur les capacités de gestion de l'API. Fonctionne avec les éléments suivants : Lambda, HTTP, services AWS.
|
||||
- **REST API Privée** : Créez une API REST qui n'est accessible que depuis un VPC.
|
||||
|
||||
### API Gateway Main Components
|
||||
### Composants principaux de l'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. **Ressources** : Dans API Gateway, les ressources sont les composants qui **constituent la structure de votre API**. Elles représentent **les différents chemins ou points de terminaison** de votre API et correspondent aux différentes actions que votre API prend en charge. Une ressource est chaque méthode (par exemple, GET, POST, PUT, DELETE) **à l'intérieur de chaque chemin** (/, ou /users, ou /user/{id}).
|
||||
2. **Étapes** : Les étapes dans API Gateway représentent **différentes versions ou environnements** de votre API, tels que développement, staging ou production. Vous pouvez utiliser des étapes pour gérer et déployer **plusieurs versions de votre API simultanément**, vous permettant de tester de nouvelles fonctionnalités ou des corrections de bogues sans affecter l'environnement de production. Les étapes **supportent également les variables d'étape**, qui sont des paires clé-valeur pouvant être utilisées pour configurer le comportement de votre API en fonction de l'étape actuelle. Par exemple, vous pourriez utiliser des variables d'étape pour diriger les requêtes API vers différentes fonctions Lambda ou d'autres services backend en fonction de l'étape.
|
||||
- L'étape est indiquée au début de l'URL du point de terminaison de l'API Gateway.
|
||||
3. **Autoriseurs** : Les autoriseurs dans API Gateway sont responsables de **contrôler l'accès à votre API** en vérifiant l'identité de l'appelant avant de permettre à la requête de se poursuivre. Vous pouvez utiliser **des fonctions AWS Lambda** comme autoriseurs personnalisés, ce qui vous permet de mettre en œuvre votre propre logique d'authentification et d'autorisation. Lorsqu'une requête arrive, API Gateway passe le jeton d'autorisation de la requête à l'autoriseur Lambda, qui traite le jeton et renvoie une politique IAM qui détermine quelles actions l'appelant est autorisé à effectuer. API Gateway prend également en charge **des autoriseurs intégrés**, tels que **AWS Identity and Access Management (IAM)** et **Amazon Cognito**.
|
||||
4. **Politique de ressource** : Une politique de ressource dans API Gateway est un document JSON qui **définit les autorisations pour accéder à votre API**. Elle est similaire à une politique IAM mais spécifiquement adaptée à API Gateway. Vous pouvez utiliser une politique de ressource pour contrôler qui peut accéder à votre API, quelles méthodes ils peuvent appeler, et depuis quelles adresses IP ou VPCs ils peuvent se connecter. **Les politiques de ressource peuvent être utilisées en combinaison avec des autoriseurs** pour fournir un contrôle d'accès granulaire pour votre API.
|
||||
- Afin de prendre effet, l'API doit être **déployée à nouveau après** que la politique de ressource a été modifiée.
|
||||
|
||||
### Logging
|
||||
### Journalisation
|
||||
|
||||
By default, **CloudWatch Logs** are **off**, **Access Logging** is **off**, and **X-Ray tracing** is also **off**.
|
||||
Par défaut, **CloudWatch Logs** sont **désactivés**, **l'enregistrement des accès** est **désactivé**, et **le traçage X-Ray** est également **désactivé**.
|
||||
|
||||
### Enumeration
|
||||
### Énumération
|
||||
|
||||
> [!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.**
|
||||
> Notez que dans les deux APIs AWS pour énumérer les ressources (**`apigateway`** et **`apigatewayv2`**), la seule autorisation dont vous avez besoin et la seule autorisation de lecture accordable est **`apigateway:GET`**, avec cela vous pouvez **énumérer tout.**
|
||||
|
||||
{{#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
|
||||
## Différentes autorisations pour accéder aux points de terminaison de l'API Gateway
|
||||
|
||||
### Resource Policy
|
||||
### Politique de ressource
|
||||
|
||||
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.
|
||||
Il est possible d'utiliser des politiques de ressource pour définir qui peut appeler les points de terminaison de l'API.\
|
||||
Dans l'exemple suivant, vous pouvez voir que **l'IP indiquée ne peut pas appeler** le point de terminaison `/resource_policy` via GET.
|
||||
|
||||
<figure><img src="../../../images/image (256).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### IAM Authorizer
|
||||
### Autorisateur IAM
|
||||
|
||||
It's possible to set that a methods inside a path (a resource) requires IAM authentication to call it.
|
||||
Il est possible de définir qu'une méthode à l'intérieur d'un chemin (une ressource) nécessite une authentification IAM pour être appelée.
|
||||
|
||||
<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**.
|
||||
Lorsque cela est défini, vous recevrez l'erreur `{"message":"Missing Authentication Token"}` lorsque vous essayez d'atteindre le point de terminaison sans aucune autorisation.
|
||||
|
||||
Une façon simple de générer le jeton attendu par l'application est d'utiliser **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**.
|
||||
Une autre façon est d'utiliser le type **`Authorization`** **`AWS Signature`** à l'intérieur de **Postman**.
|
||||
|
||||
<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:
|
||||
Définissez l'accessKey et le SecretKey du compte que vous souhaitez utiliser et vous pouvez maintenant vous authentifier contre le point de terminaison de l'API.
|
||||
|
||||
Les deux méthodes généreront un **Authorization** **header** tel que :
|
||||
```
|
||||
AWS4-HMAC-SHA256 Credential=AKIAYY7XU6ECUDOTWB7W/20220726/us-east-1/execute-api/aws4_request, SignedHeaders=host;x-amz-date, Signature=9f35579fa85c0d089c5a939e3d711362e92641e8c14cc571df8c71b4bc62a5c2
|
||||
```
|
||||
|
||||
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**.
|
||||
Notez que dans d'autres cas, l'**Authorizer** pourrait avoir été **mal codé** et envoyer **quoi que ce soit** dans l'**Authorization header** permettra **de voir le contenu caché**.
|
||||
|
||||
### Request Signing Using Python
|
||||
|
||||
```python
|
||||
|
||||
pip install requests
|
||||
@@ -193,86 +184,83 @@ response = requests.get(url, auth=awsauth)
|
||||
print(response.text)
|
||||
|
||||
```
|
||||
|
||||
### 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.
|
||||
Il est possible d'utiliser une lambda qui, en fonction d'un token donné, **retournera une politique IAM** indiquant si l'utilisateur est **autorisé à appeler le point de terminaison de l'API**.\
|
||||
Vous pouvez définir chaque méthode de ressource qui utilisera l'autoriseur.
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Lambda Authorizer Code Example</summary>
|
||||
|
||||
<summary>Exemple de code de l'autoriseur 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:
|
||||
Appelez-le avec quelque chose comme :
|
||||
|
||||
<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
|
||||
> Selon le code Lambda, cette autorisation pourrait être vulnérable
|
||||
|
||||
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"}`
|
||||
Notez que si une **politique de refus est générée et renvoyée**, l'erreur renvoyée par API Gateway est : `{"Message":"User is not authorized to access this resource with an explicit deny"}`
|
||||
|
||||
This way you could **identify this authorization** being in place.
|
||||
De cette manière, vous pourriez **identifier cette autorisation** en place.
|
||||
|
||||
### Required API Key
|
||||
### Clé API requise
|
||||
|
||||
It's possible to set API endpoints that **require a valid API key** to contact it.
|
||||
Il est possible de définir des points de terminaison API qui **nécessitent une clé API valide** pour y accéder.
|
||||
|
||||
<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).
|
||||
Il est possible de générer des clés API dans le portail API Gateway et même de définir combien elles peuvent être utilisées (en termes de requêtes par seconde et en termes de requêtes par mois).
|
||||
|
||||
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:
|
||||
Pour faire fonctionner une clé API, vous devez l'ajouter à un **Plan d'utilisation**, ce plan d'utilisation doit être ajouté à l'**Étape API** et l'étape API associée doit avoir une **limitation de méthode** configurée pour le **point de terminaison** nécessitant la clé API :
|
||||
|
||||
<figure><img src="../../../images/image (198).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
## Unauthenticated Access
|
||||
## Accès non authentifié
|
||||
|
||||
{{#ref}}
|
||||
../aws-unauthenticated-enum-access/aws-api-gateway-unauthenticated-enum.md
|
||||
@@ -290,14 +278,10 @@ To make an API key work, you need to add it to a **Usage Plan**, this usage plan
|
||||
../aws-post-exploitation/aws-api-gateway-post-exploitation.md
|
||||
{{#endref}}
|
||||
|
||||
## Persistence
|
||||
## Persistance
|
||||
|
||||
{{#ref}}
|
||||
../aws-persistence/aws-api-gateway-persistence.md
|
||||
{{#endref}}
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user