Laboratório de Segurança Web

🛡️

INTRODUÇÃO

Por que estudar Segurança Web?

Uma aplicação Web pode funcionar corretamente e ainda possuir vulnerabilidades. Segurança deve fazer parte do desenvolvimento desde o planejamento, passando pelo código, testes, implantação e manutenção.

Nesta aula vamos estudar vulnerabilidades comuns e, principalmente, aprender como pensar na prevenção.

⚠️ Importante: Os laboratórios desta aula são simulados e executados localmente. O objetivo é compreender o funcionamento das vulnerabilidades e das medidas de proteção, não atacar sistemas reais.

ACOMPANHAMENTO

Seu progresso

1 SQL

2 XSS

3 CSRF

4 Força Bruta

5 Sessão

6 Autenticação

7 Acesso

8 Upload

9 Clickjacking

10 APIs

11 Rate Limit

12 Senhas

FUNDAMENTOS

O modelo mental da Segurança Web

Antes de estudar cada vulnerabilidade, precisamos entender como pensar em segurança.

Segurança não significa apenas colocar uma senha na aplicação. Uma aplicação segura precisa proteger dados, identidade, funcionalidades, sessões, arquivos, APIs e comunicação.

Uma forma simples de analisar qualquer funcionalidade é perguntar:

🔐 Confidencialidade Quem pode visualizar a informação?

🧱 Integridade Quem pode alterar a informação?

⚡ Disponibilidade A funcionalidade continua disponível?

👤 Identidade Quem está realizando a operação?

🚪 Autorização Essa pessoa pode executar essa ação?

🧪 Validação Os dados recebidos são confiáveis?

INJEÇÃO

SQL Injection

Quando dados fornecidos pelo usuário interferem indevidamente na consulta SQL.

RISCO: ALTO

Definição

SQL Injection ocorre quando uma aplicação monta consultas SQL utilizando dados externos de forma insegura.

O problema não está no SQL em si. O problema acontece quando dados e comandos SQL são tratados como se fossem a mesma coisa.

Exemplo conceitual vulnerável

❌ NÃO FAÇA

SQL

const sql =
  "SELECT * FROM usuarios WHERE nome = '"
  + nomeUsuario
  + "'";

✅ PREFIRA

SQL

const sql =
  "SELECT * FROM usuarios WHERE nome = ?";

db.query(sql, [nomeUsuario]);

Boa prática: utilize consultas parametrizadas / prepared statements e nunca confie que um valor recebido do usuário seja seguro.

🧪 Laboratório — Separando código e dados

Nesta simulação não executaremos SQL real. Vamos observar a diferença entre concatenar dados em uma consulta e utilizar parâmetros.

Clique em uma opção para executar a simulação.

Etapa ainda não concluída.

INJEÇÃO NO NAVEGADOR

Cross-Site Scripting — XSS

Quando conteúdo controlado pelo usuário é interpretado como HTML ou script no navegador.

RISCO: ALTO

Definição

XSS ocorre quando uma aplicação permite que conteúdo não confiável seja interpretado pelo navegador como código ou marcação ativa.

Uma das medidas mais importantes é diferenciar texto de HTML.

❌ CUIDADO COM innerHTML

JavaScript

resultado.innerHTML =
  entradaUsuario;

✅ TEXTO COM textContent

JavaScript

resultado.textContent =
  entradaUsuario;

🧪 Laboratório — Texto versus HTML

O texto abaixo representa uma entrada fornecida por um usuário. Observe como o navegador deve tratá-la como texto.

ENTRADA SIMULADA

<strong>Texto fornecido pelo usuário</strong>

Resultado aparecerá aqui.

Defesa: escape/encode de saída, validação, sanitização quando HTML realmente for necessário e políticas de segurança como CSP ajudam a reduzir riscos de XSS.

Etapa ainda não concluída.

REQUISIÇÕES

Cross-Site Request Forgery — CSRF

Quando uma aplicação aceita uma ação sem verificar adequadamente se a requisição foi realmente autorizada pelo usuário.

