it-swarm.com.de

Gibt es eine Feldlänge, die zu kurz ist, um eine schädliche SQL-Injection zu ermöglichen?

Ich las über SQL Injection und sah dies, was mich zum Nachdenken brachte:

eingabefelder so klein wie möglich, um die Wahrscheinlichkeit zu verringern, dass ein Hacker SQL-Code in das Feld drücken kann, ohne dass er abgeschnitten wird (was normalerweise zu einem T-SQL-Syntaxfehler führt).

Quelle: Microsoft SQL Server 2008 R2 entfesselt

Was ist die kürzeste Feldgröße, bei der SQL-Injection Schaden anrichten kann?

Wenn die Datenbank geändert wird oder Ergebnisse zurückgegeben werden, die nicht beabsichtigt sind. Einschließlich einer Endkommentar-Markierung (--) in einem zweistelligen Feld würde keinen Schaden anrichten, sondern nur eine fehlgeschlagene Abfrage verursachen. Der potenzielle Hacker könnte erfahren, dass das Feld anfällig für Injektionen ist, aber er kann es nicht nutzen.

51
James Jenkins

Nein, es gibt keine Länge, die zu kurz ist, um ausgenutzt zu werden (zumindest in einigen Situationen).

Ein Längenfilter ist kein gültiger Schutz gegen SQL-Injection, und vorbereitete Anweisungen sind wirklich die einzig richtige Verteidigung.

Ein Längenfilter ist jedoch ein gutes Maß für die Tiefenverteidigung (ebenso wie Ganzzahlfilter, Alphanumfilter usw.). Es gibt viele Situationen, in denen z. Eine gültige Eingabe kann niemals über 30 Zeichen liegen, aber wo eine sinnvolle Ausnutzung mehr erfordert. Es sollte (aber wahrscheinlich nicht) selbstverständlich sein, dass jede Filterung als Tiefenverteidigung serverseitig erfolgen muss, da alles, was clientseitig ist, einfach umgangen werden kann.

Restriction Bypass

Einschränkungsklauseln (z. B. AND/OR) können durch zwei Zeichen umgangen werden, was echten Schaden verursachen kann, nicht nur eine fehlgeschlagene Abfrage. Das einfachste Beispiel ist ein Login (andere Beispiele wären das unbefugte Löschen zusätzlicher Daten):

SELECT * FROM users WHERE userid = [id] AND password = [password]

Injektion:

id = 1#
password = wrong_password

Nutzlast: 2 Zeichen

DoS

DoS-Angriffe erfordern nur sehr wenige Charaktere. In einem MySQL-Beispiel dauert es 7 für den tatsächlichen Aufruf + x für die angegebenen Sekunden + was auch immer erforderlich ist, um die Funktion aufrufen und die Abfrage korrigieren zu können.

Beispiel:

SELECT * FROM users WHERE userid = [id]

Injektion (dies ist eine gültige Injektion, eine längere Form wäre 1 AND sleep(99)):

sleep(99)

Nutzlast: 9 Zeichen

Daten lesen

Wenn die Daten angezeigt werden, hängt die Länge hauptsächlich vom Tabellen- und Spaltennamen ab. Ich gehe von einer gleichen Spaltenanzahl für alle Tabellen aus (es kann vorkommen, dass Zeichen gespeichert werden).

Beispiel:

SELECT * FROM comments WHERE commentid = [id]

Injektion:

1 union select * from users

Nutzlast: 27 Zeichen.

Daten bearbeiten

Nicht autorisierte Datenbankänderungen können auch mit wenigen Zeichen erreicht werden.

Beispiel:

UPDATE users SET password = '[password]' WHERE id = [id]

Injektion (in Passwort):

',isadmin='1

Nutzlast: 12 Zeichen

Ein Restriktions-Bypass würde ebenfalls funktionieren (das Ergebnis ist, dass alle Passwörter jetzt leer sind *):

'#

Nutzlast: 2 Zeichen

* Das Passwortbeispiel wird der Einfachheit halber verwendet. Passwörter sollten gehasht werden, um das Beispiel unmöglich zu machen. Das Beispiel gilt weiterhin in allen ähnlichen Situationen (Aktualisieren eines Benutzernamens, Aktualisieren von Berechtigungen usw.)

86
tim

Ohne Kontext gehe ich davon aus, dass der Autor auf Eingabefelder in einer Clientanwendung verweist. Das einfachste Beispiel wäre ein Formular in einer HTML-Seite in einer Webanwendung, obwohl das, was ich beschreiben werde, für praktisch jede Art von Clientanwendung wirksam ist.

In diesem Zusammenhang lautet die Antwort "Nein". Es gibt keine maximale Eingabefeldlänge, die kurz genug ist, um Sie vor SQL-Injection zu schützen, da Sie steuern nicht die maximale Eingabefeldlänge. Der Angreifer tut es. Wenn sich das Formular mit dem Eingabefeld auf dem Client befindet (wie in einem Browserfenster auf dem Computer des Angreifers), befindet es sich außerhalb der Vertrauensgrenze und außerhalb Ihrer Kontrolle. Es kann auf jede vom Manipulator gewünschte oder benötigte Weise manipuliert oder vollständig vermieden werden. Denken Sie daran, dass Sie für eine Web-App lediglich eine HTTP-Anfrage erhalten. Sie haben keine Ahnung, wie es erstellt wurde, und keinen Grund zu der Annahme, dass irgendetwas, was Sie vom Browser verlangt haben, tatsächlich passiert ist, dass tatsächlich clientseitige Sicherheitskontrollen ausgeführt wurden, dass irgendetwas in der Anfrage wie folgt Sie beabsichtigt oder in irgendeiner Weise sicher.

