Les péchés mortels en matière de sécurité des sites : ce que nous avons appris des statistiques du scanner de vulnérabilités en un an

Il y a environ un an, nous avons lancé chez DataLine un service un service pour la recherche et l'analyse des vulnérabilités dans les applications IT. À la base du service se trouve la solution cloud Qualys, dont nous avons déjà parlé. En un an d'utilisation de la solution, nous avons effectué 291 scans pour différents sites et accumulé des statistiques sur les vulnérabilités courantes dans les applications web. 

Dans l'article ci-dessous, je vais vous montrer quelles failles de sécurité des sites se cachent derrière différents niveaux de criticité. Voyons quelles vulnérabilités le scanner a détectées particulièrement souvent, pourquoi elles peuvent apparaître et comment se protéger. 

Toutes les vulnérabilités des applications web sont divisées par Qualys en trois niveaux de criticité : faible, moyenne et élevée. En regardant la répartition par "gravel", il semble que ce ne soit pas si grave. Il y a peu de vulnérabilités critiques, la plupart étant non critiques : 

Mais non critiques ne veut pas dire inoffensives. Elles peuvent aussi causer des dommages sérieux. 

Top des vulnérabilités "non critiques"

1. Vulnérabilités liées au contenu mixte.

   La norme de sécurité des sites suppose la transmission des données entre le client et le serveur via le protocole HTTPS, qui supporte le chiffrement et protège les informations d'interception. 

   Certains sites utilisent du contenu mixte: ils transmettent une partie des données via le protocole non sécurisé HTTP. Plus souvent, cela concerne du contenu passif – des informations qui affectent uniquement l'affichage du site : images, styles CSS. Mais parfois, cela concerne aussi du contenu actif: des scripts qui contrôlent le comportement du site. Dans ce cas, un logiciel spécial peut analyser les informations provenant du serveur avec du contenu actif, modifier les réponses en temps réel et forcer la machine à fonctionner de manière non prévue par ses créateurs. 

   Les navigateurs des nouvelles versions avertissent les utilisateurs que les sites avec du contenu mixte ne sont pas sécurisés et bloquent le contenu. Les développeurs de sites reçoivent également des avertissements du navigateur dans la console. Par exemple, voici à quoi cela ressemble dans Firefox: 

   
   
   Quels sont les dangers: Les cybercriminels utilisent un protocole non sécurisé pour intercepter les informations de l'utilisateur, substituer des scripts et envoyer des requêtes au site en son nom. Même si le visiteur du site n'a pas saisi de données, cela ne le protège pas contre le phishing – l'extraction d'informations confidentielles par des méthodes frauduleuses. Par exemple, à l'aide d'un script, il est possible de rediriger l'utilisateur vers un site non sécurisé, qui se masque sous un site familier pour l'utilisateur. Dans certains cas, le site malveillant apparaît même mieux que l'original, et l'utilisateur peut lui-même remplir un formulaire et transmettre ses données confidentielles. 

   Ce qu'un développeur web doit garder à l'esprit: Même si l'administrateur du site a installé et configuré un certificat SSL/TLS, une vulnérabilité peut survenir en raison du facteur humain. Par exemple, si sur l'une des pages un lien absolu avec http a été mis au lieu d'un lien relatif, et de plus si les redirections de http à https ne sont pas configurées. 

   Vous pouvez détecter du contenu mixte sur le site à l'aide d'un navigateur : recherchez dans le code source de la page, lisez les notifications dans la console du développeur. Cependant, le développeur devra passer beaucoup de temps à fouiller dans le code. Le processus peut être accéléré par des moyens d'analyse automatisés, par exemple : SSL Check, le logiciel libre Lighthouse ou le logiciel payant Screaming Frog SEO Spider.

   Une vulnérabilité peut également survenir à cause de problèmes avec du code hérité – du code qui a été transmis. Par exemple, si certaines pages sont générées à partir d'un ancien modèle qui ne tient pas compte de la transition des sites vers https.    

2. Cookies sans les indicateurs « HTTPOnly » et « secure ».

   L'attribut « HTTPOnly » protège les fichiers cookies du traitement par des scripts que les cybercriminels utilisent pour voler des données utilisateur. Le drapeau « secure » n'autorise pas la transmission des cookies en clair. L'échange de données sera autorisé uniquement si les cookies sont envoyés via le protocole sécurisé HTTPS. 

   Les deux attributs sont spécifiés dans les propriétés des cookies :

   Set-Cookie: Secure; HttpOnly

   Quels sont les dangers: Si le développeur du site n'a pas défini ces attributs, le criminel peut intercepter les informations de l'utilisateur à partir des cookies et en faire usage. Si les cookies sont utilisés pour l'authentification et l'autorisation, il peut pirater la session de l'utilisateur et effectuer des actions sur le site en son nom. 

   Ce qu'un développeur web doit garder à l'esprit: En général, dans les frameworks populaires, ces attributs sont définis automatiquement. Mais vérifiez quand même la configuration du serveur Web et activez l'option : Set-Cookie HttpOnly; Secure.

   L'attribut « HTTPOnly » rendra les cookies invisibles même pour votre propre JavaScript.  

