Bei den heutigen webbasierten Angriffen handelt es sich im Allgemeinen um Injektionsangriffe. Der Grund für die Injektion ist in der Regel eine unvollständige Filterung von Variablen, die es Eindringlingen ermöglicht, illegal Programme auszuführen oder beliebige Daten abzufragen und zu verändern. Da Injektionsangriffe immer intensiver werden, sind einige spezielle Filtercodes entstanden. Allerdings können Unvollkommenheiten in einigen Filtercodes zu neuen Angriffen führen. Im Folgenden wird der am weitesten verbreitete Filtercode – das universelle Anti-Injection-Programm von SQL – verwendet, um die Ursachen, Nutzungsmethoden und vorbeugenden Maßnahmen der Sicherheitsanfälligkeit zu erläutern.
Das universelle SQL-Anti-Injection-Programm wurde von Feng Zhiqiu aus Firefox geschrieben. Es handelt sich um einen ziemlich vollständigen Anti-Injection-Code. Es kann eine Get-Submission-Filterung für die definierten Filterzeichen implementieren und die von der IP des Angreifers übermittelten Dateninformationen aufzeichnen. Wenn Sie es verwenden, müssen Sie nur den Code <--#Include File="WrSky_Sql.Asp"--> zum Header der Datei hinzufügen, um die Injektion zu verhindern und eine Filterung der Variablen zu erreichen. Wenn Sie nach der Datenbankverbindungsdatei Programmcode hinzufügen (z. B. conn.asp), können Sie eine variable Filterung der gesamten Site erreichen und so den Anti-Injection-Effekt erzielen.
Okay, schauen wir uns zuerst den Code des Variablenfilterteils an:
'--------Definitionsteil------------------
Dimmen Sie Fy_Post, Fy_Get, Fy_In, Fy_Inf, Fy_Xh, Fy_db, Fy_dbstr
'Passen Sie die Zeichenfolgen an, die gefiltert werden müssen, getrennt durch „maple“
Fy_In = "' Maple; Maple und Maple Exec Maple Insert Maple Select Maple Löschen Maple Update Maple Count Maple * Maple% Maple Chr Maple Mid Maple Master Maple Truncate Maple Char Maple Declare"
'------------------------------------------------
%>
＜
Fy_Inf = split(Fy_In,"Maple")
'-------POST-Teil-----------------
Wenn Request.Form＜＞Dann
Für jeden Fy_Post in Request.Form
für Fy_Xh=0 bis Ubound(Fy_Inf)
If Instr(LCase(Request.Form(Fy_Post)),Fy_Inf(Fy_Xh))＜＞Then
'-------Teil holen------------------
If Request.QueryString＜＞Then
Für jedes Fy_Get in Request.QueryString
für Fy_Xh=0 bis Ubound(Fy_Inf)
Wenn Instr(LCase(Request.QueryString(Fy_Get)),Fy_Inf(Fy_Xh))＜＞Dann
definiert dieser Code die Filterung häufig injizierter Variablen wie „“, „und“ usw. Wenn Sie der Meinung sind, dass die Filterung nicht der Fall ist genug oder zu viel, Sie können es selbst tun. Zeichen hinzufügen oder entfernen. Solange die über Get oder Post an den Server übermittelten Daten gefilterte Zeichen enthalten, wird dies natürlich vom Programm verboten. Dies führt zu einem Problem, wenn Sie Programmcode nach der Datenbankverbindungsdatei des Forums hinzufügen, solange der Inhalt des Beitrags gefilterte Zeichen enthält, wird dieser gesperrt. Gemäß der standardmäßigen Inhaltsfilterung scheint es fast unmöglich zu sein, Inhalte zu posten, wenn sie auf Englisch sind. Darüber hinaus werden bei der Definition des Forenstils manchmal Sonderzeichen (z. B. das Prozentzeichen „%“) verwendet. Wenn diese Sonderzeichen gefiltert werden, funktioniert das gesamte Forum nicht ordnungsgemäß. Bezüglich des oben genannten Problems habe ich es mit dvbbs getestet und das Ergebnis war genau das, was ich erwartet hatte.
Die Lösung des oben genannten Problems besteht darin, das Einfügen von Verbindungsanweisungen nur in die Dateien zu verhindern, die gefiltert werden müssen. Dieser Arbeitsaufwand ist jedoch relativ groß und Webmaster wissen im Allgemeinen nicht, welche Dateien gefiltert werden müssen. Daher schlage ich vor, den Filtercode zu conn.asp hinzuzufügen, dann eine connl.asp zu erstellen, die den Filtercode nicht enthält, und die Dateien zu verbinden, die definitiv nicht gefiltert werden müssen und deren Filtercode Auswirkungen auf den Betrieb hat Diese Datei muss in conn1.asp kopiert werden. Beachten Sie jedoch, dass der grundlegende Inhalt der beiden Datenverbindungsdateien konsistent sein muss. Darüber hinaus ist es am besten, gefilterte Zeichen nicht in den Stileinstellungen zu verwenden. Wenn Sie sie wirklich verwenden müssen, können Sie die Filterung dieser Zeichen im Anti-Injection-Programm löschen.
Das oben Gesagte bezieht sich auf die Auswirkungen des Anti-Injektionsprogramms auf den Betrieb der Website und kann keinen Schaden anrichten. Tatsächlich entsteht der eigentliche Schaden durch den Datenaufzeichnungsteil. Schauen wir uns diesen Teil des Codes an:
''--------In die Datenbank schreiben-------Header---- ----
Fy_dbstr="DBQ="+server.mappath("SqlIn.mdb")+";DefaultDir=;DRIVER={Microsoft Access Driver (*.mdb)};"
Setze Fy_db=Server.CreateObject("ADODB.CONNECTION")
Fy_db.open Fy_dbstr
Fy_db.Execute("insert into SqlIn(Sqlin_IP,SqlIn_Web,SqlIn_FS,SqlIn_CS,SqlIn_SJ) Values('"&Request.ServerVariables("REMOTE_ADDR")&"','"&Request.ServerVariables("URL")&"',' GET','"&Fy_Get&"','"&replace(Request.QueryString(Fy_Get),"'","''")&"')")
Fy_db.close
Setze Fy_db = Nichts
'--------In Datenbank schreiben-------Tail--------
Response.Write "＜Script Language=JavaScript＞alert('Fengwang SQL Universal Anti-Injection System Prompt↓ nnBitte versuchen Sie nicht, illegale Zeichen in die Parameter einzufügen. nnHTTP://WwW.WrSkY.CoM Systemversion: V2.0 (ASP) perfekte Version');＜Script＞
Response.Write „Illegaler Vorgang! Das System hat die folgenden Datensätze erstellt↓＜br＞“
Response.Write "Operation IP:"&Request.ServerVariables("REMOTE_ADDR")&"<br>"
Antwort.Schreiben Sie „Operationszeit:“&Jetzt&“<br>
Response.Write "Operation page:"&Request.ServerVariables("URL")&"<br>"
Response.Write „Übermittlungsmethode: GET＜br＞“
Response.Write „Parameter senden:“&Fy_Get&“<br>“
Response.Write „Daten senden:“&Request.QueryString(Fy_Get)
Antwort.Ende
Ende wenn
Nächste
Nächste
Ende wenn
'---------------------------------
Die Funktion dieses Codes besteht darin, die Informationen und Aktionen des Angreifers aufzuzeichnen dass wir notwendige Gegenmaßnahmen ergreifen können. Aus dem Code ist ersichtlich, dass das Programm die IP, die Übermittlungsadresse, den Übermittlungsinhalt usw. des Angreifers aufzeichnet. Hier gibt es jedoch offensichtlich mehrere Lücken:
1. Häufige Angriffe werden nicht verarbeitet. Mit anderen Worten: Unabhängig davon, wie wir rechtliche Daten übermitteln, werden diese vom Programm aufgezeichnet, was höchstwahrscheinlich zu böswilligen DOS-Angriffen führt. Ich habe dazu ein Experiment durchgeführt. Ich übermittle die folgende Anweisung nach der URL einer geschützten Datei: and (select top l asc(mid (username,l,l)) from admin)>0, verwende den Schlüsselassistenten, um den Übermittlungsvorgang aufzuzeichnen, und wiederhole ihn dann automatisch Vorlage . Nach einer Weile änderte sich die Datenbankgröße erheblich (wie in den Abbildungen 1 und 2 dargestellt). Wie Sie sich vorstellen können, ist DOS definitiv kein Problem, wenn Sie Tools wie Shuoxue verwenden, um die Multi-Thread-Übermittlung zu ermöglichen.
Abbildung 1
Abbildung 2
2. Die Länge der Datensatzdaten wird nicht abgeschnitten. Das ist es, was ich beim Testen von Anti-Injection-Programmen entdeckt habe, die den Forenbetrieb beeinträchtigen. Wie in Abbildung 3 dargestellt, wird der Beitragsinhalt vollständig in der Datenbank aufgezeichnet, wenn der Beitragsinhalt gefilterte Zeichen enthält. In allgemeinen Foren oder Artikelsystemen ist die Länge der veröffentlichten Artikel begrenzt, das SQL Universal Anti-Injection-Programm legt diesbezüglich jedoch keine Beschränkungen fest. Wenn ein Angreifer nach der URL der geschützten Datei einen zu langen Inhalt einreicht, führt dies wahrscheinlich zum Absturz des Programms. Da der Schaden relativ hoch ist, habe ich es nicht getestet, aber die von mir eingereichten Inhalte bis zu 100 KB wurden wie gewohnt aufgezeichnet.
Abbildung 3
3. Problem bei der Konvertierung von Dateninhalten und der Datenbankexplosion. Dem Code nach zu urteilen, zeichnet das Programm die illegal übermittelten Daten ohne Konvertierung direkt in der Datenbank auf. Mit anderen Worten: Egal was Sie einreichen, solange es gefilterte Inhalte enthält, zeichnet das Programm alle von Ihnen eingereichten Inhalte auf. Dieses Problem ist ursprünglich nicht schwerwiegend, aber aus Sicherheitsgründen ändern einige Webmaster gerne alle MDB-Dateien in das ASP-Suffix. Darüber hinaus gibt es in der Datenbank des Anti-Injection-Programms nur eine Tabelle, sodass wir die Webshell erhalten können, indem wir die URL der geschützten Datei direkt in die Datenbank schreiben. Während des Testvorgangs haben wir sqlin.mdb in sqlin.asp geändert. und dann hinzugefügt Nachdem die URL der geschützten Datei eingegeben wurde, wurde eine Binglangzi-Micro-ASP-Hintertür eingegeben. Nach der Verbindung mit dem Ice Fox-Client wurde wedshll erfolgreich abgerufen.
Da bei dieser Methode zum Abrufen der Webshell sichergestellt werden muss, dass die Datenbank der anderen Partei im ASP-Format ausgeführt wird und der Datenpfad bekannt ist, müssen wir einen Weg finden, den Pfad dieser Datenbank abzurufen. Unter normalen Umständen können wir den Datenbankpfad direkt erraten, aber tatsächlich kann dieser Pfad offengelegt werden. Wenn wir uns das gesamte Anti-Injection-Programm ansehen, haben wir keine explosionssicheren Bibliotheksanweisungen gefunden, sodass wir nur direkt darauf zugreifen oder sie verwenden müssen Die %5C-Methode wird offengelegt. Wenn der Programmcode direkt nach der Datenbankverbindungsdatei platziert wird, können wir die Adresse der Datenbank nicht offenlegen, da die Datenverbindungsdatei im Allgemeinen explosionssichere Anweisungen enthält.
Bei den oben genannten Problemen handelt es sich um Probleme im Datenaufzeichnungsprozess. Kompetente Webmaster können die entsprechenden Lücken selbst beheben, z. B. die automatische Sperrung von IPs für große Mengen wiederholter Datenübermittlungen. Tatsächlich können wir den Datenaufzeichnungsteil des Codes vollständig entfernen, was sich nicht auf die Filterung von Variablen auswirkt, und selbst wenn die Informationen des Angreifers aufgezeichnet werden, ist dies nicht sehr nützlich. Daher schlage ich vor, dass es am besten ist, diesen Code zu entfernen, damit alle Schwachstellen nicht mehr bestehen.
Okay, das war's mit diesem Artikel. Abschließend möchte ich Sie daran erinnern, dass Sie bei der Verwendung von Sicherheitsschutzprogrammen auch auf die Sicherheitsprobleme des Programms selbst achten sollten:
Auch das Anti-Injection-Programm 3.0 weist Lücken auf Die Schlupflöcher sind schwerwiegender.