La sécurité avec des exemples réels est toujours plus intéressante.
En tant que testeur de pénétration, j'aime quand des projets basés sur des frameworks de développement rapide arrivent, comme Ruby-on-Rails, Django, AdonisJs, Express, etc. Ils vous permettent de construire un système très rapidement car les modèles commerciaux sautent immédiatement à tous les niveaux, y compris le navigateur client. Model (modèles d'objets métier dans la base de données) et ViewModel (contrat d'interaction avec les clients), ces cadres sont souvent combinés ensemble pour éviter un passage inutile de Model à ViewModel et vice versa, les services REST sont générés automatiquement. Du point de vue du développement, vous pouvez simplement développer un modèle commercial sur le serveur, puis l'utiliser immédiatement sur le client, ce qui augmente sans aucun doute la vitesse de développement.
Encore une fois, je ne dis pas que les frameworks susmentionnés sont mauvais, ou quelque chose ne va pas avec eux, ils ont les moyens et les outils d'une protection appropriée, c'est juste que les développeurs font le plus d'erreurs avec eux. Cela a également été vu dans un projet ASP.NET MVC, dans lequel les développeurs ont fait les mêmes vulnérabilités en exposant des modèles au lieu de ViewModels ...
Vulnérabilité: en raison de la faible validation des champs des modèles entrants du client, il est possible d'injecter des champs qui ne sont pas fournis par la fonctionnalité, mais qui sont dans le modèle économique. Par exemple, il existe une méthode qui vous permet de modifier uniquement le nom d'utilisateur et renvoie un objet de profil utilisateur. Que faire si je copie l'objet retourné, modifie toutes les propriétés qu'il contient et le renvoie à nouveau à l'entrée? Il peut s'avérer que vous pouvez modifier n'importe quelle propriété de l'objet (mot de passe, rôle), en contournant le flux de travail standard.
Parmi les différents projets que nous avons testés pour la sécurité, je vais donner des exemples réels. Tous ces problèmes ont été corrigés et toute information supplémentaire dans les captures d'écran est masquée.
Système 1Sur ce système, seul le nom d'utilisateur pouvait être modifié dans le profil. Mais en remplaçant un autre e-mail, j'ai pu modifier les informations de connexion de l'utilisateur. De plus, les invitations à d'autres utilisateurs ont désormais quitté ce savon.
Système 2Dans cet exemple, un simple utilisateur a réussi à changer le rôle en administrateur en ajoutant le champ des rôles, et par url / admin, il suffit d'ouvrir le panneau d'administration système avec toutes les transactions, les utilisateurs, les rapports, etc.
Système 3Dans ce système, il était possible de renouveler un abonnement gratuit pour une durée indéterminée. Il est clair que l'approche standard exigeait un paiement.
La méthode de saisie prendrait, semble-t-il, uniquement la couleur sélectionnée en fonction de la marque de l'espace de travail, et renvoie l'objet de tout l'espace de travail, y compris un vidage complet de l'objet StripeCustomer, qui reflétait le paiement. Il était possible d'insérer non seulement un champ, mais un énorme sous-objet StripeCustomer, et en conséquence, après avoir payé une fois, ou par un autre utilisateur pour capturer cet objet, et le dupliquer dans tous ses espaces de travail.
Système 4Et enfin. Ce système avait le même problème: il était possible de changer le mot de passe et la clé de passe en contournant le workflow inventé. Le manque de protection contre CSRF et le stockage des cookies d'authentification pendant une longue période a augmenté le risque de cette vulnérabilité au paradis. Un utilisateur malveillant pourrait placer un script sur une ressource populaire avec une demande de modification du mot de passe de l'utilisateur actuel de ce système, et tous les utilisateurs qui ouvriraient cette ressource perdraient l'accès au système.
Masquer dans le code serveur dans les métadonnées de ce champ, cela a permis de ne pas retourner ce champ au client dans la réponse, mais ce champ a été traité sans problème dans les données d'entrée.
Le message:- Ne faites jamais confiance aux données entrantes des utilisateurs, ils peuvent tout faire avec eux
- Soyez prudent avec les systèmes qui n'ont pas de couche ViewModel-s séparée et travaillez directement avec les modèles de base
- Explorez plus en détail les protections offertes par votre framework.
Les informations ci-dessus sont fournies uniquement à des fins éducatives et éducatives, comment faire leurs systèmes n'est pas nécessaire.
Denis Koloshko, testeur de pénétration, CISSP