Segurança de aplicações web é uma área crítica da segurança da informação, pois aplicações web são frequentemente expostas à internet e alvos de ataques. Nesta aula, exploraremos os principais riscos identificados pelo OWASP Top 10, com ênfase em injeção, quebra de controle de acesso e configurações inseguras. Compreender essas vulnerabilidades e como mitigá-las é essencial para desenvolver aplicações robustas e seguras.

OWASP Top 10

O OWASP Top 10 é um documento publicado pela Open Web Application Security Project (OWASP) que lista os dez riscos de segurança mais críticos para aplicações web. Ele é atualizado periodicamente e serve como referência para desenvolvedores, testadores e profissionais de segurança. A versão mais recente (2021) inclui categorias como:

  • A01:2021 – Broken Access Control (controle de acesso quebrado)
  • A02:2021 – Cryptographic Failures (falhas criptográficas)
  • A03:2021 – Injection (injeção)
  • A04:2021 – Insecure Design (design inseguro)
  • A05:2021 – Security Misconfiguration (má configuração de segurança)
  • A06:2021 – Vulnerable and Outdated Components (componentes vulneráveis e desatualizados)
  • A07:2021 – Identification and Authentication Failures (falhas de identificação e autenticação)
  • A08:2021 – Software and Data Integrity Failures (falhas de integridade de software e dados)
  • A09:2021 – Security Logging and Monitoring Failures (falhas de registro e monitoramento de segurança)
  • A10:2021 – Server-Side Request Forgery (SSRF) (falsificação de solicitação do lado do servidor)

O OWASP Top 10 não é uma lista exaustiva, mas orienta as prioridades de segurança. Cada risco é acompanhado de descrição, exemplos e formas de prevenção. É fundamental que equipes de desenvolvimento conheçam e apliquem essas diretrizes.

Injeção

Injeção ocorre quando dados fornecidos pelo usuário são enviados a um interpretador como parte de um comando ou consulta. Os tipos mais comuns são SQL Injection, NoSQL Injection, OS Command Injection e LDAP Injection. O atacante pode manipular a entrada para executar comandos maliciosos, acessar dados não autorizados ou comprometer o sistema.

Exemplo de SQL Injection: Suponha um formulário de login que constrói a consulta SQL diretamente com os dados do usuário:

SELECT * FROM users WHERE username = 'admin' AND password = 'senha'

Se o atacante inserir no campo de usuário: admin' --, a consulta se torna:

SELECT * FROM users WHERE username = 'admin' --' AND password = 'senha'

O -- comenta o restante da consulta, ignorando a verificação de senha. Para prevenir, utilize consultas parametrizadas (prepared statements) ou ORM que escapam automaticamente os dados. Exemplo em Java com JDBC:

String query = "SELECT * FROM users WHERE username = ? AND password = ?";
PreparedStatement stmt = connection.prepareStatement(query);
stmt.setString(1, username);
stmt.setString(2, password);
ResultSet rs = stmt.executeQuery();

Nunca concatene strings diretamente em consultas. Além disso, valide e sanitize todas as entradas do usuário, adotando uma lista branca de caracteres permitidos quando possível.

Broken Access Control

Broken access control (controle de acesso quebrado) ocorre quando um usuário pode agir fora de suas permissões pretendidas. Exemplos incluem acessar recursos de outros usuários, modificar dados sem autorização ou elevar privilégios. Isso geralmente acontece por falhas na verificação de autorização no lado do servidor.

Exemplo: Um site de e-commerce onde o usuário pode visualizar pedidos alterando o ID na URL: /pedido?id=123. Se não houver verificação de propriedade, um usuário mal-intencionado pode acessar pedidos de outros usuários simplesmente mudando o ID. A correção é verificar se o usuário logado tem permissão para acessar aquele recurso:

if (pedido.userId != usuarioLogado.id) {
    return "Acesso negado";
}

