← CEH: avaliação ética, evidência e correções
05 / 9 · 50 MIN

Aplicações web e reteste de correções

Distingue autenticação, autorização, validação e contexto de saída.

Conceito e mecanismo

Autenticar um utilizador não torna válidos todos os pedidos que envia. A aplicação deve verificar direitos, limites e transições de estado no servidor. Uma quantidade negativa pode violar um invariante financeiro mesmo quando o pedido passa pelo login. A interface não é uma fronteira suficiente porque a API pode receber pedidos diretamente. Na construção de SQL, parâmetros protegem valores, mas nomes de colunas concatenados precisam de um desenho controlado, como mapear escolhas permitidas para identificadores definidos pelo servidor. Para XSS, o contexto de saída importa: tratamento de texto HTML não deve ser considerado proteção universal para JavaScript inline ou outros contextos de interpretação.

Aplicação guiada

Num projeto fictício de reembolsos, usa contas e saldos sintéticos para retestar valores inválidos, limites e operações autorizadas. Corrigir apenas o formulário não demonstra a correção da API. Para operações por cookie que alteram estado, POST não constitui proteção anti-CSRF por si só; valida os mecanismos adequados do framework e a origem conforme o desenho. Num serviço que consulta URLs, controla os destinos realmente contactados, incluindo redirecionamentos, em vez de validar apenas a primeira ligação. Cada reteste deve conter um pedido legítimo que continua a funcionar e um pedido indevido que é recusado. Regista a versão e a fronteira testada para a equipa de produção reproduzir a evidência.

NA PRÁTICA

Formulário corrigido e API não retestada: a aceitação da correção continua pendente.

Armadilhas comuns

Login como validade do pedido; parâmetros como proteção de toda a sintaxe; POST como anti-CSRF; primeiro URL como cadeia completa.

Tópicos relacionados: Âmbito, autorização e relatório de risco · Reconhecimento e limites da observação · Sistemas, vulnerabilidades e evidência

Leva esta ideia contigo

Aceita a correção quando o controlo do servidor foi demonstrado.

Criar conta

Referência: SQL injection prevention · CEH 312-50, Exam Blueprint v5.0 effective2024-04-10; Candidate Handbook v7.3 (2026-09-21)

Certified Ethical Hacker® e CEH® são marcas registadas de EC-Council. A dr.pt é uma plataforma de preparação independente e não está afiliada, associada, patrocinada, autorizada nem aprovada por EC-Council. Os conteúdos e as perguntas são originais, não são perguntas oficiais de exame, e concluir os nossos testes não atribui nem garante qualquer certificação. Os nomes são usados apenas para identificar o tema. Todas as outras marcas pertencem aos respetivos titulares.