Corriger les problèmes identifiés par Web Security Scanner

Cette page explique comment interpréter, reproduire et corriger les résultats Web Security Scanner.

Les rôles IAM pour Security Command Center peuvent être attribués au niveau de l'organisation, du dossier ou du projet. Votre capacité à afficher, modifier, créer ou mettre à jour des résultats, des éléments, et les sources de sécurité dépendent du niveau d'accès accordé. Pour en savoir plus sur les rôles Security Command Center, consultez la page Contrôle des accès.

Classes de faille

Web Security Scanner détecte les classes de failles suivantes :

  • Script intersites (XSS)
  • Falsification de requête côté serveur (SSRF)
  • Injection Flash
  • Contenu mixte
  • Bibliothèques obsolètes ou vulnérables
  • Mots de passe en texte clair
  • Validation de l'origine non sécurisée
  • En-têtes non valides
  • En-têtes mal orthographiés
  • Dépôts accessibles
  • injection SQL
  • Injection XML
  • Prototype pollution

Si l'une de ces failles est détectée, le résultat est mis en évidence pour que vous puissiez l'explorer en détail.

Impact sur les journaux

Des traces d'analyses de Web Security Scanner apparaissent dans vos fichiers journaux. Par exemple, Web Security Scanner génère des requêtes pour des chaînes inhabituelles telles que ~sfi9876 et /sfi9876. Ce processus permet à l'analyse d'examiner les pages d'erreurs de votre application. Ces requêtes de page intentionnellement non valides apparaissent dans vos journaux.

Désactivation des résultats après résolution

Une fois que vous avez corrigé une faille, Web Security Scanner ne définit pas automatiquement l'état de la découverte correspondante dans Security Command Center sur INACTIVE. Sauf si vous modifiez l'état manuellement, l'état des résultats générés par Web Security Scanner dans Security Command Center reste ACTIVE.

Si vous utilisez la version autonome de Web Security Scanner, une fois qu'une faille a été corrigée et que Web Security Scanner ne peut plus la détecter, les rapports de failles suivants ne l'incluent pas. Il reste une trace de la vulnérabilité dans les rapports sur les failles précédents.

Web Security Scanner exécute des analyses gérées chaque semaine.

Pour en savoir plus sur les analyses Web Security Scanner, consultez Types d'analyses

Corriger les problèmes identifiés par Web Security Scanner

Cette section explique comment corriger différents types de résultats de Web Security Scanner. Pour découvrir les stratégies de protection contre les attaques courantes au niveau des applications décrites dans le Top 10 de la fondation OWASP, consultez la section Top 10 des options d'atténuation de l'OWASP sur Google Cloud.

XSS

Nom de la catégorie dans l'API : XSS

Le test d'injection de scripts intersites (XSS) de Web Security Scanner simule une attaque par injection en insérant une chaîne de test bénigne dans des champs modifiables par l'utilisateur, puis en effectuant diverses actions utilisateur. Des détecteurs personnalisés observent le navigateur et le DOM pendant ce test pour déterminer si l'injection a produit le résultat escompté et évaluer son potentiel d'exploitation.

Si le code JavaScript contenu dans la chaîne de test s'exécute correctement, il lance le débogueur de Chrome. Lorsqu'une chaîne de test peut s'exécuter, il est possible d'injecter et d'exécuter du code JavaScript sur la page. Si un pirate informatique a détecté ce problème, il pourrait exécuter un code JavaScript de son choix en tant qu'utilisateur (victime) qui clique sur un lien malveillant.

Dans certains cas, l'application testée peut modifier la chaîne de test avant son analyse par le navigateur. Par exemple, l'application peut valider l'entrée ou limiter la taille d'un champ. Lorsque le navigateur tente d'exécuter cette chaîne de test modifiée, il est probable qu'une erreur d'exécution JavaScript se produise. L'erreur indique un problème d'injection, mais il n'est peut-être pas possible de l'exploiter.

Pour résoudre ce problème, vous devez vérifier si le problème est lié à une faille XSS en vérifiant manuellement si les modifications de chaîne de test peuvent être éliminées. Pour obtenir des informations détaillées sur la façon de vérifier cette faille, consultez la page Script intersites.

Il existe plusieurs façons de corriger ce problème. La correction recommandée consiste à faire échapper toute la sortie et à utiliser un système de création de modèles compatible avec l'échappement automatique contextuel.

