🛡️ ATIVIDADE 18: SEGURANÇA NO DESENVOLVIMENTO E OWASP

Bem-vindo a mais uma etapa crítica da sua jornada na Engenharia de Software! Até aqui, aprendemos a modelar, testar, automatizar e containerizar sistemas. Mas de que adianta um sistema incrivelmente rápido, com CI/CD verde e rodando em Docker, se ele puder ser facilmente invadido por um hacker, vazando dados confidenciais dos usuários? 😱🔓

Hoje, mergulharemos no universo do DevSecOps e do Desenvolvimento Seguro (Secure by Design). Aprenderemos a analisar vulnerabilidades antes mesmo de escrevermos o código, utilizando a metodologia de modelagem de ameaças STRIDE e as diretrizes internacionais da OWASP.

🎯 Objetivos de Aprendizagem do Laboratório

Ao final deste laboratório prático (estimativa: 4 horas presenciais / autoguiadas), você será capaz de:

• Compreender a importância da segurança proativa no ciclo de desenvolvimento de software.
• Aplicar a metodologia STRIDE para identificar ameaças na arquitetura do sistema.
• Identificar as principais falhas do OWASP Top 10 (como Injection e Broken Authentication).
• Implementar defesas de código e configurações seguras em Java 17 e Spring Boot.

🏢 O Cenário Prático (Seu Desafio)

Na TecProExpress, a segurança costumava ser vista como "problema do pessoal de redes" ou "algo para olhar depois que o software estiver pronto". Essa mentalidade cobrou seu preço: na semana passada, um motorista mal-intencionado conseguiu manipular o parâmetro id na URL da API e visualizou os dados pessoais de entrega e faturamento de outros clientes. Além disso, a tela de busca de fretes sofreu um ataque de injeção de SQL que quase apagou a tabela de produtos!

"Seu desafio como Engenheiro de Segurança de Aplicações (AppSec) é blindar a arquitetura da TecProExpress. Você conduzirá uma modelagem de ameaças STRIDE e programará mecanismos de proteção no Spring Boot para barrar ataques de injeção de código e vazamento de dados de autorização de forma definitiva."

🧠 Fundamentos: A Teoria Traduzida

1. A Metodologia STRIDE (Modelagem de Ameaças)

Criada pela Microsoft, serve para mapear o que pode dar errado em um sistema com base em seis pilares fundamentais:

• Spoofing (Falsificação de identidade): Alguém fingindo ser outro usuário.
• Tampering (Adulteração de dados): Modificar dados em trânsito ou no banco.
• Repudiation (Repúdio): Um usuário alegar que não realizou uma ação por falta de logs auditáveis.
• Information Disclosure (Vazamento de informações): Expor dados confidenciais a pessoas não autorizadas.
• Denial of Service (Negação de Serviço): Derrubar o sistema por sobrecarga de requisições.
• Elevation of Privilege (Elevação de privilégio): Um usuário comum executando funções de administrador.

2. OWASP Top 10

A Open Worldwide Application Security Project (OWASP) é uma fundação global sem fins lucrativos que mapeia e publica regularmente as 10 vulnerabilidades de segurança mais críticas e recorrentes em aplicações web no mundo todo.

📊 Vetores de Ataque Comuns vs Defesa Ativa

flowchart TD
    subgraph Vetores ["Vetores de Ataque (Ameaças)"]
        A1["Injeção de SQL (SQLi)"]
        A2["Manipulação de URL (BOLA/IDOR)"]
        A3["Brute Force (Senha Fraca)"]
    end

    subgraph Defesas ["Mecanismos de Defesa (Spring Boot)"]
        D1["Uso de Spring Data JPA / Prepared Statements"]
        D2["Controle de Acesso baseado em Roles (Spring Security)"]
        D3["Criptografia BCrypt + Rate Limiting"]
    end

    A1 -->|Mitigado por| D1
    A2 -->|Mitigado por| D2
    A3 -->|Mitigado por| D3

    style Vetores fill:#ffebee,stroke:#c62828,stroke-width:2px
    style Defesas fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px

📖 Exemplo Guiado: Codificação Segura e Defesa Ativa

Vamos analisar um exemplo de código vulnerável em Spring Boot e como corrigi-lo imediatamente usando boas práticas de programação.

1. Evitando a Injeção de SQL (SQL Injection)

Cenário vulnerável (O que NÃO fazer): Concatenar strings diretamente na consulta SQL permite que o atacante envie comandos maliciosos na variável input.

// VULNERÁVEL! Permite SQL Injection
public List<Pedido> buscarPedidosPorCidade(String input) {
    String query = "SELECT * FROM pedidos WHERE cidade = '" + input + "'";
    return entityManager.createNativeQuery(query, Pedido.class).getResultList();
}

Se o atacante passar o valor Joinville' OR '1'='1, a query executará retornando todos os pedidos do banco de dados!

Cenário Seguro (Como implementar): Usar consultas parametrizadas (Prepared Statements) ou Spring Data JPA, que higienizam as entradas automaticamente.

