# Unsafe Consumption of APIs

***

## **🔍 Fundamentos**

### **O que é?**

O **Consumo Inseguro de APIs** (API10:2023 no OWASP API Security Top 10) ocorre quando um servidor consome dados de outras APIs (terceiros ou microserviços internos) e confia cegamente nessas informações sem realizar a devida validação, filtragem ou sanitização.

### **O Erro da "Confiança Absoluta"**

Muitos desenvolvedores pensam: *"Essa API é do Google/Stripe/Parceiro, então o dado que vem de lá é seguro"*. No entanto, o provedor da API pode ser comprometido, ou um atacante pode interceptar e modificar o tráfego ("Man-in-the-Middle"), injetando payloads maliciosos que serão processados pelo seu servidor.

***

## **🏗️ Cadeia de Confiança Insegura**

O fluxo da vulnerabilidade geralmente segue este padrão:

1. **API de Terceiro:** Fornece um dado (ex: nome do usuário ou URL de imagem).
2. **Sua API:** Recebe o dado e o utiliza diretamente em uma função sensível (ex: imprimir no PDF ou injetar no HTML).
3. **Resultado:** Se a API de terceiro enviar um script malicioso, o seu servidor o processará como se fosse legítimo.

***

## **⚔️ Tipos de Riscos no Consumo**

1. **Injeção de Dados:** Receber dados de uma API externa que contêm SQL, NoSQL ou Command Injection.
2. **SSRF via Terceiros:** A API externa retorna uma URL que seu servidor tenta buscar automaticamente.
3. **Negação de Serviço (DoS):** A API externa demora muito para responder, travando as threads do seu servidor (falta de timeout).
4. **Exposição de Informações:** Passar suas chaves privadas para APIs externas de forma insegura.

***

## **🔧 Técnicas de Exploração**

### **1. Manipulação de Respostas de Webhooks**

Muitas APIs consomem dados via **Webhooks**. Se um atacante descobrir a URL do seu webhook, ele pode enviar payloads fake simulando a API original.

* `POST /api/webhooks/payment-notification`
* Payload Malicioso: `{"status": "paid", "order_id": "../../../etc/passwd"}`

### **2. Exploração de Integradores de Terceiros**

Se sua API integra com um serviço de encurtamento de links ou processamento de imagens, o atacante pode fornecer um link que, ao ser processado pela API de terceiro, retorne algo que exploda no seu backend.

***

## **🚀 Cenários de Exploração Prática**

### **Cenário A: SQL Injection via API de Endereço**

Sua aplicação consome uma API de CEP para preencher o endereço.

{% stepper %}
{% step %}
O atacante compromete a base de dados do provedor de CEP ou simula a resposta.
{% endstep %}

{% step %}
A resposta enviada é: `{"rua": "Av Paulista', (SELECT user())--", "cidade": "SP"}`.
{% endstep %}

{% step %}
Seu servidor salva esse campo "rua" diretamente no banco de dados, executando a injeção SQL interna.
{% endstep %}
{% endstepper %}

### **Cenário B: SSRF via Processador de PDF**

Sua API usa uma biblioteca/serviço externo para gerar PDFs a partir de dados de rede.

{% stepper %}
{% step %}
A API externa fornece uma URL de imagem de perfil.
{% endstep %}

{% step %}
O atacante altera sua imagem de perfil no serviço externo para: `http://localhost:11211/stats`.
{% endstep %}

{% step %}
Seu gerador de PDF tenta baixar a "imagem" e acaba expondo informações do Memcached interno para o PDF final.
{% endstep %}
{% endstepper %}

***

## **🔍 Detecção e Ferramentas**

### **1. Interceptação de Tráfego (Burp Suite)**

Analise não apenas como você envia dados, mas como o seu servidor processa o que recebe de volta. Tente forjar respostas de APIs externas para ver como seu sistema reage.

### **2. Fuzzing de Webhooks**

Envie payloads inesperados para seus endpoints de webhook para testar a robustez do parser.

### **3. Monitoramento de Outbound**

Use firewalls de saída ou proxies para ver para onde seu servidor está fazendo requisições após consumir dados de terceiros.

***

## **🛡️ Mitigação e Prevenção**

### **1. Desconfiança por Padrão**

Trate dados vindos de APIs externas com o mesmo nível de desconfiança que dados vindos de usuários diretos. **Valide tudo.**

### **2. Use HTTPS e Verifique Certificados**

Nunca consuma APIs via HTTP. Garanta que seu cliente HTTP valide o certificado SSL do servidor remoto para evitar ataques MiTM.

### **3. Implemente Timeouts e Retries**

Não deixe uma API externa lenta derrubar sua aplicação. Use timeouts curtos (ex: 2-5 segundos).

### **4. Isolamento (Sandboxing)**

Se possível, processe dados de terceiros (como conversão de arquivos ou parsing de XML complexo) em ambientes isolados ou containers sem acesso à rede interna.

### **5. Lista Branca de Redirecionamentos**

Se uma API retornar uma URL, valide-a contra uma lista branca de domínios permitidos antes de tentar acessá-la.

***

> No mundo de microserviços e integrações SaaS, o perigo muitas vezes não vem da porta da frente, mas sim de uma conexão de "confiança" com um parceiro que foi comprometido.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://0xmorte.gitbook.io/bibliadopentestbr/tecnicas/web/back-end/apis/unsafe-consumption-of-apis.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.