XSS angular callback

Nom de la catégorie dans l'API : XSS_ANGULAR_CALLBACK

Une faille de script intersites (XSS) dans les modules AngularJS peut se produire lorsqu'une chaîne fournie par l'utilisateur est interpolée par Angular. L'injection de valeurs fournies par l'utilisateur dans une interpolation AngularJS peut permettre les attaques suivantes :

  • Un pirate informatique peut injecter du code arbitraire dans la page affichée par les navigateurs.
  • Un pirate informatique peut également accomplir des actions au nom du navigateur victime dans l'origine de la page.

Pour reproduire cette faille potentielle, cliquez sur le lien "URL de reproduction" dans Google Cloud Console après avoir exécuté l'analyse. Ce lien ouvre directement une boîte de dialogue d'alerte ou injecte la chaîne XSSDETECTED pour prouver que l'attaque peut exécuter du code. En cas d'injection de la chaîne, vous pouvez ouvrir les outils pour les développeurs de votre navigateur et rechercher XSSDETECTED afin de connaître la position exacte de l'injection.

XSS error

Nom de la catégorie dans l'API : XSS_ERROR

Un résultat XSS_ERROR est un bug XSS potentiel dû à la rupture de JavaScript. Dans certains cas, l'application testée peut modifier la chaîne de test avant son analyse par le navigateur. Lorsque le navigateur tente d'exécuter cette chaîne de test modifiée, il est probable qu'une erreur d'exécution JavaScript se produise. Cette erreur indique un problème d'injection, mais il n'est peut-être pas possible de l'exploiter.

Pour résoudre ce problème, vous devez vérifier si le problème est lié à une faille XSS en vérifiant manuellement si les modifications de chaîne de test peuvent être éliminées. Pour obtenir des informations détaillées sur la façon de vérifier cette faille, consultez la page Script intersites.

Server side request forgery

Nom de la catégorie dans l'API : SERVER_SIDE_REQUEST_FORGERY

Une faille SERVER_SIDE_REQUEST_FORGERY permet à un utilisateur d'application Web d'accéder à des données internes en forçant un serveur à envoyer une requête (comme une requête HTTP) à un point de terminaison de service restreint. Par exemple, un pirate informatique peut exploiter cette faille pour récupérer des données à partir du service de métadonnées Google Cloud.

Pour résoudre ce problème, utilisez une liste d'autorisation pour limiter les domaines et les adresses IP auxquels l'application Web peut envoyer des requêtes.

Rosetta flash

Nom de la catégorie dans l'API : ROSETTA_FLASH

Web Security Scanner peut constater que la valeur d'un paramètre de requête est renvoyée au début d'une réponse (par exemple, dans les requêtes utilisant JSONP). Cette faille est également appelée injection Flash. Dans certains cas, un pirate informatique peut amener le navigateur à exécuter la réponse comme s'il s'agissait d'un fichier Flash fourni par l'application Web vulnérable.

Pour résoudre ce problème, n'incluez pas de données contrôlables par l'utilisateur au début d'une réponse HTTP.

Mixed content

Nom de la catégorie dans l'API : MIXED_CONTENT

Web Security Scanner observe de manière passive le trafic HTTP et détecte lorsqu'une requête visant un fichier JavaScript ou CSS est effectuée via HTTP, dans le contexte d'une page HTTPS. Dans ce scénario, un pirate de type "homme du milieu" pourrait détourner la ressource HTTP et obtenir un accès complet au site Web qui charge la ressource ou surveiller les actions effectuées par les utilisateurs.

Pour résoudre ce problème, utilisez des liens HTTP relatifs. Par exemple, remplacez http:// par //.

Outdated library

Nom de la catégorie dans l'API : OUTDATED_LIBRARY

Web Security Scanner peut détecter que la version d'une bibliothèque incluse présente un problème de sécurité connu. En s'appuyant sur des signatures, Web Security Scanner tente d'identifier la version de la bibliothèque utilisée et la compare à une liste connue de bibliothèques vulnérables. L'analyse peut renvoyer des faux positifs si la détection de la version échoue ou si la bibliothèque a été corrigée manuellement.

Pour résoudre ce problème, installez une version sécurisée connue de la bibliothèque incluse dans votre application.

Struts insecure deserialization

Nom de la catégorie dans l'API : STRUTS_INSECURE_DESERIALIZATION

