Journal des modifications : le top 10 des projets de l'OWASP

Les applications Web ont explosé en complexité au cours de la dernière décennie. Ils sont passés de simples conteneurs pour les formulaires de contact et les sondages à des applications complètes. Nous pouvons les comparer aux applications de bureau lourdes, à la fois en taille et en performances. Avec une forte augmentation de la complexité et un nombre croissant d'applications riches en fonctionnalités, il est devenu nécessaire d'investir beaucoup de temps et d'attention pour rendre tous les composants de l'application aussi sécurisés que possible. L'augmentation massive du nombre d'utilisateurs d'Internet rend d'autant plus importante la question de la protection des données et des utilisateurs des applications. Il existe un vaste bassin de menaces qui tentent de s'infiltrer et de causer de graves maux de tête à toutes les personnes impliquées.

En 2001, une nouvelle organisation entre en scène. Son objectif était de lutter contre les problèmes de sécurité affectant les sites Web et les applications. Il a été nommé à juste titre Open Web Application Security Project (OWASP). Aujourd'hui, elle édite des ressources, organise des conférences et propose des standards sur la sécurité du web et des applications. Une norme de facto pour la sécurité des applications Web est le projet OWASP Top Ten. Il répertorie les dix menaces de sécurité les plus courantes. Les facteurs influents pour décider de ce qui entre étaient une grande quantité de données et les commentaires de la communauté. Fin 2017, il y a eu une mise à jour du projet. Plusieurs nouveaux problèmes critiques pour de nombreuses applications Web modernes ont trouvé leur place, tandis que certains se sont échappés de la liste.

Cet article complète la liste originale et illustre les dernières modifications apportées à la liste. Il décrit les menaces, tente de fournir des exemples clairs pour faciliter la compréhension et propose des moyens de lutter contre les menaces de sécurité.

Problèmes supprimés de la liste des 10 principaux problèmes de l'OWASP

Avant la mise à jour de 2017, la liste de 2013 était la plus récente. Compte tenu des changements dans la manière dont les applications Web sont désormais construites et consommées, il était logique de procéder à une révision approfondie. Les microservices prennent leur part du gâteau et de nouveaux frameworks sympas et brillants remplacent l'équipement de combat du code vanille. Ces faits signifient que certaines des menaces répertoriées précédemment ont été supprimées et que de nouvelles ont pris leur place.

Nous nous assurerons de nous rafraîchir la mémoire des problèmes oubliés depuis longtemps dans cet article, ainsi que de présenter les nouveaux méchants loups. L'apprentissage de l'histoire est le seul moyen sûr de ne pas répéter les mêmes erreurs.

Falsification de requêtes intersites

La falsification de requêtes intersites (CSRF) est l'un des "perdants" de la récente itération du projet. Il a disparu parce que de nombreux frameworks Web modernes incluent des mécanismes de défense CSRF. La probabilité d'exposer vos applications à la menace diminue ainsi rapidement.

Indépendamment de la sortie de CSRF de la liste, il est toujours bon de se rafraîchir la mémoire. Faisons en sorte qu'il ne revienne pas plus fort que jamais.

En substance, CSRF est un exploit qui ressemble à une bombe fumigène. Un attaquant trompe un utilisateur sans méfiance pour qu'il exécute une requête ou une action indésirable dans une application Web. En termes simples, un attaquant force sa victime à envoyer une requête à une application tierce, et la victime n'est pas au courant de l'envoi de la requête. La requête peut être une requête HTTP GET pour récupérer une ressource, ou pire encore, une requête HTTP POST qui modifie une ressource sous le contrôle de la victime. Lors de l'attaque, la victime pense que tout va bien, le plus souvent sans même s'apercevoir qu'il se passe quelque chose en arrière-plan. Une fois l'air dégagé, le mal est fait ou il manque quelque chose, et personne ne sait ce qui s'est passé.

