Pular para o conteúdo
MemorizeCards

A impressão deste conteúdo não está disponível. Assine o MemorizeCards para estudar este tema com flashcards: https://memorizecards.com.br/planos

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:

  1. API segura ou consulta parametrizada, que evita o interpretador.
  2. Validação positiva de entrada no servidor, como camada complementar.
  3. 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.

Outros temas de TCU

Todos os temas de TCU (Auditor Federal de Controle Externo) · Blog · Catálogo de flashcards