1. Überblick
In den letzten zwei Jahren sollten Sicherheitsexperten den Angriffen auf der Netzwerkanwendungsebene mehr Aufmerksamkeit schenken. Denn ganz gleich, wie stark Ihre Firewall-Regeln sind oder wie sorgfältig Sie sie patchen: Wenn Ihre Webanwendungsentwickler keinen sicheren Code befolgen, dringen Angreifer über Port 80 in Ihr System ein. Die beiden häufigsten Angriffstechniken sind SQL-Injection-Angriffe [ref1] und CSS-Angriffe [ref2]. Unter SQL-Injection versteht man die Technik des Einfügens von SQL-Metazeichen (Sonderzeichen, die bestimmte Daten darstellen) und Anweisungen über den Internet-Eingabebereich, um die Ausführung von Back-End-SQL-Abfragen zu manipulieren. Diese Angriffe zielen hauptsächlich auf WEB-Server anderer Organisationen ab. CSS-Angriffe stellen sicher, dass bösartiger Javascript-Code auf dem Computer des Opfers ausgeführt wird, indem sie Skript-Tags in URLs einfügen und dann vertrauenswürdige Benutzer dazu verleiten, darauf zu klicken. Diese Angriffe nutzen die Vertrauensbeziehung zwischen dem Benutzer und dem Server aus. Tatsächlich erkennt der Server die Ein- und Ausgabe nicht und lehnt daher den JavaScript-Code nicht ab.
In diesem Artikel werden Erkennungstechniken für Schwachstellen bei SQL-Injection und CSS-Angriffen erläutert. Im Internet wurde viel über diese beiden Arten von WEB-basierten Angriffen diskutiert, beispielsweise darüber, wie die Angriffe implementiert werden, welche Auswirkungen sie haben und wie man Programme zur Verhinderung dieser Angriffe besser vorbereiten und entwerfen kann. Es gibt jedoch nicht genügend Diskussion darüber, wie diese Angriffe erkannt werden können. Wir verwenden das beliebte Open-Source-IDS Snort [Ref. 3], um reguläre Ausdrücke basierend auf Regeln zur Erkennung dieser Angriffe zu formulieren. Die Standardregeleinstellungen von Snort beinhalten übrigens Methoden zur Erkennung von CSS, diese können jedoch leicht vermieden werden. Beispielsweise verwenden die meisten von ihnen eine Hex-Kodierung, wie z. B. %3C%73%63%72%69%70% 74%3E anstelle von <script>, um eine Erkennung zu vermeiden.
Abhängig von den Fähigkeiten der Organisation auf der Ebene der Paranoia haben wir mehrere Regeln geschrieben, um denselben Angriff zu erkennen. Wenn Sie alle möglichen SQL-Injection-Angriffe erkennen möchten, müssen Sie lediglich auf vorhandene SQL-Metazeichen wie einfache Anführungszeichen, Semikolons und doppelte Bindestriche achten. Eine weitere extreme Möglichkeit, CSS-Angriffe zu erkennen, besteht darin, einfach auf spitze Klammern in HTML-Tags zu achten. Dadurch werden jedoch viele Fehler erkannt. Um dies zu vermeiden, müssen die Regeln geändert werden, um ihre Erkennung präziser zu gestalten, ohne dabei Fehler zu vermeiden.
Verwenden Sie das Schlüsselwort pcre (Perl-kompatible reguläre Ausdrücke) [ref4] in Snort-Regeln. Jede Regel kann mit oder ohne andere Regelaktionen ausgeführt werden. Diese Regeln können auch von öffentlicher Software wie grep (einem Dokumentsuchtool) verwendet werden, um Netzwerkserverprotokolle zu überprüfen. Sie müssen jedoch darauf achten, dass der WEB-Server die Eingaben des Benutzers nur dann im Tagebuch aufzeichnet, wenn die Anfrage als GET gesendet wird. Wenn die Anfrage als POST gesendet wird, wird sie nicht im Tagebuch aufgezeichnet.
2. Reguläre Ausdrücke für die SQL-Injection
Wenn Sie einen regulären Ausdruck für einen SQL-Injection-Angriff auswählen, ist es wichtig zu bedenken, dass ein Angreifer eine SQL-Injection durchführen kann, indem er ein Formular sendet oder das Cookie-Feld verwendet. Ihre Eingabeerkennungslogik sollte verschiedene Arten von Eingaben berücksichtigen, die vom Benutzer organisiert werden (z. B. Formular- oder Cookie-Informationen). Und wenn Sie feststellen, dass von einer Regel viele Warnungen ausgehen, achten Sie auf einfache Anführungszeichen oder Semikolons, da diese Zeichen möglicherweise gültige Eingaben in von Ihrer Webanwendung erstellten Cookies sind. Daher müssen Sie jede Regel anhand Ihrer speziellen Webanwendung bewerten.
Wie bereits erwähnt, sollte ein detaillierter regulärer Ausdruck zur Erkennung von SQL-Injection-Angriffen auf die speziellen Metazeichen von SQL achten, z. B. einfache Anführungszeichen (') und doppelte Erweiterungszeichen (--), um diese und ihre Zeichen herauszufinden Hex-Äquivalente Zahl, gelten die folgenden regulären Ausdrücke:
2.1 Reguläre Ausdrücke zur Erkennung von SQL-Metazeichen
/(%27)|(')|(--)|(%23)|(#)/ix
Erklärung:
Wir prüfen zunächst den Hexadezimalwert des einfachen Anführungszeichens, das einfache Anführungszeichen selbst oder das doppelte Erweiterungszeichen. Hierbei handelt es sich um MS SQL Server- oder Oracle-Zeichen, die darauf hinweisen, dass es sich bei den folgenden um Kommentare handelt und alle folgenden ignoriert werden. Wenn Sie MySQL verwenden, müssen Sie außerdem auf das Vorkommen von „#“ und seinem hexadezimalen Äquivalent achten. Beachten Sie, dass wir den Hexadezimalwert nicht auf das Äquivalent des doppelten Bindestrichs überprüfen müssen, da es sich hierbei nicht um ein HTML-Metazeichen handelt und nicht vom Browser codiert wird. Wenn es einem Angreifer außerdem gelingt, den Doppelstrich manuell auf seinen Hexadezimalwert %2D zu ändern (unter Verwendung eines Proxys wie Achilles [Ref. 5]), schlägt die SQL-Injection fehl.
Die neue Snort-Regel, die dem obigen regulären Ausdruck hinzugefügt wurde, lautet wie folgt:
alarm tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"SQL Injection - Paranoid"; flow:to_server,established;uricontent:".pl";pcre:
"/ (%27)|(')|(--)|(%23
)|(#)/i";
In diesem Artikel lautet der Wert des Schlüsselworts uricontent „.pl“, da in unserer Testumgebung das CGI-Programm in Perl geschrieben ist. Der Wert des Schlüsselworts uricontent hängt von Ihrer jeweiligen Anwendung ab. Dieser Wert kann „.php“, „.asp“ oder „.jsp“ usw. sein. Unter diesem Gesichtspunkt zeigen wir nicht die entsprechenden Snort-Regeln, sondern geben die regulären Ausdrücke an, die diese Regeln erstellen. Mit diesen regulären Ausdrücken können Sie problemlos viele Snort-Regeln erstellen. In den vorherigen regulären Ausdrücken haben wir doppelte Bindestriche erkannt, da es möglicherweise SQL-Injektionspunkte gibt, auch wenn keine einfachen Anführungszeichen vorhanden sind [Ref. 6]. Beispielsweise enthält ein SQL-Abfrageeintrag nur numerische Werte wie folgt:
Wählen Sie Wert1, Wert2, Anzahl_Wert3 aus der Datenbank aus
wobei num_value3=some_user_supplied_number
In diesem Fall kann der Angreifer zusätzliche SQL-Abfragen ausführen:
3; Werte in some_other_table einfügen.
Schließlich werden die PCRE-Modifikatoren „i“ und „x“ verwendet, um die Groß- und Kleinschreibung abzugleichen ignorieren bzw. Leerzeichen. Die oben genannten Regeln können auch zusätzlich erweitert werden, um das Vorhandensein von Semikolons zu überprüfen. Allerdings kann das Semikolon durchaus Teil einer normalen HTTP-Antwort sein. Um diesen Fehler zu reduzieren und das normale Auftreten von einfachen Anführungszeichen und doppelten Erweiterungszeichen zu verhindern, sollten die oben genannten Regeln so geändert werden, dass zuerst das Vorhandensein von =-Zeichen erkannt wird. Benutzereingaben reagieren auf eine GET- oder POST-Anfrage. Im Allgemeinen werden Eingaben wie folgt übermittelt:
username=some_user_supplied_value&password=some_user_supplied_value.
Daher führen SQL-Injection-Versuche dazu, dass die Benutzereingaben nach dem a =-Zeichen oder dem entsprechenden Hexadezimalwert erscheinen.
2.2 Korrigieren Sie den regulären Ausdruck zur Erkennung von SQL-Metazeichen
/((%3D)|(=))[^n]*((%27)|(')|(--)|( %3B)|(:))/i
Erläuterung:
Diese Regel achtet zunächst auf das =-Zeichen oder seinen Hexadezimalwert (%3D), berücksichtigt dann null oder mehr Zeichen außer Zeilenumbrüchen und erkennt schließlich einfache Anführungszeichen und doppelte Bindestriche oder Semikolon.
Eine typische SQL-Injection versucht, die ursprüngliche Abfrage mithilfe einfacher Anführungszeichen zu manipulieren, um einen nützlichen Wert zu erhalten. Dieser Angriff wird im Allgemeinen mit der Zeichenfolge 1'or'1'='1 beschrieben. Die Erkennung dieser Zeichenfolge kann jedoch leicht umgangen werden, z. B. mit 1'or2>1 -- dem Anfangszeichen folgen Sie einem einfachen Anführungszeichen und fügen Sie „oder“ hinzu. Die folgende boolesche Logik kann je nach Stil variieren, von gewöhnlich bis sehr komplex. Mit dem folgenden regulären Ausdruck können diese Angriffe recht genau erkannt werden. Kapitel 2.3 erklärt.
2.3 Typischer regulärer Ausdruck eines SQL-Injection-Angriffs
/w*((%27)|('))((%6F)|o|(%4F))((%72)|r| (% 52))/ix
Erklärung:
w* – Null oder mehr Zeichen oder Unterstriche.
(%27)|' – ein einfaches Anführungszeichen oder sein hexadezimales Äquivalent.
(%6 F)|o|(%4 F))((%72)|r|-(%52) – Der Fall von „or“ und seinem Hex-Äquivalent.
Union'SQL-Abfrage in SQL-Injection Angriffe kommen auch in verschiedenen Datenbanken sehr häufig vor. Wenn der vorherige reguläre Ausdruck nur einfache Anführungszeichen oder andere SQL-Metazeichen erkennt, sollten Sie die Abfrage weiter modifizieren, um einfache Anführungszeichen und Schlüssel zu erkennen kann auch mit anderen SQL-Schlüsselwörtern wie „select“, „insert“, „update“, „delete“ usw. weiter erweitert werden.
2.4 Erkennen von SQL-Injection, UNION-Abfrageschlüsselwort regulärer Ausdruck
/ ((%27)|(') )union/ix
(%27)|(') – einfaches Anführungszeichen und sein hexadezimales Äquivalent
Union – Das Schlüsselwort Union
kann auch zum Anpassen von Ausdrücken für andere SQL-Abfragen verwendet werden, z. B. >select, insert, update, delete, drop usw.
Wenn der Angreifer zu diesem Zeitpunkt festgestellt hat, dass die Webanwendung über eine SQL-Injection verfügt Verletzlichkeit, er wird versuchen, sie auszunutzen. Wenn er feststellt, dass der Backend-Server ein MS SQL-Server ist, wird er normalerweise versuchen, gefährliche Speicher- und erweiterte gespeicherte Prozeduren auszuführen. Diese Verfahren beginnen im Allgemeinen mit den Buchstaben „sp“ oder „xp“. Normalerweise versucht er möglicherweise, die erweiterte gespeicherte Prozedur „xp_cmdshell“ auszuführen (die Windows-Befehle über SQL Server ausführt). Die SA-Berechtigung des SQL-Servers hat die Berechtigung, diese Befehle auszuführen. Ebenso können sie die Registrierung über xp_regread, xp_regwrite und andere gespeicherte Prozeduren ändern.
2.5 Erläuterung des regulären Ausdrucks
/exec(s|+)+(s|x)pw+/ix
zur Erkennung von MS SQL Server SQL-Injection-Angriffen:
exec – Schlüsselwort, das die Ausführung einer gespeicherten oder erweiterten gespeicherten Prozedur anfordert
(s|+)+ – ein oder mehrere Leerzeichen oder deren http-Äquivalente
(s|x) p-, „sp“- oder „xp“-Buchstaben werden zur Kennzeichnung von Speicher- oder erweiterten Speichervorgängen verwendet
w+ – ein oder mehrere Zeichen oder Unterstriche, die mit dem Namen einer Prozedur übereinstimmen
. 3. Regulärer Ausdruck für Cross-Site-Scripting (CSS)
Wenn ein Angreifer einen CSS-Angriff startet oder eine Website-Schwachstelle erkennt, kann er zunächst ein einfaches HTML-Tag erstellen, z < b> (fett), <i> (kursiv) oder <u> (unterstrichen), oder er könnte es mit einem einfachen Skript-Tag wie <script>alert("OK")</script> versuchen, da dies in den meisten Veröffentlichungen der Fall ist Wird als Beispiel verwendet, um zu erkennen, ob eine Website über das Internet verbreitete CSS-Schwachstellen aufweist. Diese Versuche können leicht erkannt werden. Ein geschickter Angreifer könnte jedoch die gesamte Zeichenfolge durch ihren Hexadezimalwert ersetzen. Auf diese Weise wird das <script>-Tag als %3C%73%63%72%69%70%74%3E angezeigt. Andererseits kann ein Angreifer einen Web-Proxy-Server wie Achilles verwenden, um einige Sonderzeichen wie < in %3C oder > in %3E automatisch umzuwandeln. Bei einem solchen Angriff werden spitze Klammern normalerweise durch Hexadezimalwerte ersetzt in der URL.
Der folgende reguläre Ausdruck erkennt jeden Text, der <, > in HTML enthält. Es fängt Versuche ab, <b>, <u> oder <script> zu verwenden. Dieser reguläre Ausdruck sollte die Groß-/Kleinschreibung ignorieren. Wir müssen sowohl die spitze Klammer als auch ihr hexadezimales Äquivalent (% 3C|<) erkennen. Um die gesamte in Hex konvertierte Zeichenfolge zu erkennen, müssen wir die vom Benutzer eingegebenen Zahlen und %-Zeichen erkennen, also [a-z0-9%] verwenden. Dies kann dazu führen, dass einige Fehler auftreten, die meisten erkennen jedoch keine echten Angriffe.
3.1 Regulärer Ausdruck für allgemeine CSS-Angriffe
/((%3C)|<)((%2F)|/)*[a-z0-9%]+((%3E)|>)/ix
erklären :
((%3C)|<) – prüft < und sein Hex-Äquivalent
((%2F)|/)* – schließendes Tag/ oder sein hexadezimales Äquivalent
[a-z0-9%]+ – Überprüfen Sie den Buchstaben im Tag oder sein hexadezimales Äquivalent
((%3E)|>) – Auf > oder die hexadezimale entsprechende
Snort-Regel prüfen:
Alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"NII Cross-Site-Scripting-Versuch"; flow:to_server,established; pcre:"/((%3C)|<)((%2F)| /)*[a-z0-9%]+((%3E)|>)/i"; classtype:Web-application-attack; sid:9000; rev:5;)
Cross-Site-Scripting kann auch sein gebraucht< img src=>Technologie. Die aktuellen Standard-Snort-Regeln können leicht umgangen werden.
Abschnitt 3.2 stellt Methoden zur Verhinderung dieser Technik vor.
3.2 „<img src“ CSS-Angriff auf regulären Ausdruck
/((%3C)|<)((%69)|i|(%49))((%6D)|m|(%4D) ) ((%67)|g|(%47))[^n]+((%3E)|>)/I
Erklärung:
(%3 C)|<) -<oder sein hexadezimales Äquivalent
(%69)|i|(%49))((%6D)|m|(%4D))((%67)|g|(%47) -'img' Buchstabe oder it Variationskombinationen von Hex-Äquivalenten in Groß- und Kleinbuchstaben
[^n]+ – jedes Zeichen nach <img, außer Newline
(%3E)|>) -> oder sein Hex-Äquivalent
3.3 CSS Attack Extreme Regular Expression
/((%3C)|<)[^n]+((%3E)|>) /I
Erläuterung:
Dies Die Regel sucht einfach nach <+beliebigem Zeichen außer einem Zeilenumbruchzeichen+>. Abhängig von der Architektur Ihres Webservers und Ihrer Webanwendung kann diese Regel zu Fehlern führen. Es ist jedoch garantiert, dass alle CCS- oder CSS-ähnlichen Angriffe abgefangen werden.
Zusammenfassung:
In diesem Artikel haben wir verschiedene Arten von Regeln für reguläre Ausdrücke vorgeschlagen, um SQL-Injection- und Cross-Site-Scripting-Angriffe zu erkennen. Einige Regeln sind einfach und extrem, und ein möglicher Angriff löst Alarm aus. Diese extremen Regeln können jedoch zu einigen proaktiven Fehlern führen. Aus diesem Grund haben wir diese einfachen Regeln geändert, um zusätzliche Stile zu verwenden, damit sie genauer überprüft werden können. Bei der Erkennung von Angriffen auf diese Netzwerkanwendungen empfehlen wir, diese als Ausgangspunkt für das Debuggen Ihrer IDS- oder Protokollanalysemethoden zu verwenden. Nach einigen weiteren Überarbeitungen sollten Sie bereit sein, diese Angriffe zu erkennen, nachdem Sie die nicht böswilligen Reaktionen auf den normalen Netzwerktransaktionsteil ausgewertet haben.
Referenz
1. SQL-Injection
http://www.spidynamics.com/papers/SQLInjectionWhitePaper.pdf
2. Häufig gestellte Fragen zu Cross-Site-Scripting http://www.cgisecurity.com/articles/xss -
faq.shtml
3. Das Snort IDS http://www.snort.org
4. Perl-kompatible reguläre Ausdrücke (pcre) http://www.pcre.org
5. Webanwendungs-Proxy, Achilles http://achilles.mavensecurity.com
3. Erweiterte SQL-Injection
http://www.nextgenss.com/papers/advanced_sql_injection.pdf
7. Sicheres Programmieren HOWTO, David Wheeler www.dwheeler.com
8. Bedrohungen und Gegenmaßnahmen, MSDN, Microsoft