L'authentification réussie de l'utilisateur précédent dans l'application cible est ce qui permet au trap d'être efficace. L'utilisateur s'était à un moment donné avant l'attaque connecté à une application. L'application a envoyé à la victime un cookie pour se souvenir d'elle. Une fois que le navigateur Web envoie la demande malveillante, le cookie est automatiquement envoyé avec toute charge utile potentielle et l'application ne s'oppose pas à servir la demande à un utilisateur qu'elle connaît déjà.

L'un des exemples les plus célèbres consiste à tromper un utilisateur pour qu'il transfère de l'argent de son compte vers celui qu'un attaquant contrôle. Un utilisateur se connecte à un système de banque en ligne pour vérifier le solde de son compte. Après cela, ils visitent un forum en ligne pour vérifier les critiques d'un nouveau téléphone mobile. Un attaquant, pêchant à la dynamite, publie une critique comprenant une image avec un lien hypertexte d'image apparemment cassé. Au lieu d'un véritable lien hypertexte, l'attaquant utilise un lien hypertexte que le système e-banking utilise en interne pour transférer de l'argent du compte A vers le compte B : https://payments.dummybank.com?receiver=attacker&amount=100 . Le système bancaire fait de l'utilisateur authentifié l'expéditeur et la valeur du paramètre « récepteur » le récepteur des fonds. Bien sûr, l'attaquant spécifie son compte offshore comme receveur.

Étant donné que le navigateur charge automatiquement les images lors du rendu de la page, la demande se produit en arrière-plan. Si le système de paiement de la banque met en œuvre des transferts d'argent à l'aide d'une requête HTTP GET, rien n'empêche le désastre de se produire. Notez que l'exemple est simple et que les transferts ne sont probablement pas gérés via HTTP GET. Cependant, l'attaquant peut, avec un peu plus de difficulté, parvenir à modifier l'attribut « action » dans le formulaire d'envoi de messages HTML du forum. Le navigateur envoie ensuite la demande au système de paiement de la banque, au lieu du back-end du forum.

Le vol d'argent n'est qu'un exemple parmi tant d'autres. La modification des adresses e-mail des utilisateurs ou la réalisation d'achats involontaires entrent également dans cette catégorie. Comme cela arrive souvent, l'ingénierie sociale et certaines connaissances techniques sont un levier efficace contre une erreur d'ingénierie logicielle.

Lors de la conception de vos systèmes, gardez à l'esprit les points suivants :

• N'utilisez pas de requêtes HTTP GET pour encapsuler des actions qui modifient une ressource. Vous ne devez utiliser ces requêtes que pour récupérer des informations. N'oubliez pas que la règle d'or consiste à rendre les requêtes GET idempotentes.
• Do , lors du transfert de données en interne à l'aide de requêtes HTTP POST, a tendance à envoyer les données au format JSON, XML ou dans un autre format autre que l'encodage des paramètres sous forme de chaîne de requête. L'utilisation d'un format de données non trivial réduit le risque que quelqu'un crée un faux formulaire HTML qui enverra les données à votre service.
• Assurez -vous de créer et d'inclure un jeton unique et imprévisible dans vos formulaires HTML. Ces jetons doivent également être uniques pour chaque demande. Vérifier la présence et l'exactitude de ces jetons réduira les risques de menaces. Pour trouver le jeton et l'utiliser dans leurs fausses requêtes, les attaquants devraient accéder à votre système et prendre un jeton directement à partir de là. Étant donné que les jetons sont à usage unique, ils ne peuvent pas les réutiliser dans le code malveillant.

Cette vulnérabilité a un effet encore pire lorsqu'elle est associée à des scripts intersites (XSS). Si un attaquant peut injecter un code malveillant dans un site Web ou une application favori, la portée de l'attaque devient beaucoup plus importante et dangereuse. Plus critique encore, les attaquants peuvent contourner certains des mécanismes de protection contre CSRF si des attaques XSS sont possibles.

Gardez à l'esprit que le CSRF n'a pas disparu, il n'est tout simplement plus aussi courant qu'avant.

Redirections et transferts non validés