RISCO: ALTO

Definição

Em determinadas arquiteturas, um navegador autenticado pode enviar automaticamente credenciais associadas a uma sessão.

O CSRF procura explorar justamente a ausência de uma confirmação adicional de intenção para determinadas operações.

Defesa tradicional

Uma técnica comum é utilizar um token CSRF imprevisível e verificar esse token no servidor.

HTML

<form method="post">

  <input
    type="hidden"
    name="csrf_token"
    value="TOKEN-GERADO-PELO-SERVIDOR"
  >

  <button type="submit">
    Confirmar operação
  </button>

</form>

🧪 Laboratório — Validação de token

Vamos simular a validação de um token sem enviar nenhuma requisição para um servidor.

Aguardando simulação.

Importante: cookies com atributos apropriados, como SameSite, também são parte importante da estratégia de proteção, dependendo da arquitetura.

Etapa ainda não concluída.

AUTENTICAÇÃO

Ataques de Força Bruta

Tentativas repetidas de autenticação para descobrir credenciais.

RISCO: ALTO

Uma aplicação que permite tentativas ilimitadas de login pode facilitar ataques automatizados.

A defesa não consiste apenas em aumentar a complexidade da senha. É necessário controlar também o comportamento das tentativas.

⏱️ Atraso Introduzir atraso progressivo após falhas.

🚦 Rate Limit Limitar quantidade de tentativas.

🔐 MFA Adicionar segundo fator de autenticação.

🧪 Laboratório — Bloqueio após tentativas

A simulação representa um sistema que bloqueia temporariamente o acesso após várias falhas.

Aguardando simulação.

JavaScript — MODELO CONCEITUAL

if (tentativasFalhas >= limite) {

  bloquearTemporariamente();

}

Etapa ainda não concluída.

SESSÃO

Sequestro de Sessão

Comprometimento de um identificador de sessão utilizado para representar um usuário autenticado.

RISCO: ALTO

Aplicações Web frequentemente utilizam um identificador associado à sessão do usuário. Se esse identificador for exposto ou tratado de maneira insegura, a conta pode ficar em risco.

Proteções importantes

HTTPS.
Cookies com Secure.
Cookies com HttpOnly.
SameSite quando apropriado.
Regeneração do identificador após autenticação.
Expiração adequada da sessão.
Logout correto.

HTTP COOKIE

Set-Cookie:
  sessao=valor-aleatorio;
  Secure;
  HttpOnly;
  SameSite=Lax;

🧪 Laboratório — Ciclo de uma sessão

Nenhuma sessão criada.

Não faça: nunca coloque identificadores de sessão em URLs, logs públicos, código JavaScript desnecessário ou mensagens expostas ao usuário.

Etapa ainda não concluída.

IDENTIDADE

Falhas de Autenticação

Problemas no processo de identificação e validação do usuário.

RISCO: CRÍTICO

Autenticação responde à pergunta: “Quem é você?”

Falhas podem ocorrer quando a aplicação utiliza senhas fracas, mensagens de erro reveladoras, recuperação insegura de senha, sessões mal implementadas ou ausência de mecanismos adicionais de proteção.

❌ MENSAGEM REVELADORA

“O usuário existe,
mas a senha está errada.”

✅ MENSAGEM GENÉRICA

“Usuário ou senha
inválidos.”

🧪 Laboratório — Mensagem de autenticação

Aguardando.

Etapa ainda não concluída.

AUTORIZAÇÃO

Controle de Acesso

Garantir que cada usuário possa executar somente as ações permitidas para sua função.

RISCO: CRÍTICO

Autenticação e autorização são conceitos diferentes.

Autenticação: quem é o usuário?

Autorização: o usuário pode fazer isso?

JavaScript — MODELO CONCEITUAL

if (!usuario.temPermissao("excluir")) {

  negarAcesso();

  return;
}

excluirRegistro();

🧪 Laboratório — Perfil e permissão

