Quelles sont les vulnérabilités courantes en matière de sécurité Web et les méthodes de test ?

1. Six principes de base des tests de sécurité :

Authentification : Retour des demandes aux utilisateurs authentifiés

Contrôle d'accès : Contrôle des autorisations et protection des données pour les utilisateurs non authentifiés

Intégrité : Les utilisateurs doivent recevoir avec précision les informations envoyées par le serveur Confidentialité des informations

Confidentialité : les informations doivent être fournies avec précision à l'utilisateur prévu.

Fiabilité : à quelle fréquence échoue-t-elle ? Combien de temps faut-il au réseau pour se remettre d’une panne ? Quelles mesures sont prises pour faire face à une défaillance catastrophique ? (Personnellement, je comprends que cet endroit devrait être plus enclin à la catégorie des tests de tolérance aux pannes et de tolérance aux catastrophes)

Non-répudiation : les utilisateurs doivent pouvoir prouver que les données reçues proviennent d'un serveur spécifique

2. Contenu commun des tests de sécurité

Contrôle des autorisations

Injection SQL

Tests de sécurité des URL

XSS (attaque de script intersite)

CSRF (falsification de requêtes intersites)

Vulnérabilité de saut d'URL

Autres considérations de sécurité

3 . Quelles sont les causes des problèmes de sécurité dans les applications Web ? Il existe généralement les raisons suivantes :

1. Les systèmes d'application complexes comportent une grande quantité de code et de nombreux développeurs, la négligence est donc inévitable.

2. Le système a été mis à niveau à plusieurs reprises et le personnel a été changé fréquemment, ce qui a entraîné une incohérence du code.

3. Plusieurs systèmes Web tels que les systèmes hérités historiques et les systèmes d'exploitation d'essai fonctionnent ensemble sur le même serveur.

4. Les développeurs n'ont pas reçu de formation sur le codage sécurisé ou l'entreprise ne dispose tout simplement pas de normes de codage sécurisées unifiées.

5. Les testeurs sont inexpérimentés ou libérés sans tests d'évaluation de sécurité professionnels.

6. Il n'y a aucune vérification de la saisie de l'utilisateur. Voici quelques exemples :

1) Ne faites jamais confiance aux saisies de l'utilisateur, vérifiez les saisies de l'utilisateur

2) La saisie numérique doit être des nombres légaux

3) Traitement spécial des symboles d'encodage dans saisie de caractères

4) Vérifiez tous les points d'entrée, y compris Get, Post, Cookie et autres en-têtes HTTP

4. Vulnérabilités courantes et solutions dans les tests de sécurité :

1 Attaque de script intersite XSS

SS est similaire à SQL. L'injection XSS insère des scripts malveillants via des pages Web. Les principales technologies utilisées sont également des scripts HTML et JavaScript front-end. Lorsque l'utilisateur navigue sur le Web, une méthode d'attaque est mise en œuvre pour contrôler le comportement du navigateur de l'utilisateur.

Un XSS réussi peut obtenir le cookie de l'utilisateur et utiliser le cookie pour voler les autorisations de fonctionnement de l'utilisateur sur le site Web ; il peut également obtenir la liste de contacts de l'utilisateur et utiliser l'identité de l'attaquant pour envoyer un grand nombre de messages à une cible spécifique. groupe. Spam, etc.

XSS est divisé en trois catégories : type de stockage (XSS persistant), type de réflexion (XSS non persistant) et type DOM.

Méthode de test :

Dans l'interface de saisie des données, saisissez : <script>alert(/123/)</script>. Si une boîte de dialogue apparaît après un enregistrement réussi, elle indique qu'il existe une vulnérabilité XSS ici. .

Ou modifiez les paramètres de la demande d'URL en <script>alert(/123/)</script>. Si une boîte de dialogue apparaît sur la page, elle indique qu'il existe une vulnérabilité XSS.

2. Injection SQL

L'injection SQL consiste à insérer des commandes SQL dans les soumissions de formulaires Web ou à saisir des chaînes de caractères de requête

pour les noms de domaine ou les requêtes de page, et finalement à inciter le serveur à exécuter des commandes SQL malveillantes.

Les dommages possibles causés par l'injection SQL incluent : les pages Web et les données sont falsifiées, les données de base sont volées et le serveur sur lequel se trouve la base de données est attaqué et transformé en hôte fantoche.

Par exemple, certains sites Web n'utilisent pas de SQL précompilé, et certains champs saisis par l'utilisateur sur l'interface sont ajoutés au SQL. Il est très probable que ces champs contiennent des commandes SQL malveillantes. Par exemple : password = "1' OR '1'='1" ; même si vous ne connaissez pas le mot de passe utilisateur, vous pouvez vous connecter normalement.