De nombreuses applications, après avoir terminé une action, redirigent ou transfèrent un utilisateur vers une autre partie de la même application, voire une autre. Par exemple, une connexion réussie à une application déclenche une redirection vers la page d'accueil ou la page que l'utilisateur a initialement visitée. Très souvent, la destination fait partie de l'action ou de l'adresse des liens du formulaire. Si le composant qui gère la redirection ou le transfert ne s'assure pas que l'adresse de destination est bien celle qui a été générée par l'application, une menace potentielle surgit. Il s'agit d'une vulnérabilité de sécurité appelée "redirections et transferts non validés".

Les deux principales raisons pour lesquelles les redirections et les transferts non validés seraient considérés comme dangereux sont le phishing et le piratage d'informations d'identification. Un attaquant peut réussir à modifier l'emplacement cible de redirection/transfert et envoyer un utilisateur vers une application malveillante presque impossible à distinguer de l'application d'origine. Un utilisateur peu méfiant révèle ses informations d'identification et des informations confidentielles à un tiers malveillant. Avant qu'ils ne réalisent ce qui s'était passé, il est déjà trop tard.

Par exemple, les applications Web implémentent très souvent une connexion avec prise en charge des redirections vers la dernière page visitée. Pour pouvoir le faire facilement, l'attribut d'action d'un formulaire HTML peut ressembler à http://myapp.example.com/signin?url=http://myapp.example.com/puppies . Vous êtes un grand admirateur des chiots, il était donc logique d'installer une extension de navigateur qui remplace les favicons du site Web par les vignettes de vos chiots préférés. Malheureusement, c'est un monde de chiens mangeurs de chiens. L'auteur de l'extension de navigateur a décidé de profiter de votre amour inconditionnel et d'introduire une "fonctionnalité" supplémentaire. Chaque fois que vous visitez votre site de fans de chiots préféré, il remplace le paramètre "url" dans l'attribut d'action du formulaire par un lien vers leur propre site. Étant donné que le site a exactement la même apparence, lorsque vous donnez les détails de votre carte de crédit pour acheter des cartes à jouer pour chiots, vous financez en fait un attaquant malveillant, pas votre passe-temps.

Résoudre la vulnérabilité implique de vérifier l'emplacement de destination en s'assurant qu'il s'agit bien de celui prévu. Si un framework ou une bibliothèque effectue la logique de redirection ou de transfert complète, il est avantageux de vérifier l'implémentation et de mettre à jour le code si nécessaire. Sinon, vous devez effectuer des vérifications manuelles pour vous protéger contre l'attaque.

Il existe plusieurs types de vérifications que vous pouvez effectuer. Pour une meilleure protection, utilisez une combinaison de plusieurs approches au lieu de vous en tenir à une seule.

• Validez l'URL sortante en vous assurant qu'elle pointe vers le domaine que vous contrôlez.
• Au lieu d'utiliser des adresses explicites, encodez-les sur le front-end, puis décodez-les et validez-les sur le back-end.
• Préparez une liste blanche d'URL de confiance. Autorise les transferts et les redirections uniquement vers les emplacements de la liste blanche. Préférez cette approche au maintien d'une liste noire. Les listes noires sont généralement remplies de nouveaux éléments uniquement lorsque quelque chose de grave se produit. Les listes blanches sont plus restrictives.
• Utilisez une approche utilisée par LinkedIn et certaines autres applications : présentez à vos utilisateurs une page leur demandant de confirmer une redirection/transfert, en indiquant clairement qu'ils quittent votre application.

Problèmes fusionnés

La plupart des problèmes de la liste peuvent être qualifiés de défauts de mise en œuvre, soit en raison d'un manque de connaissances, soit d'une enquête insuffisamment approfondie sur les menaces potentielles. Ces deux raisons peuvent être attribuées au manque d'expérience et la solution pour les envisager à l'avenir est simple - assurez-vous simplement d'en apprendre davantage et d'être plus approfondi. Un problème particulièrement délicat repose sur une combinaison du trait dangereux (mais très humain) de faire trop d'hypothèses couplé à la difficulté de développer et de maintenir des systèmes informatiques complexes. Une vulnérabilité qui entre dans cette catégorie est le "contrôle d'accès cassé".