// SEGURO! Parâmetros higienizados pelo JPA/Hibernate
public List<Pedido> buscarPedidosPorCidadeSeguro(String input) {
    String query = "SELECT p FROM Pedido p WHERE p.cidade = :cidade";
    return entityManager.createQuery(query, Pedido.class)
                        .setParameter("cidade", input)
                        .getResultList();
}

2. Proteção de Acesso com Spring Security

Configuração para restringir privilégios em endpoints sensíveis da API (Evitando elevação de privilégios e Broken Access Control):

@Configuration
@EnableWebSecurity
public class SecurityConfig {

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http
            .csrf(csrf -> csrf.disable()) // CSRF desabilitado apenas para fins didáticos de API
            .authorizeHttpRequests(auth -> auth
                // Endpoints públicos
                .requestMatchers("/api/public/**").permitAll()
                // Apenas motoristas autenticados podem ver entregas
                .requestMatchers("/api/entregas/**").hasRole("MOTORISTA")
                // Apenas gerentes podem deletar registros ou ver relatórios
                .requestMatchers("/api/admin/**").hasRole("GERENTE")
                .anyRequest().authenticated()
            )
            .httpBasic(Customizer.withDefaults()); // Autenticação básica simples
        
        return http.build();
    }
}

💻 Scanner de Segurança SAST (DevSecOps) & Saída no Terminal

Para auditar vulnerabilidades no código antes de cada commit, integramos o scanner estático de segurança via plugin Maven (SpotBugs + FindSecBugs):

# Executando scanner SAST via plugin Maven no código-fonte Java
mvn com.github.spotbugs:spotbugs-maven-plugin:check

🖥️ Saída Esperada no Terminal:

[INFO] --- spotbugs-maven-plugin:4.8.6:check (default-cli) @ tecproexpress-delivery ---
[INFO] BugInstance size is 1
[INFO] Error size is 0
--------------------------------------------------
>> Issue: [SQL_INJECTION_JPA] Possible SQL/JPQL Injection via native query concatenation
   Severity: High   Confidence: High   Rule: FindSecBugs SQL_INJECTION_JPA
   Location: com.tecproexpress.repository.PedidoRepository.buscarPedidosPorCidade(String)
   Linha: src/main/java/com/tecproexpress/repository/PedidoRepository.java:87
   86     public List<Pedido> buscarPedidosPorCidade(String input) {
   87         String query = "SELECT * FROM pedidos WHERE cidade = '" + input + "'";
--------------------------------------------------
>> Code scanned:
        Total classes analyzed: 24
        Total issues (by severity):
                Low: 0
                Medium: 0
                High: 1
[INFO] BUILD FAILURE
🛡️ [DEVSECOPS] Vulnerabilidade identificada! Bloqueando pipeline de deploy até correção com Prepared Statements/JPQL parametrizado.

🌐 Teste de Autorização com cURL (Acesso Permitido vs HTTP 403 Forbidden)

🔹 1. Tentativa sem Permissão de Administrador:

curl -X DELETE "http://127.0.0.1:8000/api/admin/pedidos/99" \
     -H "Authorization: Bearer token_usuario_comum"

🖥️ Resposta de Bloqueio (HTTP 403 Forbidden):

{
  "detail": "Acesso negado: Perfil requer privilégios de [GERENTE/ADMIN]"
}

🛠️ Prática Obrigatória 1: Matriz de Ameaças STRIDE

Cenário: Analisando a segurança do seu projeto de grupo.

1. Crie uma tabela Markdown contendo uma análise de ameaças do seu sistema utilizando a metodologia STRIDE.
2. Mapeie pelo menos 3 das 6 letras do STRIDE aplicadas ao seu projeto real.
3. Preencha as colunas: Elemento do Sistema (ex: Tela de Login), Ameaça Identificada (ex: Usuário interceptar tráfego) e Mitigação Proposta (ex: Uso obrigatório de HTTPS e senhas salvas com Hash BCrypt).

🛠️ Prática Obrigatória 2: Higienização de Código

Cenário: Identificação e correção de falhas de segurança no código.

1. Crie um arquivo Markdown demonstrando um trecho de código hipotético ou real do seu sistema que seja vulnerável a Injeção de SQL ou Falha de Autorização.
2. Apresente, logo abaixo, a versão corrigida desse código (Refatoração de Segurança), explicando qual técnica foi aplicada para eliminar a vulnerabilidade.

📤 Instruções de Entrega (Microsoft Teams)

Após auditar e implementar as melhorias de segurança:

1. Salve a sua matriz de ameaças e os trechos de código com o nome Atividade_18.md na pasta es-atv-18-seguranca-devsecops/ do seu repositório GitHub.
2. Certifique-se de fazer o commit e push para o repositório público.
3. Submeta o link do seu repositório no Microsoft Teams para avaliação do professor.

💡 Checkpoint de Lógica

📊 Rubrica Formativa de Avaliação