🔒 Atividade 18: Segurança no Desenvolvimento e OWASP

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.

🎯 Objetivo da Aula

Ao final desta atividade, 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

📖 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();
    }
}

🛠️ 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