Contrôle d'accès cassé

Une vulnérabilité est causée par une autorisation et un contrôle d'accès inadéquats ou absents pour certaines parties de l'application. Dans les itérations précédentes du projet Top Ten de l'OWASP, il y avait deux problèmes : des références d'objet directes non sécurisées et un contrôle d'accès au niveau des fonctions manquant. Ils sont maintenant fusionnés en un seul en raison de leur similitude.

Références directes d'objets

Les références directes d'objets sont souvent utilisées dans les URL pour identifier les ressources en cours d'utilisation. Par exemple, lorsqu'un utilisateur se connecte, il peut visiter son profil en cliquant sur un lien qui contient son identifiant de profil. Si ce même identifiant est stocké dans la base de données et est utilisé pour récupérer les informations de profil, et que l'application suppose que les personnes ne peuvent accéder à la page de profil que via une page de connexion, la modification de l'identifiant de profil dans l'URL expose les informations de profil d'un autre utilisateur.

Une application qui définit l'URL du formulaire de profil de suppression http://myapp.example.com/users/15/delete indique clairement qu'il existe au moins 14 autres utilisateurs dans l'application. Comprendre comment accéder au formulaire de suppression des autres utilisateurs n'est pas sorcier dans ce cas.

La solution à ce problème consiste à effectuer des vérifications d'autorisation pour chaque ressource sans supposer que seuls certains chemins peuvent être empruntés pour accéder à certaines parties de l'application. De plus, la suppression des références directes et l'utilisation de références indirectes est un autre pas en avant car il est difficile pour les utilisateurs malveillants de comprendre comment la référence est créée.

Pendant le développement, par précaution, écrivez un diagramme de machine d'état simple. Laissez les états représenter différentes pages de votre application et les transitions les actions que les utilisateurs peuvent effectuer. Cela facilite la liste de toutes les transitions et pages qui nécessitent une attention particulière.

Contrôle d'accès au niveau de la fonction manquant

Le contrôle d'accès manquant au niveau de la fonction est très similaire aux références d'objet directes non sécurisées. Dans ce cas, les utilisateurs modifient l'URL ou un autre paramètre pour essayer d'accéder aux parties protégées de l'application. S'il n'y a pas de contrôle d'accès approprié examinant les niveaux d'accès, un utilisateur peut obtenir un accès privilégié aux ressources de l'application ou au moins une certaine connaissance de leur existence.

En empruntant l'exemple des références directes d'objets, si une application suppose qu'un utilisateur visitant le formulaire de suppression est un superutilisateur uniquement parce que les superutilisateurs peuvent voir le lien vers le formulaire de suppression, sans faire d'autre autorisation, une énorme faille de sécurité s'ouvre. Compter sur la disponibilité de certains éléments de l'interface utilisateur n'est pas un contrôle d'accès approprié.

Le problème est résolu en veillant toujours à effectuer des vérifications dans toutes les couches de votre application. L'interface frontale n'est peut-être pas le seul moyen pour les utilisateurs malveillants d'accéder à votre couche de domaine. De plus, ne vous fiez pas aux informations transmises par les utilisateurs concernant leurs niveaux d'accès. Effectuez un contrôle de session approprié et vérifiez toujours les données reçues. Ce n'est pas parce que le corps de la requête indique que l'utilisateur est un administrateur qu'il l'est vraiment.

Le contrôle d'accès cassé combine désormais tous les problèmes liés à un contrôle d'accès insuffisant, que ce soit au niveau de l'application ou au niveau du système, comme une mauvaise configuration du système de fichiers.

Nouveaux problèmes dans la liste OWASP Top 10

L'avènement de nouveaux frameworks frontaux et l'adoption de nouvelles pratiques de développement de logiciels ont déplacé les problèmes de sécurité vers des sujets complètement nouveaux. Les nouvelles technologies ont également réussi à résoudre certains problèmes courants que nous traitions manuellement auparavant. Par conséquent, il est devenu avantageux de réviser la liste et de l'ajuster en conséquence aux tendances modernes.