3. Vulnérabilités basées sur les chemins.

   Le scanner signale une telle vulnérabilité s'il trouve un fichier ou un répertoire public sur le site contenant des informations potentiellement sensibles. Par exemple, il pourrait détecter des fichiers séparés contenant la configuration du système ou un accès à l'intégralité du système de fichiers. Cela peut se produire si les droits d'accès ne sont pas correctement définis sur le site.

   Quels sont les dangers: Si le système de fichiers est « exposé », un attaquant peut accéder à l'interface du système d'exploitation et essayer de trouver des dossiers contenant des mots de passe, s'ils sont stockés en clair (ne le faites pas !). Il peut aussi voler des hachages de mots de passe, tenter de déduire le mot de passe, et essayer d'élever ses privilèges dans le système pour progresser dans l'infrastructure.  

   Ce qu'un développeur web doit garder à l'esprit: N'oubliez pas les droits d'accès et configurez la plateforme, le serveur Web, l'application Web pour qu'il soit impossible de « fuir » en dehors du répertoire Web.

4. Formulaires pour saisir des données sensibles avec la fonction de remplissage automatique activée.

   Si un utilisateur remplit souvent des formulaires sur des sites, son navigateur sauvegarde ces informations grâce à la fonction de remplissage automatique. 

   Les formulaires sur les sites peuvent inclure des champs contenant des informations sensibles, comme des mots de passe ou des numéros de cartes de crédit. Pour ces champs, la fonction de remplissage automatique du formulaire doit être désactivée sur le site. 

   Quels sont les dangers: Si le navigateur de l'utilisateur sauvegarde des informations sensibles, un attaquant peut les intercepter plus tard, par exemple, par phishing. En gros, le développeur Web qui oublie ce détail met en péril ses utilisateurs. 

   Ce qu'un développeur web doit garder à l'esprit: Dans ce cas, nous avons un conflit classique : confort vs sécurité. Si le développeur Web pense au confort de l'utilisateur, il peut choisir délibérément le remplissage automatique. Par exemple, s'il est important de suivre Les Directives pour l'accessibilité du contenu Web – recommandations pour rendre le contenu accessible aux utilisateurs ayant des handicaps. 

   Pour la plupart des navigateurs, il est possible de désactiver le remplissage automatique avec l'attribut autocomplete="off", par exemple :

    <body>
       <form action="/fr/form/submit/" method="get" autocomplete="off" data-trp-original-action="/form/submit">
         <div>
           <input type="text" placeholder="Prénom">
         </div>
         <div>
           <input type="text" id="lname" placeholder="Nom de famille" autocomplete="on">
         </div>
         <div>
           <input type="number" placeholder="Numéro de carte de crédit">
         </div>
         <input type="submit">
       <input type="hidden" name="trp-form-language" value="fr"/></form>
     </body>

   Mais cela ne fonctionnera pas pour Chrome. On contourne cela avec JavaScript, un exemple de solution peut être trouvé. ici. 

