Controles e testes de segurança para aplicações Web e Web Services
Neste recorte, você vê quatro pontos que mais caem em prova sobre segurança de aplicações web e Web Services: controle de acesso, criptografia de senhas, injeção e proteção de mensagens SOAP.
Segurança da Informação · 4 Controles e testes de segurança · Atualizado em
Segurança de aplicações web e de Web Services aparece com frequência em concursos de Segurança da Informação. As bancas costumam cobrar duas coisas: o que fazer em cada caso e por que um controle isolado não resolve o problema. Abaixo, quatro pontos centrais.
1. Controle de acesso só é confiável no servidor
A quebra de controle de acesso subiu para o primeiro lugar do OWASP Top 10:2021, o que a torna um dos temas mais cobrados. A ideia central é que o usuário não pode agir além das suas permissões, e a verificação precisa acontecer onde o atacante não consegue mexer: no código do servidor.
Algumas regras que a prova explora:
- Negar por padrão (deny by default). Só é liberado o que for público ou expressamente permitido.
- Verificar a propriedade do registro. Um usuário só acessa o dado que lhe pertence, mesmo que informe outro identificador na URL.
- Aplicar a regra uma única vez e reutilizá-la em toda a aplicação.
- Em sessões com estado, invalidar o identificador no servidor após o logout.
- Em JWT sem estado, usar vida curta. Para JWT de vida longa, seguir os padrões OAuth de revogação.
⚠️ Pegadinha: ocultar um botão na tela não é controle de acesso. A verificação precisa existir no servidor, porque o atacante pode enviar a requisição diretamente.
🧠 Memorize: negue por padrão, verifique no servidor, registre e limite (deny by default, servidor, logs, rate limit).
2. Senhas exigem hash lento, com salt e fator de trabalho
Na categoria de falhas criptográficas, a banca gosta de testar o armazenamento de senhas. Hash rápido, mesmo com salt, pode ser quebrado por placas de vídeo com grande poder de processamento.
- Errado: MD5 ou SHA1 puros, sem salt, ou hash rápido de uso geral.
- Certo: funções adaptativas, com salt e fator de trabalho, como Argon2, scrypt, bcrypt ou PBKDF2.
Outro ponto que costuma aparecer: em modos de operação que usam nonce, o IV não precisa vir de um gerador criptograficamente seguro. Mesmo assim, ele nunca pode ser reutilizado com a mesma chave.
📌 Cai muito: senha com hash adaptativo, salt e fator de trabalho. Hash sem salt e hash rápido são as respostas erradas.
3. Injeção: separe dados de comandos
A injeção ficou em terceiro lugar no OWASP e cobre SQL, comandos de sistema operacional, LDAP, ORM e outros interpretadores. O princípio é um só: os dados enviados pelo usuário não podem ser interpretados como parte do comando.
A ordem de preferência é a mesma em quase todas as questões:
- API segura ou consulta parametrizada, que evita o interpretador.
- Validação positiva de entrada no servidor, como camada complementar.
- Escape de caracteres, apenas para o que ainda for dinâmico.
A validação de entrada não é defesa completa, porque muitas aplicações precisam aceitar caracteres especiais. Nomes de tabelas e colunas não podem ser escapados, então, quando vierem do usuário, são um risco à parte.
💡 Dica: se a pergunta pede a melhor forma de detectar injeção, a resposta é a revisão de código-fonte. Se pede detecção antes da produção, pense em ferramentas SAST, DAST e IAST no pipeline CI/CD.
4. Web Services precisam proteger a própria mensagem
Em Web Services baseados em XML e SOAP, o perímetro da rede não basta. As trocas são dinâmicas, passam por intermediários e o HTTP atravessa a maioria dos firewalls sem restrição.
O TLS protege a conexão entre dois pontos, mas não a mensagem em si. Quando há intermediários, a mensagem precisa ser protegida como documento. Por isso, a prova compara:
- TLS: criptografa e autentica o canal entre dois endpoints.
- XML Encryption: garante confidencialidade do documento XML.
- XML Signature: garante integridade, assinando seletivamente os dados.
- WS-Security: extensões de cabeçalho SOAP para troca de mensagens assinadas e criptografadas ponta a ponta.
⚠️ Pegadinha: TLS sozinho não resolve a segurança de SOAP com intermediários. A proteção precisa acompanhar a mensagem.
Continue estudando
A aula completa deste tema, com os mapas mentais e os flashcards com repetição espaçada, está disponível no plano do MemorizeCards. Você pode ver os planos ou ver o catálogo para escolher o formato ideal para a sua rotina de estudos.
Perguntas frequentes
Por que o controle de acesso precisa ficar no servidor?
Porque o atacante consegue alterar tudo o que roda no navegador, como o código da tela e os metadados enviados. A verificação feita apenas no cliente pode ser contornada com facilidade. O servidor é o único lugar confiável para impor a regra.
Qual a melhor forma de armazenar senhas segundo o OWASP?
Use funções de hash adaptativas, com salt e fator de trabalho, como Argon2, scrypt, bcrypt ou PBKDF2. Hashes rápidos, como MD5 e SHA1, são fáceis de quebrar com hardware moderno. O fator de trabalho torna cada tentativa de adivinhação mais custosa.
Validação de entrada basta para prevenir injeção de SQL?
Não. A validação é uma camada complementar, porque muitas aplicações precisam aceitar caracteres especiais. A defesa preferida é a consulta parametrizada ou a API segura, que separa os dados dos comandos. Nomes de tabelas e colunas vindos do usuário devem ser evitados, pois não podem ser escapados.