Quel est le principal mécanisme de défense d'une application Web ?

Pour empêcher les entrées malveillantes, l'application implémente un grand nombre de mécanismes de sécurité, et ces mécanismes de sécurité sont tous similaires dans leur concept.

Ces mécanismes de sécurité comprennent les aspects suivants :

1. Traitement des données et des fonctions des utilisateurs accédant aux applications Web (empêchant les accès non autorisés)

2. Traitement des données saisies par les utilisateurs dans les fonctions des applications Web (empêchant les accès non autorisés) Construire des données malveillantes)

3. Répondre aux attaques (gérer les erreurs inattendues, bloquer automatiquement les attaques évidentes, envoyer automatiquement des alertes aux administrateurs, conserver les journaux d'accès aux programmes)

4. différents types d'utilisateurs pour une application, tels que les utilisateurs ordinaires, les utilisateurs de vérification de connexion et les administrateurs. Différentes autorisations sont accordées aux différentes applications Web des utilisateurs afin qu'ils ne puissent accéder qu'à différentes données et fonctions.

Les applications Web gèrent l'accès des utilisateurs via trois mécanismes de sécurité interdépendants :

1 Authentification (Authentification)

2 Gestion de session (Gestion de session)

3. accès aux applications, et ce sont aussi trois surfaces d'attaque ; et ces trois sont interdépendantes et indispensables. Peu importe où il y a un problème, un accès non autorisé se produira (principe du baril).

Authentification

L'authentification est le premier mécanisme permettant de gérer l'accès des utilisateurs. À moins que le site Web n'ait un seul type d'utilisateur, l'authentification doit être utilisée.

La plupart des applications Web utilisent aujourd'hui le modèle d'authentification traditionnel, à savoir le nom d'utilisateur et le mot de passe.

Dans les applications avec une sécurité plus élevée telles que les banques, d'autres certificats, l'authentification à deux facteurs, etc. seront utilisés pour renforcer ce modèle ; dans les applications avec des exigences de sécurité plus élevées, des certificats clients, des cartes à puce ou des mécanismes de défi-réponse peuvent être requis ; . Autres modèles d'authentification.

Les mécanismes d'authentification nécessitent souvent une série d'autres fonctions de support, telles que l'enregistrement, le mot de passe oublié, le changement de mot de passe, etc.

Il existe certaines vulnérabilités courantes dans le mécanisme d'authentification, telles que la traversée du nom d'utilisateur, les mots de passe faibles, les failles logiques pour éviter la connexion, les requêtes de base de données d'ingénierie sociale, etc.

Gestion de session

Après avoir réussi la vérification, il est temps de gérer la session de l'utilisateur. Afin de mettre en œuvre le contrôle d'accès, l'application doit identifier diverses requêtes soumises par différents utilisateurs ; pour cela, l'application doit établir une session pour chaque utilisateur et envoyer un jeton représentant la session, c'est-à-dire un jeton de session, au utilisateur. La session elle-même est un ensemble de structures de données stockées sur le serveur qui suivent l'état d'interaction entre l'utilisateur et l'application.

Les jetons de session sont généralement transmis dans les cookies et apparaissent parfois dans des champs de formulaire masqués ou dans des chaînes de requête d'URL. Le jeton de session expirera dans un délai après l'arrêt de la demande.

Certaines applications n'utilisent pas de jetons de session pour identifier les sessions, mais identifient plutôt les sessions en soumettant à plusieurs reprises des certificats d'utilisateur (c'est le cas du mécanisme d'authentification intégré de http, qui identifie les sessions en soumettant à plusieurs reprises des mots de passe de compte cryptés en base64). Dans certains cas, les informations de session ne sont pas enregistrées sur le serveur, mais sur le client. Afin d'éviter que les utilisateurs ne les modifient, elles sont généralement cryptées.

La surface d'attaque de la gestion de session est le jeton de session lui-même. En déduisant les règles de génération du jeton de session ou en interceptant les jetons de session d'autres utilisateurs, vous pouvez accéder aux fonctions et données non autorisées comme les autres.

Contrôle d'accès

Si l'authentification précédente et la gestion de session fonctionnent normalement, l'application peut confirmer l'identité et l'état d'interaction de chaque utilisateur via le jeton de session dans chaque demande, puis décider d'accepter ou non la demande de l'utilisateur.

Étant donné que les exigences du contrôle d'accès typique sont relativement complexes, chaque rôle dispose d'autorisations différentes et chaque utilisateur n'est autorisé à accéder qu'à une partie des données et des fonctions de l'application. Par conséquent, il existe généralement un grand nombre de failles dans ce domaine. mécanisme pouvant provoquer un accès non autorisé.

Traitement des entrées

Toutes les entrées utilisateur ne sont pas dignes de confiance. La plupart des attaques contre les applications Web sont liées à des entrées spécialement construites par des attaquants, donc le traitement sécurisé des entrées utilisateur est la clé pour garantir la sécurité des applications.

Diversité des entrées

Les applications Web peuvent effectuer des contrôles très stricts sur certaines entrées spéciales, telles que les limites de longueur, les limites de caractères, etc. ; elles peuvent parfois devoir accepter toute entrée soumise par l'utilisateur et masquer les champs de formulaire et les cookies ; etc. Ils sont générés sur le serveur et renvoyés au client, puis renvoyés au serveur à la demande de l'utilisateur. Au cours de ce processus, l'attaquant peut les visualiser et les modifier.

Méthodes de traitement des entrées

Utilisez différentes méthodes de traitement dans différentes situations, ou utilisez-les en combinaison.

1. Liste noire

La liste noire contient un ensemble de chaînes ou de modèles qui seront utilisés dans les attaques. Toutes les données correspondant à la liste noire seront bloquées.

La liste noire est la méthode la moins efficace pour confirmer la saisie. Il y a deux raisons :

1) La saisie de l'utilisateur peut être contournée via divers encodages ou d'autres formes d'expression, comme l'absence de certains caractères qui ont le même effet. Par exemple, si alert('xss') est bloqué, vous pouvez également utiliser prompt('xss'). Par exemple, les pare-feu d'applications Web sont souvent soumis à des attaques par octet nul (null). Cela est dû au fait que les chaînes sont traitées différemment dans les applications gérées. et des situations non gérées.