5. L'en-tête X-Frame-Options n'est pas défini dans le code du site. 

   Cet en-tête affecte les balises frame, iframe, embed ou object. Il permet de totalement interdire l'intégration de votre site à l'intérieur d'un cadre. Pour cela, il suffit d'indiquer la valeur X-Frame-Options : deny. Ou vous pouvez spécifier X-Frame-Options : sameorigin, ce qui permettra l'intégration dans un iframe uniquement sur votre domaine.

   Quels sont les dangers: L'absence de cet en-tête peut être exploitée sur des sites malveillants pour le clickjacking.Pour ce type d'attaque, un cybercriminel crée un cadre transparent au-dessus des boutons et trompe l'utilisateur. Par exemple, des escrocs placent dans le cadre une page de réseaux sociaux. L'utilisateur pense qu'il clique sur un bouton sur ce site. Au lieu de cela, le clic est intercepté et envoie la requête de l'utilisateur vers le réseau social où il a une session active. Ainsi, les malfaiteurs envoient du spam au nom de l'utilisateur ou augmentent le nombre de ses abonnés et de ses likes. 

   Si cette possibilité n'est pas interdite, un malveillant peut placer le bouton de votre application sur un site nuisible. Il pourrait être intéressé par votre programme de parrainage ou par vos utilisateurs.  

   Ce qu'un développeur web doit garder à l'esprit: Une vulnérabilité peut apparaître si X-Frame-Options avec une valeur conflictuelle est définie sur le serveur web ou le répartiteur de charge. Dans ce cas, le serveur et le répartiteur écraseront simplement l'en-tête, car ils ont une priorité plus élevée par rapport au code backend.  

   Les valeurs deny et sameorigin de l'en-tête X-Frame-Options peuvent interférer avec le fonctionnement du webvisor de Yandex. Pour autoriser l'utilisation de l'iframe pour le webvisor, il faut écrire une règle distincte dans les paramètres. Par exemple, pour nginx, cela peut être configuré comme suit :

   http{
   ...
    map $http_referer $frame_options {
    "~webvisor.com" "ALLOW-FROM http://webvisor.com";
    default "SAMEORIGIN";
    }
    add_header X-Frame-Options $frame_options;
   ...
   }
   
   

6. Vulnérabilités PRSSI (Importation de feuille de style relative au chemin).  

   Il s'agit d'une vulnérabilité dans les styles du site. Elle survient lorsque des liens relatifs tels que href="/somefolder/styles.css/" sont utilisés pour accéder aux fichiers de styles. Un attaquant en profitera s'il trouve un moyen de rediriger l'utilisateur vers une page malveillante. La page substituera le lien relatif dans son URL et imiterait un appel aux styles. Cela donnerait une requête du type badsite.ru/.../somefolder/styles.css/, qui sous prétexte de style pourrait réaliser des actions malveillantes. 

   Quels sont les dangers: Un escroc pourrait exploiter cette vulnérabilité s'il trouve une autre faille de sécurité. Cela pourrait permettre de voler des données utilisateur à partir des cookies ou des jetons.

   Ce qu'un développeur web doit garder à l'esprit: Définissez l'en-tête X-Content-Type-Options : nosniff. Dans ce cas, le navigateur vérifiera le type de contenu pour les styles. Si le type diffère de text/css, le navigateur bloquera la requête.

Vulnérabilités critiques

1. La page contenant un champ de mot de passe est transmise par le serveur via un canal non sécurisé (HTML form containing password field(s) is served over HTTP).

   La réponse du serveur sur un canal non chiffré est vulnérable aux attaques de type 'Man in the Middle'. Un attaquant peut intercepter le trafic et s'immiscer entre le client et le serveur lorsque la page passe du serveur au client. 

   Quels sont les dangers: Un escroc pourrait remplacer la page et envoyer à l'utilisateur un formulaire pour des données sensibles qui seront envoyées au serveur de l'agresseur. 

   Ce qu'un développeur web doit garder à l'esprit: Certains sites envoient aux utilisateurs un code temporaire par e-mail / téléphone au lieu d'un mot de passe. Dans ce cas, la vulnérabilité n'est pas aussi critique, mais cela complique la vie des utilisateurs.

2. Soumission de formulaire avec identifiant et mot de passe par un canal non sécurisé (Login Form Is Not Submitted Via HTTPS).

   Dans ce cas, un formulaire avec identifiant et mot de passe est envoyé au serveur par un canal non chiffré.

   Quels sont les dangers: Contrairement à l'exemple précédent, il s'agit déjà d'une vulnérabilité critique. Intercepter des données sensibles est plus facile, car il n'est même pas nécessaire d'écrire du code pour cela. 

3. Utilisation de bibliothèques JavaScript avec des vulnérabilités connues.

   Pendant la période d'analyse, la bibliothèque la plus utilisée est devenue jQuery avec une large gamme de versions. Chaque version présente au moins une, voire plusieurs vulnérabilités connues. L'impact peut varier en fonction de la nature de la vulnérabilité.

   Quels sont les dangers: Pour les vulnérabilités connues, il existe des exploits, par exemple :

   
   
   Ce qu'un développeur web doit garder à l'esprit: Revenez régulièrement au cycle : recherche de vulnérabilités connues – correction – vérification. Si vous utilisez des bibliothèques obsolètes de manière consciente, par exemple pour prendre en charge d'anciens navigateurs ou pour économiser un budget, recherchez la possibilité de corriger les vulnérabilités connues. 