Web Security Scanner peut détecter que votre application Web utilise une version d'Apache Struts qui est vulnérable aux attaques par injection de commandes à distance. Les versions de Struts concernées peuvent analyser de manière incorrecte l'en-tête HTTP "Content-Type" non valide fourni par un pirate informatique. Cette faille permet d'exécuter les commandes malveillantes avec les droits du serveur Web.

Voici les versions vulnérables d'Apache Struts :

  • Versions 2.3.x antérieures à la version 2.3.32
  • Versions 2.5.x antérieures à la version 2.5.10.1

Pour résoudre ce problème, mettez à niveau Apache Struts vers la dernière version.

Pour en savoir plus sur la faille d'Apache Struts, consultez la page CVE-2017-5638.

Cacheable password input

Nom de la catégorie dans l'API : CACHEABLE_PASSWORD_INPUT

Web Security Scanner peut détecter que, lors de la saisie d'un mot de passe, l'application Web utilise un élément <input> dont l'attribut type n'est pas défini sur password. Cela peut conduire les navigateurs à mettre en cache le mot de passe saisi par l'utilisateur dans le cache du navigateur standard plutôt que de le stocker dans un espace sécurisé.

Pour résoudre ce problème, ajoutez l'attribut type à l'élément <input>, puis définissez-le sur password (par exemple, <input type="password">). Cet attribut masque les caractères que l'utilisateur saisit dans le champ de mot de passe.

Clear text password

Nom de la catégorie dans l'API : CLEAR_TEXT_PASSWORD

Web Security Scanner peut détecter que l'application semble transmettre un champ de mot de passe en texte clair. Un pirate informatique peut espionner le trafic réseau et intercepter le mot de passe saisi dans le champ.

Pour protéger les informations sensibles échangées entre le client et le serveur, prenez toujours les précautions suivantes :

  • Utilisez des certificats TLS/SSL.
  • Utilisez systématiquement le protocole HTTPS pour les pages incluant des champs de mot de passe.
  • Assurez-vous que les attributs "form action" pointent toujours vers une URL HTTPS.

Insecure allow origin ends with validation

Nom de la catégorie dans l'API : INSECURE_ALLOW_ORIGIN_ENDS_WITH_VALIDATION

Web Security Scanner peut détecter qu'un point de terminaison HTTP ou HTTPS intersites ne valide qu'un suffixe de l'en-tête de requête Origin avant de le refléter dans l'en-tête de réponse Access-Control-Allow-Origin. Si la validation est mal configurée, le point de terminaison peut accorder l'accès à un domaine malveillant ayant le même suffixe qu'un domaine ajouté à la liste d'autorisation. Par exemple, si l'outil de validation des points de terminaison correspond à des domaines tels que *google.com, il peut accorder par erreur l'accès à maliciousdomaingoogle.com.

Pour résoudre ce problème, vérifiez que le domaine racine attendu fait partie de la valeur d'en-tête Origin avant de le refléter dans l'en-tête de réponse Access-Control-Allow-Origin. Pour les caractères génériques de sous-domaine, ajoutez le point au domaine racine, par exemple .endsWith(".google.com").

Insecure allow origin starts with validation

Nom de la catégorie dans l'API : INSECURE_ALLOW_ORIGIN_STARTS_WITH_VALIDATION

Web Security Scanner peut détecter qu'un point de terminaison HTTP ou HTTPS intersites ne valide qu'un préfixe de l'en-tête de requête Origin avant de le refléter dans l'en-tête de réponse Access-Control-Allow-Origin. Si la validation est mal configurée, le point de terminaison peut accorder l'accès à un domaine malveillant ayant le même préfixe qu'un domaine autorisé. Par exemple, si l'outil de validation des points de terminaison vérifie uniquement si le domaine demandeur contient google.com, il peut accorder par erreur l'accès à google.com.maliciousdomain.com.

Pour corriger ce résultat, vérifiez que le domaine attendu correspond entièrement à la valeur de l'en-tête Origin avant de le refléter dans l'en-tête de réponse Access-Control-Allow-Origin (par exemple, .equals(".google.com")).

Session ID leak

Nom de la catégorie dans l'API : SESSION_ID_LEAK

