DataSunrises Ansatz zur Konfiguration von Strafen für die Erkennung von SQL-Injection

SQL-Injection ist eine weit verbreitete Bedrohung für die Datensicherheit, bei der Angreifer SQL-Abfragen manipulieren, um unbefugten Zugriff auf Daten zu erhalten. DataSunrise, eine Lösung zur Datensicherheit, bietet einen robusten Mechanismus zur Erkennung und Verhinderung von SQL-Injection-Angriffen durch ein Punktesystem für Strafen. In diesem Artikel wird untersucht, wie DataSunrise Strafen für verschiedene Arten von SQL-Injection-Mustern konfiguriert und Beispiele für jedes Muster bereitstellt.

Strafpunktsystem

Das Strafpunktsystem von DataSunrise weist verschiedenen Komponenten einer SQL-Abfrage, die auf eine potenzielle Injektion hinweisen könnten, einen numerischen Wert zu. Wenn die Summe dieser Strafen einen vordefinierten Schwellenwert überschreitet, ergreift DataSunrise Maßnahmen, entweder durch Protokollierung einer Warnung (Audit-Regel) oder durch vollständiges Blockieren der Abfrage (Sicherheitsregel).

Beispiele für SQL-Injection-Muster und Strafen

Kommentarbedingte Strafe

Eines der grundlegenden Ziele eines Angreifers bei dem Versuch, eine Injektion durchzuführen, besteht darin, die Anforderung radikal zu ändern. Dazu muss er den Teil der Anforderung deaktivieren/abschneiden, den er nicht kontrolliert oder der ihn daran hindert, die Injektion durchzuführen. Zu diesem Zweck wird dem Injektionscode ein Kommentar hinzugefügt, der den Teil der Anforderung auskommentiert, der sich nach dem injizierten Block befindet. Hier sind einige Beispiele.

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

Injection in den Username-Parameter: admin’–

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

Wenn dies erfolgreich ist, loggen Sie sich als Admin-Benutzer ein, da der Rest der SQL-Abfrage nach ‘–’ ignoriert wird.

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

