MÓDULO 1 — OWASP Top 10 (Base): Tópico 1.1 — Broken Access Control

A falha de Controle de Acesso Quebrado (Broken Access Control) ocupa o 1º lugar no ranking do OWASP Top 10. Ela ocorre quando as restrições sobre o que usuários autenticados ou anônimos podem fazer não são devidamente aplicadas no servidor. Como resultado, atacantes conseguem visualizar, modificar ou deletar dados não autorizados, ou até executar funções administrativas.

1. Principais Tipos de Falha de Controle de Acesso

A) IDOR (Insecure Direct Object References) Ocorre quando a aplicação utiliza um identificador direto fornecido pelo usuário (como um ID na URL ou em parâmetros JSON) para acessar um recurso no banco de dados, sem verificar se aquele usuário é o dono legítimo do recurso.

B) Escalação de Privilégios (Privilege Escalation) - Escalação Vertical: Um usuário comum ganha acesso a funcionalidades ou dados restritos a perfis superiores (ex: painel de administrador). - Escalação Horizontal: Um usuário acessa funcionalidades ou dados pertencentes a outro usuário com o mesmo nível de permissão (conceitualmente alinhado ao IDOR).

C) Path Traversal / Directory Traversal Ocorre quando entradas do usuário são usadas de forma não sanitizada para construir caminhos no sistema de arquivos do servidor, permitindo ler ou executar arquivos fora do diretório web.

2. Cenários Reais e Exemplos Práticos

Cenário 1: IDOR (Acesso a dados de outro usuário) Um usuário acessa seu próprio perfil via URL GET /api/v1/profile?userId=1001. Ele altera o parâmetro para userId=1002 e consegue visualizar o nome, CPF e dados bancários de outro cliente.

Cenário 2: Escalação Vertical (Forjando atributos do perfil) Durante a atualização de perfil, o usuário envia uma requisição PUT /api/user/profile e injeta um parâmetro extra na carga útil JSON: "role": "admin". Se o servidor não validar os campos autorizados para edição, o usuário se promove a administrador.

Cenário 3: Path Traversal (Leitura arbitrária de arquivos) Uma funcionalidade carrega documentos do usuário através do parâmetro GET /download?file=fatura.pdf. Substituindo o valor por ../../../../etc/passwd, o servidor retorna o arquivo de senhas/usuários do sistema operacional.

3. Exemplos de Requisições HTTP: Vulnerável vs. Segura

Exemplo 1: IDOR em Atualização de Dados

❌ Requisição Vulnerável (Cliente manda o ID e o Servidor confia):

POST /api/v1/alterar-email HTTP/1.1
Host: sistema-vulneravel.com
Authorization: Bearer token_do_usuario_comum_1001
Content-Type: application/json

{
  "user_id": 1002,
  "novo_email": "atacante@hacker.com"
}

O servidor aceita o parâmetro user_id do corpo da requisição e atualiza o e-mail do usuário 1002 sem verificar se o dono do token Bearer tem permissão sobre esse ID.

✅ Requisição e Tratamento Seguro:

POST /api/v1/alterar-email HTTP/1.1
Host: sistema-seguro.com
Authorization: Bearer token_do_usuario_comum_1001
Content-Type: application/json

{
  "novo_email": "usuario@exemplo.com"
}

No servidor (código seguro), o ID do usuário é extraído diretamente e exclusivamente do contexto da sessão/JWT validado, ignorando qualquer parâmetro enviado no corpo:

# Código Python/Flask (Seguro)
@app.route('/api/v1/alterar-email', methods=['POST'])
@autenticado
def alterar_email():
    # Extrai o ID do usuário diretamente do token validado, NÃO da requisição
    user_id_autenticado = g.user.id  
    novo_email = request.json.get('novo_email')

    # Atualiza apenas o registro do próprio usuário autenticado
    db.execute("UPDATE users SET email = %s WHERE id = %s", (novo_email, user_id_autenticado))
    return jsonify({"status": "sucesso"})

Exemplo 2: Bypass de Painel Admin (Escalação Vertical)

❌ Requisição Vulnerável (Segurança por Ocultação):

GET /admin/deletar-usuario?id=50 HTTP/1.1
Host: empresa.com
Cookie: session_id=sessao_usuario_comum

A aplicação apenas ocultava o botão de "Deletar" na interface do usuário comum, mas o endpoint no backend não valida o nível de permissão do usuário.

✅ Código Seguro (Verificação explícita no servidor):

# Código Python/Flask (Seguro)
@app.route('/admin/deletar-usuario', methods=['POST'])
@autenticado
def deletar_usuario():
    # Valida obrigatoriamente a role do usuário no backend
    if g.user.role != 'ADMIN':
        return jsonify({"erro": "Acesso Negado"}), 403
    
    # Prossegue com a remoção apenas se for ADMIN
    ...

4. Como Testar Manualmente (Metodologia de Teste)

• Mapeamento de Matriz de Permissões: Crie duas ou mais contas com privilégios diferentes (ex: Usuário A, Usuário B, e Administrador).
• Troca de Identificadores (IDOR):
• - Autentique-se como Usuário A.
• - Intercepte a requisição no Burp Suite (ex: GET /invoice/101).
• - Altere o identificador para o da fatura do Usuário B (GET /invoice/102).
• - Observe se a resposta é 200 OK (Vulnerável) ou 403 Forbidden / 404 Not Found (Seguro).
• Substituição de Tokens/Cookies:
• - Faça uma requisição restrita de administrador.
• - Intercepte a requisição no Burp Repeater e substitua o cabeçalho Authorization ou Cookie pelo token de um Usuário Comum.
• - Se o servidor executar a ação, há falha de escalação vertical.
• Fuzzing de Métodos e Caminhos:
• - Tente trocar verbos HTTP (ex: alterar de GET /user/data para POST ou DELETE).
• - Tente acessar endpoints de admin usando bypasses de caminho (ex: /api/v1/user -> /api/v1/../admin).

5. Como Mitigar (Boas Práticas de Desenvolvimento)

• Deny by Default (Negação por Padrão): Por padrão, todo recurso deve ser inacessível, exceto se houver uma regra explícita de permissão.
• Validação Unificada no Server-Side: Nunca confie em validações feitas apenas no front-end ou em botões ocultos. Toda regra de negócio/autorização deve ser checada no servidor.
• Uso de IDs Não Previsíveis: Adote identificadores únicos universais (UUIDv4) em vez de números inteiros sequenciais (1, 2, 3...) para dificultar a enumeração de recursos.
• Log de Falhas de Autorização: Registre e monitore tentativas repetidas de violação de controle de acesso para identificar comportamentos maliciosos.