React: implementando segurança web com padrões OWASP

Fundamentos sobre segurança - Apresentação

Apresentando a instrutora e o objetivo do curso

Olá! Seja bem-vindo a mais este curso. Meu nome é Patrícia Silva.

Audiodescrição: Patrícia é uma mulher branca, com cabelos cacheados e usando óculos de aro preto. Ela é instrutora na Alura e trabalha como Fullstack Engineer (Engenheira de Software) há mais de 15 anos.

Ao longo desses anos, já observamos muitas aplicações incríveis, super bem construídas, utilizando os melhores design patterns (padrões de design), mas que acabaram comprometidas por falhas de segurança que poderiam ter sido evitadas no início do desenvolvimento. É exatamente sobre isso que vamos trabalhar aqui.

Desenvolvendo uma mentalidade de segurança

A proposta deste curso é ajudar a desenvolver uma mentalidade de segurança. Não se trata apenas de aprender a corrigir falhas pontuais ou bugs, mas de aprender a pensar em segurança desde o primeiro commit do nosso projeto. Vamos trabalhar como pessoas desenvolvedoras que fazem auditoria de segurança no próprio código, ou seja, vamos agir como profissionais experientes que investigam, identificam e corrigem vulnerabilidades reais.

Vamos aprender a identificar vulnerabilidades, corrigi-las de forma prática e, principalmente, entender o raciocínio por trás de cada vulnerabilidade. Não se trata apenas de decorar soluções temporárias ou uma sopa de letrinhas.

Explorando a aplicação CodeConnect

Nós vamos trabalhar no CodeConnect, que já está aberto no nosso navegador.

Esta é uma aplicação real que já está em funcionamento, mas possui falhas que exploraremos passo a passo. A aplicação inclui uma área logada, registro de conta, redefinição de senha, integração com banco de dados, e permite fazer login e visualizar todos os posts.

Podemos interagir com os posts, dando like, fazendo comentários e deletando, se necessário. Trabalharemos com a autenticação e protegeremos a aplicação contra diversos tipos de ataques. Faremos isso seguindo a referência mundial em segurança web, o OWASP Top 10, que é uma lista dos ataques mais comuns na vida real.

Defendendo contra ataques e vulnerabilidades

Aprenderemos a defender a aplicação contra injeção de código, como SQL Injection e XSS, falhas de autenticação, vazamento de tokens, ataques CSRF, exposição de dados sensíveis, entre outros problemas que realmente encontramos no dia a dia.

Prepare seu editor, pegue sua água ou café, e vamos juntos transformar o código vulnerável em um código seguro. Vamos tornar esta aplicação muito mais confiável para nosso negócio e para nossos clientes. Segurança não é um recurso opcional; é responsabilidade de quem escreve código.

Requisitos e início do curso

Para isso, é necessário conhecer React, ter familiaridade com o Next.js, e saber versionamento com o Git. Vamos começar?

Fundamentos sobre segurança - Conhecendo a estrutura do projeto

Analisando a estrutura do projeto

Vamos começar analisando a estrutura do projeto. À primeira vista, pode parecer simples, mas não é. Muitos erros e problemas de segurança ocorrem não por um erro trivial, mas geralmente porque a pessoa desenvolvedora não compreende a estrutura do projeto ou o fluxo de dados. Por que isso é importante? Às vezes, parece óbvio, mas não é. Precisamos ter um conhecimento básico da planta, da estrutura do nosso código. É como ter uma casa e estar em uma sala sem conhecer as outras. Não sabemos se há problemas em outros cômodos. Portanto, é essencial conhecer a casa, pois ao olhar para uma janela, identificamos pontos que merecem atenção, assim como uma porta que vale a pena verificar. Na nossa aplicação, isso é primordial.

Este é um projeto acadêmico, mas quando ingressamos em uma empresa, a quantidade de arquivos, funções, etc., é maior, embora a lógica permaneça a mesma. Por exemplo, vamos usar o Next.js, que trabalha com Page Routes e também com API Routes. Já fizemos o clone do projeto, que está em nossa máquina. Dentro de src, é onde o usuário entra em contato com o sistema, pois dentro de app, src/app, temos todas as páginas: a home, a página de login, a página de post, e o perfil, que contém funcionalidades para o usuário editar a biografia, recuperar senha e registrar uma nova conta. Esta é a primeira parte de contato do usuário, e uma dica simples é que, se o usuário consegue digitar algo, isso é automaticamente uma superfície de ataque. Portanto, um registro de conta, adicionar uma biografia ou fazer um comentário em um post são áreas que requerem atenção.

