Esta página explica como interpretar, reproduzir e corrigir as descobertas do Web Security Scanner.
Os papéis do IAM para o Security Command Center podem ser concedidos no nível da organização, da pasta ou do projeto. A capacidade de ver, editar, criar ou atualizar descobertas, recursos e fontes de segurança depende do nível a que você tem acesso. Para saber mais sobre Para papéis do Security Command Center, consulte Controle de acesso.
Classes de vulnerabilidade
O Web Security Scanner detecta as seguintes classes de vulnerabilidades:
- Scripting em vários locais (XSS)
- Falsificação de solicitação do lado do servidor
- Injeção Flash
- Conteúdo misto
- Bibliotecas desatualizadas ou vulneráveis
- Senhas não criptografadas
- Validação de origem não segura
- Cabeçalhos inválidos
- Cabeçalhos com erros ortográficos
- Repositórios acessíveis
- injeção de SQL
- Injeção XML
- Poluição de protótipos
Se alguma vulnerabilidade for encontrada, o resultado será destacado para que você explore os detalhes.
Impacto nos registros
Traces de verificações do Web Security Scanner são exibidos nos seus arquivos de registros. Por exemplo,
o Web Security Scanner gera solicitações para strings incomuns, como ~sfi9876
e /sfi9876
. Esse processo permite que a verificação examine as páginas de erro do
aplicativo. Essas solicitações de páginas intencionalmente inválidas aparecerão nos seus registros.
Desativação das descobertas após a correção
Depois que você corrige uma vulnerabilidade, o Web Security Scanner não define automaticamente o estado da descoberta correspondente do Security Command Center como INACTIVE
.
A menos que você altere o estado manualmente, o estado das descobertas geradas pelo Web Security Scanner no Security Command Center permanecerá ACTIVE
.
Se você estiver usando a versão independente do Web Security Scanner, depois que você corrigir uma vulnerabilidade e o Web Security Scanner não conseguir mais detectá-la, os relatórios de vulnerabilidade subsequentes não incluirão a vulnerabilidade. Um registro da vulnerabilidade permanece nos relatórios de vulnerabilidade anteriores.
O Web Security Scanner faz verificações gerenciadas semanalmente.
Para saber mais sobre as verificações do Web Security Scanner, consulte Tipos de verificações.
Como corrigir descobertas do Web Security Scanner
Veja nesta seção como corrigir diferentes tipos de descobertas do Web Security Scanner. Para ver estratégias para se defender contra ataques comuns no nível do aplicativo descritos em 10 principais do OWASP, consulte as 10 principais opções de mitigação do OWASP no Google Cloud.
XSS
Nome da categoria na API: XSS
O teste de injeção de scripting em vários locais (XSS, na sigla em inglês) do Web Security Scanner simula um ataque de injeção por meio da inserção de uma string de teste benigna em campos editáveis pelo usuário, e a execução de várias ações dos usuários. Detectores personalizados observam o navegador e o DOM durante esse teste para determinar se uma injeção foi executada com sucesso e para avaliar o potencial de exploração.
Se o JavaScript contido na string de teste for executado corretamente, ele iniciará o depurador do Google Chrome. Quando uma string de teste é executada, é possível injetar e executar JavaScript na página. Se um invasor descobrisse esse problema, ele poderia executar qualquer JavaScript como um usuário (vítima) que clica em um link mal-intencionado.
Em algumas circunstâncias, o aplicativo testado pode modificar a string de teste antes que ela tenha sido analisada pelo navegador. Por exemplo, o aplicativo pode validar a entrada ou limitar o tamanho de um campo. Quando o navegador tenta executar essa string de teste modificada, é provável que ele falhe e gere um erro de execução do JavaScript. O erro indica um problema de injeção, mas talvez não seja possível realizá-lo.
Para resolver esse problema, você precisa confirmar se o problema é uma vulnerabilidade do XSS verificando manualmente se é possível remover as modificações da string de teste. Para informações detalhadas sobre como verificar essa vulnerabilidade, consulte Scripting em vários locais.
Existem várias maneiras de corrigir esse problema. A correção recomendada é aplicar o escape a todas as saídas e usar um sistema de modelos compatível com a adição automática de escapes.
XSS angular callback
Nome da categoria na API: XSS_ANGULAR_CALLBACK
Pode ocorrer uma vulnerabilidade de scripting em vários locais (XSS) nos módulos AngularJS quando o Angular interpola uma string fornecida pelo usuário. A injeção de valores fornecidos pelo usuário em uma interpolação do AngularJS pode permitir os seguintes tipos de ataques:
- Um invasor pode injetar um código arbitrário na página renderizada pelos navegadores.
- Um invasor pode executar ações em nome do navegador da vítima na origem da página.
Para reproduzir essa vulnerabilidade em potencial, siga o link URL de reprodução em
no console do Google Cloud depois de executar a verificação. Esse link abre diretamente uma
caixa de diálogo de alerta ou injeta a string XSSDETECTED
para provar que o ataque pode executar
o código. Se a string for injetada, abra as ferramentas do desenvolvedor do seu
navegador e pesquise por XSSDETECTED
para encontrar a posição exata da
injeção.
XSS error
Nome da categoria na API: XSS_ERROR
Uma descoberta de XSS_ERROR
é um possível bug de XSS devido ao rompimento de JavaScript. Em algumas circunstâncias, o aplicativo em teste pode modificar a string de teste
antes de o navegador analisá-la. Quando o navegador tenta executar essa string de teste
modificada, é provável que ele falhe e gere um erro de execução do JavaScript. Este erro
indica um problema de injeção, mas talvez não seja possível analisá-lo.
Para resolver esse problema, você precisa confirmar se o problema é uma vulnerabilidade do XSS verificando manualmente se é possível remover as modificações da string de teste. Para informações detalhadas sobre como verificar essa vulnerabilidade, consulte Scripting em vários locais.
Server side request forgery
Nome da categoria na API: SERVER_SIDE_REQUEST_FORGERY
Uma vulnerabilidade SERVER_SIDE_REQUEST_FORGERY
permite que um usuário do aplicativo da Web tenha acesso a dados internos forçando um servidor a fazer uma solicitação (como uma solicitação HTTP) a um endpoint de serviço restrito. Por exemplo, um invasor pode explorar essa vulnerabilidade para recuperar dados do serviço de metadados do Google Cloud.
Para resolver esse problema, use uma lista de permissões para limitar os domínios e endereços IP em que o aplicativo da Web pode fazer solicitações.
Rosetta flash
Nome da categoria na API: ROSETTA_FLASH
O Web Security Scanner pode descobrir que o valor de um parâmetro de solicitação é refletido no início de uma resposta, por exemplo, em solicitações que usam JSONP. Essa vulnerabilidade também é conhecida como injeção Flash. Em determinadas circunstâncias, um invasor pode fazer o navegador executar a resposta como se fosse um arquivo Flash fornecido pelo aplicativo vulnerável da Web.
Para corrigir esse erro, não inclua dados que podem ser controlados pelo usuário no início de uma resposta HTTP.
Mixed content
Nome da categoria na API: MIXED_CONTENT
O Web Security Scanner observa passivamente o tráfego HTTP e detecta quando uma solicitação de um arquivo JavaScript ou CSS é executada por HTTP no contexto de uma página HTTPS. Nesse cenário, um invasor "man-in-the-middle" pode adulterar o recurso HTTP para ter acesso total ao site que carrega o recurso ou para monitorar as ações realizadas pelo usuário.
Para corrigir esse problema, use links HTTP relativos. Por exemplo, substitua http://
por
//
.
Outdated library
Nome da categoria na API: OUTDATED_LIBRARY
O Web Security Scanner pode descobrir que a versão de uma biblioteca incluída pode conter um problema de segurança. O Web Security Scanner é um verificador baseado em assinatura que tenta identificar a versão da biblioteca em uso e a verifica em uma lista conhecida de bibliotecas vulneráveis. Você poderá ter falsos positivos se a detecção da versão falhar ou caso a biblioteca tenha recebido um patch manual.
Para corrigir esse problema, atualize para uma versão segura e conhecida da biblioteca incluída.
Struts insecure deserialization
Nome da categoria na API: STRUTS_INSECURE_DESERIALIZATION
O Web Security Scanner pode descobrir que seu aplicativo da Web está usando uma versão do Apache Struts que é vulnerável a ataques de injeção de comando remoto. As versões afetadas do Struts podem analisar incorretamente o cabeçalho HTTP do tipo de conteúdo inválido de um invasor. Essa vulnerabilidade permite que os comandos maliciosos sejam executados nos privilégios do servidor da Web.
Veja a seguir as versões vulneráveis do Apache Struts:
- Versões 2.3.x anteriores à versão 2.3.32
- Versões 2.5.x anteriores à versão 2.5.10.1
Para corrigir esse problema, faça upgrade do Apache Struts para a versão mais recente.
Para mais informações sobre a vulnerabilidade do Apache Struts, consulte CVE-2017-5638.
Cacheable password input
Nome da categoria na API: CACHEABLE_PASSWORD_INPUT
O Web Security Scanner pode descobrir que, para uma entrada de senha, o aplicativo da Web
usa um elemento <input>
que não tem o atributo type
definido como password
.
Isso pode fazer com que os navegadores armazenem a senha digitada pelo usuário no cache comum do navegador, em vez de um armazenamento de senha seguro.
Para corrigir esse problema, adicione o atributo type
no elemento <input>
e defina-o
como password
. Por exemplo: <input type="password">
.
Esse atributo oculta os caracteres que o usuário digita no campo de senha.
Clear text password
Nome da categoria na API: CLEAR_TEXT_PASSWORD
O Web Security Scanner pode descobrir que o aplicativo está transmitindo um campo de senha em texto não criptografado. Um invasor pode interceptar o tráfego de rede e descobrir o campo de senha.
Para proteger informações confidenciais que passam entre o cliente e o servidor, sempre tome as seguintes precauções:
- Use certificados TLS/SSL.
- Sempre use HTTPS em páginas que incluem campos de senha.
- Verifique se os atributos de ação de formulário sempre apontam para um URL HTTPS.
Insecure allow origin ends with validation
Nome da categoria na API: INSECURE_ALLOW_ORIGIN_ENDS_WITH_VALIDATION
O Web Security Scanner talvez descubra que um endpoint HTTP ou HTTPS entre sites
valida apenas um sufixo do cabeçalho de solicitação Origin
antes de refleti-lo
no cabeçalho de resposta Access-Control-Allow-Origin
. Se a validação estiver
configurada incorretamente, o endpoint poderá conceder acesso a um domínio malicioso que tenha o
mesmo sufixo de um domínio permitido. Por exemplo, se o validador do endpoint
corresponder a domínios como *google.com
, ele poderá conceder acesso a maliciousdomaingoogle.com
por engano.
Para corrigir esse problema, valide se o domínio raiz esperado faz parte do valor do cabeçalho
Origin
antes de refleti-lo no cabeçalho
de resposta Access-Control-Allow-Origin
. Para caracteres curinga de subdomínio, adicione o ponto no domínio raiz ao início, por
exemplo, .endsWith(".google.com")
.
Insecure allow origin starts with validation
Nome da categoria na API: INSECURE_ALLOW_ORIGIN_STARTS_WITH_VALIDATION
O Web Security Scanner talvez descubra que um endpoint HTTP ou HTTPS entre sites
valida apenas um prefixo do cabeçalho de solicitação Origin
antes de refleti-lo
no cabeçalho de resposta Access-Control-Allow-Origin
. Se a validação estiver
incorreta, o endpoint poderá conceder acesso a um domínio malicioso que tenha o
mesmo prefixo de um domínio permitido. Por exemplo, se o validador do endpoint
verificar o domínio apenas se o domínio solicitante contiver google.com
, ele poderá conceder acesso a google.com.maliciousdomain.com
por engano.
Para corrigir essa descoberta, valide se o domínio esperado corresponde totalmente ao valor do cabeçalho
Origin
antes de refleti-lo no cabeçalho
de resposta Access-Control-Allow-Origin
, por exemplo, .equals(".google.com")
.
Session ID leak
Nome da categoria na API: SESSION_ID_LEAK
O Web Security Scanner pode encontrar um identificador de sessão no cabeçalho de solicitação Referer
de solicitações entre domínios do aplicativo da Web.
Os domínios que recebem o Referer
podem usar o identificador de sessão para personificar um usuário (usando o token dele) ou identificar exclusivamente o usuário.
Para corrigir essa descoberta, armazene os identificadores de sessão em cookies, em vez do URL. Além disso, proteja seus cookies usando estes atributos:
- HTTPOnly: um atributo que torna os cookies inacessíveis aos scripts do cliente.
- Seguro: um atributo que torna os cookies transmissíveis somente por HTTPS
Invalid content type
Nome da categoria na API: INVALID_CONTENT_TYPE
O Web Security Scanner pode descobrir que um recurso foi carregado que não corresponde
ao cabeçalho HTTP da resposta Content-Type. Nesse cenário, o aplicativo
retorna conteúdo confidencial com um tipo de conteúdo inválido ou sem um
cabeçalho X-Content-Type-Options: nosniff
.
Para corrigir esse problema, verifique se:
- As respostas JSON são exibidas com o cabeçalho Content-Type
application/json
. - Outras respostas confidenciais são disponibilizadas com tipos MIME apropriados.
- Exibir conteúdo com o cabeçalho HTTP
X-Content-Type-Options: nosniff
Invalid header
Nome da categoria na API: INVALID_HEADER
O Web Security Scanner pode descobrir que um cabeçalho de segurança tem um erro de sintaxe, resultando em um cabeçalho de valor inválido ou malformado. Como resultado, o navegador ignora esses cabeçalhos.
Os cabeçalhos válidos são descritos nas seções a seguir.
Cabeçalho da política de referência
Uma política de referenciador válida contém um dos seguintes valores:
- Uma string vazia
no-referrer
no-referrer-when-downgrade
same-origin
origin
strict-origin
origin-when-cross-origin
strict-origin-when-cross-origin
unsafe-url
Cabeçalho X-Frame-Options
Um cabeçalho X-Frame-Options válido só pode ter os seguintes valores:
DENY
: não permite todo o enquadramentoSAMEORIGIN
: permitir o enquadramento se o URL de nível superior for a mesma origemALLOW-FROM URL
O Chrome não é compatível com ALLOW-FROM URL
. Vários X-Frame-Options não
são permitidos.
Cabeçalho X-Content-Type-Options
Um cabeçalho X-Content-Type-Options válido só pode ter um valor: nosniff
.
Cabeçalho X-XSS-Protection
Um cabeçalho X-XSS-Protection válido precisa começar com 0
("desativar") ou
1
("ativar"). Então, somente se você ativar a proteção, poderá adicionar até duas
opções:
mode=block
mostra uma página em branco em vez de filtrar o XSSreport=URL
envia relatórios paraURL
Separe as opções com ponto e vírgula. Por exemplo, 1; mode=block; report=URI
. Verifique
se você há um ponto e vírgula no final da linha.
Misspelled security header name
Nome da categoria na API: MISSPELLED_SECURITY_HEADER_NAME
O Web Security Scanner pode encontrar um nome de cabeçalho de segurança incorreto. O cabeçalho de segurança é ineficaz quando escrito de maneira incorreta e precisa ser corrigido.
Para reproduzir essa vulnerabilidade, verifique o erro de ortografia na guia de rede das ferramentas para desenvolvedores do seu navegador.
Mismatching security header values
Nome da categoria na API: MISMATCHING_SECURITY_HEADER_VALUES
O Web Security Scanner pode descobrir que a resposta tem cabeçalhos de resposta duplicados relacionados à segurança com valores conflitantes. Alguns cabeçalhos HTTP relacionados à segurança apresentam comportamento indefinido se declarados duas vezes na resposta com valores incompatíveis.
Para corrigir esse problema, mantenha apenas um desses cabeçalhos incompatíveis.
Repositório acessível
O Web Security Scanner pode encontrar um repositório GIT ou SVN no aplicativo. Esta condição pode levar a vazamentos de configuração e código-fonte.
Para reproduzir a vulnerabilidade, clique no URL de reprodução no relatório de descobertas.
XXE reflected file leakage
Nome da categoria na API: XXE_REFLECTED_FILE_LEAKAGE
O Web Security Scanner talvez encontre uma vulnerabilidade de entidade externa XML (XXE) em um aplicativo da Web que analisa XML de entradas do usuário. Um invasor pode fornecer um XML que contém uma entidade externa. Essa entidade externa pode referir-se a conteúdo a que o aplicativo tem acesso, por exemplo, arquivos na máquina host do aplicativo. Quando o analisador XML do aplicativo processa o XML malicioso, o conteúdo dos arquivos pode ser vazado no host.
Para corrigir essa descoberta, configure seus analisadores de XML para proibir entidades externas.
Para mais informações sobre essa vulnerabilidade, consulte Processamento de entidade externa de XML (XXE).
SQL injection
Nome da categoria na API: SQL_INJECTION
O Web Security Scanner pode encontrar uma vulnerabilidade de injeção de SQL. Os invasores podem criar entradas que manipulam a estrutura de consulta da consulta SQL subjacente em execução no servidor. Essas entradas permitem exfiltrar dados do banco de dados e, em alguns casos, modificar esses dados. Para resolver essa descoberta, use consultas parametrizadas para evitar que a entrada do usuário influencie a estrutura da consulta SQL.
Para mais informações sobre essa vulnerabilidade, consulte Injeção de SQL.
Prototype pollution
Nome da categoria na API: PROTOTYPE_POLLUTION
O Web Security Scanner pode encontrar uma vulnerabilidade de poluição de protótipos em um aplicativo da Web em que as propriedades de objeto são atribuídas a valores controláveis pelo invasor. Os invasores podem criar entradas que tornam o aplicativo vulnerável a scripting em vários locais ou outras vulnerabilidades do lado do cliente.
Para corrigir essa descoberta, exclua a propriedade proto
descontinuada e torne o objeto Object.prototype
imutável.
Se essa mitigação for incompatível com seu código, mude a parte vulnerável do código para copiar apenas os valores esperados das entradas controladas pelo invasor.
Verificar o problema
Quando o Web Security Scanner relata um problema, você precisa verificar o local do problema. Esta seção explica como usar os relatórios de descoberta para reproduzir e verificar vulnerabilidades.
Acesse a página do Web Security Scanner no console do Google Cloud.
Selecione um projeto. Uma página é exibida com uma lista de verificações gerenciadas e personalizadas.
Em Verificar configurações, selecione a que contém a descoberta que você quer verificar. Uma página é aberta com os detalhes da verificação.
Navegue até a guia Resultados, expanda uma categoria e selecione uma descoberta para ver os detalhes.
O método de verificação é diferente com base na categoria da descoberta. Use um navegador de teste e siga as instruções abaixo.
- Scripting em vários locais: seguir o URL de reprodução gera um pop-up vazio no navegador, indicando que a verificação injetou código benigno em um script.
- Biblioteca desatualizada: seguir o URL vulnerável retorna uma página com o texto "Explorado", indicando que a verificação injetou o código benigno em um script.
- Conteúdo misto: seguir o URL da página HTTPS retorna um aviso sobre uma vulnerabilidade de conteúdo misto. O relatório de descobertas identifica o recurso vulnerável no URL do recurso disponibilizado por HTTP.
- Injeção de Flash: o Web Security Scanner pode retornar descobertas nessa categoria, mas a maioria dos navegadores modernos está protegida contra injeção Flash. É improvável que essas descobertas possam ser exploradas.
- Poluição do protótipo: siga o URL no campo URL de reprodução.
e procurar mudanças no objeto
Object.prototype
introduzidas pelo payload, com os seguintes snippets JavaScript.({}).__secret_injected_property
({}).__defineGetter__.__secret_injected_property
({}).hasOwnProperty.__secret_injected_property
A aplicação da política de segurança de conteúdo (CSP, na sigla em inglês) ainda pode impedir a execução do código JavaScript. Essa condição pode dificultar a reprodução do XSS. Se esse problema ocorrer, verifique o console de registros do navegador para ver detalhes sobre a violação da CSP.