Boas práticas incluem: aplicar controle de acesso em todas as camadas (API, servidor), usar um modelo de permissões baseado em funções (RBAC), negar por padrão e registrar todas as tentativas de acesso negado. Evite expor IDs sequenciais; use identificadores imprevisíveis (UUIDs).

Configuração Insegura

Configuração insegura (security misconfiguration) é um dos riscos mais comuns. Pode ocorrer por configurações padrão inseguras, contas de administrador com senhas fracas, diretórios não protegidos, cabeçalhos HTTP ausentes, permissões excessivas em arquivos, entre outros. Atacantes exploram essas falhas para obter informações, executar comandos ou comprometer o sistema.

Exemplos:

  • Servidor web com listagem de diretórios habilitada, expondo arquivos sensíveis.
  • Framework em modo debug ativado em produção, revelando stack traces e informações internas.
  • Banco de dados com senha padrão (admin/admin) ou exposto publicamente.
  • Falta de cabeçalhos de segurança como Content-Security-Policy, X-Frame-Options, etc.

Para mitigar: realize hardening do sistema (desative serviços desnecessários, remova contas padrão), aplique o princípio do menor privilégio, mantenha software atualizado, use ferramentas de varredura de configuração e automatize a verificação de conformidade. Exemplo de configuração segura para um servidor Apache:

# Desabilitar listagem de diretórios
Options -Indexes

# Remover versão do servidor
ServerTokens Prod
ServerSignature Off

# Cabeçalhos de segurança
Header always set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options "DENY"
Header always set Content-Security-Policy "default-src 'self'"

Além disso, revise regularmente as configurações e utilize ferramentas como OWASP ZAP ou Nessus para identificar falhas.

Boas Práticas e Observações Finais

Além dos tópicos abordados, lembre-se de que segurança é um processo contínuo. Incorpore práticas como modelagem de ameaças, revisões de código, testes de penetração e educação da equipe. Aplique o princípio de defesa em profundidade, combinando múltiplas camadas de proteção. Nunca confie na entrada do usuário e sempre valide no servidor. Utilize bibliotecas e frameworks seguros, mantenha-se atualizado sobre novas vulnerabilidades e participe da comunidade de segurança.

Referências

Exercícios

  1. Explique o que é SQL Injection e cite duas formas de preveni-lo.

    2. ✓ Resposta: SQL Injection é uma vulnerabilidade onde dados fornecidos pelo usuário são inseridos em consultas SQL de forma insegura, permitindo que um atacante execute comandos maliciosos. Duas formas de prevenção: uso de prepared statements (consultas parametrizadas) e validação/sanitização de entradas com listas brancas.
  2. Dê um exemplo de Broken Access Control e como corrigi-lo.

    3. ✓ Resposta: Exemplo: um usuário acessa /pedido?id=456 e consegue ver pedidos de outros usuários alterando o ID. Correção: verificar no servidor se o pedido pertence ao usuário logado, por exemplo: if (pedido.userId != usuario.id) { return erro; }.
  3. Liste três medidas para evitar configurações inseguras em um servidor web.

    4. ✓ Resposta: 1) Desabilitar listagem de diretórios; 2) Remover informações de versão do servidor; 3) Configurar cabeçalhos de segurança (Content-Security-Policy, X-Frame-Options, etc.).
  4. Qual a importância do OWASP Top 10 para desenvolvedores?

    5. ✓ Resposta: O OWASP Top 10 fornece uma lista priorizada dos riscos de segurança mais críticos em aplicações web, ajudando desenvolvedores a focar nos problemas mais comuns e a adotar práticas de prevenção desde o início do desenvolvimento.
  5. Cite dois tipos de injeção além de SQL Injection e como preveni-los.

    6. ✓ Resposta: Dois tipos: OS Command Injection e LDAP Injection. Prevenção: evitar executar comandos do sistema com entrada do usuário; se necessário, usar funções que escapam argumentos e validar rigorosamente a entrada. Para LDAP, usar bibliotecas que tratam a codificação adequadamente e evitar concatenação direta.