2) Le développement rapide de la technologie a abouti à de nouvelles méthodes d'exploitation des vulnérabilités.

2. Liste blanche

Une liste blanche contient un ensemble de chaînes, de modèles ou un ensemble de critères inoffensifs. Toutes les données qui ne correspondent pas à la liste blanche seront bloquées.

Whitelist est la meilleure méthode de confirmation d'entrée, car seules les chaînes sûres seront laissées lors de la spécification de la liste blanche, et les attaquants ne peuvent pas construire l'entrée.

Mais la liste blanche a des limites. Dans de nombreux cas, les applications Web doivent accepter certains caractères qui ne répondent pas aux normes de sécurité. Par exemple, l'application demande aux utilisateurs de s'inscrire avec leur vrai nom, mais les noms contiennent des traits d'union, des apostrophes et d'autres caractères susceptibles de provoquer des attaques sur la base de données. . Par conséquent, la liste blanche a ses limites et ne constitue pas une solution universelle aux entrées dangereuses.

3. Purification

Cette méthode résout le problème que la liste blanche ne peut pas gérer. Elle accepte certaines saisies de données qui ne peuvent pas garantir la sécurité, mais les purifieront, comme la suppression. échappement, encodage, etc.

La purification peut être utilisée comme méthode générale, mais il convient de noter que si un élément d'entrée doit accueillir plusieurs données malveillantes possibles, il peut effectivement s'agir d'une évolution. Dans ce cas, une confirmation des limites est requise.

4. Traitement sécurisé des données

La gestion non sécurisée des données soumises par les utilisateurs est à l'origine de nombreuses vulnérabilités d'applications Web.

Une méthode de traitement des données sûre qui n'a pas besoin de se soucier de la confirmation des données saisies par l'utilisateur, mais garantit plutôt la sécurité absolue du processus de traitement. Par exemple, des requêtes paramétrées pour empêcher l’injection SQL.

