Luiz Pessol

Tag: OWASP

  • Como configurar o AWS WAF (Web Application Firewall)

    Como configurar o AWS WAF (Web Application Firewall)

    Neste post de apoio ao vídeo, vamos proteger uma aplicação web com o AWS WAF. Vamos criar uma Web ACL associada a um Application Load Balancer, configurar regras próprias e regras gerenciadas da AWS, e depois ver os bloqueios acontecendo.

    Para o laboratório usei o OWASP Juice Shop, uma aplicação propositalmente vulnerável que é ótima para testar WAF. Mostro como subir o seu neste post: Estudando Application Security com o OWASP Juice Shop na AWS.

    O que é um WAF

    Um WAF (Web Application Firewall) inspeciona o tráfego da camada 7, ou seja, HTTP e HTTPS, e decide se cada requisição pode ou não chegar à aplicação. Ele detecta e bloqueia ataques como SQL injection e XSS (Cross-Site Scripting), os mesmos que aparecem no OWASP Top 10.

    No mercado existem várias opções, como Cloudflare, Akamai e soluções nacionais. O AWS WAF tem a vantagem de se integrar nativamente com os serviços da AWS.

    Onde o AWS WAF pode ser usado

    O AWS WAF se associa a recursos que recebem tráfego HTTP:

    • Amazon CloudFront, na borda. Nesse caso a Web ACL é global e criada na região us-east-1.
    • Application Load Balancer, que é o caso do vídeo.
    • Amazon API Gateway (APIs REST). É assim que o WAF protege o projeto Score Trust: Score Trust: arquitetura serverless na AWS.
    • AWS AppSync, Amazon Cognito, App Runner e Verified Access.

    Um detalhe que confunde muita gente: para recursos regionais, como o ALB, a Web ACL precisa ser criada na mesma região do recurso. Selecione a região certa no console antes de começar.

    Recursos AWS utilizados

    RecursoPapel no laboratório
    AWS WAF (Web ACL)Conjunto de regras avaliadas em cada requisição
    Application Load BalancerRecurso protegido, na frente da aplicação. Veja como configurar: Como configurar o AWS Application Load Balancer com 2 target groups
    Amazon EC2Instância rodando o OWASP Juice Shop
    Regras gerenciadas da AWSGrupos de regras prontos, mantidos pela AWS
    Sampled requests e CloudWatchVisualização das requisições permitidas e bloqueadas

    Passo a passo resumido

    1. Criar a Web ACL

    • Tipo de recurso: regional, na região do seu ALB.
    • Associe o Application Load Balancer.
    • Ação padrão: Allow. Tudo o que nenhuma regra bloquear passa. É o modelo mais comum: você libera por padrão e bloqueia o que é malicioso.

    2. Regra de CAPTCHA em um path

    A primeira regra customizada aplica um CAPTCHA no path /ftp do Juice Shop. Ao acessar esse caminho, o usuário precisa resolver o desafio antes de seguir.

    O CAPTCHA serve bem para proteger formulários de login e de cadastro contra bots. Para um diretório que não deveria estar exposto, porém, não é a melhor solução. Por isso, no vídeo, troco essa regra por um bloqueio.

    3. Bloquear um path sensível

    Mesma condição (o URI path começa com /ftp), mas com ação Block. A requisição recebe 403 Forbidden e nem chega à aplicação. Esse tipo de regra serve para fechar rapidamente caminhos que ficaram expostos por engano, como painéis administrativos e backups, enquanto a correção definitiva não sai.

    4. Bloquear o tráfego de fora do Brasil

    Uma regra de geo match com a condição não originado do Brasil e ação Block. Se a sua aplicação atende só o público brasileiro, essa regra corta uma parte grande do tráfego automatizado e dos ataques oportunistas.

    Cuidado com quem viaja ou usa VPN fora do país. Se isso for comum entre os seus usuários, considere usar a ação Count antes de bloquear.

    5. Regras gerenciadas da AWS

    A AWS mantém grupos de regras prontos, e vários deles são gratuitos (sem custo adicional por grupo). No vídeo adicionei proteção contra SQL injection com o grupo de banco de dados SQL. Outros que valem avaliar:

    • Core rule set: cobre boa parte do OWASP Top 10.
    • Known bad inputs: padrões de exploração conhecidos.
    • Grupos por plataforma: Linux, Windows, PHP, WordPress. Use só os que fazem sentido para a sua stack.
    • Amazon IP reputation list: IPs com histórico de atividade maliciosa.

    Também existem regras pagas no AWS Marketplace, de fornecedores especializados.

    6. Testar e observar

    Com as regras ativas, simulei ataques de SQL injection e XSS no Juice Shop. Na aba Sampled requests da Web ACL dá para ver cada requisição: IP de origem, país, URI e qual regra bloqueou. É o que você usa para ajustar regras e investigar falsos positivos.

    Boas práticas

    • Comece em modo Count nas regras gerenciadas e acompanhe por alguns dias antes de bloquear. Assim você evita derrubar funcionalidades legítimas.
    • Ordem das regras importa: as de Allow explícito (IPs internos, por exemplo) vêm antes; as mais baratas e mais restritivas, como as de geo e path, vêm em seguida.
    • Rate-based rules limitam requisições por IP e são uma defesa simples contra força bruta.
    • Habilite logs completos do WAF (CloudWatch Logs, S3 ou Firehose) para retenção e análise.
    • Custo: o AWS WAF cobra por Web ACL, por regra e por milhão de requisições. CAPTCHA e alguns grupos gerenciados têm cobrança própria. Revise antes de deixar ligado.
    • WAF não substitui código seguro. Ele é uma camada de defesa em profundidade, não a correção da vulnerabilidade.

    Material de apoio

    Ficou alguma dúvida sobre as regras? Deixe nos comentários.

  • Estudando Application Security com o OWASP Juice Shop na AWS

    Estudando Application Security com o OWASP Juice Shop na AWS

    Quem estuda segurança de aplicações precisa de um lugar para praticar sem atacar o sistema de ninguém. Neste post de apoio ao vídeo, mostro como subir o OWASP Juice Shop em uma instância EC2 com Docker e usá-lo como laboratório de Application Security.

    O que é o OWASP Juice Shop

    O Juice Shop é uma loja virtual propositalmente vulnerável, mantida pela fundação OWASP. Ela é escrita em Node.js e roda em contêiner. A aplicação reúne dezenas de desafios que cobrem o OWASP Top 10 e muito mais, como:

    • Broken Access Control: acessar dados ou funções de outro usuário.
    • Injection: o clássico SQL injection, que continua aparecendo em aplicações reais.
    • Cross-Site Scripting (XSS).
    • Falhas de autenticação, de criptografia e de configuração.

    Cada desafio resolvido aparece no placar (Score Board) da própria aplicação, o que transforma o estudo em um jogo com progresso visível. A página do projeto também tem um guia completo de instruções.

    O Juice Shop é a mesma aplicação que uso como alvo no laboratório de WAF: Como configurar o AWS WAF.

    Recursos AWS utilizados

    RecursoPapel no laboratório
    Amazon EC2 (Ubuntu)Máquina que roda o contêiner do Juice Shop
    VPC padrão e IP públicoAcesso à aplicação pelo navegador, sem montar rede
    Security GroupLibera a porta 3000, que é a porta do Juice Shop
    DockerBaixa e executa a imagem oficial do Juice Shop

    Existe também uma imagem do Juice Shop no AWS Marketplace, mas no vídeo subo tudo manualmente. Assim você entende cada peça, e o processo é simples.

    Passo a passo resumido

    1. Criar a instância EC2

    • AMI Ubuntu, tipo pequeno (elegível ao nível gratuito, se for o seu caso).
    • VPC padrão, com IP público habilitado, para acessar pelo navegador sem precisar de NAT ou VPN.
    • Security Group: entrada TCP 3000 para acessar a aplicação, e SSH (22) para administrar.

    2. Instalar o Docker

    Conecte na instância e rode:

    sudo apt update && sudo apt upgrade -y
