Pour un trop grand nombre d’entreprises, ce n’est qu’après une violation de la sécurité que les meilleures pratiques de sécurité Web deviennent une priorité.
Les problèmes de sécurité du développement web est obscur pour un grand nombre de programmeurs.
Une approche efficace des menaces de sécurité du Web doit, par définition, être proactive et défensive. À cette fin, nous cherchons à susciter un état d’esprit de sécurité et à injecter au lecteur une bonne dose de paranoïa.
➟ Ce guide se concentre sur la sensibilisation et l’atténuation de 10 pièges communs et importants en matière de sécurité Web.
Je classerais cette question dans la catégorie des problèmes de maintenance/déploiement.
Avant d’incorporer un nouveau code, faites des recherches, et éventuellement des audits.
Utiliser le code d’une personne prise au hasard sur GitHub, par exemple, peut être pratique, mais ce n’est pas sans risque de grave vulnérabilité en matière de sécurité web.
J’ai vu de nombreux cas où des sites ont été pris en charge (c’est-à-dire où une personne extérieure obtient un accès administratif à un système), parce que des logiciels tiers (par exemple des plugins WordPress) sont restés sans correctifs pendant des années en production.
Si vous pensez qu’ils ne trouveront pas votre installation cachée de phpmyadmin, laissez-moi vous présenter DirBuster.
➟ La leçon à tirer ici est que le développement de logiciels ne se termine pas lorsque l’application est déployée.
- Il doit y avoir de la documentation
- des tests
- et des plans sur la façon de maintenir et de mettre à jour l’application
…surtout si elle contient des composants tiers ou open source.
Prévention :
- Ne soyez pas un codeur qui fait du copier-coller.
- Inspectez soigneusement le morceau de code que vous vous apprêtez à intégrer dans votre logiciel, car il peut être défectueux ou, dans certains cas, intentionnellement malveillant. Les attaques de sécurité sur le Web sont parfois invitées involontairement de cette manière.
- Restez au courant des dernières versions de tous les logiciels auxquels vous faites confiance et prévoyez des mises à jour régulières. Pour rester au courant des nouvelles failles de sécurité, abonnez-vous aux bulletins d’information de vos produits.
Les programmeurs et les professionnels de l’informatique expriment souvent leur confusion quant à la distinction entre autorisation et authentification.
L’utilisation de l’abréviation auth pour les deux termes augmente le flou qui les entoure.
Définissons et clarifions cette distinction :
- Authentification : Vérification qu’un utilisateur est (ou du moins semble être) la personne qu’il prétend être.
- Autorisation : Accorder à un utilisateur l’accès à une ressource spécifique ou la permission d’effectuer une action particulière.
En d’autres termes, l’authentification consiste à savoir qui est une entité, tandis que l’autorisation concerne ce qu’une entité donnée peut faire. En gardant cela à l’esprit, explorons 10 problèmes courants de vulnérabilité d’internet.
Les failles d’injection résultent d’un échec classique du filtrage des entrées non fiables.
- Les failles d’injection peuvent se produire lorsque nous transmettons des données non filtrées au serveur SQL (injection SQL),
- au navigateur (via Cross Site Scripting),
- au serveur LDAP (injection LDAP),
- ou à tout autre endroit.
Le problème ici est que l’attaquant peut injecter des commandes pour détourner les navigateurs des clients, ce qui entraîne une perte de données.
Tout ce que votre application reçoit d’une source non fiable doit être filtré, de préférence selon une liste blanche. L’utilisation d’une liste noire à cette fin n’est pas recommandée, car elle est difficile à configurer correctement.
Une liste noire est également considérée comme facile à contourner par un pirate. Les logiciels antivirus fournissent généralement de très bons exemples de listes noires défaillantes.
Prévention :
La protection contre l’injection consiste « simplement » à filtrer nos entrées et à déterminer les expéditeurs auxquels on peut faire confiance.
Le filtrage est une entreprise considérable car nous devons traiter toutes les entrées à moins qu’elles ne soient incontestablement fiables.
Si nous filtrons 999 entrées dans un système qui en compte 1 000, il nous reste un champ qui peut être le talon d’Achille et faire tomber notre système.
L’utilisation de l’injection SQL de second ordre pour injecter le résultat d’une requête SQL dans une autre est également considérée comme dangereuse. Cela peut sembler être une bonne idée car la base de données est fiable. Mais si le périmètre ne l’est pas, notre entrée pourrait provenir indirectement d’une source malveillante.
Le filtrage étant assez difficile à réaliser, il est conseillé de s’appuyer sur les fonctions de filtrage du framework. Leur efficacité est prouvée et elles ont fait l’objet d’un examen approfondi.
Si vous n’utilisez pas encore de framework, considérez les avantages en matière de sécurité des serveurs qu’il y a à en adopter un.
Les problèmes qui peuvent survenir lors d’une authentification brisée ne proviennent pas nécessairement d’une seule et même cause.
Il n’est pas recommandé de déployer votre propre code d’authentification, car il est difficile à réaliser correctement. Il existe une multitude de pièges possibles, en voici quelques-uns :
- L’URL peut contenir l’ID de session et le divulguer dans l’en-tête de référence.
- Les mots de passe peuvent ne pas être chiffrés lors du stockage et/ou du transit.
- Les identifiants de session peuvent être prévisibles, ce qui rend l’accès non autorisé un peu trop facile.
- La fixation de la session peut être possible.
- Le détournement de session peut se produire si les délais d’attente ne sont pas correctement mis en œuvre, ou si l’on utilise le protocole HTTP (sans sécurité SSL), etc.
Prévention :
La manière la plus directe d’éviter les vulnérabilités de sécurité web liées à l’authentification brisée est d’implémenter un framework.
Si vous développez votre propre code, soyez paranoïaque et renseignez-vous sur les problèmes potentiels qui peuvent survenir.
Un attaquant envoie des balises JavaScript en entrée à votre application Web.
Lorsque cette entrée est renvoyée à l’utilisateur sans être nettoyée, le navigateur de l’utilisateur l’exécute. Il s’agit d’une défaillance assez répandue de l’assainissement des entrées, essentiellement une sous-catégorie des failles d’injection.
- Les CSS peuvent être aussi simples que la création d’un lien
- La persuasion d’un utilisateur de cliquer dessus
- Mais ils peuvent aussi être beaucoup plus sinistres
- Par exemple, au chargement d’une page, le script peut s’exécuter et être utilisé pour envoyer vos cookies à l’attaquant
Prévention :
Ne renvoyez pas de balises HTML au client. Cela vous protégera également contre l’injection HTML, qui consiste pour un attaquant à injecter du contenu HTML brut (comme des images ou des lecteurs Flash bruyants mais invisibles).
Pour mettre en œuvre cette solution, convertissez toutes les entités HTML pour qu’elles renvoient autre chose.
Par exemple, convertissez <script> pour qu’elle renvoie <script>.
Vous pouvez également utiliser des expressions régulières pour éliminer les balises HTML en utilisant des expressions régulières sur < et >. Mais c’est dangereux car certains navigateurs peuvent ne pas interpréter le HTML sévèrement cassé.
Il est préférable de convertir tous les caractères en leurs équivalents.
Il s’agit d’un cas classique où l’on fait confiance à l’entrée de l’utilisateur et où l’on paie le prix en héritant d’une vulnérabilité de sécurité résultante.
Une référence directe à un objet signifie qu’un objet interne (par exemple, un fichier ou une clé de base de données) est exposé à l’utilisateur, ce qui nous rend vulnérables aux attaques.
L’attaquant peut fournir cette référence et, si l’autorisation n’est pas appliquée ou si elle n’est pas respectée, l’attaquant peut entrer.
Par exemple, le code comporte un module download.php qui lit et laisse l’utilisateur télécharger des fichiers, en utilisant un paramètre CGI pour spécifier le nom du fichier (par exemple, download.php?file=quelquechose.txt).
Si le développeur a omis l’autorisation dans le code, l’attaquant peut maintenant l’utiliser pour télécharger des fichiers système accessibles à l’utilisateur qui exécute PHP (par exemple, le code de l’application ou des données aléatoires du serveur comme les sauvegardes).
➟ Un autre exemple de vulnérabilité de référence directe à un objet non sécurisée est une fonction de réinitialisation de mot de passe qui s’appuie sur la saisie de l’utilisateur pour déterminer son identité.
Après avoir cliqué sur l’URL valide, un attaquant pourrait modifier le champ du nom d’utilisateur dans l’URL pour dire quelque chose comme « admin » .
Soit dit en passant, j’ai souvent vu ces deux exemples « dans la nature » .
Prévention :
Effectuez l’autorisation de l’utilisateur correctement et systématiquement, et mettez les choix sur une liste blanche.
Le plus souvent, la vulnérabilité peut être évitée en stockant les données en interne et en ne comptant pas sur les données transmises par le client via des paramètres CGI.
Les variables de session dans la plupart des frameworks sont bien adaptées à cet effet.
D’après mon expérience, il est fréquent de rencontrer des serveurs et des applications web mal configurés. Quelques exemples :
- Exécuter une application avec le débogage activé en production.
- Activation de la liste des répertoires (qui laisse échapper des informations précieuses) sur le serveur
- Exécution de logiciels obsolètes (plugins WordPress, vieux PhpMyAdmin)
- Exécution de services inutiles
- Ne pas changer les clés et mots de passe par défaut (ce qui arrive plus souvent qu’on ne le croit)
- Révéler des informations sur la gestion des erreurs (par exemple, les traces de la pile) à des attaquants potentiels.
Prévention :
Disposez d’un bon processus (de préférence automatisé) de « construction et de déploiement » , qui peut exécuter des tests lors du déploiement.
La solution du pauvre en matière de mauvaise configuration de la sécurité consiste à utiliser des crochets post-commit, afin d’empêcher le code de sortir avec des mots de passe par défaut et/ou des éléments de développement intégrés.
Cette vulnérabilité de sécurité web concerne la cryptographie et la protection des ressources.
Les données sensibles doivent être chiffrées à tout moment, y compris en transit et au repos. Aucune exception.
- Les informations relatives aux cartes de crédit et les mots de passe des utilisateurs ne doivent jamais voyager ou être stockés en clair,
- et les mots de passe doivent toujours être hachés.
Évidemment, l’algorithme de cryptage/hachage ne doit pas être faible. En cas de doute, les normes de sécurité du web recommandent l’AES (256 bits et plus) et le RSA (2048 bits et plus).
On ne saurait trop insister sur le fait que les identifiants de session et les données sensibles ne doivent pas voyager dans les URL. Les cookies contenant des données sensibles doivent avoir le drapeau « sécurisé » activé.
Prévention :
- En transit : Utilisez HTTPS avec un certificat approprié et PFS (Perfect Forward Secrecy). N’acceptez rien via des connexions non HTTPS. Activez le drapeau « sécurisé » sur les cookies.
- En stockage : Réduisez votre exposition à cette vulnérabilité. Si vous n’avez pas besoin de données sensibles, déchiquetez-les virtuellement. Les données que vous n’avez pas ne peuvent pas être volées. Ne stockez pas d’informations relatives aux cartes de crédit, et vous n’aurez pas à vous soucier de la conformité PCI. Inscrivez-vous auprès d’un processeur de paiement comme Stripe ou Braintree. Stockez et chiffrez les données sensibles, et veillez à ce que tous les mots de passe soient chiffrés à l’aide de bcrypt. Si vous n’utilisez pas bcrypt, renseignez-vous sur le salage et les tables arc-en-ciel.
➟ Et au risque d’énoncer une évidence, ne stockez pas les clés de chiffrement à proximité des données protégées.
C’est comme si vous stockiez votre vélo avec un cadenas dont la clé se trouve à l’intérieur.
Protégez vos sauvegardes par chiffrement et gardez vos clés privées. Et bien sûr, ne perdez pas les clés !
Il s’agit d’une défaillance qui se produit si une autorisation appropriée n’est pas effectuée lorsqu’une fonction est appelée sur le serveur.
Les développeurs ont tendance à penser que, puisque le côté serveur génère l’interface utilisateur, le client ne peut pas accéder à une fonctionnalité qui n’est pas fournie par le serveur. Ce n’est pas aussi simple que cela, car un attaquant peut toujours falsifier une requête vers la fonctionnalité « cachée » .
Un attaquant ne sera pas dissuadé par le fait que la fonctionnalité souhaitée n’est pas facilement accessible.
Imaginez qu’il y ait un panneau /admin, et que le bouton ne soit présent dans l’interface utilisateur que si l’utilisateur est effectivement un administrateur. Rien n’empêche un attaquant de découvrir et d’utiliser cette fonctionnalité à mauvais escient si l’autorisation fait défaut.
Prévention :
Du côté du serveur, l’autorisation doit toujours être effectuée.
Dans cette attaque (également appelée attaque par confusion), un tiers malveillant trompe le navigateur en abusant de son autorité pour faire quelque chose pour l’attaquant.
- Un site tiers utilise votre navigateur
- vos cookies
- et votre session
…pour émettre une requête vers un site cible (par exemple, votre banque).
Si, dans un onglet du navigateur, vous êtes connecté à votre banque et si celle-ci est vulnérable à ce type d’attaque, un autre onglet peut être autorisé à faire en sorte que votre navigateur utilise ses informations d’identification à mauvais escient pour le compte de l’attaquant, ce qui donne lieu au problème de la confusion du suppléant.
L’adjoint est le navigateur qui abuse de son autorité (cookies de session) pour exécuter les instructions de l’attaquant.
Prévention :
Stockez un jeton secret dans un champ de formulaire caché, inaccessible à un site tiers. Cela nécessite bien sûr que vous vérifiiez le champ caché.
Certains sites peuvent demander un mot de passe avant de vous permettre de modifier des paramètres sensibles (comme un email de rappel du mot de passe).
Cela pourrait empêcher l’utilisation abusive de vos sessions abandonnées sur des ordinateurs publics.
Il s’agit encore d’un problème de filtrage des entrées.
Supposons que le site cible possède un module redirect.php qui prend une URL comme paramètre GET. La manipulation du paramètre peut créer une URL sur sitevictime.com qui redirige le navigateur vers virusinfecte.com.
Un utilisateur verrait le lien comme sitevictime.com/blablabla, ce qui semble suffisamment inoffensif pour qu’il fasse confiance et clique. Mais cliquer sur ce lien pourrait transférer l’utilisateur vers une page de dépôt de logiciels malveillants (ou toute autre page malveillante).
L’attaquant peut aussi rediriger le navigateur vers sitevictime.com/deleteprofile?confirm=1.
Il convient de mentionner que l’insertion d’une entrée définie par l’utilisateur dans un en-tête HTTP peut conduire à une injection d’en-tête, ce qui est assez grave.
Prévention :
- Ne faites pas de redirections ; elles sont rarement nécessaires.
- Lorsqu’une redirection est nécessaire, disposez d’une liste statique des emplacements de redirection valides.
- Mettez le paramètre défini par l’utilisateur sur une liste blanche. Notez que cela peut s’avérer délicat.
En savoir plus ➟ Comment effacer toute trace des sites visités
J’espère que j’ai réussi à titiller votre cerveau et à introduire une bonne dose de paranoïa et de sensibilisation aux failles de sécurité des sites Web.
Ce qu’il faut retenir, c’est que les pratiques logicielles ancestrales existent pour une bonne raison.
Ce qui s’appliquait à l’époque aux débordements de tampon s’applique encore aujourd’hui aux chaînes de caractères décapées en Python. Les protocoles de sécurité nous aident à écrire des programmes meilleurs et plus sûrs, ce à quoi nous devons aspirer.
Veuillez utiliser ces connaissances de manière responsable, et ne testez pas de pages sans autorisation !