Explorando componentes e segurança

Temos a página de posts, onde é possível comentar. Além disso, temos o API Handler, que é o API REST, onde se pode inserir comentários, dar like, e acessar a API para obter os posts. Após app, temos os componentes, que estão próximos ao usuário e são o que é renderizado. Nossos componentes incluem formulários, como o componente de comentário. Precisamos verificar se esse comentário está preparado para sanitizar, ou seja, limpar o que será exibido, pois pode ser que o back-end não tenha sanitizado corretamente, e na hora de renderizar, isso pode se tornar um executável.

Devemos verificar se esses componentes estão preparados, especialmente aqueles onde o usuário insere informações, como comment e input. Temos também modal, comment, reply para responder, e text area, que precisam ser analisados. Há também o card post. Precisamos entender se, por exemplo, temos um dangerouslySetInnerHTML, que permite renderizar HTML, pois é uma rede social para desenvolvedores e precisamos renderizar HTML, scripts e tudo que envolve sintaxe de linguagem de programação. Isso representa um desafio, pois é difícil de controlar. Precisamos determinar se é um comentário de fato ou um executável, ou ainda um JavaScript que executará algo.

Avaliando ações do servidor e autenticação

Nos componentes, vamos perceber se há algum em que o usuário entra com a informação e ela está protegida. Em seguida, temos as server actions, que são muito sensíveis no projeto, pois são chamadas diretamente dos componentes. Elas rodam no servidor, e por isso é seguro utilizarmos informações confidenciais que devem permanecer protegidas lá. No entanto, não podemos permitir que essas informações vazem para o cliente. Isso torna as server actions extremamente críticas, pois é uma linha tênue: o que é confidencial deve permanecer no servidor e não pode vazar para os componentes.

Além disso, temos actions de autenticação, de redefinição de senha, de salvar dados do usuário, e, como estamos em uma área logada, é necessário ter autorização. O usuário precisa de autorização para, por exemplo, editar sua biografia. Se um token vazar e outra pessoa conseguir realizar as mesmas ações que a pessoa logada, isso se torna um grande problema.

Trabalhando com o banco de dados e serviços

Na parte de lib, trabalhamos com um banco de dados, o Supabase, que é um back-end as a service. O banco de dados é o Postgres, e na camada de dados, que chamamos de data layer, é onde fazemos as queries. Não há proteção para filtrar dados maliciosos; ela apenas salva e recupera dados, sem filtragem.

Para centralizar todas as consultas do Supabase, podemos criar um serviço de banco de dados. Vamos ver como isso é feito com o seguinte código:

import db from "../../supabase/db";
import logger from "../logger";

// Data layer para centralizar todas as consultas do Supabase
export class DatabaseService {
    // ==== POSTS ====

