Skip to main content

Testes de Casos

Este guia irá orientá-lo sobre como escrever e executar testes para verificar a infraestrutura implantada, com foco em validar os recursos de segurança do Google Cloud, como Cloud Armor, Rate Limiting, reCAPTCHA, WAF (Web Application Firewall) e Cloud Edge.

Pré-Requisitos​

  • Sua infraestrutura deve já estar implantada e acessível (por exemplo, via SSH, API ou console de gerenciamento de nuvem).
  • Certifique-se de que as regras de segurança, como Cloud Armor, estejam configuradas corretamente.

Passo 1: Preparar o Ambiente de Testes​

Antes de iniciar os testes, verifique se os recursos de segurança estão configurados no GCP. Isso inclui:

  • Cloud Armor: Protege contra ataques e abusos, como DDoS.
  • Rate Limiting: Limita o número de requisições por unidade de tempo.
  • reCAPTCHA: Protege seus serviços contra bots.
  • WAF (Web Application Firewall): Filtra o tráfego HTTP/S e previne ataques.
  • Cloud Edge: Acelerador de conteúdo que pode incluir regras de segurança.

Exemplo de Ambiente de Teste:​

  1. Acesse o painel do Google Cloud Console.
  2. Certifique-se de que as configurações de segurança estão corretamente configuradas no Cloud Armor.
  3. Tenha os scripts de teste prontos para execução.

Passo 2: Testes de Segurança Cloud Armor​

As regras são avaliadas por prioridade: os números mais baixos são avaliados primeiro e, uma vez acionados, o processamento não continua para regras com valores de prioridade mais altos.

2.1 Teste de Rate Limiting com Cloud Armor [Application]​

O Cloud Armor permite configurar Rate Limiting para limitar o número de requisições por IP. Para testar a configuração de Rate Limiting, você pode usar o seguinte comando para fazer múltiplas requisições consecutivas e verificar se o limite está sendo aplicado corretamente.

Teste de Rate Limiting:​

  1. Criando o Script tests.sh:
cat > tests.sh << EOF
# Envia 100 requisições para verificar o rate limit
for i in {1..100}; do
    curl -I http://$APP_DOMINIO.com
done
EOF
  1. Executando o teste:
chmod +x tests.sh && ./tests.sh

2.2 Teste de WAF (Web Application Firewall) [OWASP Juice Shop application]​

O WAF protege contra ataques comuns, como injeções de SQL ou XSS.

Observe a proteção do Cloud Armor com o conjunto de regras principais do OWASP ModSecurity Regras implementadas:

  • Prioridade 9000 - Bloquear LFI (inclusão de arquivo local)
  • Prioridade 9001 - Bloquear RCE (execução remota de código/injeção de comando)
  • Prioridade 9002 - Bloquear scanners detectados
  • Prioridade 9003 - Bloqueio de ataques de protocolo, como divisão de HTTP e contrabando de HTTP
  • Prioridade 9004 - Bloqueio de ataques de fixação de sessão
  • Prioridade 10000 - Permitir que seu IP acesse o site
  • Prioridade padrão - Negar.

Teste de uma vulnerabilidade LFI: travessia de caminho​

A Inclusão de Arquivo Local é o processo de observar arquivos presentes no servidor explorando a falta de validação de entrada na solicitação para potencialmente expor dados sensíveis. O seguinte mostra que uma travessia de caminho é possível. No seu navegador ou com curl, observe um caminho existente servido pelo aplicativo.

No Cloud Shell, confirme que a vulnerabilidade do LFI foi mitigada:\

Teste 1

curl -Ii "https://$OWASP_JUICE_DOMINIO/?a=../"

Teste 2

curl -Ii "https://$OWASP_JUICE_DOMINIO/ftp"

Teste 3

curl -Ii "https://$OWASP_JUICE_DOMINIO/ftp/../"

Teste de uma vulnerabilidade RCE​

A Execução Remota de Código (RCE) inclui vários cenários de injeção de comando UNIX e Windows, permitindo que invasores executem comandos do SO geralmente restritos a usuários privilegiados. O exemplo a seguir mostra a execução de um comando ls simples transmitido.

No Cloud Shell, confirme se o ataque RCE foi mitigado:

curl -Ii http://$OWASP_JUICE_DOMINIO/ftp?doc=/bin/ls

Observar o acesso de um scanner conhecido​

Os aplicativos de varredura, tanto comerciais quanto de código aberto, têm várias finalidades, inclusive encontrar vulnerabilidades. Essas ferramentas usam cabeçalhos User-Agent e outros cabeçalhos bem conhecidos. Observe que o curl funciona com um cabeçalho User-Agent bem conhecido.

No Cloud Shell, confirme a detecção do scanner conhecido.:

curl -Ii http://$OWASP_JUICE_DOMINIO -H "User-Agent: blackwidow"

Observe um ataque ao protocolo: Divisão de HTTP​

Alguns aplicativos da Web usam a entrada do usuário para gerar os cabeçalhos nas respostas. Se o aplicativo não filtrar adequadamente a entrada, um invasor poderá envenenar o parâmetro de entrada com a sequência %0d%0a (a sequência CRLF que é usada para separar linhas diferentes).
A resposta poderia então ser interpretada como duas respostas por qualquer coisa que a analisasse, como um servidor proxy intermediário, servindo potencialmente conteúdo falso em solicitações subsequentes. Insira a sequência %0d%0a no parâmetro de entrada, o que pode levar à exibição de uma página enganosa.

No Cloud Shell, a confirmação de um ataque de protocolo é atenuada. De acordo com o OWASP ModSecurity Core Rule Set ver.3.0.2, o ataque ao protocolo é atenuado por:

curl -Ii "http://$OWASP_JUICE_DOMINIO/index.html?foo=advanced%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContent-Length:%2035%0d%0a%0d%0a<html>Sorry,%20System%20Down</html>"

Observar a fixação da sessão​

No Cloud Shell, confirme se as tentativas de fixação de sessão estão bloqueadas:

curl -Ii http://$OWASP_JUICE_DOMINIO/?session_id=a

2.3 Teste de Proteção com Cloud Edge [Storage - Edge Cache]​

As políticas de segurança de borda do Google Cloud Armor permitem restringir o acesso a objetos armazenados em cache no Cloud CDN (Content Delivery Network) e no Cloud Storage. As políticas de segurança de borda são implantadas e aplicadas no perímetro mais externo da rede do Google, a montante de onde reside o cache do Cloud CDN. Os motivos para fazer isso incluem garantir que os usuários não acessem objetos em buckets de armazenamento de regiões geográficas restritas ou que a distribuição de mídia seja filtrada nas regiões geográficas para as quais você tem licença.

Verifique se o Cloud Edge está aplicando regras de segurança e melhorando a entrega de conteúdo.

Verifique a política de segurança​

Você pode verificar se a política do Cloud Armor está em execução.

No Cloud Shell, execute o seguinte comando, que lhe dará um 403:

curl -svo /dev/null http://$STORAGE_DOMINIO/images/cat.png

Um erro 403 ocorre quando você não tem permissão para acessar uma página da Web ou algo em um servidor da Web.