Questão de Segurança da Informação — Ataques a Aplicações Web (XSS, CSRF, SQL Injection etc.) — INSTITUTO AOCP 2024

Segurança em Aplicações Web: CSRF, XSS e SQL Injection

Gabarito: letra A. A prática eficaz para proteger contra CSRF é o uso de tokens CSRF, que validam a legitimidade das requisições, impedindo que um atacante force ações em nome do usuário autenticado. As demais alternativas apresentam práticas incorretas ou insuficientes, como validação apenas no cliente, armazenamento de senhas em texto simples, execução irrestrita de scripts e desabilitação de logs.

O desenvolvimento seguro de aplicações web exige a implementação de controles específicos para cada tipo de ameaça. O CSRF (Cross-Site Request Forgery) explora a confiança que o site deposita no navegador do usuário: o atacante induz a vítima a executar ações indesejadas (como transferências bancárias ou alteração de senha) em uma aplicação na qual ela já está autenticada. A defesa clássica é o token anti-CSRF, um valor aleatório e único embutido em cada formulário ou requisição, que o servidor valida para garantir que a solicitação veio de uma página legítima da própria aplicação — não de um site malicioso.

Já o XSS (Cross-Site Scripting) consiste em injetar scripts maliciosos que são executados no navegador da vítima, dentro do contexto de um site confiável, podendo roubar cookies, tokens de sessão e outras informações sensíveis. A prevenção envolve validação e sanitização de entradas no servidor, codificação de saída e políticas de segurança de conteúdo (CSP). O SQL Injection ocorre quando o atacante manipula as entradas da aplicação para inserir comandos SQL arbitrários nas consultas ao banco de dados. A defesa mais eficaz é o uso de consultas parametrizadas (prepared statements), que separam os dados dos comandos SQL, além de validação rigorosa de entrada.

É importante destacar que a validação de entrada no lado do cliente (JavaScript) é insuficiente e facilmente contornável, pois o atacante pode desabilitar o script ou enviar requisições diretamente ao servidor. A segurança deve ser implementada no servidor, onde os dados são efetivamente processados. Da mesma forma, armazenar senhas em texto simples viola princípios básicos de segurança — o correto é usar hash com salt (ex.: bcrypt, PBKDF2). Permitir execução irrestrita de scripts de terceiros aumenta a superfície de ataque, e desabilitar logs de auditoria compromete a detecção e investigação de incidentes.

A banca explora a confusão entre as defesas de cada ataque: enquanto o CSRF é mitigado com tokens, o XSS exige sanitização de saída e o SQL Injection, consultas parametrizadas. Guarde essa distinção: cada ameaça tem sua contramedida específica, e a alternativa correta é aquela que associa corretamente a defesa ao ataque.

Alternativa A — ✅ Correta ⟵ GABARITO

O uso de tokens CSRF é a prática consagrada para proteger contra ataques de Cross-Site Request Forgery. O token é um valor aleatório gerado pelo servidor, embutido em formulários e requisições, e validado a cada solicitação. Como o atacante não consegue prever ou obter esse token, ele não consegue forjar requisições legítimas em nome do usuário autenticado. Essa é a defesa diretamente associada ao CSRF, conforme descrito no contexto: "Uso de tokens anti-CSRF para validar requisições legítimas".

Alternativa B — ❌ Incorreta

A validação de entrada no lado do cliente é insuficiente para prevenir SQL Injection e XSS. Ela pode ser facilmente contornada pelo atacante, que pode desabilitar o JavaScript ou enviar requisições diretamente ao servidor. A validação deve ser feita no servidor, onde os dados são processados. Para SQL Injection, a defesa eficaz é o uso de consultas parametrizadas; para XSS, a sanitização de saída e a codificação de caracteres. A validação no cliente é apenas uma camada de usabilidade, não de segurança.

Alternativa C — ❌ Incorreta

Armazenar senhas em texto simples é uma prática gravemente insegura. Se o banco de dados for comprometido, todas as senhas ficam expostas. O correto é armazenar apenas o hash da senha, preferencialmente com salt (dado aleatório adicionado antes do hash), usando algoritmos robustos como bcrypt, PBKDF2 ou Argon2. Isso dificulta a recuperação das senhas originais mesmo em caso de vazamento.

Alternativa D — ❌ Incorreta

Permitir que scripts de terceiros sejam executados sem restrições aumenta a superfície de ataque e facilita ataques de XSS e outras vulnerabilidades. Scripts de terceiros podem conter código malicioso ou ser comprometidos, permitindo roubo de dados. A prática segura é restringir a execução de scripts, usar políticas de segurança de conteúdo (CSP) e auditar regularmente as bibliotecas externas.

Alternativa E — ❌ Incorreta

Desabilitar logs de auditoria para melhorar a performance é uma decisão contrária à segurança. Os logs são essenciais para detectar, investigar e responder a incidentes, além de atender a requisitos de conformidade. A falta de logs impede a identificação de ataques e a análise forense. O correto é manter logs adequados, com proteção contra adulteração, e balancear a performance com a necessidade de auditoria.

Gabarito: letra A