Nein, die Länge des Eingabefelds ist kein gültiger Mechanismus zur Verhinderung der SQL-Injektion. Vertrauen Sie niemals Eingaben, die eine Sicherheitsgrenze überschreiten, ohne diese zu validieren.

90
Xander

eingabefelder so klein wie möglich, um die Wahrscheinlichkeit zu verringern, dass ein Hacker SQL-Code in das Feld drücken kann, ohne dass er abgeschnitten wird (was normalerweise zu einem T-SQL-Syntaxfehler führt).

IMHO, das ist nur Scheiße. Es ist ein schrecklicher Rat, die Länge der Eingabefelder zum Schutz vor SQL-Injection zu verwenden:

  • Der einzig richtige Weg, um sich vor SQL-Injection zu schützen, ist die Verwendung einer vorbereiteten Anweisung. Die Eingabedaten sind ein Parameter der Abfrage und werden niemals als SQL-Text verwendet.
  • Die Größe eines Feldes muss serverseitig gesteuert werden , da Sie niemals vertrauen können, was in einer Anfrage enthalten ist - es könnte sich um eine gefälschte handeln - und sollte verwendet werden Daten vor der Verwendung in der Business-Schicht oder im Datenbankspeicher zu bereinigen.
  • Der Rat, etwas anderes als die Best Practices zu verwenden, ist für unerfahrene Entwickler verwirrend.
11
Serge Ballesta

Nein.

Betrachten Sie die Abfrage:

select * from tweets
WHERE RowNum >= [offset]
AND RowNum < [offset] + [limit]

Wenn Sie eine einzelne Nicht-Ganzzahl (z. B. den Buchstaben "a") für offset einfügen könnten, würde die Abfrage zu einem Syntaxfehler führen und es würden keine Beiträge angezeigt, die Ihre "nicht vom Entwurf beabsichtigten Ergebnisse" ergeben. Voraussetzung für die Verursachung von Schäden. Wenn Sie eine leere Zeichenfolge einfügen können, erhalten Sie den gleichen Effekt mit einer Nutzlast von null Länge. Das Einfügen eines Endkommentars wäre eine Verschwendung von zwei Zeichen;)

Ein Angreifer kann dies bei einem Denial-of-Service-Angriff nutzen (anders als bei einem Netzwerk-Flooding , der im Allgemeinen mit DoS verbunden ist, aber dennoch ein DoS ). Abhängig vom verweigerten Dienst kann dies katastrophal sein.

Wie andere Antworten vermuten lassen, hat die Feldlänge keinen Einfluss auf die Auswirkung der SQL-Injektion. Vorbereitete, parametrisierte Anweisungen sind der richtige Weg, wie im OWASP SQL Injection Prevention Cheat Sheet erwähnt.

8
benrifkah

Nein.

Einfaches Beispiel für eine einstellige SQL-Injection:

`

Es würde einen Fehler auslösen, der ein Beispiel für "Rückgabe von Ergebnissen, die nicht vom Design beabsichtigt sind" wäre. Oft können Fehler verwendet werden, um Informationen zu erhalten, die später bei einem Exploit hilfreich sind.

4
MikeSchem

Ja.

Die maximale Länge ist Null. Die einzige Möglichkeit, nicht vertrauenswürdige Eingaben über die maximale Länge ohne weitere Validierung oder Überprüfungen sicher zu machen, besteht darin, die Eingabe ab Index 0 vollständig zu ignorieren.

Es gibt hier viele andere (bessere) Antworten, aber diese dient dazu, die theoretische Frage zu beantworten, wie man sicher bleibt, wenn nur die Feldlänge zur Verfügung steht.

3
Dan

Die Länge eines Feldes hat nichts mit SQL-Injection zu tun, da bei einem solchen Angriff einfach der vorherige Code auskommentiert und der Angriffscode gestartet wird, sodass die Länge eines Felds diese Strategie nicht beeinflusst.

0

Hier gibt es viel Theorie, aber keine konkreten Beispiele. Als ich eine echte SQL-Injection-Schwachstelle fand (jetzt gepatcht), habe ich versucht, Eingabefelder mit einer Länge von etwa 30 Zeichen zu verwenden. Das war sehr frustrierend, da ich eine Weile gebraucht habe, um herauszufinden, dass alles nach 30 Zeichen gelöscht wurde und 30 Zeichen mir nicht viel Platz ließen.

(Viele SQL-Injection-Beispiele haben einfache SQL-Anweisungen wie "select * from table where id = @id". SQL in der realen Welt ist normalerweise viel komplizierter.)

Sie können sich mit Ihrer Eingabe ein Bild machen, und ein SQL-Experte könnte wahrscheinlich einige Tricks anwenden, um die Anzahl der Nutzdaten zu reduzieren. Aber egal wie schwierig Sie sind, wenn Sie einen langen Tabellennamen auswählen möchten, benötigen Sie dafür viele Zeichen.

Als ich auf ein Eingabefeld mit mehr als 1.000 Zeichen umstieg, fand ich jedenfalls so viel für die SQL-Injektion.

Davon abgesehen, wie viele Kommentatoren über mir sagten, Die beste Verteidigung gegen SQL-Injektion sind vorbereitete Aussagen

0
Almenon