Entités externes XML

Le standard XML propose une idée peu connue appelée entité externe, qui fait partie de la définition du type de données (DTD) du document. Il permet aux auteurs de documents de spécifier des liens vers des entités externes qui peuvent ensuite être référencées et incluses dans le document principal. Un exemple très simple serait :

 <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE foo [ <!ELEMENT foo ANY> <!ENTITY bar "baz"> ]> <foo> &bar; </foo>

Lors de l'analyse, une référence &bar; est remplacé par le contenu de l'entité définie, donnant ainsi <foo>baz</foo> .

Si l'application devait prendre une entrée externe et l'inclure, sans aucune vérification, directement dans la définition de document XML, un large éventail de fuites de données et d'attaques deviendrait possible.

Ce qui est magique, c'est que l'entité n'a pas besoin d'être une simple chaîne : il peut s'agir d'une référence à un fichier du système de fichiers. L'analyseur XML se fera un plaisir de prendre le contenu du fichier spécifié et de l'inclure dans la réponse générée, révélant potentiellement des informations système sensibles. Comme l'illustre l'OWASP, il serait très facile d'obtenir des informations sur les utilisateurs du système en définissant l'entité comme

 <!ENTITY xxe SYSTEM "file:///etc/passwd" >]>

Une « caractéristique » particulièrement gênante de cette vulnérabilité est la possibilité d'exécuter facilement une attaque par déni de service. Un moyen simple de le faire serait de lister le contenu d'un fichier sans fin comme /dev/random . L'autre consiste à créer une séquence d'entités, chacune référençant la précédente plusieurs fois. Cela transforme la référence finale en une racine d'un arbre potentiellement très large et profond dont l'analyse pourrait épuiser la mémoire système. Cette attaque est même connue sous le nom de Billion Laughs. Comme indiqué sur Wikipedia, une série d'entités factices sont définies, ce qui permet à un attaquant d'inclure un milliard de lols dans le document final.

 <?xml version="1.0"?> <!DOCTYPE lolz [ <!ENTITY lol "lol"> <!ELEMENT lolz (#PCDATA)> <!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;"> <!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;"> <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;"> <!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;"> <!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;"> <!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;"> <!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;"> <!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;"> <!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;"> ]> <lolz>&lol9;</lolz>

La prévention des exploits d'entités externes XML pourrait être réalisée en utilisant un format de données moins complexe. JSON est un bon remplacement, à condition que certaines précautions soient également prises en raison d'éventuelles attaques contre lui. La mise à jour des bibliothèques XML est indispensable, associée à la désactivation du traitement des entités externes et de la DTD. Comme toujours, validez et nettoyez les données provenant de sources non fiables avant de les utiliser ou de les inclure dans vos documents.

Désérialisation non sécurisée

Lors de l'écriture de code, les développeurs ont le pouvoir de contrôler les systèmes qu'ils développent à l'aide du code qu'ils écrivent. Ne serait-il pas génial de contrôler le comportement de systèmes tiers n'écrivant que peu ou pas de code ? Grâce au fait que les gens ne sont pas parfaits et que les bibliothèques ont des défauts, c'est tout à fait possible.

L'état et la configuration de l'application sont souvent sérialisés et stockés. Parfois, les navigateurs servent de moteurs de stockage si les données sérialisées sont étroitement couplées à l'utilisateur actuel. Une application essayant d'être intelligente et de gagner du temps de traitement pourrait utiliser un cookie pour marquer qu'un utilisateur s'est connecté. Étant donné que le cookie ne peut être créé qu'une fois la connexion réussie, il est logique de stocker le nom d'utilisateur dans le cookie. Un utilisateur est alors authentifié et autorisé sur la base de l'existence et du contenu du cookie. Si les gens n'étaient pas mal intentionnés, rien ne pouvait mal tourner. Pour être honnête, ils ne doivent pas non plus être curieux.

Si un utilisateur curieux trouvait un cookie sur sa machine, il pourrait voir quelque chose comme ceci :

 {"username": "joe.doe", "expires": "2018-06-01 10:28:16"}

Un dictionnaire Python parfaitement valide sérialisé en JSON, rien de spécial à ce sujet. L'utilisateur toujours curieux peut modifier la date d'expiration pour empêcher l'application de forcer la déconnexion. Un utilisateur encore plus curieux pourrait essayer de modifier le nom d'utilisateur en "jane.doe" . Si ce nom d'utilisateur existait, il ouvrirait un tout nouveau monde pour l'utilisateur sans méfiance qui a maintenant accès à des données privées.

Un exemple simple de sérialisation des données dans JSON et de tout garder transparent est loin d'être la pire chose qui puisse vous arriver. Si un attaquant parvient à modifier certaines données sérialisées, il peut être en mesure de les modifier de manière à forcer votre système à exécuter du code arbitraire.

Supposons que vous construisez une API REST qui permet aux utilisateurs d'écrire leurs propres modèles d'apprentissage automatique en Python et de les télécharger sur votre service. Le service évaluera les modèles téléchargés et les entraînera à l'aide de vos ensembles de données. Cela permet aux utilisateurs d'utiliser vos ressources informatiques et une grande quantité d'ensembles de données disponibles pour la création de modèles rapide et facile.

Le service ne stocke pas le code au format texte brut. Les utilisateurs sélectionnent leur code, le chiffrent à l'aide de leur clé privée et l'envoient à l'API pour la formation. Lorsque le service doit exécuter un modèle, il déchiffre le code, le décode et l'exécute. La partie délicate est que le protocole de cornichon n'est pas sûr. Le code peut être construit de manière à permettre l'exécution de code malveillant arbitraire lors de la désérialisation.

Le protocole pickle de Python permet aux classes de définir une méthode __reduce__ , qui renvoie des informations sur la façon de désérialiser un objet personnalisé. L'une des valeurs de retour prises en charge est un tuple de deux arguments : un appelable et un tuple d'arguments à transmettre à l'appelable. En tenant compte du fait que votre système de formation de modèle ML vise à fournir une flexibilité maximale de la structure du code, il est possible d'écrire le code suivant :

 class Algo(object): def run(self): pass def __reduce__(self): import itertools return (list, (itertools.count(1), ))

Une fois que l'objet doit être désérialisé (unpicklé), une list de fonctions est appelée avec un seul argument. La fonction list est un constructeur de liste en Python, et la fonction itertools.count produit un itérateur infini de valeurs, en commençant par le paramètre passé. Transformer un itérateur infini en une liste finie peut avoir des conséquences désastreuses sur les performances et la stabilité de votre système.

Le seul véritable remède à ce type de vulnérabilité est de choisir de ne pas désérialiser les données provenant de sources externes. Si cela n'est pas possible, il est suggéré d'utiliser une somme de contrôle ou une signature numérique pour empêcher la désérialisation des données potentiellement modifiées par un utilisateur malveillant. Essayez également de configurer un environnement sandbox découplé de votre système principal pour limiter les effets des problèmes qui pourraient survenir.

Lorsque vous utilisez des bibliothèques externes pour désérialiser des données, par exemple à partir de XML ou de JSON, essayez de choisir celles qui vous permettent d'effectuer des vérifications de type d'objet avant qu'une procédure de désérialisation réelle ne soit exécutée. Cela pourrait intercepter des types d'objets inattendus dont le seul but est de nuire à votre système.

Comme pour toutes les autres actions effectuées par votre application, appliquez une journalisation et une surveillance étendues. Les désérialisations qui se produisent souvent ou échouent plus que la normale sont des signaux que quelque chose de mauvais se produit. Attrapez les problèmes tôt.

Journalisation et surveillance insuffisantes

Combien de temps passez-vous à vous assurer de consigner tous les avertissements et erreurs qui se produisent dans votre application ? Enregistrez-vous uniquement les erreurs qui se produisent dans le code ou enregistrez-vous également les erreurs de validation ? Que se passe-t-il lorsque les règles commerciales de votre domaine ne sont pas respectées ? Le fait de ne pas conserver toutes les activités erronées et suspectes dans votre application présente un compromis en matière de sécurité et de données.

Imaginez le scénario suivant. Votre application contient une page de connexion, comme la plupart le font. Le formulaire comporte deux champs, un pour saisir un email et l'autre pour un mot de passe. Si un utilisateur essaie de se connecter et qu'il fournit un mot de passe incorrect, il peut réessayer. Malheureusement, le nombre de tentatives erronées n'est pas limité, la page de connexion ne sera donc pas verrouillée après N tentatives infructueuses. Un attaquant peut profiter de cette opportunité et, étant donné un e-mail correct, continuer à saisir des mots de passe à partir d'une table arc-en-ciel jusqu'à ce qu'une combinaison réussisse finalement. Si votre application est suffisamment sécurisée et que vous hachez les mots de passe avant de les entrer dans une base de données, cette attaque particulière ne fonctionnera pas. Cependant, avez-vous un mécanisme pour identifier les intrusions ?

Ce n'est pas parce que cette tentative n'a pas réussi à ouvrir votre page de connexion qu'une autre ne le fera pas. La page de connexion n'est probablement pas non plus la seule porte dérobée potentielle que vous avez. Si ce n'est pas pour autre chose, quelqu'un pourrait essayer d'utiliser un contrôle d'accès cassé contre vous. Même les applications parfaitement conçues devraient savoir que quelqu'un essaie de les attaquer, même si cela n'est pas possible. C'est toujours ça, pourtant.

Pour faire de votre mieux pour vous protéger contre de telles attaques, procédez comme suit :

• Enregistrez tous les échecs et avertissements se produisant dans l'application, qu'il s'agisse d'exceptions levées dans le code ou d'erreurs de contrôle d'accès, de validation et de manipulation de données. Toutes les informations stockées doivent être répliquées et conservées suffisamment longtemps pour permettre une inspection et une analyse rétrospectives.
• Il est important de déterminer le format et la couche de persistance. Avoir un énorme fichier avec un format de texte arbitraire est facile à réaliser ; le traiter plus tard ne l'est pas. Choisissez une option de stockage qui facilite le stockage et la lecture des données et un format qui permet une (dé)sérialisation facile et rapide. Le stockage de JSON dans une base de données permettant un accès rapide facilite l'utilisation. Gardez la base de données petite en la sauvegardant régulièrement.
• Si vous traitez des données importantes et précieuses, gardez une trace des actions qui peuvent être suivies pour auditer l'état final. Mettre en place un mécanisme pour empêcher la falsification des données.
• Demandez aux systèmes d'arrière-plan d'analyser les journaux et de vous alerter si quelque chose se produit. Les vérifications, qui sont aussi simples que de tester si un utilisateur essaie à plusieurs reprises d'accéder à une partie protégée de l'application, aident. Ne surchargez pas le système avec des chèques fictifs, cependant. Les systèmes de surveillance doivent être exécutés en tant que services distincts et ne doivent pas affecter les performances du système principal.

Lors de la résolution du problème, veillez tout particulièrement à ne pas divulguer les journaux d'erreurs aux utilisateurs externes. Ne pas le faire vous expose à des informations sensibles. La journalisation et la surveillance devraient vous aider à résoudre les problèmes, et non les attaquants à faire leur travail plus efficacement.

Prochaines étapes

Il est important d'être conscient des menaces et des vulnérabilités potentielles des applications Web. Il est encore plus important de commencer à les identifier dans vos applications et d'appliquer les correctifs pour les supprimer.

L'attention portée à la sécurité des applications est une partie importante de toutes les étapes du projet de développement logiciel. Les architectes de logiciels, les développeurs et les testeurs doivent tous intégrer des procédures de test de logiciels dans leurs flux de travail. Il est avantageux d'utiliser des listes de contrôle de sécurité et des tests automatisés dans les étapes appropriées du processus de développement logiciel pour réduire le risque de sécurité.

Que vous analysiez une application existante ou que vous en développiez une nouvelle, vous devriez vous pencher sur le projet de norme de vérification de la sécurité des applications OWASP (ASVS). L'objectif du projet est de développer une norme pour la vérification de la sécurité des applications. La norme énumère les tests et les exigences pour le développement d'applications Web sécurisées. Les tests se voient attribuer des niveaux allant de un à trois, où un signifie le moins de danger et trois signifie la menace potentielle la plus élevée. La classification permet aux gestionnaires d'applications de décider lesquelles des menaces sont les plus probables et les plus importantes. Il n'est pas nécessaire d'inclure chaque test dans chaque application.

Les projets d'applications Web nouveaux et existants, en particulier ceux qui suivent les principes Agile, bénéficient d'une planification structurée des efforts pour sécuriser leurs applications. La planification des tests OWASP ASVS est plus facile si vous décidez d'utiliser OWASP Security Knowledge Framework. Il s'agit d'une application de gestion de sprints axés sur les tests de sécurité, accompagnée d'un ensemble d'exemples sur la façon de résoudre les problèmes de sécurité courants et de listes de contrôle faciles à suivre basées sur OWASP ASVS.

Si vous venez de commencer à explorer la sécurité des applications Web et que vous avez besoin d'un terrain de jeu sécurisé, utilisez une implémentation d'application Web d'OWASP — WebGoat. Il s'agit d'une implémentation intentionnellement non sécurisée d'une application Web. L'application vous guide à travers les leçons, chaque leçon étant concentrée sur une menace de sécurité.

Lors du développement de l'application, assurez-vous de :

• Identifiez et hiérarchisez les menaces. Définissez quelles menaces peuvent réellement se produire et présenter un risque pour votre application. Hiérarchisez les menaces et décidez lesquelles méritent le plus d'efforts de développement et de test. Il ne sert à rien de déployer beaucoup d'efforts pour résoudre l'insuffisance de journalisation et de surveillance si vous servez un blog statique.
• Évaluez l'architecture et la conception de votre application. Certaines vulnérabilités sont très difficiles à résoudre lors des phases ultérieures de développement d'applications. Par exemple, si vous avez l'intention d'exécuter du code tiers et que vous n'envisagez pas d'utiliser un environnement sandbox, il sera très difficile de vous défendre contre les attaques de désérialisation et d'injection non sécurisées.
• Mettre à jour le processus de développement logiciel. Les tests contre les menaces des applications Web doivent, autant que possible, être un processus automatisé. Il est avantageux d'augmenter vos flux de travail CI/CD avec des tests automatisés essayant de trouver des failles de sécurité. Vous pouvez même utiliser votre système de test unitaire existant pour développer des tests de sécurité et les exécuter périodiquement.
• Apprenez et améliorez-vous. La liste des problèmes et des vulnérabilités n'est pas statique et certainement pas limitée à dix ou quinze menaces. De nouvelles fonctionnalités et idées ouvrent les portes à de nouveaux types d'attaques. Il est important de lire les tendances actuelles dans le monde de la sécurité des applications Web pour rester à jour. Appliquez ce que vous apprenez; sinon, vous perdez votre temps.

Conclusion

Même si, comme son nom l'indique, le projet OWASP Top Ten ne répertorie que dix vulnérabilités de sécurité, il existe des milliers de pièges et de portes dérobées possibles menaçant vos applications et, surtout, vos utilisateurs et leurs données. Assurez-vous d'être à l'affût et de constamment rafraîchir vos connaissances, car les changements et les améliorations technologiques ont des avantages et des inconvénients.

Oh, et n'oubliez pas, le monde n'est pas en noir et blanc. Les vulnérabilités de sécurité ne viennent pas seules ; ils sont souvent liés. Être exposé à l'un signifie souvent qu'un tas d'autres sont dans les coins, attendant de lever la tête et parfois, même si ce n'est pas de votre faute, en tant que développeur de la sécurité du système, vous êtes toujours censé corriger les failles pour freiner cybercriminalité. Pour un exemple, voir Les numéros de carte de crédit piratés sont toujours, toujours compatibles avec Google .