Visão geral do Web Security Scanner

>

Esta página fornece uma visão geral do Web Security Scanner.

Introdução

O Web Security Scanner identifica vulnerabilidades de segurança nos aplicativos da Web do App Engine, Google Kubernetes Engine (GKE) e Compute Engine. Ele segue todos os links no escopo dos URLs iniciais para rastrear seu aplicativo e tenta acessar o máximo possível de entradas do usuário e manipuladores de eventos. Atualmente, o Web Security Scanner é compatível apenas com URLs públicos e IPs que não estão protegidos por firewall.

No momento, o Web Security Scanner é compatível com o ambiente padrão do App Engine e os ambientes flexíveis, as instâncias do Compute Engine e os recursos do GKE.

O Web Security Scanner foi projetado para complementar seus processos de desenvolvimento e design seguros. Para que você não seja distraído com falsos positivos, o Web Security Scanner apresenta baixo desempenho na geração de relatórios e não exibe alertas de baixa confiança. Ele não substitui uma análise de segurança manual e não garante que seu aplicativo esteja livre de falhas de segurança. Para mais informações sobre segurança da Web, acesse o Projeto OWASP Top 10 (em inglês).

Saiba mais sobre a segurança do Google Cloud

Tipos de verificação

O Web Security Scanner fornece verificação de vulnerabilidade da Web gerenciada e personalizada para aplicativos da Web públicos do App Engine, GKE e do Compute Engine.

Verificações gerenciadas

As verificações gerenciadas do Web Security Scanner são configuradas e gerenciadas pelo Security Command Center. As verificações gerenciadas são executadas automaticamente uma vez por semana para detectar e verificar os endpoints da Web públicos. Essas verificações não usam autenticação e enviam solicitações somente GET para que não enviem formulários em sites ativos.

As verificações gerenciadas são executadas separadamente das verificações personalizadas definidas no nível do projeto. É possível usar verificações gerenciadas para gerenciar centralmente a detecção de vulnerabilidades de aplicativos da Web básicos para projetos na organização, sem precisar envolver equipes de projeto individuais. Quando as descobertas são descobertas, trabalhe com essas equipes para configurar verificações personalizadas mais abrangentes.

Quando você ativa o Web Security Scanner como um serviço, as descobertas da verificação gerenciada são disponibilizadas automaticamente na guia vulnerabilidades do Security Command Center e nos relatórios relacionados. Para ver informações sobre como ativar as verificações gerenciadas do Web Security Scanner, consulte Como configurar o Security Command Center.

Verificações personalizadas

As verificações personalizadas do Web Security Scanner fornecem informações detalhadas sobre descobertas de vulnerabilidades de aplicativos, como bibliotecas desatualizadas, scripts entre sites ou uso de conteúdo misto. As descobertas da verificação personalizada estão disponíveis no Security Command Center depois de concluir o guia para configurar verificações personalizadas do Web Security Scanner.

Descobertas de verificação

Essas tabelas incluem uma descrição do mapeamento entre os detectores compatíveis e o melhor mapeamento de esforço para os esquemas de conformidade relevantes.

Os mapeamentos do CIS Google Cloud Foundation 1.0 foram revisados e certificados pelo centro para segurança de internet para o comparativo de mercado do CIS Google Computing Foundations v1.0.0. Os mapeamentos de conformidade adicionais estão incluídos para referência e não são fornecidos ou revisados pelo Padrão de segurança de dados da indústria de cartões de pagamento ou pela OWASP Foundation. Consulte o Comparativo de mercado do CIS Google Cloud Foundations v1.0.0 (CIS Google Cloud Foundation 1.0), Padrão de segurança de dados da indústria de cartões de pagamento 3.2 (PCI-DSS v3.2), OWASP Top, Instituto Nacional de Padrões e Tecnologia 800-53 (NIST 800-53) e Organização Internacional de Padronização 27001 (ISO 27001) para saber como verificar essas violações manualmente.

Essa funcionalidade destina-se apenas ao monitoramento de violações de controles de conformidade. Os mapeamentos não são fornecidos para uso como base ou como substitutos para a auditoria, certificação ou relatório de conformidade dos seus produtos ou serviços com comparativos de mercado ou padrões regulatórios ou do setor.

Veja a seguir os tipos que são identificados pelos leitores personalizados e gerenciados do Web Security Scanner. No nível Standard, o Web Security Scanner é compatível com verificações personalizadas de aplicativos implantados com URLs e IPs públicos que não estão atrás de um firewall.

