DataSunrise’s Ansatz zur Konfiguration von Strafen für die Erkennung von SQL-Injections

SQL-Injection ist eine weit verbreitete Bedrohung für die Datensicherheit, bei der Angreifer SQL-Abfragen manipulieren, um unautorisierten Zugriff auf Daten zu erlangen. DataSunrise, eine Lösung für die Datensicherheit, bietet einen robusten Mechanismus zur Erkennung und Verhinderung von SQL-Injections durch ein Punktesystem. Dieser Artikel wird erläutern, wie DataSunrise Strafen für verschiedene Arten von SQL-Injection-Mustern konfiguriert und Beispiele für jedes Muster bereitstellen.

Punktesystem für Strafen

DataSunrise’s Punktesystem weist verschiedenen Komponenten einer SQL-Abfrage, die auf eine potenzielle Injection hinweisen könnten, einen numerischen Wert zu. Wenn die Summe dieser Punkte einen vordefinierten Schwellenwert überschreitet, ergreift DataSunrise Maßnahmen, entweder durch Protokollierung einer Warnung (Audit-Regel) oder durch Blockieren der Abfrage (Sicherheitsregel).

Beispiele für SQL-Injection-Muster und Strafen

Strafe für Kommentare

Eine der grundlegenden Aufgaben eines Angreifers bei einer Injection besteht darin, die Anfrage radikal zu verändern. Dazu muss er den Teil der Anfrage, den er nicht kontrolliert oder der ihn an der Durchführung der Injection hindern würde, deaktivieren. Zu diesem Zweck wird Code zur Injection hinzugefügt, der den Teil der Anfrage kommentiert, der sich nach dem injizierten Block befindet. Hier sind einige Beispiele.

1 Beispiel. Ein gängiges Beispiel ist die Anmeldung als Admin:

Injection in den Benutzernamen-Parameter: admin’–

SELECT * FROM members WHERE username = 'admin'--' AND password = 'password'

Wenn es erfolgreich ist, werden Sie als Admin-Benutzer angemeldet, da der Rest der SQL-Abfrage nach ‘–‘ ignoriert wird.

2 Beispiel. Klassische Inline-Kommentar-SQL-Injection-Angriffsmuster

