Grâce à la détection JS, votre système Web est-il vraiment sécurisé ?

Recommandations d'apprentissage associées : javascript

Votre Web est le système est-il vraiment sûr ?

Un remblai de mille kilomètres s'effondre dans un nid de fourmis.

Dans les systèmes Web, une petite vulnérabilité peut souvent entraîner des conséquences extrêmement graves. Par conséquent, la sécurité Web est une question que chaque système doit prendre en compte lors de la conception, du développement, de l’exploitation et de la maintenance.

Les mesures défensives prises par de nombreux systèmes Web aujourd'hui sont orientées vers les bases et les simples, ciblant souvent uniquement les vulnérabilités de sécurité courantes, telles que :

• Csrf
• XSS
• Injection SQL

et ainsi de suite. Ces mesures défensives de base sont nécessaires et peu coûteuses à mettre en œuvre, mais elles ne constituent que la partie fondamentale de la défense de la sécurité du système. De nombreux développeurs pensent que faire ces choses suffit pour faire face à la plupart des situations. Cette idée est très dangereuse. En fait, en plus de ces vulnérabilités basiques et standardisées, la logique métier de chaque système d’entreprise elle-même est également susceptible de devenir la cible d’attaques de pirates. Une fois détectée et brisée, les conséquences seront très graves. Ci-dessous, nous énumérerons quelques failles courantes de la logique métier. Ces failles ont également été rencontrées lors du développement de systèmes auparavant. J'espère qu'elles pourront inspirer tout le monde.

La gestion des informations d'identification de session prête à confusion

Nous savons tous que HTTP lui-même est sans état. Pour que le navigateur et le serveur connaissent l'identité de chacun et se fassent confiance, la plupart des systèmes Web utilisent des « jetons ». Ceci est mis en œuvre à l'aide des informations d'identification convenues. Le jeton sera généré après la connexion de l'utilisateur et expirera lorsque l'utilisateur se déconnectera activement ou après un certain temps. C'est-à-dire que si la requête apporte le jeton correspondant, alors le serveur peut obtenir le jeton et effectuer la vérification correspondante. Si la vérification réussit, il fera confiance à la requête et exécutera la logique métier correspondante. en apportera un illégal ou expiré est considéré comme illégal. Cela ne semble pas poser de problème, mais il peut y avoir des failles cachées dans la mise en œuvre réelle.

Regardons deux exemples :

1. Lorsque le développeur front-end Xiao Ming a écrit la logique permettant à l'utilisateur de cliquer sur le bouton de sortie, il a simplement effacé la valeur du jeton dans le cookie ou le stockage local. (le jeton est généralement stocké à ces deux endroits) et n'a pas lancé de demande au backend pour laisser le jeton expirer dans l'entreprise. La validité de ce jeton va alors essentiellement à l’encontre de l’intention de l’utilisateur, et le risque est actuellement très élevé. Lorsque l'utilisateur quitte spontanément, le jeton est toujours valide. Si le jeton est obtenu et enregistré par d'autres d'une manière ou d'une autre, il peut parfaitement rejouer les opérations effectuées par l'utilisateur, telles que la modification des informations utilisateur, la passation de commandes, etc.

2. Dans l'exemple ci-dessus, nous avons mentionné que le jeton doit être configuré pour expirer. Un délai d'expiration raisonnable peut réduire efficacement les risques. Mais le développeur back-end peut être ébloui et ses mains tremblent lors de la définition de la configuration d'expiration du jeton, et il peut entrer un chiffre supplémentaire, ou il peut mal comprendre l'unité et utiliser les valeurs de niveau MS pour les unités de niveau S, alors le délai d'expiration sera fixé. La commande est très longue. C'est très dangereux pour les utilisateurs qui n'aiment pas se déconnecter activement après s'être connectés ou qui restent longtemps sur la page. Le jeton est toujours valide même si l'utilisateur ne l'utilise pas pendant une longue période. Si quelqu'un d'autre obtient le jeton, il peut faire beaucoup de mauvaises choses.

Échec de la vérification

Le téléchargement de fichiers devrait être une fonction courante dans les applications Web, comme le téléchargement d'avatars, le téléchargement de fichiers sur des disques réseau, etc. Les utilisateurs malveillants peuvent télécharger des chevaux de Troie, des virus, des scripts malveillants et d'autres fichiers lors du téléchargement. Si de tels fichiers sont exécutés sur le serveur, ils auront de graves conséquences. Cette méthode d’attaque est relativement peu coûteuse et relativement facile à exploiter par les attaquants. Plus le nombre de types de fichiers autorisés à être téléchargés est élevé, plus le potentiel d'attaque est grand. Lorsque le programme malveillant est téléchargé avec succès, il peut être téléchargé par l'utilisateur et empoisonné après avoir été exécuté sur l'ordinateur de l'utilisateur. Des programmes malveillants peuvent également être exécutés sur le serveur, provoquant le contrôle du serveur, entraînant une paralysie du serveur et une perte de données.