ID-Wert: 10; DROP TABLE members /*

Einfach den restlichen Kram am Ende der Abfrage loswerden. Dasselbe wie 10; DROP TABLE members –

Daher ist die Anwesenheit von Kommentaren in der Anforderung eines der Anzeichen für eine potenzielle Injektion.

Schlüsselwort in Kommentar-Bestrafung

Setzt man das Thema Kommentare in einer Anforderung fort, so kann man sagen, dass gewöhnliche Kommentare häufig in legitimen Anfragen vorkommen. Zum Beispiel fügen viele von Entwicklern verwendete IDEs automatisch die aktuelle Uhrzeit oder die Version der IDE, in der die Anforderung generiert wurde, oder andere Meta-Informationen in Form eines Kommentars an den Anfang der Anforderung an. 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. in ihm.

Zum Beispiel in dem oben besprochenen 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 von mehr als einer Abfrage in einer Transaktion. Diese Technik kann nützlich sein, funktioniert jedoch nur für einige Kombinationen von Datenbankserver und Zugriffsmethoden:

SELECT * FROM members; DROP members --`

Wenn dies erfolgreich ist, wird eine Abfrage beendet und eine andere gestartet.

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

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

ODER-Strafe + Konstante-Ausdruck-Strafe

Oft muss ein Angreifer, um eine Injektion durchführen zu können, eine Bedingung erstellen, die wahr (TRUE) ist. Der einfachste Weg dazu kann eine ODER-Operation mit einem Wert sein, der immer TRUE ist. Zum Beispiel wie in dem Beispiel: https://insecure-website.com/products?category=Gifts’+OR+1=1–

Dies führt zu 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 sie anzeigen soll.

Natürlich ist die OR-Operation in der Anwendungsentwicklung gängig und beliebt, aber zusammen mit anderen Anzeichen kann sie dazu beitragen, Injektionen zu erkennen. Gleiches gilt für Ausdrücke, die immer TRUE oder FALSE zurückgeben.

Union-Strafe

Unsere Forschung hat gezeigt, dass Cyber-Angreifer automatisierte Tools verwenden, die ihnen helfen, die theoretische Möglichkeit der Ausnutzung einer bestimmten Schwachstelle zu identifizieren. Wenn es möglich ist, einer anfälligen Abfrage einen zusätzlichen Ausdruck hinzuzufügen, wird normalerweise die Möglichkeit geprüft, auf andere Tabellen zuzugreifen

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

Wenn Sie einen SQL-Injection-UNION-Angriff ausführen, gibt es zwei effektive Methoden, um zu bestimmen, wie viele Spalten von der ursprünglichen Abfrage zurückgegeben werden.

Eine Methode besteht darin, eine Reihe von UNION SELECT-Payloads einzureichen, wobei eine unterschiedliche Anzahl von Nullwerten angegeben wird:

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

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

Alle Abfragen, die mit einem UNION-, INTERSECT- oder EXCEPT-Operator kombiniert werden, müssen eine gleiche Anzahl von Ausdrücken in ihren Ziellisten 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, was die Wahrscheinlichkeit maximiert, dass die Payload erfolgreich ist, wenn die Spaltenanzahl stimmt.

Um die Chancen auf die Erkennung einer Injektion 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 auf Fehler basierende Methode der SQL-Injection zwingt die Datenbank, einen Fehler zu generieren, der dem Angreifer oder Tester Informationen liefert, auf deren Grundlage er seine Injektion verfeinern kann.

Um eine Anwendung zu zwingen, eine Anfrage zu generieren, die mit einem Fehler ausgeführt wird, werden viele verschiedene Techniken verwendet. Eine davon ist das Ausführen von 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. Sie kann auch für Blind Error-basierte Angriffe verwendet werden, bei denen der Angreifer nur herausfinden kann, ob ein Fehler aufgetreten ist oder nicht.

Wahrscheinlich die schwierigste Art der Überprüfung aus Implementierungssicht. Der Grund dafür ist, dass es eine Vielzahl von Möglichkeiten gibt, einen Fehler zu verursachen.

Verkettung einzelner Zeichen für viele Arten von Angriffen

Ein weiteres Muster, das häufig in Angriffen verwendet wird, ist das Entkommen aus den zurückgegebenen Daten. Dies ist oft notwendig, wenn sich der Inhalt der angegriffenen Seite häufig ändert und das automatische Überprüfungsskript für Injektionen spezielle Marker verwenden muss, um die Payload zu finden (die wertvollen Daten, die wir extrahieren möchten).

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

Verdächtiger Funktionsaufruf

In jeder ordentlichen Produktionsanwendung können Sie auf der Seite im Allgemeinen keine Fehlermeldungen sehen. Dies schließt das direkte Extrahieren von Daten über UNION-Angriffe oder Fehler-basierte 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 Injektionen. Sie können die Antwort nicht direkt auf der Seite sehen, aber Sie können das Ergebnis einer Abfrage basierend auf einer Antwort oder einem HTTP-Statuscode immer noch bestimmen.

Völlig blinde Injektionen. Sie können die Auswirkungen Ihrer Injektion in keiner Art von Ausgabe sehen. Dies ist weniger häufig, zum Beispiel wenn Sie in eine Protokollierungsfunktion oder ähnliches injizieren.

Bei normalen blinden Injektionen können Sie IF-Anweisungen verwenden oder WHERE-Klauseln in Abfragen missbrauchen, was im Allgemeinen der einfachere Weg ist. Für völlig blinde Injektionen müssen Sie einige Arten von Wartefunktionen 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 Anforderung ähnliche Abfragen enthält, die häufig in Angriffen verwendet werden.

Verdächtige Bedingung zur Überprüfung des Booleschen blinden Angriffs

Blinde SQL-Injection ist eine Form von SQL-Injection, bei der der Angreifer keine offensichtliche Antwort von der angegriffenen Datenbank erhält und stattdessen die Datenbankstruktur Schritt für Schritt rekonstruiert, indem er das Verhalten des Datenbankservers und der Anwendung beobachtet. Blinde SQL-Injection wird auch als inferentielle SQL-Injection bezeichnet.

Es gibt zwei Arten von blinden SQL-Injections: boolesche und zeitbasierte.

Bei dieser Art von Angriff kann man das vollständige Ergebnis nicht erhalten. Der Angreifer versucht, den Inhalt der Tabellen, die ihn interessieren, Buchstabe für Buchstabe blind zu erlangen. 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ählung-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 die zeitbasierte SQL-Injection verfügbar ist, der Angreifer irgendwie zwischen zwei Code-Ausführungszweigen unterscheiden muss. Dazu wird eine Abfrage in einem der Zweige ausgeführt, die viel Zeit in Anspruch nimmt. Beispielsweise die Zählung der Anzahl der Zeilen in einem Join von zwei oder mehr Tabellen. Beim Joins werden die Zeilen multipliziert und es werden viele Zeilen erhalten. Und COUNT läuft lange genug, dass das Skript es bemerkt. Detailliertere Informationen dazu finden Sie hier. In diesem Artikel finden Sie SLEEP(5), aber das ist nur Kindergarten.

Viele Menschen 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 Anforderung, die Teil einer komplexeren Anfrage ist, nicht verwendet, und daher kann dies als eines der Anzeichen für eine Injektion dienen.

Fazit

DataSunrises Ansatz zur Konfiguration von Strafen für die Erkennung von SQL-Injection stellt eine umfassende und proaktive Strategie dar, um Datenbanken vor dieser allgegenwärtigen Bedrohung zu schützen. Durch die Verwendung eines Strafpunktsystems, das verschiedene Aspekte von SQL-Abfragen bewertet, identifiziert und mindert DataSunrise effektiv potenzielle Injektionsversuche. Anhand von Beispielen, die verschiedene SQL-Injection-Muster und zugehörige Strafen veranschaulichen, zeigt 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-Injections durch DataSunrise das Engagement zur Bereitstellung robuster Sicherheitslösungen für Datenbanken. Durch den Einsatz fortschrittlicher Erkennungstechniken und die kontinuierliche Verfeinerung seines Strafsystems befähigt DataSunrise Organisationen, ihre kritischen Datenbestände effektiv vor SQL-Injection-Angriffen zu schützen.