ID-Wert: 10; DROP TABLE members /*

Einfach den restlichen Teil der Abfrage entfernen. Genauso wie 10; DROP TABLE members –

Daher ist das Vorhandensein von Kommentaren in der Anfrage eines der Anzeichen einer potenziellen Injection.

Schlüsselwort-Strafe in einem Kommentar

Im Kontext von Kommentaren in einer Anfrage kann gesagt werden, dass gewöhnliche Kommentare recht häufig in legitimen Anfragen zu finden sind. Beispielsweise fügen viele von Entwicklern verwendete IDEs automatisch die aktuelle Uhrzeit zu Beginn der Anfrage in Form eines Kommentars hinzu oder die Version der IDE, in der die Anfrage generiert wurde, oder andere Metainformationen. Daher ist ein weiteres Anzeichen dafür, dass ein Kommentar verdächtig ist, das Vorhandensein von SQL-Schlüsselwörtern wie AND/OR/SELECT usw.

Beispielsweise im oben diskutierten SQL-Ausdruck

SELECT * FROM members WHERE username = ‘admin’--‘ AND password = ‘password’

Das AND-Schlüsselwort wurde auskommentiert.

Doppelte Abfrage-Strafe (Stacking Queries)

Das Stapeln bedeutet das Ausführen mehrerer Abfragen in einer Transaktion. Diese Technik kann nützlich sein, funktioniert aber nur für einige Kombinationen aus Datenbankserver und Zugriffsmethoden:

SELECT * FROM members; DROP members--`

Bei Erfolg endet eine Abfrage und eine andere beginnt.

Nicht alle Datenbanken unterstützen das Ausführen von zwei oder mehr Ausdrücken in einer Abfrage, aber wo dies unterstützt wird, müssen solche Fälle kontrolliert werden.

DataSunrise generiert keine Fehler, wenn Konfigurationsausdrücke (SET und ähnliche) oder Abfragen zur Variablendeklaration in einem Ausdruck verwendet werden. Solche Anfragen sind nicht ungewöhnlich.

OR-Strafe + Konstante Ausdrucksstrafe

Oftmals muss ein Angreifer, um eine bestimmte Injection zu verwenden, eine Bedingung erstellen, die wahr (TRUE) ist. Die einfachste Möglichkeit hierfür ist eine OR-Operation mit einem Wert, der immer TRUE ist. Zum Beispiel, wie im Beispiel: https://insecure-website.com/products?category=Gifts‘+OR+1=1–

Dies resultiert in der SQL-Abfrage:

SELECT * FROM products WHERE category = ‘Gifts’ OR 1=1--‘ AND released = 1

In diesem Fall wird die Abfrage alle Kategorien anzeigen und nicht nur die, die angezeigt werden sollten.

Natürlich ist die OR-Operation in der Anwendungsentwicklung weit verbreitet und beliebt, aber zusammen mit anderen Anzeichen kann sie helfen, eine Injection zu erkennen. Das Gleiche gilt für Ausdrücke, die immer TRUE oder FALSE zurückgeben.

Union-Strafe

Unsere Forschung hat gezeigt, dass Cyber-Angreifer automatisierte Werkzeuge verwenden, die ihnen helfen festzustellen, ob eine bestimmte Schwachstelle potenziell ausnutzbar ist. Wenn es möglich ist, einen zusätzlichen Ausdruck zu einer anfälligen Abfrage hinzuzufügen, wird normalerweise die Möglichkeit überprüft, auf andere Tabellen zuzugreifen

select id, id from products where name = ‘Gifts’ UNION SELECT NULL, NULL from SYS.USERS --‘

Bei einem SQL-Injection-UNION-Angriff gibt es zwei effektive Methoden, um zu bestimmen, wie viele Spalten von der ursprünglichen Abfrage zurückgegeben werden.

Eine Methode beinhaltet das Einreichen einer Reihe von UNION SELECT-Nutzlasten, die eine unterschiedliche Anzahl von NULL-Werten angeben:

‘ UNION SELECT NULL--
‘ UNION SELECT NULL,NULL--
‘ UNION SELECT NULL,NULL,NULL—, usw.

Wenn die Anzahl der NULL-Werte nicht der Anzahl der Spalten entspricht, gibt die Datenbank einen Fehler zurück, wie zum Beispiel:

Alle Abfragen, die mittels UNION, INTERSECT oder EXCEPT kombiniert werden, müssen die gleiche Anzahl an Ausdrücken in ihren Ziel-Listen haben.

Ein Angreifer verwendet NULL als die von der injizierten SELECT-Abfrage zurückgegebenen Werte, da die Datentypen in jeder Spalte zwischen der ursprünglichen und der injizierten Abfrage kompatibel sein müssen. NULL ist in jeden gängigen Datentyp konvertierbar, sodass es die Chancen maximiert, dass die Nutzlast erfolgreich ist, wenn die Spaltenanzahl korrekt ist.

Um die Chancen für die Erkennung einer Injection zu verringern, erkennt DataSunrise ähnliche UNIONs, die bei der Überprüfung anfälliger Anwendungen verwendet werden, und vergibt zusätzliche Strafpunkte.

Verdächtige Konvertierung: Fehlerangriff

Die Fehlerbasierte SQL-Injection-Technik zwingt die Datenbank, einen Fehler zu erzeugen, der dem Angreifer oder Tester Informationen liefert, um seine Injection zu verfeinern.

Um eine Anwendung zu zwingen, eine Anfrage zu generieren, die mit einem Fehler ausgeführt wird, werden viele verschiedene Techniken verwendet. Eine davon sind Operationen, die explizit oder implizit versuchen, einen Wert in einen Typ zu konvertieren, in den er nicht konvertiert werden kann:

‘ und 1=convert(int,(select top 1 table_name from information_schema.tables))--

In diesem Fall wird ein Fehler generiert, dessen Text einen Textwert aus der Systemtabelle information_schema.tables enthalten wird.

Diese Technik ist jedoch nicht auf solche Angriffe beschränkt. Diese Technik kann auch bei Blind Error-basierten Angriffen verwendet werden, wenn der Angreifer nur herausfinden kann, ob ein Fehler aufgetreten ist oder nicht.

Wahrscheinlich die schwierigste Überprüfungsart aus Implementierungssicht. Der Grund dafür ist, dass es eine enorme Anzahl von Möglichkeiten gibt, einen Fehler zu verursachen.

Verkettung einzelner Zeichen für viele Arten von Angriffen

Ein weiteres Muster, das häufig bei Angriffen verwendet wird, ist das Escaping der zurückgegebenen Daten. Dies ist oft notwendig, wenn sich der Inhalt der angegriffenen Seite häufig ändert und das automatische Injection-Überprüfungsskript spezielle Marker verwenden muss, um die Nutzlast (die wertvollen Daten, die wir extrahieren möchten) zu finden.

Beispielsweise,

AND 3516=CAST((CHR(113)||CHR(106)||CHR(122)||CHR(106)||CHR(113))||(SELECT (CASE WHEN (3516=3516) THEN 1 ELSE 0 END))::text||(CHR(113)||CHR(112)||CHR(106)||CHR(107)||CHR(113)) AS NUMERIC)

Solche Konstruktionen sind für DataSunrise verdächtig.

Verdächtige Funktionsaufrufe

In jeder ordentlichen Produktionsanwendung können Sie im Allgemeinen keine Fehlerantworten auf der Seite sehen. Dies schließt das direkte Extrahieren von Daten durch UNION-Angriffe oder fehlerbasierte Angriffe aus. In diesen Fällen müssen Sie blinde SQL-Injections verwenden, um die Daten zu extrahieren. Es gibt zwei grundlegende Arten von blinden SQL-Injections.

Normale blinde Injections. Sie können die Antwort nicht direkt auf der Seite sehen, aber Sie können trotzdem das Ergebnis einer Abfrage basierend auf einer Antwort oder einem HTTP-Statuscode bestimmen.

Völlig blinde Injections. Sie können die Auswirkungen Ihrer Injection in keiner Art von Ausgabe sehen. Dies ist seltener, beispielsweise wenn Sie in eine Protokollierungsfunktion oder Ähnliches injizieren.

Bei normalen blinden Injections können Sie IF-Anweisungen verwenden oder WHERE-Klauseln in Abfragen missbrauchen, was im Allgemeinen der einfachere Weg ist. Für völlig blinde Injections müssen Sie eine Art Wartefunktion verwenden und dann die Antwortzeiten analysieren.

Beispiele für verfügbare Warte-/Timeout-Funktionen umfassen:

WAITFOR DELAY '0:0:10' in SQL Server
BENCHMARK() und sleep(10) in MySQL
pg_sleep(10) in PostgreSQL

DataSunrise vergibt zusätzliche Strafpunkte, wenn die Anfrage ähnliche Abfragen enthält, die häufig bei Angriffen verwendet werden.

Verdächtige Bedingung zur Überprüfung auf Boolean Blind Attack

Blind SQL-Injection ist eine Art von SQL-Injection, bei der der Angreifer keine offensichtliche Antwort von der angegriffenen Datenbank erhält und stattdessen die Datenbankstruktur Schritt für Schritt durch Beobachtung des Verhaltens des Datenbankservers und der Anwendung rekonstruiert. Blind SQL-Injection wird auch als inferential SQL-Injection bezeichnet. Es gibt zwei Arten von Blind SQL-Injections: Boolean-basiert und zeitbasiert.

Bei dieser Art von Angriff können Sie das vollständige Ergebnis nicht erhalten. Der Angreifer kommt blind, um den Inhalt der Tabellen, die ihn interessieren, Buchstabe für Buchstabe zu erhalten. Dies kann sehr zeitaufwändig sein und erfordert eine gute Automatisierung.

Hier ist ein Beispiel für eine solche Anfrage.

ORD(MID((SELECT grantee FROM(SELECT DISTINCT(grantee) FROM INFORMATION_SCHEMA.USER_PRIVILEGES LIMIT 0, 1) AS caou), 22, 1)) > 39--MnqX'

DataSunrise vergibt auch Strafpunkte, wenn Anzeichen für solche Abfragen festgestellt werden.

Verdächtige SELECT COUNT-Strafe

Dies sind die Punkte, die DataSunrise für verdächtige Blöcke in SQL in der Form SELECT count(*) FROM t1,t2 vergibt.

Der Punkt ist, dass, wenn eine zeitbasierte SQL-Injection verfügbar ist, der Angreifer irgendwie zwischen zwei Verzweigungen des Codeablaufs unterscheiden muss. Dazu wird eine Abfrage in einer der Verzweigungen ausgeführt, die viel Zeit in Anspruch nimmt. Zum Beispiel das Zählen der Zeilen in einem Join von zwei oder mehr Tabellen. Beim Join werden die Zeilen multipliziert und es entstehen viele Zeilen. Und COUNT läuft lange genug, um dies im Skript zu bemerken. Sie können mehr Details hier nachlesen. In dem Artikel finden Sie das SLEEP(5), aber das ist nur Kindergarten.

Viele Leute haben dies bereits bewiesen, und aus diesem Grund verwenden sie ausgeklügeltere Methoden in Form von COUNT+JOIN, die wir oben beschrieben haben. In der normalen Praxis wird eine solche Abfrage, die Teil einer komplexeren Abfrage ist, nicht verwendet und daher kann dies als eines der Anzeichen einer Injection dienen.

Schlussfolgerung

DataSunrises Ansatz zur Konfiguration von Strafen für die Erkennung von SQL-Injections stellt eine umfassende und proaktive Strategie dar, um Datenbanken gegen diese weit verbreitete Bedrohung zu schützen. Durch die Verwendung eines Punktesystems, das verschiedene Aspekte von SQL-Abfragen bewertet, identifiziert und mindert DataSunrise effektiv potenzielle Injections-Versuche. Durch Beispiele, die verschiedene SQL-Injection-Muster und zugehörige Strafen veranschaulichen, zeigt dieser Artikel die Vielseitigkeit und Wirksamkeit der Erkennungsmechanismen von DataSunrise.

Im Wesentlichen unterstreicht DataSunrises akribische Konfiguration von Strafen für die Erkennung von SQL-Injections ihr Engagement für die Bereitstellung robuster Datenbanksicherheitslösungen. Durch die Nutzung fortschrittlicher Erkennungstechniken und die kontinuierliche Verfeinerung seines Punktesystems befähigt DataSunrise Organisationen, ihre kritischen Datenbestände wirksam vor SQL-Injection-Angriffen zu schützen.