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

SQL-Injection ist eine weit verbreitete Bedrohung für die Datenbanksicherheit, bei der Angreifer SQL-Abfragen manipulieren, um unbefugten Zugriff auf Daten zu erlangen. DataSunrise, eine Datenbanksicherheitslösung, bietet einen robusten Mechanismus zur Erkennung und Verhinderung von SQL-Injection-Angriffen durch ein Strafpunktsystem. Dieser Artikel wird untersuchen, wie DataSunrise Strafen für verschiedene Arten von SQL-Injection-Mustern konfiguriert und Beispiele für jedes liefert.

Strafpunktsystem

DataSunrises Strafpunktsystem weist verschiedenen Komponenten einer SQL-Abfrage, die auf eine potenzielle Injection hindeuten könnten, einen numerischen Wert zu. Wenn die Summe dieser Strafen einen vordefinierten Schwellenwert überschreitet, ergreift DataSunrise Maßnahmen, entweder durch das Protokollieren einer Warnung (Audit-Regel) oder das Blockieren der Abfrage (Sicherheitsregel).

Beispiele für SQL-Injection-Muster und -Strafen

Kommentarstrafe

Eine der grundlegenden Aufgaben eines Angreifers, wenn er eine Injection versucht, besteht darin, die Anfrage radikal zu ändern. Dafür muss er den Teil der Anfrage deaktivieren/abschneiden, den er nicht kontrolliert oder der ihn daran hindert, die Injection durchzuführen. Dazu wird Code in die Injection eingefügt, der den nach dem eingefügten Block befindlichen Teil der Anfrage kommentiert. Hier sind einige Beispiele.

1 Beispiel. Ein häufiges Beispiel ist das Einloggen als Admin:

Injection in den Benutzernamen-Parameter: admin’–

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

Wenn erfolgreich, wird dies als Admin-Benutzer eingeloggt, da der Rest der SQL-Abfrage nach ‘–’ ignoriert wird.

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