Web Security Scanner peut trouver un identifiant de session dans l'en-tête de requête Referer des requêtes interdomaines de votre application Web. Les domaines recevant le Referer peuvent utiliser l'identifiant de session pour emprunter l'identité d'un utilisateur (à l'aide de son jeton) ou identifier l'utilisateur de manière unique.

Pour résoudre ce problème, stockez les identifiants de session dans des cookies plutôt que dans URL. De plus, sécurisez vos cookies à l'aide des attributs suivants :

  • HTTPOnly : attribut qui rend les cookies inaccessibles aux scripts côté client.
  • Secure : attribut qui rend les cookies transmissibles uniquement via HTTPS.

Invalid content type

Nom de la catégorie dans l'API : INVALID_CONTENT_TYPE

Web Security Scanner peut détecter qu'une ressource ne correspondant pas à l'en-tête HTTP Content-Type de la réponse a été chargée. Dans ce scénario, l'application renvoie un contenu sensible avec un type de contenu non valide ou sans en-tête X-Content-Type-Options: nosniff.

Pour résoudre ce problème, vérifiez les points suivants :

  • les réponses JSON sont diffusées avec l'en-tête Content-Type application/json ;
  • tous les autres types de réponses sensibles sont diffusés avec les types MIME appropriés ;
  • le contenu est diffusé avec l'en-tête HTTP X-Content-Type-Options: nosniff.

Invalid header

Nom de la catégorie dans l'API : INVALID_HEADER

Web Security Scanner peut détecter qu'un en-tête de sécurité présente une erreur de syntaxe, ce qui génère un en-tête mal formé ou non valide. Par conséquent, le navigateur ignore ces en-têtes.

Les en-têtes valides sont décrits dans les sections suivantes.

En-tête "Referrer-Policy"

Une règle d'URL de provenance contient l'une des valeurs suivantes :

  • Une chaîne vide
  • no-referrer
  • no-referrer-when-downgrade
  • same-origin
  • origin
  • strict-origin
  • origin-when-cross-origin
  • strict-origin-when-cross-origin
  • unsafe-url

En-tête "X-Frame-Options"

Un en-tête X-Frame-Options valide ne peut avoir que les valeurs suivantes :

  • DENY : interdire tout l'encadrement.
  • SAMEORIGIN : autoriser l'encadrement si l'URL de premier niveau a la même origine.
  • ALLOW-FROM URL

Chrome n'est pas compatible avec ALLOW-FROM URL. L'utilisation de plusieurs en-têtes X-Frame-Options n'est pas autorisée.

En-tête "X-Content-Type-Options"

Un en-tête X-Content-Type-Options valide ne peut avoir qu'une seule valeur : nosniff.

En-tête "X-XSS-Protection"

Un en-tête X-XSS-Protection valide doit commencer par 0 ("désactiver") ou par 1 ("activer"). Ensuite, uniquement si vous activez la protection, vous pouvez ajouter jusqu'à deux options :

  • mode=block affiche une page vide au lieu de filtrer le script XSS.
  • report=URL envoie des rapports à URL.

Séparez les options par un point-virgule (par exemple, 1; mode=block; report=URI). Vérifiez que vous n'avez pas de point-virgule final.

Misspelled security header name

Nom de la catégorie dans l'API : MISSPELLED_SECURITY_HEADER_NAME

Web Security Scanner peut trouver un nom d'en-tête de sécurité mal orthographié. En raison de cette faute, l'en-tête de sécurité est inefficace et doit être corrigé.

Pour reproduire cette faille, recherchez la faute d'orthographe dans l'onglet "Réseau" des outils de développement de votre navigateur.

Mismatching security header values

Nom de la catégorie dans l'API : MISMATCHING_SECURITY_HEADER_VALUES

Web Security Scanner peut détecter que la réponse contient des en-têtes de réponse liés à la sécurité en double avec des valeurs conflictuelles. Si des en-têtes HTTP liés à la sécurité sont déclarés deux fois dans la réponse avec des valeurs incompatibles, leur comportement peut être perturbé.

Pour corriger ce problème, ne conservez qu'un seul de ces en-têtes incompatibles.

Dépôt accessible

Web Security Scanner peut détecter un dépôt GIT ou SVN accessible dans l'application. Cela peut entraîner des fuites de code source et de configuration.

Pour reproduire la faille, cliquez sur l'URL de reproduction dans le rapport de recherche.

XXE reflected file leakage

Nom de la catégorie dans l'API : XXE_REFLECTED_FILE_LEAKAGE

Web Security Scanner peut détecter une faille XML External Entity (XXE) sur une application Web qui analyse XML à partir des entrées utilisateur. Un pirate informatique peut fournir un fichier XML contenant une entité externe. Cette entité externe peut faire référence à du contenu auquel l'application a accès, par exemple des fichiers sur la machine hôte de l'application. Lorsque l'analyseur XML de l'application traite le fichier XML malveillant, il peut divulguer le contenu des fichiers de son hôte.

Pour corriger ce résultat, configurez vos analyseurs XML de manière à interdire les entités externes.

Pour plus d'informations sur cette faille, consultez la page Traitement des entités externes XML (XMLE).

SQL injection

Nom de la catégorie dans l'API : SQL_INJECTION

Web Security Scanner peut détecter une faille d'injection SQL. Les pirates informatiques peuvent créer des entrées qui manipulent la structure de la requête SQL sous-jacente exécutée sur le serveur. Ces entrées leur permettent d'exfiltrer les données de la base de données et, dans certains cas, de les modifier. Pour résoudre ce résultat, utilisez des requêtes paramétrées afin d'empêcher l'entrée utilisateur d'affecter la structure de la requête SQL.

Pour en savoir plus sur cette faille, consultez la page Injection SQL.

Prototype pollution

Nom de la catégorie dans l'API : PROTOTYPE_POLLUTION

Web Security Scanner peut détecter un prototype de faille de pollution sur une application Web dont les propriétés d'objet sont affectées à des valeurs contrôlables par les pirates informatiques. Les pirates informatiques peuvent créer des entrées qui rendent l'application vulnérable aux scripts intersites ou à d'autres failles côté client.

Pour résoudre ce résultat, supprimez la propriété obsolète proto et rendez l'objet Object.prototype immuable. Si cette mesure d'atténuation est incompatible avec votre code, modifiez la partie de code vulnérable pour ne copier que les valeurs attendues à partir des entrées pouvant être contrôlées par d'éventuels pirates informatiques.

Vérifier le problème

Lorsque Web Security Scanner signale un problème, vous devez vérifier l'emplacement du problème. Cette section explique comment utiliser les rapports de résultats pour reproduire et vérifier les failles.

  1. Accédez à la page Web Security Scanner dans la console Google Cloud.

    Accéder à Web Security Scanner

  2. Sélectionnez un projet. Une page contenant la liste de vos analyses gérées et personnalisées s'affiche.

  3. Sous Analyser les configurations, sélectionnez l'analyse contenant le résultat que vous souhaitez vérifier. La page qui s'ouvre contient les détails de l'analyse.

  4. Accédez à l'onglet Résultats, développez une catégorie, puis sélectionnez un résultat pour afficher ses détails.

  5. La méthode de validation varie en fonction de la catégorie de résultat. Utilisez un navigateur de test, puis suivez les instructions ci-dessous.

    • Script intersites : le suivi de l'URL de reproduction génère une fenêtre pop-up vide dans le navigateur, indiquant que l'analyse a correctement injecté du code anodin dans un script.
    • Bibliothèque obsolète : le suivi de l'URL Vulnerable renvoie une page contenant le texte "Exploited", indiquant que l'analyse a correctement injecté du code anodin dans un script.
    • Contenu mixte : le suivi de l'URL de la page HTTPS renvoie un avertissement concernant une faille de contenu mixte. Le rapport de résultats identifie la ressource vulnérable sous l'URL de la ressource diffusée via HTTP.
    • Injection Flash : Web Security Scanner peut renvoyer des résultats dans cette catégorie, mais la plupart des navigateurs modernes sont protégés contre l'injection Flash. Il est peu probable que ces résultats puissent être exploités.
    • Polluisation du prototype: suivez l'URL indiquée dans le champ URL de reproduction. et rechercher les modifications apportées à l'objet Object.prototype présenté par la charge utile, à l'aide des extraits JavaScript suivants.
      • ({}).__secret_injected_property
      • ({}).__defineGetter__.__secret_injected_property
      • ({}).hasOwnProperty.__secret_injected_property

L'application de Content Security Policy (CSP) peut toujours empêcher l'exécution du code JavaScript. Il peut donc être plus difficile de reproduire le script XSS. Si vous rencontrez ce problème, consultez la console de journalisation du navigateur pour plus d'informations sur la violation CSP survenue.