Pour trop d’entreprises, ce n’est que après une faille de sécurité s'est produite que les meilleures pratiques de sécurité Web deviennent une priorité. Au cours de mes années de travail en tant que professionnel de la sécurité informatique, j'ai vu à maintes reprises à quel point le monde des problèmes de sécurité du développement Web peut être obscur pour tant de mes collègues programmeurs .
Une approche efficace des menaces de sécurité Web doit, par définition, être proactive et défensive. À cette fin, cet article vise à susciter un état d'esprit de sécurité, en injectant, espérons-le, au lecteur une bonne dose de paranoïa.
En particulier, ce guide se concentre sur 10 écueils de sécurité Web courants et importants à prendre en compte, y compris des recommandations sur la manière de les atténuer. L'accent est mis sur la Top 10 des vulnérabilités Web identifié par le Ouvrir le projet de sécurité des applications Web (OWASP) , une organisation internationale à but non lucratif dont le but est d'améliorer la sécurité des logiciels à travers le monde.
Un petit aperçu de la cybersécurité avant de commencer - authentification et autorisation
Lorsque je parle avec d'autres programmeurs et professionnels de l'informatique, je rencontre souvent une confusion concernant la distinction entre autorisation et authentification. Et bien sûr, le fait que l'abréviation auth est souvent utilisé pour les deux contribue à aggraver cette confusion commune. Cette confusion est si courante que ce problème devrait peut-être être inclus dans cet article en tant que «Common Web Vulnerability Zero».
Alors avant de continuer, clarifions la distinction entre ces deux termes:
- Authentification: Vérifier qu'une personne est (ou au moins semble être) un utilisateur spécifique, car elle a correctement fourni ses informations de sécurité (mot de passe, réponses aux questions de sécurité, scan d'empreintes digitales, etc.).
- Autorisation: Confirmer qu'un utilisateur particulier a accès à une ressource spécifique ou est autorisé à effectuer une action particulière.
Dit d'une autre manière, authentification c'est savoir qui est une entité, tandis que autorisation c'est savoir ce qu'une entité donnée peut faire. Dans cet esprit, examinons les 10 principaux problèmes de sécurité Internet.
Erreur de sécurité Web courante n ° 1: failles d'injection
Les défauts d'injection résultent d'un échec classique de filtrage des entrées non fiables. Cela peut arriver lorsque vous transmettez des données non filtrées au serveur SQL (injection SQL), au navigateur (XSS - nous en parlerons plus tard ), vers le serveur LDAP (injection LDAP), ou ailleurs. Le problème ici est que l'attaquant peut injecter des commandes à ces entités, entraînant une perte de données et le piratage des navigateurs des clients.
Tout ce que votre application reçoit de sources non fiables doit être filtré, de préférence selon une liste blanche. Vous ne devriez presque jamais utiliser une liste noire, car il est très difficile et généralement facile à contourner. Les produits logiciels antivirus fournissent généralement des exemples stellaires d'échecs de listes noires. La correspondance de modèle ne fonctionne pas.
La prévention: La bonne nouvelle est que la protection contre l'injection consiste «simplement» à filtrer correctement votre entrée et à se demander si une entrée peut être fiable. Mais la mauvaise nouvelle est que tout les entrées doivent être correctement filtrées, à moins qu'elles ne puissent être incontestablement fiables (mais le dicton «ne jamais dire jamais» vient à l'esprit ici).
Dans un système avec 1000 entrées, par exemple, filtrer avec succès 999 d'entre elles n'est pas suffisant, car cela laisse encore un champ qui peut servir de guérison d'Achille pour faire tomber votre système. Et vous pourriez penser que mettre un résultat de requête SQL dans une autre requête est une bonne idée, car la base de données est approuvée, mais si le périmètre ne l'est pas, l'entrée provient indirectement de personnes malintentionnées. C'est appelé Injection SQL de second ordre au cas où vous seriez intéressé.
Étant donné que le filtrage est assez difficile à faire correctement (comme la cryptographie), ce que je conseille généralement est de s'appuyer sur les fonctions de filtrage de votre framework: elles ont fait leurs preuves et sont minutieusement examinées. Si vous n'utilisez pas de frameworks, vous devez vraiment vous demander si ne pas les utiliser a vraiment un sens dans le contexte de la sécurité de votre serveur. 99% du temps, ce n'est pas le cas.
Erreur de sécurité Web courante n ° 2: authentification interrompue
Il s’agit d’un ensemble de problèmes pouvant survenir lors d’une authentification interrompue, mais ils ne sont pas tous dus à la même cause fondamentale.
En supposant que quelqu'un veuille toujours rouler son propre code d'authentification en 2014 (à quoi pensez-vous ??), je le déconseille. Il est extrêmement difficile de bien faire et il existe une myriade de pièges possibles, pour n'en citer que quelques-uns:
- L'URL peut contenir l'ID de session et le divulguer dans l'en-tête du référent à quelqu'un d'autre.
- Les mots de passe peuvent ne pas être chiffrés ni en stockage ni en transit.
- Les identifiants de session peuvent être prévisibles, l'accès est donc trivial.
- Une fixation de session pourrait être possible.
- Le détournement de session peut être possible, les délais ne sont pas correctement mis en œuvre ou en utilisant HTTP (pas de sécurité SSL), etc.
La prévention: Le moyen le plus simple d'éviter cette vulnérabilité de sécurité Web est d'utiliser un framework. Vous pourrez peut-être l'implémenter correctement, mais le premier est beaucoup plus facile. Au cas où vous voudriez rouler votre propre code, soyez extrêmement paranoïaque et renseignez-vous sur les pièges. Il y en a pas mal.
Erreur de sécurité Web courante n ° 3: Cross Site Scripting (XSS)
Il s'agit d'un échec de désinfection des entrées assez répandu (essentiellement un cas particulier de erreur courante n ° 1 ). Un attaquant donne à votre application Web des balises JavaScript en entrée. Lorsque cette entrée est renvoyée à l’utilisateur non assainie, le navigateur de l’utilisateur l’exécutera. Cela peut être aussi simple que de créer un lien et de persuader un utilisateur de cliquer dessus, ou cela peut être quelque chose de beaucoup plus sinistre. Lors du chargement de la page, le script s'exécute et, par exemple, peut être utilisé pour envoyer vos cookies à l'attaquant.
La prévention: Il existe une solution de sécurité Web simple: ne renvoyez pas de balises HTML au client. Cela a l'avantage supplémentaire de se défendre contre l'injection HTML, une attaque similaire par laquelle l'attaquant injecte du contenu HTML brut (comme des images ou des lecteurs flash invisibles bruyants) - pas à fort impact mais sûrement ennuyeux («s'il vous plaît, arrêtez-le!»). Habituellement, la solution de contournement consiste simplement à convertir tous Entités HTML , donc cela est renvoyé comme