CompTIA SY0-701: Segurança de Aplicação e Web — Guia de estudos
Faz parte do CompTIA Security+ SY0-701 — Guia de estudos. Pratique com respostas verificadas no centro de exames da CompTIA, ou faça testes cronometrados no ExamRoll.io.
Aplicações modernas se encontram na interseção da lógica de negócios, dados sensíveis e entradas de usuário não confiáveis. Como os front-ends web e mobile são expostos a toda a internet, eles representam uma das maiores e mais consistentemente exploradas superfícies de ataque em qualquer empresa. Defendê-las exige controles em camadas que começam na forma como o código é escrito e se estendem por proteções em tempo de execução, verificação de integridade e testes contínuos.
Ataques de Injeção
A injeção continua sendo a vulnerabilidade web arquetípica. Ela ocorre sempre que uma aplicação concatena uma entrada não confiável em um interpretador — uma consulta SQL, um comando de shell, um filtro LDAP, um parser XML ou um motor de template — sem separar adequadamente o código dos dados. Em uma injeção de SQL (SQLi), um invasor manipula uma consulta para que o banco de dados execute uma lógica controlada pelo invasor. Um padrão vulnerável clássico em PHP se parece com isto:
$query = "SELECT * FROM users WHERE username = '" . $_GET['user'] . "'";
Submeter admin' OR '1'='1 transforma a consulta em uma tautologia que retorna todas as linhas. Variantes mais avançadas incluem extração baseada em union (' UNION SELECT credit_card FROM payments--), inferência cega booleana ou baseada em tempo (' AND SLEEP(5)--) e exfiltração out-of-band por meio de callbacks de DNS. A correção definitiva são as consultas parametrizadas ou as instruções preparadas (prepared statements), que enviam o modelo da consulta e seus parâmetros para o banco de dados como estruturas separadas:
cursor.execute("SELECT * FROM users WHERE username = %s", (user_input,))
A injeção de comando segue o mesmo padrão, mas visa o shell do sistema operacional. Um código como os.system("ping " + host) permite que um invasor envie 8.8.8.8; cat /etc/passwd e execute comandos arbitrários. A remediação exige evitar totalmente a invocação do shell, usando APIs que aceitam arrays de argumentos (subprocess.run(["ping", host], shell=False)) e aplicando uma validação estrita de lista de permissão (allow-list) a qualquer valor que precise chegar a um shell.
Cross-Site Scripting e CSRF
Cross-site scripting (XSS) é a injeção de script malicioso em páginas renderizadas por uma aplicação confiável, fazendo com que o navegador da vítima execute o código do invasor dentro da origem do site. O XSS refletido reflete payloads a partir de um parâmetro vulnerável; o XSS armazenado persiste o payload no banco de dados e o entrega a todos os visualizadores; o XSS baseado em DOM ocorre inteiramente no JavaScript do lado do cliente que escreve dados não confiáveis em innerHTML, document.write ou sinks similares. As consequências variam de sequestro de sessão e keylogging até a tomada de controle total da conta por meio de ações forçadas.
Cross-site request forgery (CSRF) é um ataque distinto, mas complementar. Ele abusa da inclusão automática de cookies pelo navegador para enganar um usuário autenticado e fazê-lo enviar uma requisição indesejada — por exemplo, um formulário oculto em um site malicioso que faz um POST para bank.com/transfer. As defesas incluem tokens sincronizadores (valores aleatórios por sessão embutidos em formulários e verificados no lado do servidor), o atributo de cookie SameSite=Lax ou SameSite=Strict e a exigência de reautenticação para ações sensíveis. XSS e CSRF são frequentemente confundidos, mas o XSS executa código no navegador da vítima, enquanto o CSRF simplesmente faz com que o navegador emita uma requisição; notavelmente, um ataque de XSS bem-sucedido pode anular a maioria das defesas contra CSRF.
Codificação Segura: Validação de Entrada vs. Codificação de Saída
Dois controles são frequentemente confundidos, mas resolvem problemas diferentes. A validação de entrada (input validation) garante que os dados estejam em conformidade com a estrutura esperada — comprimento, tipo, conjunto de caracteres, intervalo, formato — antes que a aplicação atue sobre eles. Ela deve ocorrer no servidor, usando listas de permissão (allow-lists) sempre que possível (^[A-Za-z0-9_]{3,20}$ para um nome de usuário). A validação do lado do cliente usando JavaScript é apenas um recurso de usabilidade; ela pode ser contornada com qualquer proxy HTTP e nunca deve ser a barreira de segurança.
A codificação de saída (output encoding) garante que os dados sejam renderizados com segurança em qualquer contexto para o qual fluam. A mesma string que é uma entrada perfeitamente válida pode precisar de tratamento diferente dependendo de onde ela vai parar: o contexto do corpo HTML requer codificação de entidade HTML (< → <), o contexto de atributo requer codificação de atributo entre aspas, o contexto JavaScript requer escape \xHH e as URLs requerem codificação de percentual (percent-encoding). Um nome de usuário como O'Brien é uma entrada legítima, mas deve ser codificado como O'Brien ao ser colocado em HTML. A validação de entrada não pode substituir a codificação de saída, e a codificação não pode substituir a validação — elas abordam problemas diferentes em pontos diferentes do ciclo de vida dos dados.
O fortalecimento adicional inclui cabeçalhos de Content Security Policy (CSP) para restringir as fontes de script, flags HttpOnly e Secure em cookies de sessão e APIs parametrizadas em todas as fronteiras de confiança.
WAFs e Proteções de Upload de Arquivos
Um firewall de aplicação web (WAF) inspeciona o tráfego HTTP e bloqueia requisições que correspondem a padrões maliciosos conhecidos — assinaturas de SQLi, payloads de XSS, sequências de path traversal, anomalias de protocolo. Implantado como um proxy reverso (ModSecurity com o OWASP Core Rule Set, AWS WAF, Cloudflare, F5), ele fornece um valioso patching virtual quando uma vulnerabilidade é descoberta antes que o código possa ser corrigido. No entanto, um WAF é um controle compensatório, não um substituto para a codificação segura. Invasores sofisticados rotineiramente contornam WAFs por meio de truques de codificação, poluição de parâmetros HTTP e fragmentação de payload.
Uploads de arquivos merecem atenção especial porque combinam conteúdo não confiável com armazenamento no lado do servidor e, muitas vezes, execução. As proteções incluem validar o tipo de arquivo inspecionando os bytes mágicos em vez de confiar na extensão ou no cabeçalho Content-Type, armazenar os uploads fora do web root, renomear os arquivos para identificadores gerados pelo servidor (prevenindo path traversal por meio de nomes de arquivo criados para esse fim), escanear com antivírus antes do armazenamento e servir o conteúdo enviado pelo usuário a partir de um domínio separado para evitar a execução de scripts de mesma origem (same-origin).
Cenário Prático: Injeção de SQL Levando ao Comprometimento Total do Banco de Dados
O endpoint de busca de produtos de uma empresa de varejo aceitava um parâmetro category que era concatenado diretamente em uma consulta SQL sem sanitização. Um pesquisador de segurança descobriu que submeter ' UNION SELECT table_name,null,null FROM information_schema.tables-- retornava uma lista de todas as tabelas do banco de dados na resposta. Requisições subsequentes extraíram a tabela customers, resultando em 1,2 milhão de registros, incluindo nomes, endereços de e-mail e senhas com hash bcrypt. O atacante também descobriu uma stored procedure que poderia ser invocada via injeção de SQL para gravar arquivos na raiz da web, permitindo a implantação de um webshell e o comprometimento total do servidor. A vulnerabilidade estava presente há três anos e não foi detectada em dois testes de penetração anteriores porque os testadores haviam testado apenas o formulário de login, e não o endpoint de busca. A lição: os testes de injeção devem cobrir todos os parâmetros em todos os endpoints, não apenas os caminhos de autenticação óbvios.
← Resposta a Incidentes · Todos os domínios · Segurança de Cloud →
Pratique estas questões → · Prática cronometrada no ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Passe no seu exame →