Escolha um perfil.

Regra fundamental: esconder um botão na interface não é controle de acesso. A autorização precisa ser validada no servidor.

Etapa ainda não concluída.

ARQUIVOS

Upload de Arquivos

Como receber arquivos de usuários com segurança.

RISCO: ALTO

Upload de arquivos é uma funcionalidade que exige atenção porque o arquivo recebido passa a fazer parte da infraestrutura da aplicação.

Validações importantes

Extensão permitida.
Tipo MIME esperado.
Tamanho máximo.
Nome gerado pelo servidor.
Local de armazenamento adequado.
Permissões corretas.
Verificação adicional quando necessária.

❌ NÃO CONFIE SOMENTE NA EXTENSÃO

MODELO

if (arquivo.nome.endsWith(".jpg")) {

  aceitarArquivo();

}

✅ VALIDAR VÁRIOS ATRIBUTOS

MODELO

validarTamanho(arquivo);

validarTipo(arquivo);

validarConteudo(arquivo);

gerarNomeSeguro(arquivo);

armazenarForaDaÁreaExecutável();

🧪 Laboratório — Validação de arquivo

Selecione um arquivo para iniciar a simulação.

Etapa ainda não concluída.

NAVEGADOR

Clickjacking

Técnica que procura induzir o usuário a clicar em uma interface diferente daquela que acredita estar utilizando.

RISCO: MÉDIO / ALTO

Uma defesa importante é impedir que páginas sensíveis sejam incorporadas em frames de origens não autorizadas.

Exemplo de cabeçalho

HTTP HEADER

Content-Security-Policy:
  frame-ancestors 'self';

OUTRA PROTEÇÃO

X-Frame-Options: SAMEORIGIN

🧪 Laboratório — Política de enquadramento

Aguardando verificação.

Etapa ainda não concluída.

APIs

Segurança de APIs

Proteção de endpoints, dados, autenticação e autorização.

RISCO: CRÍTICO

Uma API expõe funcionalidades da aplicação para outros sistemas, aplicativos ou interfaces. Cada endpoint precisa considerar autenticação, autorização, validação e tratamento de erros.

🔑 Autenticação Identificar quem está fazendo a chamada.

🚪 Autorização Verificar o que o usuário pode fazer.

🧪 Validação Validar parâmetros recebidos.

📦 Respostas Não retornar dados desnecessários.

⏱️ Limites Controlar frequência de chamadas.

📝 Logs Registrar eventos sem expor segredos.

MODELO DE ENDPOINT

GET /api/produtos

1. Autenticar usuário
2. Autorizar operação
3. Validar parâmetros
4. Executar operação
5. Retornar somente os dados necessários
6. Registrar evento relevante

🧪 Laboratório — Pipeline de segurança da API

Aguardando.

Etapa ainda não concluída.

CONTROLE DE TRÁFEGO

Rate Limiting

Controle da quantidade de requisições que podem ser realizadas em determinado intervalo.

PROTEÇÃO

Rate limiting ajuda a controlar abuso, excesso de requisições, automações indesejadas e determinados tipos de ataques.

O limite deve ser definido de acordo com a funcionalidade. Um endpoint de login pode possuir uma política diferente de um endpoint de consulta pública.

MODELO CONCEITUAL

if (requisicoesNoPeriodo >= limite) {

  retornarErro429();

} else {

  processarRequisicao();

}

🧪 Laboratório — Simulação de Rate Limit

Nenhuma requisição simulada.

Resposta HTTP: quando o servidor limita requisições, o status 429 Too Many Requests é frequentemente utilizado.

Etapa ainda não concluída.

CRIPTOGRAFIA

Criptografia e Hash de Senhas

Como proteger credenciais e diferenciar criptografia de hashing.

RISCO: CRÍTICO

Criptografia

Criptografia normalmente permite que um dado seja transformado e posteriormente recuperado utilizando uma chave apropriada.

Hash

Hash é uma transformação de mão única. Em sistemas de autenticação, senhas não devem ser armazenadas em texto puro.