4. Scripts intersites (XSS). 
   Le Cross-Site Scripting (XSS) est une attaque sur une application web où du code malveillant apparaît dans la base de données. Si Qualys détecte une telle vulnérabilité, cela signifie qu'un attaquant potentiel peut avoir inséré ou a déjà inséré son script js dans le code du site pour exécuter des actions malveillantes.

   XSS stocké est plus dangereux, car le script est injecté sur le serveur et s'exécute à chaque fois que la page compromise est ouverte dans le navigateur.

   XSS réfléchi est plus simple à réaliser, car le script malveillant peut être injecté dans la requête HTTP. L'application recevra la requête HTTP, ne validera pas les données, les empaquettera et les enverra immédiatement. Si l'attaquant intercepte le trafic et insère un script tel que

   <script>/*+что+то+плохое+*/</script> 

   alors une requête malveillante sera envoyée au nom du client.

   Un exemple frappant de XSS : des js-sniffers qui imitent des pages pour saisir le CVC, la date d'expiration de la carte, etc. 

   Ce qu'un développeur web doit garder à l'esprit: Dans l'en-tête Content-Security-Policy, utilisez l'attribut script-src pour que le navigateur du client ne charge et n'exécute que le code provenant de sources de confiance. Par exemple, script-src 'self' autorise uniquement les scripts venant de notre site. 
   La meilleure pratique consiste à autoriser le code inline : permettez uniquement le javascript inline en utilisant la valeur unsafe-inline. Cette valeur autorise l'utilisation de js/css inline, mais n'interdit pas l'inclusion de fichiers js. En combinaison avec script-src 'self', nous interdisons l'exécution de scripts externes.

   Veillez à enregistrer toutes les tentatives d'injection sur le site à l'aide de report-uri.

5. Injection SQL.
   La vulnérabilité indique la possibilité d'injecter du code SQL sur le site, qui s'adresse directement à la base de données. L'injection SQL est possible si les données utilisateur ne sont pas échappées : elles ne sont pas vérifiées pour être conformes et sont immédiatement utilisées dans la requête. Par exemple, cela se produit si le formulaire sur le site ne vérifie pas la correspondance des entrées avec le type de données. 

   Quels sont les dangers: Si un attaquant entre une requête SQL dans un tel formulaire, il peut faire tomber la base de données ou divulguer des informations confidentielles. 

   Ce qu'un développeur web doit garder à l'esprit: Ne faites pas confiance à ce qui vient du navigateur. La protection doit être assurée à la fois côté client et côté serveur. 

   Côté client, écrivez une validation des champs à l'aide de JavaScript. 

   Les fonctions intégrées dans les frameworks populaires aident également à échapper aux caractères suspects sur le serveur. Il est également recommandé d'utiliser des requêtes paramétrées pour les bases de données sur le serveur.

   Déterminez exactement où se produit l'interaction avec la base de données dans l'application web. 

   L'interaction se produit lorsque nous récupérons des informations : une requête avec un id (changement d'id), création d'un nouvel utilisateur, nouveau commentaire, – nouvelles entrées dans la base. Des injections SQL peuvent se produire ici. Même en supprimant une entrée de la base, une injection SQL est possible.

Recommandations générales

Ne réinventez pas la roue – utilisez des frameworks éprouvés. En général, les frameworks populaires sont plus sûrs. Pour .NET, il s'agit d'ASP.NET MVC et d'ASP.NET Core, pour Python – Django ou Flask, pour Ruby – Ruby on Rails, pour PHP – Symfony, Laravel, Yii, pour JavaScript – Node.JS- Express.js, pour Java – Spring MVC.

Restez attentif aux mises à jour du fournisseur et mettez à jour régulièrement. Une vulnérabilité sera découverte, un exploit sera rédigé, rendu public, et tout recommencera. Abonnez-vous aux mises à jour des versions stables du fournisseur de logiciels.

Vérifiez les droits d'accès. Du côté du serveur, traitez toujours votre code comme s'il avait été rédigé par votre pire ennemi, désireux de casser votre site et de compromettre l'intégrité de vos données. D'autant plus que parfois, c'est vraiment le cas.

Utilisez des clones, des environnements de test, puis passez à la production. Cela permettra d'éviter, d'une part, des erreurs et des faux pas dans l'environnement de production : l'environnement de production génère des revenus et son inactivité est critique. Lors de l'ajout, de la correction ou de la résolution de problème, il est conseillé de travailler dans un environnement de test, puis de vérifier la fonctionnalité et les vulnérabilités détectées avant de planifier des opérations dans l'environnement de production. 

Protégez l'application web avec un Web Application Firewall et intégrez les rapports du scanner de vulnérabilités avec celui-ci. Par exemple, chez DataLine, les services Qualys et FortiWeb sont utilisés comme lien.

Source : habr.com