ID-Wert: 10; DROP TABLE members /*

Einfach alles andere am Ende der Abfrage loswerden. Genauso wie 10; DROP TABLE members –

Daher ist das Vorhandensein von Kommentaren in der Anfrage eines der Anzeichen für eine potenzielle Injection.

Schlüsselwort in einem Kommentarstrafe

Fortfahrend mit dem Thema Kommentare in einer Anfrage, können wir sagen, dass gewöhnliche Kommentare häufig in legitimen Anfragen zu finden sind. Zum Beispiel fügen viele von Entwicklern verwendete IDEs automatisch die aktuelle Zeit oder andere Metainformationen in Form eines Kommentars am Anfang der Anfrage hinzu. Daher ist ein weiteres Zeichen dafür, dass ein Kommentar verdächtig ist, das Vorhandensein von SQL-Schlüsselwörtern wie AND/OR/SELECT usw. darin.

Zum Beispiel im oben besprochenen SQL-Ausdruck

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

Wurde das AND-Schlüsselwort auskommentiert.

Doppelte Abfragestrafe (Stapeln von Abfragen)

Das Stapeln bedeutet, mehr als eine Abfrage in einer Transaktion auszuführen. Diese Technik kann nützlich sein, funktioniert jedoch nur für einige Kombinationen von Datenbankserver und Zugriffsmethoden:

SELECT * FROM members; DROP members--`

Wenn erfolgreich, beendet dies eine Abfrage und startet eine andere.

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

DataSunrise erzeugt keine Fehler, wenn in einer Abfrage Variablendeklarationsabfragen oder Konfigurationsexpressionen (wie SET) verwendet werden. Solche Anfragen sind nicht ungewöhnlich.

ODER-Strafe + Konstante Ausdruckstrafe

Oft muss ein Angreifer, um eine bestimmte Injection zu verwenden, eine Bedingung schaffen, die wahr (TRUE) ist. Und dafür kann die einfachste Methode eine ODER-Operation mit einem Wert sein, der immer TRUE ist. Zum Beispiel wie im Beispiel: https://insecure-website.com/products?category=Gifts’+OR+1=1–

Dies führt zur SQL-Abfrage:

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

In diesem Fall zeigt die Abfrage alle Kategorien und nicht nur die, die gezeigt werden sollten.

Natürlich ist die ODER-Operation in der Anwendungsentwicklung üblich 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.

Vereinigungsstrafe (Union)

Unsere Forschung hat gezeigt, dass Cyberangreifer automatisierte Tools verwenden, die ihnen helfen, die theoretische Möglichkeit einer Ausnutzung einer bestimmten Schwachstelle zu identifizieren. Wenn es möglich ist, einem anfälligen Abfrage eine zusätzliche Expression hinzuzufügen, wird in der Regel die Fähigkeit geprüft, auf andere Tabellen zuzugreifen

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

Bei der Durchführung eines SQL-Injection-UNION-Angriffs gibt es zwei wirksame Methoden, um festzustellen, wie viele Spalten von der ursprünglichen Abfrage zurückgegeben werden.

Eine Methode besteht darin, eine Reihe von UNION SELECT-Payloads mit einer unterschiedlichen Anzahl von NULL-Werten einzureichen:

' UNION SELECT NULL--
' UNION SELECT NULL,NULL--
' UNION SELECT NULL,NULL,NULL–, etc.

Wenn die Anzahl der NULLs nicht mit der Anzahl der Spalten übereinstimmt, gibt die Datenbank einen Fehler zurück, wie:

Alle Abfragen, die einen UNION-, INTERSECT- oder EXCEPT-Operator kombinieren, müssen eine gleiche Anzahl von Ausdrücken in ihren Ziellisten haben.

Ein Angreifer verwendet NULL als die Werte, die von der eingefügten SELECT-Abfrage zurückgegeben werden, da die Datentypen in jeder Spalte zwischen der ursprünglichen und der eingefügten Abfrage kompatibel sein müssen. NULL ist in jeden gebräuchlichen Datentyp konvertierbar, sodass die Wahrscheinlichkeit maximiert wird, dass die Payload erfolgreich ist, wenn die Spaltenanzahl korrekt ist.

Um die Wahrscheinlichkeit der Erkennung einer Injection zu verringern, erkennt DataSunrise ähnliche UNIONs, die beim Scannen anfälliger Anwendungen verwendet werden, und weist zusätzliche Strafpunkte zu.

Verdächtige Konvertierung: Fehlerangriff

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

Um eine Anwendung zu zwingen, eine Anfrage mit einem Fehler auszuführen, 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:

‘ and 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 enthält.

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

Wahrscheinlich der schwierigste Typ von Überprüfungen 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 der Inhalt der angegriffenen Seite häufig geändert wird und das automatische Verifizierungsskript für Injection spezielle Marker verwenden muss, um das Payload (die wertvollen Daten, die wir extrahieren möchten) zu finden.

Beispiel:

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 Entwürfe sind für DataSunrise verdächtig.

Verdächtiges Funktionsaufruf

In jeder anständigen 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 blind SQL-Injection verwenden, um die Daten zu extrahieren. Es gibt zwei grundlegende Arten von blinden SQL-Injections.

Normale blind Injections. Sie können die Antwort nicht direkt auf der Seite sehen, aber Sie können das Ergebnis einer Abfrage anhand einer Antwort oder eines HTTP-Statuscodes dennoch bestimmen.

Völlig blinde Injections. Sie können die Auswirkungen Ihrer Injection in keiner Art von Ausgabe sehen. Dies ist weniger verbreitet, z.B. wenn Sie in eine Protokollierungsfunktion oder ähnliches injizieren.

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

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

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

DataSunrise weist zusätzliche Strafpunkte zu, wenn die Anfrage ähnliche Abfragen enthält, die oft bei Angriffen verwendet werden.

Verdächtige Bedingung zur Überprüfung eines boolean-basierten Blindangriffs

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 gesamte Ergebnis nicht erhalten. Der Angreifer erhält den Inhalt der Tabellen, die ihn interessieren, blind, Buchstabe für Buchstabe. Dies kann sehr zeitaufwendig sein und erfordert 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 solcher Abfragen festgestellt werden.

Verdächtige Zählstrafe

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 zeitbasierte SQL-Injection verfügbar ist, der Angreifer irgendwie zwischen zwei Codeausführungszweigen unterscheiden muss. Zu diesem Zweck wird in einem der Zweige eine Anfrage ausgeführt, die viel Zeit in Anspruch nimmt. Zum Beispiel das Zählen der Anzahl der Zeilen in einem Join von zwei oder mehr Tabellen. Beim Joinen werden die Zeilen multipliziert und es werden viele Zeilen erhalten. Und COUNT läuft lange genug, damit das Skript es bemerken kann. Sie können hier mehr darüber lesen hier. In diesem Artikel finden Sie das SLEEP(5), aber das ist nur Kindergarten.

Viele Leute haben dies bereits bewiesen, und aus diesem Grund verwenden sie ausgefeiltere 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.

Fazit

DataSunrises Ansatz zur Konfiguration von Strafen für die Erkennung von SQL-Injection stellt eine umfassende und proaktive Strategie dar, um Datenbanken gegen diese allgegenwärtige Bedrohung zu schützen. Durch die Verwendung eines Strafpunktsystems, das verschiedene Aspekte von SQL-Abfragen bewertet, erkennt und mildert DataSunrise effektiv potenzielle Injection-Versuche. Anhand von Beispielen, die verschiedene SQL-Injection-Muster und zugehörige Strafen veranschaulichen, demonstriert dieser Artikel die Vielseitigkeit und Effektivität der Erkennungsmechanismen von DataSunrise.

Im Wesentlichen unterstreicht die akribische Konfiguration von Strafen für die Erkennung von SQL-Injection durch DataSunrise das Engagement des Unternehmens, robuste Datenbanksicherheitslösungen bereitzustellen. Durch die Nutzung fortschrittlicher Erkennungstechniken und die kontinuierliche Verfeinerung seines Strafsystems befähigt DataSunrise Organisationen, ihre kritischen Datenbestände wirksam gegen SQL-Injection-Angriffe zu schützen.