Dans des circonstances normales, le programme jugera le type de fichier et autorisera uniquement le téléchargement sur le serveur des fichiers que nous pensons légaux. Cependant, dans certains programmes Web, ce jugement est effectué uniquement sur le front-end et non sur le back-end. Cela crée des opportunités pour les attaquants, qui peuvent facilement modifier les demandes de téléchargement de fichiers illégaux.

L'approche correcte devrait consister à effectuer un jugement d'extension de fichier, une détection MIME et à télécharger des restrictions de taille de fichier sur le backend pour s'en défendre. De plus, les fichiers peuvent être enregistrés sur un serveur isolé de l'entreprise pour empêcher des fichiers malveillants d'attaquer le serveur de l'entreprise et de provoquer une indisponibilité du service.

Énumération des données

Lors de la connexion au système, la plupart des systèmes détermineront si l'utilisateur existe lorsque l'utilisateur se connecte, puis afficheront une invite "Ce numéro de téléphone mobile n'est pas enregistré". Si cette logique est effectuée à l'aide d'une interface distincte, il existe un risque d'énumération par force brute. Un attaquant peut utiliser cette interface pour utiliser la bibliothèque de numéros de téléphone mobile afin d'effectuer une énumération des demandes et d'identifier les numéros de téléphone mobile qui ont été enregistrés dans le système, ce qui offrira des opportunités de piratage de mot de passe par force brute à l'étape suivante.

Pour ce problème, il est recommandé de mettre ce jugement dans l'interface de vérification de connexion et de ne pas renvoyer d'invite claire. Vous verrez que sur les sites Web bien conçus, le message « Le numéro de téléphone mobile n'est pas enregistré ou le mot de passe est erroné ». Bien que cela compromette l’expérience utilisateur, cela est également plus sécurisé.

Relecture d'écriture de données

Prenons un message de forum comme exemple, utilisez l'outil de capture de paquets pour capturer le processus de demande de la publication du forum et rejouez le processus via l'outil, vous constaterez que la liste des messages apparaît. Deux messages identiques, il s'agit d'une attaque par rejeu. Si la fréquence de relecture est accélérée, non seulement de nombreuses données indésirables seront générées dans le système, mais des écritures fréquentes exerceront également une pression énorme sur la base de données de l'entreprise.

Pour les requêtes présentant un risque de relecture, il est recommandé d'ajouter une limite de fréquence de requête. Par exemple, vous pouvez déterminer les horodatages de deux requêtes et les définir pour qu'ils soient valides s'ils sont supérieurs à une certaine valeur temporelle.

Vulnérabilité des autorisations

La vérification des autorisations est une fonction de base du système Web, telle qu'un système de gestion de la structure organisationnelle d'une entreprise, qui fournit la fonction de modification des noms de département et des chefs de département. L'ajout d'une vérification des autorisations peut empêcher efficacement tout utilisateur de modifier des informations qu'il n'est pas autorisé à utiliser via ces fonctions. La vérification des autorisations sera certainement mise en œuvre dans de tels systèmes, mais est-elle réellement mise en œuvre correctement ?

Supposons que nous stipulions qu'un utilisateur du système doit remplir deux conditions : disposer des autorisations de super gestion et appartenir au département A, afin de modifier le nom du département. Souvent, dans l'implémentation réelle du code, les développeurs déterminent uniquement si l'utilisateur est un super administrateur, mais ne déterminent pas si l'utilisateur appartient au département. Dans ce cas, on peut utiliser le super compte de gestion du service B pour modifier le nom du service A, ce qui revient à le modifier au-delà de l'autorité. Ce n'est évidemment pas le résultat attendu. Même si l'utilisateur super-administrateur du département B ne trouve pas l'entrée pour modifier le nom du département A sur l'interface, il peut toujours modifier les paramètres en saisissant la demande.

En plus des modifications non autorisées, vous pouvez bien entendu également les consulter au-delà de votre autorité. Nous ne nous attendons certainement pas à ce que le super manager du département A puisse voir les informations du département B, n'est-ce pas ?

Il est recommandé que votre système vérifie et limite strictement les droits d'accès des utilisateurs aux rôles.

La sécurité n'est pas une mince affaire. Comme mentionné au début, toute vulnérabilité peut apporter des coups dévastateurs. J'espère que tout le monde y prêtera attention. Non seulement nous devons prêter attention à la conception commerciale, mais nous devons également prêter attention à la révision du code pour éviter les vulnérabilités de bas niveau causées par la mise en œuvre.

Ce qui précède ne sont que quelques-unes des nombreuses vulnérabilités de sécurité. Pour les risques de sécurité des applications Web plus graves, veuillez vous référer aux 10 principaux problèmes de sécurité publiés dans le Top 10 OWASP 2017. www.owasp.org.cn/owasp-proje…

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!