    async getAllPosts(page = 1, searchTerm = null) {
        try {
            const perPage = 4;
            const skip = (page - 1) * perPage;

            // Construir query base
            let query = db
                .from("Post")
                .select(
                    `
                    *,
                    author:User(*),
                    comments:Comment(*)
                    `
                )
                .order("id", { ascending: false })
                .range(skip, skip + perPage - 1);

            // Adicionar filtro de busca se necessário
            if (searchTerm) {
                query = query.ilike("title", `%${searchTerm}%`);
            }
            
            const { data: posts, error, count } = await query;
            
            if (error) {
                logger.error("DB:getAllPosts error", {
                    step: "DATABASE",
                    operation: "LIST_POSTS",
                    page,
                    searchTerm,
                    perPage,
                    error,
                });
                throw error;
            }

            return { posts: posts ?? [], count };
        } catch (error) {
            logger.error("DB:getAllPosts catch error", {
                step: "DATABASE",
                operation: "LIST_POSTS",
                page,
                searchTerm,
                error,
            });
            throw error;
        }
    }

Esse serviço de banco de dados nos permite buscar todos os posts, com suporte a paginação e busca por termos específicos. Ele também inclui tratamento de erros, registrando logs detalhados em caso de falhas.

Configurando utilitários e segurança

Temos também os utilitários, que servem para instanciar o Supabase, criar a conexão e interagir com o ambiente remoto. Contamos com o middleware de sessão e o event logger. Se já estudamos isso na carreira, abordamos e aprendemos a criar logs estruturados de maneira profissional. Já temos essa facilidade no curso, com logs estruturados.

Depois, temos os scripts que criam e populam as tabelas no Supabase. No next.config.js, apenas os padrões remotos estão configurados. Permitimos que assets e imagens venham do host do GitHub User Content, limitando o contato e permitindo que dados de imagens e assets sejam consumidos somente de lá. No entanto, faltam algumas configurações de segurança, como headers básicos, que precisaremos resolver posteriormente.

Para configurar o Next.js para permitir imagens de fontes remotas específicas, podemos usar o seguinte código:

/** @type {import('next').NextConfig} */
const nextConfig = {
    images: {
        remotePatterns: [
            // GitHub Raw Content
            {
                protocol: "https",
                hostname: "raw.githubusercontent.com",
                port: "",
                pathname: "/**", // Permite qualquer path do GitHub
            },
            // GitHub Assets (caso use github.com/user/repo/blob)
            {
                protocol: "https",
                hostname: "github.com",
                port: "",
                pathname: "/**",
            },
        ],
    },
};

export default nextConfig;

Compreendendo o fluxo de dados e próximos passos

O fluxo de dados funciona da seguinte forma: o usuário acessa nosso site e, inicialmente, tem acesso às páginas dentro de "app". As páginas se comunicam com a API REST para obter dados ou com as Actions, que também podem acessar o banco de dados. A API conversa com o banco de dados, onde fazemos a query, e esses dados são renderizados por meio dos componentes na página. Esse é o fluxo de dados da nossa aplicação.

Já criamos um mapa mental dessa primeira versão, e ao longo do curso, vamos nos acostumando mais. Se a base de código fosse maior, é natural que leve tempo para nos acostumarmos, mas já fizemos o primeiro scanner. Agora, vamos falar sobre XSS e as vulnerabilidades antes de colocarmos a mão na massa. Nos vemos na sequência!

Fundamentos sobre segurança - Entendendo OWASP e auditoria de segurança

Alinhando a mentalidade de segurança

Antes de colocarmos a mão na massa, precisamos alinhar algo muito importante: a mentalidade que os times de segurança utilizam para analisar aplicações web. Embora estejamos do outro lado, como pessoas desenvolvedoras, para aprendermos a nos proteger, é essencial entender como os hackers ou os times de segurança agem. Geralmente, trabalhamos em times ou empresas que contratam consultorias de segurança ou possuem seus próprios times de segurança. Esses profissionais utilizam uma abordagem estruturada para procurar vulnerabilidades, não saindo simplesmente à procura sem nenhum processo.

Por isso, precisamos compreender o que é o OWASP, que é a base aqui. OWASP significa Open Worldwide Application Security Project (Projeto Aberto de Segurança de Aplicações Mundiais) e é amplamente utilizado como um guia. Essa fundação global, sem fins lucrativos, cria os principais padrões de segurança do mundo para aplicações web. As auditorias formais e os times de segurança utilizam esses padrões para formalizar auditorias. No nosso caso, vamos aproveitar esse benefício para entender como eles operam, tornando-nos mais eficazes em conhecer esse processo, essa mentalidade, e proteger melhor nossas aplicações.

Compreendendo a importância dos padrões OWASP

Não é necessário ser um especialista em segurança de aplicações (AppSec), um pen tester (testador de penetração), um hacker ou um engenheiro de segurança. Precisamos apenas entender como proteger o sistema das vulnerabilidades mais comuns. Compreender esses padrões do OWASP nos torna muito mais eficazes, pois são os mesmos padrões utilizados por empresas e consultorias em auditorias formais. Isso é extremamente útil, pois reflete o que acontece diariamente no mercado de trabalho. Quando falamos de um processo estruturado de segurança, ele é baseado em padrões oficiais e utilizado por profissionais da área.

Empresas grandes, com produtos gigantescos e sistemas críticos, precisam realizar auditorias formais para comprovar a segurança, como é o caso de bancos. Nosso objetivo, assim como o deles, é sempre encontrar, classificar e priorizar vulnerabilidades em aplicações web, e é exatamente isso que precisamos fazer. O que estamos trazendo aqui é uma maneira fundamentada, utilizando algo que o mercado usa de forma robusta para encontrar vulnerabilidades de maneira sistemática. Aqui começa a mudança de mentalidade: não se trata de consertar um bug isolado ou tentar encontrar vulnerabilidades sem saber exatamente o que procurar. Vamos analisar o sistema como um todo, com o mesmo olhar que os profissionais de segurança possuem.

Explorando os três pilares da auditoria OWASP

Para isso, vamos entender os três pilares da auditoria do OWASP e como eles podem nos ajudar. Esse processo se apoia em três pilares principais: o ASVS, que indica o que precisa ser verificado; o Top 10, que mostra onde geralmente ocorrem os problemas, os riscos mais comuns e mais graves; e o WSTG, que ensina como testar na prática, funcionando como um roteiro de teste. Esses três guias são muito comuns para um mapa mental: o ASVS nos diz qual é o destino, o Top 10 nos mostra o que evitar, e o WSTG nos ensina como navegar. Isso nos ajudará a proteger melhor nossas aplicações.

O ASVS, que em inglês significa Application Security Verification Standard (Padrão de Verificação de Segurança de Aplicações), é uma extensa lista de requisitos de segurança para aplicações web e APIs. Ele foca em pontos principais e essenciais, como autenticação, autorização, criptografia, validação de entrada, gestão de sessão, login e auditoria. As partes que forem mal implementadas abrem portas para ataques graves. Este padrão de verificação possui três níveis, e vamos nos concentrar no nível 2, que é adequado para aplicações React expostas à internet, sendo nosso nível de referência.

Abordando o OWASP Top 10 e suas falhas comuns

Além disso, temos o OWASP Top 10, que destaca as falhas mais comuns, funcionando como um mapa de risco do mundo real. Ele mostra as categorias onde, estatisticamente, as falhas mais perigosas ocorrem. No curso de React, vamos abordar as falhas mais relevantes para React, enquanto as que são mais pertinentes ao back-end ou cloud serão deixadas de lado. Cada uma dessas falhas será explicada, demonstrada e corrigida no momento apropriado.

Entre os exemplos atualizados, temos o Broken Access Control (Controle de Acesso Quebrado), onde uma pessoa consegue acessar dados de outra conta e usá-la como se fosse a própria. Também abordaremos criptografia mal implementada e injeções como XSS. Se nossa aplicação permitir que o usuário insira dados sem garantir sua segurança, esses dados podem ser executáveis, o que é catastrófico, podendo resultar em vazamento de tokens de sessão e dados.

Conectando teoria e prática no curso

Outras questões incluem design inseguro, que pode expor dados indevidamente, misconfigurações de segurança, como a ausência de headers de segurança, e dependências vulneráveis, que são pacotes de terceiros que esquecemos de atualizar. É crucial manter os pacotes NPM atualizados para evitar brechas de segurança. Falhas de autenticação também serão abordadas.

Como isso se conecta ao nosso curso? Vamos utilizar esse guia para identificar as superfícies de ataque em nossa aplicação, focando nos fluxos críticos, como login, cadastro e redefinição de senha. Tudo o que estamos discutindo não é apenas teoria; vamos aplicar no projeto para garantir proteção. Procuraremos por vulnerabilidades de injeção de conteúdo malicioso, vazamento de tokens e garantiremos que apenas pessoas autorizadas acessem os recursos.

Desenvolvendo uma mentalidade de segurança

Este curso é uma construção de mentalidade, não uma memorização. Segurança é uma mentalidade. Os invasores são criativos e desenvolvem novos métodos constantemente, por isso precisamos estar atentos ao que acontece no mundo da segurança. O guia da organização, que é gratuito e Open Source (código aberto), lista anualmente as vulnerabilidades mais comuns e as atualiza. Vamos praticar para desenvolver um olhar mais apurado.

Vamos nos perguntar: aqui há risco? Está faltando controle? Precisamos de log? Pode haver XSS? Precisamos validar a entrada? Se há um input onde o usuário insere dados, é necessário validar o que foi inserido. Faltou autenticação? Precisamos de log? Esse é o pensamento de uma pessoa profissional de AppSec. Vamos treinar a partir daqui e mapear as superfícies vulneráveis da nossa aplicação. Sabemos que há superfícies onde o usuário insere dados, então começaremos a explorar a partir daí.

Nos vemos a seguir. Até já!

Sobre o curso React: implementando segurança web com padrões OWASP

O curso React: implementando segurança web com padrões OWASP possui 327 minutos de vídeos, em um total de 55 atividades. Gostou? Conheça nossos outros cursos de React em Front-end, ou leia nossos artigos de Front-end.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Fundamentos sobre segurança
• Proteção XSS e CSRF
• Gestão segura de tokens
• RBAC e ABAC na prática
• CORS, CSP e Security Headers
• Deploy e monitoramento seguro