Les attaques Web actuelles sont généralement des attaques par injection. La raison de l'injection est généralement un filtrage incomplet des variables, qui permet aux intrus d'exécuter illégalement des programmes ou d'interroger et de modifier des données arbitraires. Alors que les attaques par injection deviennent de plus en plus intenses, certains codes de filtrage spécialisés sont apparus. Cependant, des imperfections dans certains codes de filtrage peuvent conduire à de nouvelles attaques. Ce qui suit utilise le code de filtrage le plus largement utilisé - le programme anti-injection universel SQL - pour expliquer les causes, les méthodes d'utilisation et les mesures préventives de la vulnérabilité.
Le programme anti-injection universel SQL est écrit par Feng Zhiqiu de Firefox. Il s'agit d'un code anti-injection assez complet. Il peut implémenter un filtrage de soumission pour les caractères de filtre définis et peut enregistrer les informations de données soumises par l'adresse IP de l'attaquant. Lors de son utilisation, il vous suffit d'ajouter le code <--#Include File="WrSky_Sql.Asp"--> à l'en-tête du fichier pour empêcher l'injection pour réaliser le filtrage des variables. Si vous ajoutez du code de programme après le fichier de connexion à la base de données (comme conn.asp), vous pouvez obtenir un filtrage variable de l'ensemble du site, obtenant ainsi l'effet anti-injection.
Bon, regardons d'abord le code de la partie filtrage des variables :
'--------Partie définition------------------
Dim Fy_Post, Fy_Get, Fy_In, Fy_Inf, Fy_Xh, Fy_db, Fy_dbstr
'Personnalisez les chaînes qui doivent être filtrées, séparées par "érable"
Fy_In = "' maple; maple et maple exec maple insert maple select maple delete maple update maple count maple * maple% maple chr maple mid maple master maple tronquer maple char maple declare"
'----------------------------------
%>
＜
Fy_Inf = split(Fy_In,"Érable")
'--------Partie POST------------------
Si Request.Form＜＞Alors
Pour chaque Fy_Post dans Request.Form
pour Fy_Xh=0 vers Ubound (Fy_Inf)
Si Instr(LCase(Request.Form(Fy_Post)),Fy_Inf(Fy_Xh))＜＞Alors
'--------OBTENIR une partie------------------
Si Request.QueryString＜＞Alors
Pour chaque Fy_Get dans Request.QueryString
pour Fy_Xh=0 vers Ubound (Fy_Inf)
If Instr(LCase(Request.QueryString(Fy_Get)),Fy_Inf(Fy_Xh))＜＞Alors
ce code définit le filtrage des variables couramment injectées telles que "'", "et", etc. Si vous estimez que le filtrage n'est pas assez ou trop, vous pouvez le faire vous-même. Ajoutez ou soustrayez des caractères. Évidemment, tant que les données soumises au serveur via get ou post contiennent des caractères filtrés, elles seront interdites par le programme. Cela entraîne un problème. Si vous ajoutez du code de programme après le fichier de connexion à la base de données du forum, tant que le contenu du message contient des caractères filtrés, il sera banni. Selon le filtrage de contenu par défaut, il semble qu'il soit presque impossible de publier si le contenu est en anglais. De plus, certains caractères spéciaux (comme le signe de pourcentage « % ») sont parfois utilisés lors de la définition du style du forum. Si ces caractères spéciaux sont filtrés, l'ensemble du forum ne fonctionnera pas correctement. Concernant le problème mentionné ci-dessus, j'ai utilisé dvbbs pour le tester, et le résultat était exactement ce à quoi je m'attendais.
La façon de résoudre le problème ci-dessus consiste à empêcher l’injection d’instructions de connexion uniquement dans les fichiers qui doivent être filtrés. Mais cette charge de travail est relativement importante et les webmasters ne savent généralement pas quels fichiers doivent être filtrés. Par conséquent, ma suggestion est d'ajouter le code de filtrage à conn.asp, puis de créer un connl.asp qui ne contient pas le code de filtrage et de connecter les fichiers qui n'ont certainement pas besoin de filtrage et le code de filtrage a un impact sur le fonctionnement de ce fichier dans conn1.asp, mais vous devez noter que le contenu de base des deux fichiers de connexion de données doit être cohérent. De plus, il est préférable de ne pas utiliser de caractères filtrés dans les paramètres de style. Si vous en avez vraiment besoin, vous pouvez supprimer le filtrage de ces caractères dans le programme anti-injection.
Ce qui précède concerne l’impact du programme anti-injection sur le fonctionnement du site, et il ne peut causer aucun préjudice. En fait, le vrai mal vient de la partie enregistrement des données. Jetons un coup d'œil à cette partie du code :
''--------Écrire dans la base de données-------En-tête----. ----
Fy_dbstr="DBQ="+server.mappath("SqlIn.mdb")+";DefaultDir=;DRIVER={Pilote Microsoft Access (*.mdb)};"
Définir Fy_db=Server.CreateObject("ADODB.CONNECTION")
Fy_db.open Fy_dbstr
Fy_db.Execute("insérer dans SqlIn(Sqlin_IP,SqlIn_Web,SqlIn_FS,SqlIn_CS,SqlIn_SJ) valeurs('"&Request.ServerVariables("REMOTE_ADDR")&"','"&Request.ServerVariables("URL")&"',' GET','"&Fy_Get&"','"&replace(Request.QueryString(Fy_Get),"'","''")&"')")
Fy_db.close
Définir Fy_db = Rien
'--------Écrire dans la base de données------------Tail--------
Response.Write "＜Script Language=JavaScript＞alert('Fengwang SQL invite du système anti-injection universel↓ nnVeuillez ne pas essayer d'injecter des caractères illégaux dans les paramètres nnHTTP://WwW.WrSkY.CoM Version du système : V2.0 (ASP) version parfaite');＜Script＞
Réponse.Écrivez « Opération illégale ! Le système a effectué les enregistrements suivants↓＜br＞ »
Response.Write "Opération IP :"&Request.ServerVariables("REMOTE_ADDR")&"<br>"
Réponse.Écrivez « Heure de l'opération : »&Maintenant&»<br>
réponse.Écrivez "Page d'opération :"&Request.ServerVariables("URL")&"<br>"
Response.Write "Méthode de soumission : GET＜br＞"
Response.Write "Soumettre les paramètres :"&Fy_Get&"<br>"
Response.Write "Soumettre les données :"&Request.QueryString(Fy_Get)
Réponse.Fin
Fin si
Suivant
Suivant
Fin si
'---------------------------------
La fonction de ce code est d'enregistrer les informations et les actions de l'attaquant. que nous pouvons prendre les contre-mesures nécessaires. Il ressort du code que le programme enregistre l'adresse IP de l'attaquant, l'adresse de soumission, le contenu de la soumission, etc., mais il y a évidemment plusieurs failles ici :
1. Les attaques fréquentes ne sont pas traitées. En d’autres termes, quelle que soit la manière dont nous soumettons les données légales, elles seront enregistrées par le programme, ce qui conduira très probablement à des attaques DOS malveillantes. J'ai fait une expérience à ce sujet. Je soumets la déclaration suivante après l'URL d'un fichier protégé : et (sélectionnez top l asc(mid (username,l,l)) from admin)>0, utilisez l'assistant de clé pour enregistrer le processus de soumission, puis répétez automatiquement l'opération. soumission . Après un certain temps, la taille de la base de données a considérablement changé (comme le montrent les figures 1 et 2). Comme vous pouvez l'imaginer, si vous utilisez des outils tels que Shuoxue pour activer la soumission multithread, le DOS ne sera certainement pas un problème.
Figure 1
Figure 2
2. La longueur des données d'enregistrement n'est pas tronquée. C'est ce que j'ai découvert lors de mes tests de programmes anti-injection affectant le fonctionnement des forums. Comme le montre la figure 3, si le contenu de la publication contient des caractères filtrés, le contenu de la publication sera entièrement enregistré dans la base de données. Les forums généraux ou les systèmes d'articles ont des limites sur la longueur des articles publiés, mais le programme anti-injection universel SQL n'impose aucune restriction à ce sujet. Si un attaquant soumet un contenu trop long après l'URL du fichier protégé, cela entraînera probablement le blocage du programme. Parce que le préjudice est relativement élevé, je ne l'ai pas testé, mais le contenu que j'ai soumis jusqu'à 100 Ko a été enregistré comme d'habitude.
Figure 3
3. Problème de conversion du contenu des données et d'explosion de la base de données. À en juger par le code, le programme enregistre les données soumises illégalement directement dans la base de données sans conversion. En d’autres termes, peu importe ce que vous soumettez, tant qu’il contient du contenu filtré, le programme enregistrera tout le contenu que vous soumettez. Ce problème n'est pas grave à l'origine, mais par souci de "sécurité", certains webmasters aiment changer tous les fichiers mdb en suffixe asp. De plus, il n'y a qu'une seule table dans la base de données du programme anti-injection, nous pouvons donc obtenir le webshell en écrivant directement l'URL du fichier protégé dans la base de données. Pendant le processus de test, nous avons changé sqlin.mdb en sqlin.asp, puis ajouté. Après avoir saisi l'URL du fichier protégé, une porte dérobée micro ASP Binglangzi a été saisie. Après vous être connecté au client Ice Fox, wedshll a été obtenu avec succès.
Parce que cette méthode d'obtention de webshell nécessite de s'assurer que la base de données de l'autre partie fonctionne au format ASP et connaît le chemin des données, nous devons trouver un moyen d'obtenir le chemin de cette base de données. Dans des circonstances normales, nous pouvons deviner directement le chemin de la base de données, mais en fait, ce chemin peut être exposé. En examinant l'ensemble du programme anti-injection, nous n'avons trouvé aucune instruction de bibliothèque antidéflagrante, nous n'avons donc besoin que d'y accéder ou de l'utiliser directement. la méthode %5C. La base de données est exposée. Si le code du programme est placé directement après le fichier de connexion à la base de données, puisque le fichier de connexion aux données contient généralement des instructions antidéflagrantes, nous ne pouvons pas exposer l'adresse de la base de données.
Les problèmes mentionnés ci-dessus concernent tous le processus d'enregistrement des données. Les webmasters compétents peuvent corriger eux-mêmes les failles pertinentes, telles que le blocage automatique des adresses IP pour de grandes quantités de soumissions répétées de données. En fait, nous pouvons supprimer complètement la partie enregistrement des données du code, ce qui n'affectera pas le filtrage des variables, et même si les informations de l'attaquant sont enregistrées, cela ne sera pas très utile. Je suggère donc qu'il est préférable de supprimer ce code, afin que toutes les vulnérabilités n'existent plus.
Bon, c'est tout pour cet article. Enfin, je voudrais vous rappeler que lorsque vous utilisez des programmes de protection de sécurité, vous devez également faire attention aux problèmes de sécurité du programme lui-même.
Rappel spécial : le programme anti-injection 3.0 présente également des failles, et. les lacunes sont plus graves.