sudo apt install -y docker.io
sudo systemctl enable --now docker
docker --version

    3. Subir o Juice Shop

    sudo docker pull bkimminich/juice-shop
sudo docker run -d --name juice-shop -p 3000:3000 bkimminich/juice-shop

    Acesse http://IP-PUBLICO-DA-INSTANCIA:3000 no navegador e a loja já estará funcionando.

    Cuidados importantes com o laboratório

    Lembre-se de que você está publicando uma aplicação vulnerável de propósito. Alguns cuidados evitam que o laboratório vire um problema:

    • Restrinja o Security Group ao seu IP (opção My IP no console), tanto na porta 3000 quanto na 22. Nunca deixe aberto para 0.0.0.0/0 por mais tempo do que o necessário.
    • Use uma conta AWS só para laboratório, separada de qualquer ambiente com dados reais.
    • Não reutilize senhas nem chaves de outros ambientes na instância.
    • Desligue ou apague a instância quando terminar. Além do risco, a EC2 e o IP público geram custo enquanto existirem.
    • Ataque apenas a sua própria instância. Testar sistemas de terceiros sem autorização é crime.

    Próximos passos de estudo

    1. Abra o Score Board e comece pelos desafios de uma estrela.
    2. Use um proxy de interceptação, como o OWASP ZAP ou o Burp Suite Community, para ver e modificar as requisições.
    3. Para cada vulnerabilidade explorada, estude como corrigi-la no código. É aí que o conhecimento vira AppSec de verdade.
    4. Depois, coloque um AWS WAF na frente da aplicação e veja quais ataques ele bloqueia e quais passam: Como configurar o AWS WAF.
    5. Leve o aprendizado para o pipeline com práticas de DevSecOps: Como começar com DevSecOps.

    Material de apoio

    Você já usa o Juice Shop nos seus estudos? Conta nos comentários qual desafio deu mais trabalho.

Visão geral de privacidade

Este site usa cookies para que possamos oferecer a melhor experiência de usuário possível. As informações dos cookies são armazenadas em seu navegador e executam funções como reconhecê-lo quando você retorna ao nosso site e ajudar nossa equipe a entender quais seções do site você considera mais interessantes e úteis.