Tabela 18.Descobertas do Web Security Scanner
Categoria Como encontrar a descrição CIS GCP Foundation 1.0 PCI-DSS v3.2.1 10 principais OWASP NIST 800-53 ISO-27001
ACCESSIBLE_GIT_REPOSITORY Um repositório GIT é exposto publicamente. Para resolver esse problema, remova o acesso público não intencional ao repositório do GIT. A3
ACCESSIBLE_SVN_REPOSITORY Um repositório SVN é exposto publicamente. Para resolver isso, remova o acesso não intencional público ao repositório SVN. A3
CLEAR_TEXT_PASSWORD As senhas estão sendo transmitidas em texto não criptografado e podem ser interceptadas. Para resolver isso, criptografe a senha transmitida pela rede. A3
INVALID_CONTENT_TYPE Um recurso foi carregado e ele não corresponde ao cabeçalho HTTP da resposta Content-Type. Para resolver isso, defina o cabeçalho HTTP "X-Content-Type-Options" com o valor correto. A6
INVALID_HEADER Um cabeçalho de segurança tem um erro de sintaxe e será ignorado pelos navegadores. Para resolver isso, defina os cabeçalhos de segurança HTTP corretamente. A6
MISMATCHING_SECURITY_HEADER_VALUES Um cabeçalho de segurança tem valores duplicados e incompatíveis, o que resulta em comportamento indefinido. Para resolver isso, defina os cabeçalhos de segurança HTTP corretamente. A6
MISSPELLED_SECURITY_HEADER_NAME Um cabeçalho de segurança é escrito incorretamente e é ignorado. Para resolver isso, defina os cabeçalhos de segurança HTTP corretamente. A6
MIXED_CONTENT Os recursos são exibidos por HTTP em uma página HTTPS. Para resolver isso, todos os recursos precisam ser exibidos por HTTPS. A6
OUTDATED_LIBRARY Foi detectada uma biblioteca com vulnerabilidades conhecidas. Para resolver isso, faça o upgrade das bibliotecas para uma versão mais recente. A9
XSS Um campo nesse aplicativo da Web é vulnerável a um ataque de script entre sites (XSS). Para resolver isso, valide e escapar os dados não confiáveis fornecidos pelo usuário. A7
XSS_ANGULAR_CALLBACK Uma string fornecida pelo usuário não tem escape e pode ser interpolada pelo AngularJS. Para resolver isso, valide e escape dados não confiáveis fornecidos pelo usuário manipulados pela estrutura Angular. A7
XSS_ERROR Um campo neste aplicativo da Web é vulnerável a um ataque de scripting em vários locais. Para resolver isso, valide e evite escape dados não confiáveis fornecidos pelo usuário. A7

Avisos de uso

Algumas ressalvas importantes ao usar o Web Security Scanner:

  • Por causa das constantes atualizações, uma verificação futura pode relatar problemas que não são relatados pela atual.
  • Alguns recursos ou seções do seu aplicativo podem não ser testados.
  • O Web Security Scanner tenta ativar todos os controles e entradas que encontra.
  • Se você expuser as ações de alteração de estado para as quais sua conta de teste tem permissão, é provável que elas sejam ativadas pelo Web Security Scanner. Isso pode levar a resultados indesejáveis.

Quem pode executar uma verificação de segurança?

Para mais informações sobre os papéis de gerenciamento de identidade e acesso (IAM, na sigla em inglês) disponíveis para o Web Security Scanner, consulte Controle de acesso.

Quanto tempo uma verificação de segurança leva para ser feita?

A verificação de segurança não é executada imediatamente. Ela fica na fila e é executada mais tarde, possivelmente horas depois, dependendo da carga do sistema. Assim que a verificação é iniciada, o tempo necessário dependerá do tamanho do seu aplicativo. Aplicativos grandes com muitos URLs podem levar várias horas para serem concluídos.

Restrições de segmentação

O Web Security Scanner tem filtros que restringem os destinos de verificação à instância específica do App Engine para a qual a verificação é criada. A inserção de URLs para um projeto diferente do App Engine ou para um domínio externo gera uma mensagem de erro.

No seu projeto, o Web Security Scanner tenta automaticamente evitar URLs de saída e outros locais genéricos que possam afetar negativamente uma verificação. Para ter certeza, use as configurações de verificação para excluir URLs manualmente.

Práticas recomendadas

Como o Web Security Scanner preenche os campos, envia botões, clica em links e executa outras ações do usuário, use-o com cautela. O Web Security Scanner pode ativar recursos que alteram o estado dos dados ou do sistema, com resultados indesejáveis.

Por exemplo:

  • Em um aplicativo de blog que permite comentários públicos, o Web Security Scanner pode postar strings de teste como comentários em todos os artigos do seu blog.
  • Em uma página de inscrição de e-mail, o Web Security Scanner pode gerar um grande número de e-mails de teste.

Veja a seguir algumas técnicas que você pode usar, separadamente ou em combinação, para evitar resultados indesejados:

  1. Execute as verificações em um ambiente de teste. Para criar um ambiente de teste, crie um projeto separado do App Engine e, neste local, carregue seu aplicativo e seus dados. Se você usar a ferramenta de linha de comando gcloud, será possível especificar o projeto de destino como uma opção de linha de comando ao fazer upload do seu aplicativo.
  2. Use uma conta de teste. Crie uma conta de usuário que não tenha acesso a dados confidenciais ou operações perigosas para usar ao verificar seu app. Vários aplicativos apresentam um fluxo de trabalho especial durante o primeiro login do usuário, com aceitar termos e criar um perfil. Por causa do diferente fluxo de trabalho, uma conta de teste para um usuário inicial pode ter resultados de verificação diferentes da conta de usuário estabelecida. É recomendado que a verificação seja feita com uma conta com estado norma de usuário, depois que o fluxo inicial já tenha sido concluído.
  3. Bloqueie elementos individuais da interface do usuário que você não quer ativar aplicando a classe CSS inq-no-click. Os manipuladores de evento conectados a este elemento não são ativados durante o rastreamento e teste, independentemente de eles serem JavaScript inline ou anexados usando addEventListener ou configurando a propriedade do manipulador de eventos apropriado.
  4. Faça backup dos dados. Faça um backup dos dados antes da verificação.
  5. URLs excluídos. Especifique os padrões de URL que não serão rastreados ou testados. Para saber informações sobre a sintaxe, consulte Como excluir URLs.

Antes da verificação, faça uma auditoria minuciosa do seu aplicativo para detectar qualquer recurso que possa afetar os dados, usuários ou sistemas além do escopo pretendido para a verificação.

A seguir