mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-31 23:15:48 -08:00
Translated ['src/README.md', 'src/banners/hacktricks-training.md', 'src/
This commit is contained in:
@@ -4,40 +4,39 @@
|
||||
|
||||
## API Gateway
|
||||
|
||||
### Basic Information
|
||||
### Informazioni di 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 è un servizio completo offerto da Amazon Web Services (AWS) progettato per gli sviluppatori per **creare, pubblicare e gestire API su larga scala**. Funziona come un punto di accesso a un'applicazione, consentendo agli sviluppatori di stabilire un insieme di regole e procedure. Questo insieme governa l'accesso che gli utenti esterni hanno a determinati dati o funzionalità all'interno dell'applicazione.
|
||||
|
||||
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 ti consente di definire **come le richieste alle tue API devono essere gestite**, e può creare endpoint API personalizzati con metodi specifici (ad es., GET, POST, PUT, DELETE) e risorse. Può anche generare SDK client (Software Development Kits) per facilitare agli sviluppatori la chiamata delle tue API dalle loro applicazioni.
|
||||
|
||||
### API Gateways Types
|
||||
### Tipi di 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**: Crea API REST a bassa latenza e costo efficace con funzionalità integrate come OIDC e OAuth2, e supporto nativo per CORS. Funziona con i seguenti: Lambda, backend HTTP.
|
||||
- **WebSocket API**: Crea un'API WebSocket utilizzando connessioni persistenti per casi d'uso in tempo reale come applicazioni di chat o dashboard. Funziona con i seguenti: Lambda, HTTP, Servizi AWS.
|
||||
- **REST API**: Sviluppa un'API REST dove hai il completo controllo sulla richiesta e sulla risposta insieme alle capacità di gestione delle API. Funziona con i seguenti: Lambda, HTTP, Servizi AWS.
|
||||
- **REST API Privata**: Crea un'API REST accessibile solo dall'interno di una VPC.
|
||||
|
||||
### API Gateway Main Components
|
||||
### Componenti principali di 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. **Risorse**: In API Gateway, le risorse sono i componenti che **costituiscono la struttura della tua API**. Rappresentano **i diversi percorsi o endpoint** della tua API e corrispondono alle varie azioni che la tua API supporta. Una risorsa è ogni metodo (ad es., GET, POST, PUT, DELETE) **all'interno di ogni percorso** (/, o /users, o /user/{id}).
|
||||
2. **Fasi**: Le fasi in API Gateway rappresentano **diverse versioni o ambienti** della tua API, come sviluppo, staging o produzione. Puoi utilizzare le fasi per gestire e distribuire **più versioni della tua API simultaneamente**, consentendoti di testare nuove funzionalità o correzioni di bug senza influenzare l'ambiente di produzione. Le fasi supportano anche **variabili di fase**, che sono coppie chiave-valore che possono essere utilizzate per configurare il comportamento della tua API in base alla fase attuale. Ad esempio, potresti utilizzare variabili di fase per indirizzare le richieste API a diverse funzioni Lambda o altri servizi backend a seconda della fase.
|
||||
- La fase è indicata all'inizio dell'URL dell'endpoint di API Gateway.
|
||||
3. **Autenticatori**: Gli autenticatori in API Gateway sono responsabili di **controllare l'accesso alla tua API** verificando l'identità del chiamante prima di consentire la continuazione della richiesta. Puoi utilizzare **funzioni AWS Lambda** come autenticatori personalizzati, il che ti consente di implementare la tua logica di autenticazione e autorizzazione. Quando arriva una richiesta, API Gateway passa il token di autorizzazione della richiesta all'autenticatore Lambda, che elabora il token e restituisce una policy IAM che determina quali azioni il chiamante è autorizzato a eseguire. API Gateway supporta anche **autenticatori integrati**, come **AWS Identity and Access Management (IAM)** e **Amazon Cognito**.
|
||||
4. **Policy delle risorse**: Una policy delle risorse in API Gateway è un documento JSON che **definisce le autorizzazioni per accedere alla tua API**. È simile a una policy IAM ma specificamente adattata per API Gateway. Puoi utilizzare una policy delle risorse per controllare chi può accedere alla tua API, quali metodi possono chiamare e da quali indirizzi IP o VPC possono connettersi. **Le policy delle risorse possono essere utilizzate in combinazione con gli autenticatori** per fornire un controllo degli accessi dettagliato per la tua API.
|
||||
- Per rendere effettiva la modifica, l'API deve essere **ridistribuita dopo** che la policy delle risorse è stata modificata.
|
||||
|
||||
### Logging
|
||||
### Registrazione
|
||||
|
||||
By default, **CloudWatch Logs** are **off**, **Access Logging** is **off**, and **X-Ray tracing** is also **off**.
|
||||
Per impostazione predefinita, **CloudWatch Logs** sono **disattivati**, **Access Logging** è **disattivato**, e **X-Ray tracing** è anch'esso **disattivato**.
|
||||
|
||||
### Enumeration
|
||||
### Enumerazione
|
||||
|
||||
> [!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.**
|
||||
> Nota che in entrambe le API AWS per enumerare le risorse (**`apigateway`** e **`apigatewayv2`**) l'unico permesso di cui hai bisogno e l'unico permesso di lettura concessibile è **`apigateway:GET`**, con quello puoi **enumerare tutto.**
|
||||
|
||||
{{#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
|
||||
## Diverse autorizzazioni per accedere agli endpoint di API Gateway
|
||||
|
||||
### Resource Policy
|
||||
### Politica delle risorse
|
||||
|
||||
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.
|
||||
È possibile utilizzare le politiche delle risorse per definire chi può chiamare gli endpoint API.\
|
||||
Nell'esempio seguente puoi vedere che l'**IP indicato non può chiamare** l'endpoint `/resource_policy` tramite GET.
|
||||
|
||||
<figure><img src="../../../images/image (256).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### IAM Authorizer
|
||||
### Autenticatore IAM
|
||||
|
||||
It's possible to set that a methods inside a path (a resource) requires IAM authentication to call it.
|
||||
È possibile impostare che un metodo all'interno di un percorso (una risorsa) richieda l'autenticazione IAM per essere chiamato.
|
||||
|
||||
<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**.
|
||||
Quando questo è impostato, riceverai l'errore `{"message":"Missing Authentication Token"}` quando cerchi di raggiungere l'endpoint senza alcuna autorizzazione.
|
||||
|
||||
Un modo semplice per generare il token atteso dall'applicazione è utilizzare **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**.
|
||||
Un altro modo è utilizzare il tipo **`Authorization`** **`AWS Signature`** all'interno di **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:
|
||||
Imposta l'accessKey e la SecretKey dell'account che desideri utilizzare e puoi autenticarti contro l'endpoint API.
|
||||
|
||||
Entrambi i metodi genereranno un **Authorization** **header** come:
|
||||
```
|
||||
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**.
|
||||
Nota che in altri casi l'**Authorizer** potrebbe essere stato **mal codificato** e inviare **qualsiasi cosa** all'interno dell'**Authorization header** **permetterà di vedere il contenuto nascosto**.
|
||||
|
||||
### 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.
|
||||
È possibile utilizzare un lambda che, basato su un determinato token, **restituirà una policy IAM** che indica se l'utente è **autorizzato a chiamare l'endpoint API**.\
|
||||
Puoi impostare ogni metodo di risorsa che utilizzerà l'autenticatore.
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Lambda Authorizer Code Example</summary>
|
||||
|
||||
<summary>Esempio di codice Lambda Authorizer</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:
|
||||
Chiamalo con qualcosa come:
|
||||
|
||||
<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
|
||||
> A seconda del codice Lambda, questa autorizzazione potrebbe essere vulnerabile
|
||||
|
||||
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"}`
|
||||
Nota che se viene **generata e restituita una policy di negazione**, l'errore restituito da 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.
|
||||
In questo modo potresti **identificare questa autorizzazione** in atto.
|
||||
|
||||
### Required API Key
|
||||
### Chiave API richiesta
|
||||
|
||||
It's possible to set API endpoints that **require a valid API key** to contact it.
|
||||
È possibile impostare endpoint API che **richiedono una chiave API valida** per contattarlo.
|
||||
|
||||
<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).
|
||||
È possibile generare chiavi API nel portale API Gateway e persino impostare quanto possono essere utilizzate (in termini di richieste al secondo e in termini di richieste al mese).
|
||||
|
||||
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:
|
||||
Per far funzionare una chiave API, è necessario aggiungerla a un **Piano di Utilizzo**, questo piano di utilizzo deve essere aggiunto allo **Stadio API** e lo stadio API associato deve avere configurato un **throttling del metodo** per l'**endpoint** che richiede la chiave API:
|
||||
|
||||
<figure><img src="../../../images/image (198).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
## Unauthenticated Access
|
||||
## Accesso non autenticato
|
||||
|
||||
{{#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
|
||||
## Persistenza
|
||||
|
||||
{{#ref}}
|
||||
../aws-persistence/aws-api-gateway-persistence.md
|
||||
{{#endref}}
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user