Il y a environ un an, chez DataLine, nous avons lancé pour rechercher et analyser les vulnérabilités des applications informatiques. Le service s'appuie sur la solution cloud Qualys, dont le fonctionnement est expliqué . Au cours d'une année de travail avec la solution, nous avons effectué 291 analyses de différents sites et accumulé des statistiques sur les vulnérabilités courantes des applications Web.
Dans l’article ci-dessous, je vais vous montrer exactement quelles failles dans la sécurité des sites Web 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 se produire et comment vous protéger.
Qualys divise toutes les vulnérabilités des applications Web en trois niveaux de criticité : faible, moyen et élevé. Si l’on regarde la répartition par « gravité », il semble que tout ne soit pas si mal. Il existe peu de vulnérabilités avec un niveau de criticité élevé, la plupart sont toutes non critiques :
Mais non critique ne veut pas dire inoffensif. Ils peuvent également causer de graves dégâts.
Principales vulnérabilités « non critiques »
- Vulnérabilités de contenu mixte.
La norme en matière de sécurité des sites Web est le transfert de données entre le client et le serveur via le protocole HTTPS, qui prend en charge le cryptage et protège les informations contre l'interception.
Certains sites utilisent contenu mixte: Certaines données sont transférées via le protocole HTTP non sécurisé. C'est ainsi que cela est le plus souvent transmis contenu passif – des informations qui affectent uniquement l'affichage du site : images, styles css. Mais parfois c'est comme ça que ça se transmet contenu actif: scripts qui contrôlent le comportement du site. Dans ce cas, à l'aide d'un logiciel spécial, vous pouvez analyser les informations à contenu actif provenant du serveur, modifier vos réponses à la volée et faire fonctionner la machine d'une manière qui n'était pas prévue par ses créateurs.
Les versions plus récentes des navigateurs avertissent les utilisateurs que les sites au contenu mixte ne sont pas sûrs et bloquent le contenu. Les développeurs de sites Web reçoivent également des avertissements du navigateur dans la console. Par exemple, voici à quoi cela ressemble dans :
Qu'est-ce qui est dangereux: Les attaquants utilisent un protocole non sécurisé pour intercepter les informations de l'utilisateur, remplacer les scripts et envoyer des requêtes au site en son nom. Même si un visiteur du site n'a pas saisi de données, cela ne le protège pas contre Hameçonnage – obtenir des informations confidentielles par des méthodes frauduleuses. Par exemple, à l'aide d'un script, vous pouvez rediriger l'utilisateur vers un site dangereux qui se fait passer pour un site familier à l'utilisateur. Dans certains cas, le site malveillant est encore plus beau que l'original et l'utilisateur peut remplir lui-même le formulaire et soumettre des données confidentielles.Ce qu'un développeur Web doit retenir: Même si l'administrateur du site a installé et configuré un certificat SSL/TLS, une vulnérabilité peut survenir en raison d'une erreur humaine. Par exemple, si sur l'une des pages vous mettez non pas un lien relatif, mais un lien absolu depuis http, et qu'en plus vous n'avez pas mis en place de redirections de http vers https.
Vous pouvez détecter le contenu mixte sur un site à l’aide d’un navigateur : recherchez le code source de la page, lisez les notifications dans la console développeur. Cependant, le développeur devra bricoler le code pendant longtemps et de manière fastidieuse. Vous pouvez accélérer le processus avec des outils d'analyse automatisés, par exemple : , le logiciel Lighthouse gratuit ou le logiciel payant Screaming Frog SEO Spider.
En outre, la vulnérabilité peut survenir en raison de problèmes liés au code hérité, c'est-à-dire au code hérité. Par exemple, si certaines pages sont générées à partir d'un ancien modèle, qui ne prend pas en compte le passage des sites vers https.
- Cookies sans les indicateurs « HTTPOnly » et « secure ».
L'attribut "HTTPOnly" protège les cookies contre le traitement par des scripts que les attaquants utilisent pour voler les données des utilisateurs. Le flag « sécurisé » ne permet pas l'envoi de cookies en texte clair. La communication ne sera autorisée que si le protocole sécurisé HTTPS est utilisé pour envoyer des cookies.
Les deux attributs sont spécifiés dans les propriétés du cookie :
Set-Cookie: Secure; HttpOnlyQu'est-ce qui est dangereux: Si le développeur du site ne précisait pas ces attributs, un attaquant pourrait intercepter les informations de l'utilisateur issues du cookie et les exploiter. Si des cookies sont utilisés à des fins d'authentification et d'autorisation, il pourra détourner la session de l'utilisateur et effectuer des actions sur le site en son nom.
Ce qu'un développeur Web doit retenir: En règle générale, dans les frameworks populaires, ces attributs sont définis automatiquement. Mais vérifiez toujours la configuration du serveur Web et définissez l'indicateur : Set-Cookie HttpOnly ; Sécurisé.
Dans ce cas, l'attribut « HTTPOnly » rendra les cookies invisibles pour votre propre JavaScript.
- Vulnérabilités basées sur le chemin.
Le scanner signale une telle vulnérabilité s'il trouve un fichier ou un répertoire de site Web accessible au public contenant des informations potentiellement confidentielles. Par exemple, il détecte les fichiers de configuration système individuels ou l'accès à l'ensemble du système de fichiers. Cette situation est possible si les droits d'accès sont mal définis sur le site.
Qu'est-ce qui est dangereux: Si le système de fichiers « dépasse », un attaquant peut pénétrer dans l'interface du système d'exploitation et essayer de trouver des dossiers avec des mots de passe s'ils sont stockés en texte clair (ne faites pas ça !). Ou vous pouvez voler des hachages de mot de passe et forcer brutalement le mot de passe, et également essayer d'augmenter les privilèges dans le système et d'approfondir l'infrastructure.
Ce qu'un développeur Web doit retenir: N'oubliez pas les droits d'accès et configurez la plateforme, le serveur web, l'application web de manière à ce qu'il soit impossible de « s'échapper » du répertoire web.
- Formulaires de saisie de données sensibles avec remplissage automatique activé.
Si un utilisateur remplit fréquemment des formulaires sur des sites Web, son navigateur stocke ces informations à l'aide de la fonction de remplissage automatique.
Les formulaires sur les sites Web peuvent inclure des champs contenant des informations sensibles, telles que des mots de passe ou des numéros de carte de crédit. Pour de tels champs, il vaut la peine de désactiver la fonction de remplissage automatique du formulaire sur le site lui-même.
Qu'est-ce qui est dangereux: Si le navigateur de l'utilisateur stocke des informations sensibles, un attaquant peut les intercepter ultérieurement, par exemple via du phishing. Essentiellement, un développeur Web qui a oublié cette nuance configure ses utilisateurs.
Ce qu'un développeur Web doit retenir: Dans ce cas, nous avons un conflit classique : commodité contre sécurité. Si un développeur Web réfléchit à l’expérience utilisateur, il peut consciemment choisir la saisie semi-automatique. Par exemple, s'il est important de suivre – des recommandations pour l'accessibilité des contenus pour les utilisateurs handicapés.
Pour la plupart des navigateurs, vous pouvez désactiver la saisie semi-automatique avec l'attribut autocompete="off", par exemple :
<body> <form action="/fr/form/submit" method="get" autocomplete="off"> <div> <input type="text" placeholder="First Name"> </div> <div> <input type="text" id="lname" placeholder="Last Name" autocomplete="on"> </div> <div> <input type="number" placeholder="Credit card number"> </div> <input type="submit"> </form> </body>Mais cela ne fonctionnera pas pour Chrome. Ceci est contourné en utilisant JavaScript, une variante de la recette peut être trouvée .
- 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. Avec son aide, vous pouvez interdire complètement l'intégration de votre site dans un cadre. Pour ce faire, vous devez spécifier la valeur X-Frame-Options : deny. Ou vous pouvez spécifier X-Frame-Options : sameorigin, l'intégration dans une iframe ne sera alors disponible que sur votre domaine.
Qu'est-ce qui est dangereux: L'absence d'un tel en-tête peut être utilisée sur des sites malveillants pour détournement de clic. Pour cette attaque, l'attaquant crée un cadre transparent au-dessus des boutons et trompe l'utilisateur. Par exemple : les fraudeurs encadrent les pages de réseaux sociaux sur un site Web. L'utilisateur pense qu'il clique sur un bouton de ce site. Au lieu de cela, le clic est intercepté et la demande de l'utilisateur est envoyée au réseau social où se trouve une session active. C'est ainsi que les attaquants envoient du spam au nom de l'utilisateur ou gagnent des abonnés et des likes.
Si vous ne désactivez pas cette fonctionnalité, un attaquant peut placer votre bouton d'application sur un site malveillant. Il peut être intéressé par votre programme de parrainage ou par vos utilisateurs.
Ce qu'un développeur Web doit retenir: La vulnérabilité peut se produire si X-Frame-Options avec une valeur conflictuelle est définie sur le serveur Web ou l'équilibreur de charge. Dans ce cas, le serveur et l'équilibreur réécriront 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 interféreront avec le fonctionnement de la visionneuse Web Yandex. Pour autoriser l'utilisation d'iframes pour la visionneuse Web, vous devez écrire une règle distincte dans les paramètres. Par exemple, pour nginx, vous pouvez le configurer comme ceci :
http{ ... map $http_referer $frame_options { "~webvisor.com" "ALLOW-FROM http://webvisor.com"; default "SAMEORIGIN"; } add_header X-Frame-Options $frame_options; ... } - Vulnérabilités PRSSI (importation de feuille de style relative au chemin).
Il s'agit d'une vulnérabilité dans le style du site. Cela se produit si des liens relatifs comme href="/fr/somefolder/styles.css/" sont utilisés pour accéder aux fichiers de style. Un attaquant en profitera s'il trouve un moyen de rediriger l'utilisateur vers une page malveillante. La page insérera un lien relatif dans son URL et simulera un appel de styles. Vous recevrez une requête comme badsite.ru/…/somefolder/styles.css/, qui peut effectuer des actions malveillantes sous le couvert d'un style.
Qu'est-ce qui est dangereux: Un fraudeur pourrait exploiter cette vulnérabilité s'il découvre une autre faille de sécurité. De ce fait, il est possible de voler des données utilisateur à partir de cookies ou de tokens.
Ce qu'un développeur Web doit retenir: Définissez l'en-tête X-Content-Type-Options sur : nosniff. Dans ce cas, le navigateur vérifiera le type de contenu des styles. Si le type est autre que text/css, le navigateur bloquera la requête.
Vulnérabilités critiques
- Une page avec un champ de mot de passe est transmise depuis le serveur via un canal non sécurisé (un formulaire HTML contenant un ou plusieurs champs de mot de passe est servi via HTTP).
La réponse du serveur sur un canal non crypté est vulnérable aux attaques de type « Man in the middle ». Un attaquant peut intercepter le trafic et se coincer entre le client et le serveur pendant que la page passe du serveur au client.
Qu'est-ce qui est dangereux: Le fraudeur pourra remplacer la page et envoyer à l’utilisateur un formulaire de données confidentielles, qui ira sur le serveur de l’attaquant.
Ce qu'un développeur Web doit retenir: Certains sites envoient aux utilisateurs un code à usage unique par email/téléphone au lieu d'un mot de passe. Dans ce cas, la vulnérabilité n'est pas si critique, mais le mécanisme compliquera la vie des utilisateurs.
- Envoi d'un formulaire avec identifiant et mot de passe sur un canal non sécurisé (le formulaire de connexion n'est pas soumis via HTTPS).
Dans ce cas, un formulaire avec un identifiant et un mot de passe est envoyé de l'utilisateur au serveur via un canal non crypté.
Qu'est-ce qui est dangereux: Contrairement au cas précédent, il s'agit déjà d'une vulnérabilité critique. Il est plus facile d’intercepter des données sensibles car vous n’avez même pas besoin d’écrire du code pour le faire.
- Utilisation de bibliothèques JavaScript avec des vulnérabilités connues.
Lors de l'analyse, la bibliothèque la plus utilisée était jQuery avec un grand nombre de versions. Chaque version présente au moins une, voire plusieurs, vulnérabilités connues. L’impact peut être très différent selon la nature de la vulnérabilité.
Qu'est-ce qui est dangereux: Il existe des exploits pour des vulnérabilités connues, par exemple :
Ce qu'un développeur Web doit retenir: Revenir régulièrement au cycle : recherche des vulnérabilités connues - correction - vérification. Si vous utilisez délibérément des bibliothèques existantes, par exemple pour prendre en charge des navigateurs plus anciens ou pour économiser de l'argent, recherchez une opportunité de corriger une vulnérabilité connue. - Scripts intersites (XSS).
Cross-Site Scripting (XSS), ou cross-site scripting, est une attaque contre une application Web qui entraîne l'introduction d'un logiciel malveillant dans la base de données. Si Qualys découvre une telle vulnérabilité, cela signifie qu'un attaquant potentiel peut ou a déjà introduit son propre script js dans le code du site pour effectuer des actions malveillantes.XSS stocké plus dangereux, puisque le script est embarqué sur le serveur et exécuté à chaque fois que la page attaquée est ouverte dans le navigateur.
XSS réfléchi plus facile à réaliser puisqu'un script malveillant peut être injecté dans une requête HTTP. L'application recevra une requête HTTP, ne validera pas les données, les conditionnera et les enverra immédiatement. Si un attaquant intercepte le trafic et insère un script comme
<script>/*+что+то+плохое+*/</script>alors une requête malveillante sera envoyée de la part du client.
Un exemple frappant de XSS : les renifleurs js qui simulent des pages de saisie de CVC, de date d'expiration de la carte, etc.
Ce qu'un développeur Web doit retenir: Dans l'en-tête Content-Security-Policy, utilisez l'attribut script-src pour forcer le navigateur client à télécharger et exécuter uniquement le code provenant d'une source fiable. Par exemple, script-src 'self' met uniquement sur liste blanche tous les scripts de notre site.
La meilleure pratique est le code en ligne : autorisez uniquement le javascript en ligne en utilisant la valeur unsafe-inline. Cette valeur autorise l'utilisation de js/css en ligne, mais n'interdit pas l'inclusion de fichiers js. En combinaison avec script-src 'self', nous désactivons l'exécution des scripts externes.Assurez-vous de tout enregistrer à l'aide de report-uri et d'examiner les tentatives de mise en œuvre sur le site.
- Injection SQL.
La vulnérabilité indique la possibilité d'injecter du code SQL dans un site Web qui accède directement à la base de données du site Web. L'injection SQL est possible si les données de l'utilisateur ne sont pas filtrées : leur exactitude n'est pas vérifiée et sont immédiatement utilisées dans la requête. Par exemple, cela se produit si un formulaire sur un site Web ne vérifie pas si l'entrée correspond au type de données.Qu'est-ce qui est dangereux: Si un attaquant saisit une requête SQL dans ce formulaire, il peut faire planter la base de données ou révéler des informations confidentielles.
Ce qu'un développeur Web doit retenir: Ne faites pas confiance à ce qui vient du navigateur. Vous devez vous protéger à la fois côté client et côté serveur.
Côté client, écrivez la 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 de base de données paramétrées sur le serveur.
Déterminez où exactement l'interaction avec la base de données a lieu sur l'application Web.
L'interaction se produit lorsque nous recevons une information : une demande avec un identifiant (changement d'identifiant), la création d'un nouvel utilisateur, un nouveau commentaire ou de nouvelles entrées dans la base de données. C'est là que les injections SQL peuvent avoir lieu. Même si nous supprimons un enregistrement de la base de données, l'injection SQL est possible.
Recommandations générales
Ne réinventez pas la roue : utilisez des frameworks éprouvés. En règle générale, les frameworks populaires sont plus sécurisés. Pour .NET - ASP.NET MVC et 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 - Printemps MVC.
Suivez les mises à jour des fournisseurs et mettez à jour régulièrement. Ils trouveront une vulnérabilité, puis rédigeront un exploit, le rendront public, et tout se reproduira. Abonnez-vous aux mises à jour des versions stables du fournisseur de logiciels.
Vérifier les droits d'accès. Côté serveur, traitez toujours votre code comme s'il, de la première à la dernière lettre, avait été écrit par votre ennemi le plus détesté, qui veut casser votre site, violer l'intégrité de vos données. D’ailleurs, c’est parfois vrai.
Utilisez des clones, des sites de test, puis utilisez-les pour la production. Cela permettra, premièrement, d'éviter les erreurs et les fautes dans un environnement productif : un environnement productif rapporte de l'argent, un environnement productif simple est essentiel. Lors de l'ajout, de la résolution ou de la résolution d'un problème, il vaut la peine de travailler dans un environnement de test, puis de vérifier les fonctionnalités et les vulnérabilités trouvées, puis de planifier le travail avec l'environnement de production.
Protégez votre application Web avec et intégrez-y les rapports du scanner de vulnérabilités. Par exemple, DataLine utilise Qualys et FortiWeb comme ensemble de services.
Source: habr.com