Méthode de test :

Sur la page qui doit être interrogée, entrez les conditions de requête correctes et des instructions SQL simples telles que 1=1, et vérifiez les résultats de la réponse si les résultats renvoyés en entrant les conditions de requête correctes sont cohérents, cela indique que l'application ne filtre pas les entrées de l'utilisateur. , on peut juger au préalable qu'il existe une vulnérabilité d'injection SQL ici

Suggestions de modification :

Vérifiez l'entrée de l'utilisateur, vous pouvez utiliser des expressions régulières ou limiter la longueur de la conversion ; mots-clés suivants, etc. ,|like'|and|exec|execute|insert| create|drop|table|from|grant|group_concat|column_name|information_schema.columns|table_schema|union|where|select|delete|update|order|by|count|chr |mid|master|truncate|declare|or|-- |+|,|like|//

N'utilisez pas SQL d'assemblage dynamique, vous pouvez utiliser SQL paramétré ou utiliser directement des procédures stockées pour la requête et l'accès aux données ;

N'utilisez pas de connexions à la base de données avec des droits d'administrateur, utilisez-la pour chaque application Connexion à une base de données séparée avec des autorisations limitées

Les informations d'exception de l'application doivent donner le moins d'invites possible, et il est préférable d'utiliser des informations d'erreur personnalisées pour envelopper l'erreur d'origine ; information.

3. Vulnérabilité de saut d'URL

La vulnérabilité de saut d'URL, c'est-à-dire une vulnérabilité de redirection non vérifiée, signifie que le programme Web accède directement à l'URL dans le paramètre ou introduit l'URL de n'importe quel développeur dans la page, sur laquelle les programmes démarreront. zones tierces dangereuses, provoquant des problèmes de sécurité.

Méthode de test :

1. Utilisez l'outil de capture de paquets pour capturer la demande.

2. Saisissez l'URL 302, modifiez l'adresse cible et vérifiez si elle peut sauter.

ps : Cependant, de nombreux sauts ont désormais une vérification du référent ajoutée, empêchant les attaquants de sauter.

4. Vulnérabilité de téléchargement de fichier

Une attaque de téléchargement de fichier signifie que l'attaquant télécharge un fichier exécutable sur le serveur et l'exécute.

Cette méthode d'attaque est la plus directe et la plus efficace. Les fichiers téléchargés peuvent être des virus, des chevaux de Troie, des scripts malveillants, des webshells, etc.

Webshell est un environnement d'exécution de commandes qui existe sous la forme de fichiers Web tels que asp, php, jsp ou cgi. On peut également dire qu'il s'agit d'une porte dérobée Web. Une fois qu'un attaquant a empêché ou inséré un webshell dans le système affecté, il peut facilement entrer dans le système via le webshell et contrôler le serveur du site Web.

Méthode de test :

Vérifiez strictement le type, la taille, etc. du fichier téléchargé et interdisez le téléchargement de fichiers contenant un code malveillant.

Vérifiez les autorisations d'exécution des répertoires concernés. Vous pouvez accéder à tous les répertoires du serveur Web via le navigateur et vérifier si la structure des répertoires est renvoyée. Si la structure des répertoires est affichée, il peut y avoir un problème de sécurité.

5. Attaque de requêtes falsifiées intersites CSRF

CSRF utilise l'identité de l'utilisateur connecté pour envoyer des requêtes malveillantes au nom de l'utilisateur afin d'effectuer des opérations illégales.

Par exemple : si un utilisateur navigue et fait confiance au site Web A qui présente une vulnérabilité CSRF, le navigateur génère un cookie correspondant et l'utilisateur visite le site Web dangereux B sans quitter le site Web.

Le site Web dangereux B demande à accéder au site Web A et fait une demande. Le navigateur visite le site Web A avec les informations de cookie de l'utilisateur. Étant donné que le site Web A ne sait pas si la demande provient de l'utilisateur lui-même ou d'un site Web dangereux B, il traitera la demande du site Web dangereux B, complétant ainsi la simulation des opérations de l'utilisateur. . C'est l'idée de base des attaques CSRF.

Méthode de test :

1. Ouvrez deux pages dans le même navigateur. Après l'expiration de l'autorisation d'une page, l'autre page peut-elle être utilisée avec succès, si elle peut toujours être utilisée avec succès, il y a un risque.

2. Utilisez des outils pour envoyer des requêtes, n'ajoutez pas le champ référent dans l'en-tête de la requête http, vérifiez la réponse du message renvoyé et redirigez vers l'interface d'erreur ou l'interface de connexion.

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!