Mais cette méthode ne s'applique pas à toutes les tâches qu'une application Web doit effectuer. Le cas échéant, il s'agit d'une méthode générale de gestion des entrées malveillantes.

5. Vérification logique

Dans certaines vulnérabilités, les entrées de l'attaquant et de l'utilisateur normal sont exactement les mêmes, mais la motivation est différente. Dans ce cas, ce qui précède. Le mécanisme est presque totalement inefficace. Par exemple, attaquer un compte soumis en modifiant un champ de formulaire masqué pour tenter d'accéder à d'autres comptes d'utilisateurs. À ce stade, aucune confirmation de saisie ne peut distinguer les données de l'attaquant de celles des utilisateurs normaux. Pour empêcher tout accès non autorisé, l'application doit confirmer que le compte soumis appartient à l'utilisateur qui a précédemment soumis le compte.

Boundary Confirmation

Compte tenu de la nature du problème de sécurité principal (toutes les entrées de l'utilisateur ne sont pas fiables), il est possible de combler le fossé entre Internet (non fiable) et le serveur application (de confiance) En tant que limite, toutes les entrées provenant d'Internet sont ensuite nettoyées à la frontière et les données nettoyées sont transmises à l'application serveur. Ce qui précède est une simple confirmation des limites. Lors de l'analyse des vulnérabilités réelles, il a été constaté que cette simple confirmation de saisie n'était pas suffisante.

En fonction de l'étendue des fonctions exécutées par l'application et de la diversité des technologies qu'elle adopte, une application typique doit se défendre contre un grand nombre d'attaques d'entrée différentes, chacune d'entre elles pouvant employer une approche complètement différente. données spécialement conçues, ce qui rend difficile la mise en place d'un mécanisme simple au niveau du périmètre externe pour se défendre contre toutes les attaques.

De nombreuses fonctionnalités de l'application sont conçues pour combiner une série de processus différents. Une entrée de l'utilisateur peut effectuer de nombreuses opérations dans de nombreux composants, où la sortie de l'opération précédente est utilisée dans l'opération suivante. Les données sont transformées de manière à être complètement différentes de l'entrée d'origine. Cependant, les attaquants expérimentés peuvent profiter de cette différence pour générer des données malveillantes à des étapes critiques et attaquer les composants qui reçoivent les données. Il est donc difficile d’établir un mécanisme simple à la frontière extérieure pour se défendre contre toutes les attaques.

La confirmation des limites est un modèle plus efficace. La frontière ici ne se limite plus à la frontière entre Internet et l'application Web. Chaque composant ou unité fonctionnelle de l'application Web a une frontière. De cette façon, chaque composant peut se défendre contre le type particulier d’entrée spécialement conçue qu’il reçoit. Lorsque les données passent par différents composants, des contrôles de validation peuvent être effectués sur les données générées précédemment, et puisque différents contrôles de validation sont effectués à différentes étapes du traitement, il n'y a aucune possibilité de conflits entre eux.

Par exemple, l'image ci-dessous :

Confirmation et standardisation en plusieurs étapes

Pendant le processus de vérification de confirmation, un problème souvent rencontré par les mécanismes de saisie survient lorsque la saisie de l'utilisateur doit être traitée en plusieurs étapes. Ce problème se produit lorsqu'une application tente de nettoyer les entrées utilisateur en supprimant ou en codant certains caractères. Si ce problème n’est pas traité avec soin, un attaquant peut créer des entrées spécialisées afin que les données malveillantes puissent contourner le mécanisme de confirmation. Par exemple, le contournement de la double écriture et le contournement de la séquence d'exécution des étapes.

La normalisation des données crée un autre problème. Afin de transmettre certains caractères inhabituels et données binaires via http, ils sont généralement normalisés via le codage. Cependant, si le décodage est effectué après la mise en œuvre du filtrage, l'attaquant peut éviter le mécanisme de confirmation via le codage.

En plus des schémas de codage standard utilisés par les applications Web, dans d'autres cas, si des composants de l'application convertissent des données d'un jeu de caractères à un autre, cela peut également entraîner des problèmes de normalisation. Par exemple, Ÿ et  sont convertis en Y et A. Les attaquants utilisent souvent cette méthode pour transmettre des caractères et des mots-clés bloqués.

Parfois, il est difficile d'éviter les problèmes causés par la confirmation et la normalisation en plusieurs étapes, et il n'existe pas de solution unique à ces problèmes. Comment est-il possible d'éviter généralement de nettoyer les mauvaises entrées et de les rejeter complètement.

Réponse aux attaques

Nous avons fait de notre mieux pour empêcher les attaquants de s'introduire, mais il n'existe pas de système absolument sûr si un incident de sécurité survient, comment l'application Web doit-elle réagir à l'attaque ?

1. Gérez les erreurs inattendues

2. Bloquez automatiquement les attaques évidentes

3. Envoyez automatiquement des alertes aux administrateurs

4. Tenez à jour les journaux d'accès au programme

Gestion des erreurs

Une clé de l'application. comment gérer les erreurs inattendues. Généralement, dans un environnement de production, les applications ne doivent renvoyer à l'utilisateur aucune information générée par le système ou autre information de débogage. Ces informations fournissent aux attaquants de bonnes informations de référence pour la prochaine attaque. Et des erreurs inattendues indiquent souvent une faille dans les mécanismes de défense d'un programme. Les mécanismes de gestion des erreurs sont souvent intégrés aux mécanismes de journalisation.

Réponse aux attaques

De nombreuses attaques enverront un grand nombre de caractères malveillants courants. Dans de tels cas, les applications doivent prendre des mesures de réponse automatiques pour empêcher les attaquants de les détecter. Par exemple, mettre fin à la session, exiger une reconnexion, interdire l'IP, etc.

Maintenir les journaux

Les journaux enregistreront l'intrusion et le processus d'intrusion pourra toujours être restauré après l'intrusion.

Les journaux d'applications importants doivent enregistrer toutes les demandes. Généralement, il doit inclure au moins les éléments suivants :

1. Tous les événements liés à l'authentification, tels que les connexions réussies ou échouées, les modifications de mot de passe

2. Demandes de contrôle d'accès

4. Contiennent des chaînes d'attaque connues

Le journal enregistrera l'heure, l'adresse IP et le compte utilisateur de chaque événement. Les journaux doivent être strictement protégés contre toute lecture non autorisée. Écriture, modification, etc.

Les journaux peuvent également devenir une surface d'attaque. Par exemple, les journaux accessibles sans autorisation fourniront aux attaquants des informations sensibles telles que des jetons de session et des paramètres de requête.

Alerte aux administrateurs

Le problème principal réside dans les faux positifs et les faux négatifs, qui peuvent être améliorés en combinant le mécanisme d'alerte avec un mécanisme de confirmation et d'autres méthodes de contrôle.

De manière générale, les événements anormaux surveillés sont les suivants :

1. Anomalie d'application, telle que la réception d'un grand nombre de demandes provenant d'une adresse IP

2. Anomalie de transaction, telle que des fonds transférés vers et depuis un compte bancaire. Le numéro est anormal

3. Contient des chaînes d'attaque connues

4. Les données de la demande qui ne peuvent pas être consultées par les utilisateurs ordinaires ont été modifiées

Application de gestion

Le programme de gestion peut aider les administrateurs à gérer les comptes et les rôles d'utilisateurs, l'application. fonctions de surveillance et d'audit, effectuer des tâches de diagnostic et configurer diverses fonctionnalités de l'application.

Les mécanismes de gestion sont l'une des principales surfaces d'attaque des applications, et les mécanismes de gestion disposent souvent de permissions très élevées. Prendre le contrôle du mécanisme de gestion, c'est prendre le contrôle de l'application. En outre, le mécanisme de gestion comporte souvent des lacunes évidentes et des fonctions sensibles. Les vulnérabilités qui obtiennent des autorisations d'administrateur se produisent généralement dans le mécanisme d'accès des utilisateurs, comme un accès non autorisé, des mots de passe faibles, etc. Si l'arrière-plan de gestion peut gérer les demandes envoyées par des utilisateurs ordinaires, vous pouvez essayer de saisir aveuglément la vulnérabilité XSS en arrière-plan.

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!