Para senhas, aplicações modernas devem utilizar algoritmos específicos para armazenamento de senhas, como Argon2id, bcrypt ou scrypt, com parâmetros adequados.

❌ NUNCA ARMAZENE ASSIM

PHP — EXEMPLO

$senha = $_POST['senha'];

INSERT INTO usuarios
(senha)
VALUES
('$senha');

✅ USE HASH ESPECÍFICO PARA SENHAS

PHP

$hash = password_hash(
    $senha,
    PASSWORD_DEFAULT
);

password_verify(
    $senha,
    $hash
);

⚠️ Atenção: o exemplo de hash abaixo usa SHA-256 apenas para demonstrar o conceito matemático de uma função hash no navegador. Não utilize SHA-256 puro para armazenar senhas em produção.

🧪 Laboratório — Hash de demonstração

O hash aparecerá aqui.

Etapa ainda não concluída.

DESAFIO

Auditoria de Segurança

Imagine que você recebeu um pequeno sistema Web para avaliar. Analise cada item e identifique qual mecanismo de segurança deveria ser utilizado.

Login

Controle de tentativas
Senha com hash adequado
MFA quando apropriado

Banco de dados

Prepared statements
Privilégio mínimo
Validação de entrada

Upload

Limite de tamanho
Validação de tipo
Armazenamento seguro

API

Autenticação
Autorização
Rate limiting

PROJETO FINAL

Security Review

Realize uma análise de segurança de uma aplicação Web didática. O objetivo é identificar riscos, explicar o impacto e propor medidas de proteção.

01 Identificar Encontre pontos vulneráveis.

02 Classificar Avalie o risco.

03 Corrigir Proponha uma solução.

Entrega esperada: um documento contendo vulnerabilidade, evidência, impacto, correção proposta e resultado esperado.

REVISÃO

Resumo da Aula

SQL Injection → consultas parametrizadas

XSS → tratar entrada como texto quando apropriado

CSRF → validar intenção e origem da operação

Força Bruta → limitar tentativas

Sessão → proteger identificadores

Autenticação → confirmar identidade

Acesso → verificar autorização

Upload → validar arquivos

Clickjacking → controlar framing

APIs → autenticar, autorizar e validar

Rate Limit → controlar frequência

Senhas → utilizar hash apropriado

Regra principal: segurança deve ser considerada desde o projeto da aplicação, e não somente depois que um problema aparece.

🛡️

Aula concluída!

Você estudou os principais conceitos de segurança Web abordados nesta aula e realizou simulações práticas.

Continue praticando a identificação de riscos e, principalmente, a implementação das correções.

Por que estudar Segurança Web?

Seu progresso

O modelo mental da Segurança Web

SQL Injection

Definição

Exemplo conceitual vulnerável

🧪 Laboratório — Separando código e dados

Cross-Site Scripting — XSS

Definição

🧪 Laboratório — Texto versus HTML

Cross-Site Request Forgery — CSRF

Definição

Defesa tradicional

🧪 Laboratório — Validação de token

Ataques de Força Bruta

🧪 Laboratório — Bloqueio após tentativas

Sequestro de Sessão

Proteções importantes

🧪 Laboratório — Ciclo de uma sessão

Falhas de Autenticação

🧪 Laboratório — Mensagem de autenticação

Controle de Acesso

🧪 Laboratório — Perfil e permissão

Upload de Arquivos

Validações importantes

🧪 Laboratório — Validação de arquivo

Clickjacking

Exemplo de cabeçalho

🧪 Laboratório — Política de enquadramento

Segurança de APIs

🧪 Laboratório — Pipeline de segurança da API

Rate Limiting

🧪 Laboratório — Simulação de Rate Limit

Criptografia e Hash de Senhas

Criptografia

Hash

🧪 Laboratório — Hash de demonstração

Checklist de Segurança

Auditoria de Segurança

Security Review

Resumo da Aula

Aula concluída!