Frage:
Gibt es eine Feldlänge, die zu kurz ist, um eine schädliche SQL-Injection zu ermöglichen?
James Jenkins
2017-02-28 22:18:55 UTC
view on stackexchange narkive permalink

Ich habe über SQL-Injection gelesen und dies gesehen, 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 es 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?

Ein Schaden ist eine Datenbankänderung oder die Rückgabe von Ergebnissen, die nicht vom Entwurf beabsichtigt sind. Das Einfügen einer Endkommentar-Markierung ( - ) in ein zweistelliges Feld würde keinen Schaden verursachen, 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.

Wenn der angegebene Fehler ausführlich ist, kann dies ausreichen, um nützliche Informationen zu erhalten, insbesondere wenn ein Entwickler Tabellennamen als "geheim" behandelt hat ...
SQL Injection wird nicht immer für ein Eingabefeld ausgeführt. Sie können auf orderby-Klauseln in URLs abzielen, z. B. wo Sie böswilliges SQL ausführen könnten.Die begrenzte Größe eines Feldes wird das nicht aufhalten.
@iain: Guter Punkt.Das Begrenzen der Feldlängen für (ich nehme an) empfangene HTML-Formulardaten ist für mich kein guter Weg, um eine SQL-Injektion zu vermeiden.Die Vermeidung von SQL-Injektionen ist im Grunde ein gelöstes Problem.Lassen Sie die Datenbankverbindungsbibliothek einfach damit umgehen, indem Sie vorbereitete Anweisungen mit Platzhaltern verwenden, anstatt Abfragen mit den Zeichenfolgenfunktionen Ihrer Programmiersprache zusammenzufügen und falsch zu verstehen, weil Sie vergessen haben, sich vor der Lücke 59654 zu schützen.
@Pascal "* Die Vermeidung von SQL-Injektionen ist grundsätzlich ein gelöstes Problem. *" Gilt nur für neuen Code, wenn entsprechende Überlegungen angestellt wurden.Es gibt viel Code, in dem das Problem nicht behoben wurde.Vermutlich gibt es eine Zeichenlänge, unterhalb derer die Behebung bestehender Probleme weniger dringlich ist als die mit längeren Längen.
Bin ich der einzige, der meint, dass das Buch öffentlich verbrannt werden sollte?Parametrisierte Abfragen gibt es schon so lange, dass der Autor mich glauben lässt, dass sie nicht einmal eine halbe Ahnung haben, wovon sie sprechen.Es klingt so, als würden sie Müll aus einer Sammlung von Blogs kopieren und einfügen und ein Buch veröffentlichen.Sie könnten Ihnen genauso gut sagen, dass Sie üben sollten, mit kleineren Kugeln erschossen zu werden, damit Sie Immunität gegen größere Kugeln aufbauen können.
@MonkeyZeus Dies ist eher die Regel als die Ausnahme für technische Bücher.Wenn Nicht-Sicherheitsexperten Sicherheitsratschläge anbieten, ist diese oft von schlechter Qualität.
Wie wäre es mit 0 Zeichen?Und nur wenn auf dem Server validiert.
@Xander Diese Aussage bereitet mir große Sorgen.Ich bin sicherlich auch kein Sicherheitsexperte, aber mein einziger Absatz dezimiert wahrscheinlich alles, was dieses Buch zu bieten hat.Ich denke, [Argument aus Unwissenheit] (https://en.wikipedia.org/wiki/Argument_from_ignorance) hat immer noch eine unergründliche Popularität.Die einzig mögliche Einsparung für dieses Buch wäre, wenn die Parametrisierung in dieser Version von SQL Server nicht unterstützt würde.Auch wenn das mehr die Regel als die Ausnahme ist, werden wir ein mächtiges feines Feuer haben.
@MonkeyZeus Ich stimme zu, dass es beunruhigend ist, aber ich habe es mir zum Hobby gemacht, die Sicherheitshinweise in technischen Büchern und insbesondere in Programmierbüchern zu überprüfen.Die Abdeckung ist im Allgemeinen entweder miserabel oder fehlt vollständig.Zum Beispiel habe ich ein Buch über den Aufbau von E-Commerce-Systemen von Grund auf, in dem die Verwendung von HTTPS kurz erörtert wird, und das dann erklärt, dass weitere Sicherheitsdiskussionen "außerhalb des Geltungsbereichs" des Buches lagen.
@Xander Ich würde sagen, dass "woanders hinschauen" edler ist, als dreist zu behaupten: "Verschleiern Sie Ihre Formulardaten mit JavaScript und einem vom Server generierten Zufallsschlüssel, bevor Sie Daten an Ihren Server senden."Zumindest heißt es in diesem E-Commerce-Buch: "Hey Mann, wir möchten nicht, dass sich Ihr Server mit einem Sandpapier-Phallus duckt. Wenn Sie also Wert auf Sicherheit legen, besorgen Sie sich ein gutes Buch darüber. In unserem Buch erfahren Sie nur, wie Sie ein E erstellen-Commerce-Site, nicht wie man eine sichert. "
Ich bin grundsätzlich gegen das Brennen von Büchern - würde aber dafür stimmen, die Bestände für die Autoren zurückzubringen - "was normalerweise zu einem T-SQL-Syntaxfehler führt" - der Sinn von SQL Injection besteht darin, Ihre übermittelten Daten dazu zu bringen, mit dem zu interagierenGrenzen des beabsichtigten Ziels.
Wie aus anderen Antworten hervorgeht, verhindern kurze Feldlängen keine Probleme.Ich habe kürzlich an einer Legacy-Anwendung mit einem 8-stelligen Benutzernamenfeld gearbeitet (und 8 Zeichen wurden im Code eingecheckt), aber es war immer noch offen für SQL-Injection.Die Situation wurde noch schlimmer, als das Passwortfeld auch für die Injektion verwendet wurde.
Ich stimme zwar zu 100% zu, wie schlecht diese Sicherheitsprobleme normalerweise angegangen werden und wie schlecht die Ratschläge aus diesem Buch sind, aber ich denke, dass diese Ratschläge hauptsächlich deshalb schlecht sind, weil es sehr wahrscheinlich ist, dass die Leute sich täuschen, dies zu tun, indem sie diese "Vorsichtsmaßnahme treffen""Sie haben sich vor SQL-Injection geschützt, und es ist auch schlecht, weil es die Risikominderung in einem Fall fördert, in dem eine Risikoeliminierung möglich (und einfach) wäre.Es gibt keine Möglichkeit zu leugnen, dass dieses Zitat nicht behauptet, die SQL-Injection zu verhindern.es behauptet nur, "die Wahrscheinlichkeit zu verringern" (was albern und irreführend ist).
@MonkeyZeus Viele DB-APIs unterstützen * immer noch * keine Array-Parameter, z. B. die für die rechte Seite des Operators "IN".Um dies zu umgehen, müssen Sie eine variable Anzahl von Parametern in eine Abfrage aufnehmen. Zu diesem Zeitpunkt "fügen" Sie eine Liste von Platzhaltern zusammen und halten die Reihenfolge der Positionsplatzhalter (`?`) Zwischen den Anweisungen synchronund das Wertearray ist so schwer wie das Entkommen.
Acht antworten:
#1
+90
Xander
2017-02-28 23:18:13 UTC
view on stackexchange narkive permalink

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

In diesem Kontext lautet die Antwort Nein, es gibt keine maximale Eingabefeldlänge, die kurz genug ist, um Sie vor SQL-Injection zu schützen, da Sie die maximale Eingabefeldlänge nicht steuern. 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 etwas, zu dem Sie den Browser aufgefordert haben, tatsächlich passiert ist, dass clientseitige Sicherheitskontrollen tatsächlich ausgeführt wurden und dass alles in der Anforderung so ist Sie haben beabsichtigt oder in irgendeiner Weise sicher.

Nein, die Länge des Eingabefelds ist kein gültiger Mechanismus zur Verhinderung der SQL-Injektion und vertraut niemals einer Eingabe, die eine Sicherheitsgrenze überschreitet, ohne sie zu validieren.

Es ist eine gute Antwort. Vielleicht bedeutet der Autor, dass ein zu kurzes Feld die Wahrscheinlichkeit verringert, Informationen aus Datenbanken zu erhalten, aber es kann einen Schaden durch eine SQL-Injektion nicht vermeiden. Beispielsweise kann "oder 1 = 1" großen Schaden verursachen.
@hmrojas.p Dies ist jedoch nicht der Fall, da eine maximale Länge der eingegebenen Datei einen böswilligen Benutzer nicht daran hindert, so viele Daten zu senden, wie er oder sie in diesem Feld möchte.Ich kann eine maximale Eingabelänge auf 3 festlegen, und ein Angreifer kann weiterhin senden oder 1 = 1; Tabellenbenutzer löschen; - Wenn Sie nicht auf der Serverseite prüfen, verhindert dies nichts.
Ja, ich stimme zu, ich ging davon aus, dass es auf der Serverseite eine Längenüberprüfung gibt. Ich meine, diese Art von SQL-Injection (`oder 1 = 1`) könnte eine SQL-Abfrage wie UPDATE oder DELETE beeinflussen und die Datenintegrität beeinträchtigen.Selbst wenn Sie eine Längenvalidierung auf der Serverseite haben, ist diese Maßnahme komplementär.
Was ist dann, wenn der Server diese Validierung dann durchführt?Böswillige Benutzer können das nicht anfassen.Wenn mein PHP-Skript nur bis zu den ersten x Zeichen verwendet (was extrem einfach ist und mitten in der Abfrage ausgeführt werden kann), was dann?
@Ryan Das ist in der Tat der Schlüssel.* Das * wäre die Sicherheitskontrolle.Das Festlegen der maximalen Länge des Eingabefelds ist für UX hilfreich, hat jedoch keinen Sicherheitswert.Es ist die serverseitige Eingabevalidierung, die Sicherheit bietet.Dies ist eine grundlegende und wichtige Unterscheidung.Es ist eine theoretische Unterscheidung, da die richtige Antwort darin besteht, parametrisierte Abfragen zu verwenden, aber wenn man sich das Eingabemanagement genau ansieht, ist es immer noch eine wichtige Unterscheidung.
Ich habe ein Downvoting durchgeführt, da dies voraussetzt, dass die Feldlänge nicht serverseitig validiert ist.Obwohl ich damit einverstanden bin, dass in jeder Antwort erwähnt wird, dass die Länge serverseitig und außerhalb der Kontrolle des Benutzers validiert werden muss, um von Nutzen zu sein, glaube ich, dass die serverseitige Validierung der Länge Ihre gesamte Antwort vollständig ungültig machen würde.(Die Antwort könnte immer noch nein sein, aber nicht aus diesem Grund.)
@jpmc26 Ob es serverseitig validiert ist, spielt keine Rolle.Der Kontext des Angebots ist eine clientseitige "Sicherheitsmaßnahme", und die serverseitige Validierung wird nicht behandelt.
@Xander Die einzige Person, die hier eine clientseitige Validierung angenommen hat, sind Sie.Ich sehe nichts in der Frage oder den Kommentaren, was darauf hindeutet, dass dies die Situation ist, die das OP beschreibt.
@jpmc26 Aus der Frage: * "Eingabefelder so klein wie möglich" *.Weiß der Server, was ein Eingabefeld ist, wenn er eine Antwort erhält?Ich meine, wenn Sie ein HTML-Formular senden, hat der Server kein Konzept für "Eingabefeld".Es werden nur die Daten abgerufen.Ich denke, ohne Kontext aus dem Buch ist das Zitat etwas mehrdeutig.
@JacobAlvarez Der Server kennt offensichtlich die Eingaben und kann die Werte erkennen, wenn er sie in eine SQL-Abfrage einfügen kann, in der eine Injektion erfolgen kann.Wenn es die Werte erkennen kann, kann es die Länge bestimmen.Versteh mich nicht falsch;Das Zitat ist Unsinn.Aber es gibt auch Gründe, warum es Unsinn ist. Lassen Sie uns die Gründe richtig verstehen.
@jpmc26, das Zitat sagt "Eingabefeld".Hier findet die Benutzerinteraktion statt.Mir ist also klar, dass es um die Client-Seite geht, nicht um die Server-Seite.Gleiches gilt für Formulare, die eine JS-Eingabevalidierung durchführen.Sofern nicht ausdrücklich angegeben wird, dass die Validierung serverseitig wiederholt wird, kann davon ausgegangen werden, dass keine serverseitige Validierung vorhanden ist.
@aross Nach allem, was wir wissen, könnten wir über eine REST-Schnittstelle sprechen, die nicht einmal eine GUI bietet."Eingabefeld" bedeutet für mich nichts weiter als der vom Benutzer generierte Wert.Es ist auf jeden Fall angebracht zu erwähnen, dass die Längenüberprüfung in einer Umgebung durchgeführt werden muss, die der Benutzer nicht kontrolliert.Angenommen, es passiert nicht und als Grundlage für eine * vollständige * Antwort wird eigentlich nur vermieden, die Frage überhaupt zu beantworten.
@jpmc26 Sie scheinen Parameter mit Eingabefeldern zusammenzuführen.
@aross Ich denke anscheinend darüber nach, dass die Werte aus diesen "Eingabefeldern" * in einer SQL-Abfrage * enden.Es gibt keinen praktischen Unterschied und "Eingabefeld" ist nicht so streng definiert.Die Vorstellung, dass dies nur eine clientseitige Validierung ist, ist eine * völlig ungerechtfertigte Annahme *, die nicht mehr als eine Randnotiz verdient.Es beantwortet * nichts * über die Frage, ob die Länge im Kontext der SQL-Injection von Bedeutung ist.
Wenn wir eine Diskussion über Semantik beginnen, sind hier einige Quellen: [Eingabe] (https://en.wikipedia.org/wiki/Input_ (Computer_science)), [Parameter] (https: //en.wikipedia.org / wiki / Parameter_ (Computerprogrammierung))
Lassen Sie uns [diese Diskussion im Chat fortsetzen] (http://chat.stackexchange.com/rooms/54700/discussion-between-jpmc26-and-aross).
#2
+86
tim
2017-03-01 00:10:54 UTC
view on stackexchange narkive permalink

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 es wirklich nur richtige Verteidigung.

Ein Längenfilter ist jedoch ein gutes Maß für die Tiefenverteidigung (ebenso wie Ganzzahlfilter, Alphanum-Filter 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 Starke>

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 eine Anmeldung (andere Beispiele wären das unbefugte Löschen zusätzlicher Daten):

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

Injektion:

  id = 1 # password = falsches Passwort  

Nutzlast: 2 Zeichen

DoS

DoS-Angriffe erfordern nur sehr wenige Zeichen. 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

Lesen von Daten

Wenn die Daten angezeigt wird, 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 Kommentare WHERE commentid = [id]  

Injektion:

  1 union select * from users  

Nutzlast: 27 Zeichen.

Bearbeiten von Daten

Nicht autorisierte Datenbankänderungen können auch mit wenigen Zeichen durchgeführt werden.

Beispiel:

  UPDATE-Benutzer SET password = '[password]' WHERE id = [id]  

Injektion (in Passwort):

  ', isadmin =' 1  

Nutzlast: 12 Zeichen

Eine Einschränkungsumgehung würde ebenfalls funktionieren (das Ergebnis ist, dass alle Passwörter jetzt leer sind *):

  '#  

Nutzlast: 2 Zeichen

* Das Kennwortbeispiel 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.) sub>

"Ein Längenfilter ist kein gültiger Schutz gegen SQL-Injection, und vorbereitete Anweisungen sind wirklich die einzig richtige Verteidigung." Dies ist die einzig gültige Antwort.SQL ohne vorbereitete Anweisungen erinnert mich an ["Strategien, wie man ein totes Pferd reitet"] (http://www.deadhorses.org/)
Viel Glück beim Erstellen einer Anweisung mit einer variablen Anzahl von Platzhaltern, z. B. der rechten Seite des Operators "IN".
@DamianYerrick Ich denke, das ist eine fehlerhafte Hypothese.Warum sollten Sie einem Endbenutzer endlose Kombinationen von Platzhaltern für eine IN-Klausel bereitstellen müssen?Es ist einfach genug, eine Handvoll Vorlagen zu haben, die 1..n (für ein kleines n) erlauben.
In "SELECT * FROM users WHERE userid = [id]" können Sie a einfügen, wenn a der Name einer Spalte ist, sodass Sie nur ein Zeichen einfügen.
@ShawnC Der Anwendungsfall besteht darin, dass ein Benutzer eine Liste der abzufragenden Elemente eingibt.Wie groß ist zum einen "ein kleines n"?Es scheint gegen die Null-Eins-Unendlichkeitsregel zu verstoßen.Wenn zum anderen zwei verschiedene Eingabefelder mit Listenwert vorhanden sind, müssen Sie jetzt O (n ^ 2) -Vorlagen speichern und testen.
@Alexander: Bitte beachten Sie, dass Sie nicht immer vorbereitete Anweisungen verwenden können, da diese nicht über Feldnamen parametrisiert werden können.Und wenn Sie Ihre Joins aus Benutzereingaben erstellen müssen, wird Ihre Arbeit noch viel schwieriger ...
@Joshua Dies sind Sonderfälle.> 99% der nicht parametrisierten Abfragen können ohne großen Aufwand parametrisiert werden.Und für die Sonderfälle ist es viel einfacher, zu erzwingen, dass Feldnamen mit "[a-zA-Z] +" übereinstimmen müssen, als bestimmte Sonderzeichen in Werten zuzulassen und andere nicht zuzulassen.Wissenswertes: Als ich in PHP zu parametrisierten Abfragen wechselte, bestand das Hauptproblem darin, einen Anbieter zu finden, auf dem mysqli aktiviert war.[Mein Hauptproblem in DotNet war die IN-Klausel.] (Http://stackoverflow.com/questions/20143012/sqlparameter-and-in-statement)
@Alexander: Gibt es ein Sicherheitsproblem bei der Laufzeit, bei dem eine Abfrage der Form `SELECT [was auch immer] aus MyTable generiert wird, wobei id = @ @p0 ODER id = @ @p1 ODER id = @ @p2` für eine beliebige Anzahl von Parametern, die der Benutzer eingibt, falls keinedes Textes der Parameter ist in der Anweisung enthalten?
#3
+11
Serge Ballesta
2017-03-01 04:13:06 UTC
view on stackexchange narkive permalink

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. Die Verwendung der Länge von Eingabefeldern zum Schutz vor SQL-Injection ist ein schrecklicher Rat:

  • Der einzig richtige Weg zum Schutz vor SQL-Injection ist die Verwendung einer vorbereiteten Anweisung. Die Eingabedaten sind ein Parameter der Abfrage und werden niemals als SQL-Text verwendet.
  • Die Größe eines Felds muss serverseitig gesteuert werden, da Sie können niemals vertrauen, was in einer Anfrage enthalten ist - es kann sich um eine gefälschte Anfrage handeln - und sollten verwendet werden, um Daten vor der Verwendung in der Geschäftsschicht oder im Datenbankspeicher zu bereinigen.
  • Es wird empfohlen, andere als die Best Practices zu verwenden ist für unerfahrene Entwickler verwirrend.
#4
+8
benrifkah
2017-03-01 03:10:19 UTC
view on stackexchange narkive permalink

Nr.

Betrachten Sie die Abfrage:

  Wählen Sie * aus TweetsWO RowNum > = [Offset] UND 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 einer Syntax führen Fehler und keine Beiträge würden angezeigt, was Ihre Anforderung "Ergebnisse, die nicht beabsichtigt sind" zur Verursachung von Schäden ergibt. 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 einer Netzwerküberflutung, die im Allgemeinen mit DoS verbunden ist immer noch ein DoS). Abhängig vom verweigerten Dienst kann dies katastrophal sein.

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

Denial of Service und SQL Injection sind zwei sehr unterschiedliche Dinge.Diese Antwort bietet nichts Hilfreiches, das in vorhandenen Antworten noch nicht behandelt wurde.
Richtig, SQL-Injection ist eine Form der Kategorie "Injection Attack", die viele verschiedene Ziele erreichen kann, einschließlich Denial-of-Service.Denial-of-Service ist eine Technik, die durch verschiedene Vektoren erreicht werden kann.Eine häufige ist über eine verteilte Flut.Jede Technik, die einen nicht reagierenden Dienst liefert, wird ordnungsgemäß als Denial-of-Service-Angriff eingestuft.Dies kann SQL-Injection beinhalten.Meine Antwort liefert eine Erklärung, wie dies mit null Zeichen gemacht werden kann.Es bietet auch einen Link zum OWASP SQL Injection Prevention Cheat Sheet.Vielen Dank für den Hinweis, dass ich diese hervorheben sollte.
#5
+4
MikeSchem
2017-03-02 02:14:18 UTC
view on stackexchange narkive permalink

Nein.

Einfaches Beispiel für eine einstellige SQL-Injektion:

  ` 

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

Vielleicht könnten Sie eine Erklärung hinzufügen, wie diese Injektion schädlich sein könnte?
Dies wäre ein Fehler, der ein Beispiel für die Rückgabe von Ergebnissen darstellt, die nicht vom Entwurf beabsichtigt sind. Oft können Fehler verwendet werden, um Informationen zu erhalten, die später bei einem Exploit hilfreich sind.
Vielen Dank!Ich habe mir erlaubt, Ihre Erklärung in die Antwort aufzunehmen.
#6
+3
Dan
2017-03-03 00:27:35 UTC
view on stackexchange narkive permalink

Ja.

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

Hier gibt es viele andere (bessere) Antworten, aber diese dient zur Beantwortung der theoretischen Frage, wie Sie sicher sein können, wenn Ihnen nur die Feldlänge zur Verfügung steht.

Ich bin ehrlich gesagt nicht davon überzeugt, dass ein kluger Angreifer einen Angriff mit null Zeichen nicht bewältigen kann.
In Anlehnung an andere Kommentare oben - wo Ergebnisse, die nicht vom Design beabsichtigt sind, eine Form der SQL-Injection sind;Wäre es auch gültig zu sagen, dass jedes Verhalten, das nicht beabsichtigt ist, eine Form der SQL-Injektion ist (unter Bezugnahme auf das obige Beispiel für Schlaf (60). Was war irgendwie cool :)? Eine SQL-Injektion mit einer Länge von 0 müsste dann nicht unbedingt SQL beinhalten ... solange Sie die Verbindung herstellen können?
@Dan na meine Güte, wenn ich wüsste, dass ich eine Gegenmaßnahme treffen würde.Dies ist das Problem mit der Sicherheit im Allgemeinen ... Wir denken, dass es sicher ist, bis ein Angreifer beweist, dass dies nicht der Fall ist.
#7
  0
Spencer Williams
2017-03-03 05:47:59 UTC
view on stackexchange narkive permalink

Die Länge eines Feldes hat nichts mit SQL-Injection zu tun, da ein solcher Angriff einfach durch Auskommentieren des vorherigen Codes und Starten des Angriffscodes funktioniert, sodass die Länge eines Felds diese Strategie nicht beeinflusst.

Ich denke, der Punkt von OP ist, dass die Anwendung nicht zulässt, dass eine beliebige Textmenge in die Datenbank gelangt - sie wird immer noch bei einer bestimmten Länge abgeschnitten.
#8
  0
Almenon
2018-08-02 20:38:10 UTC
view on stackexchange narkive permalink

Hier gibt es viel Theorie, aber keine konkreten Beispiele. Als ich eine reale 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 Beispiele für SQL-Injektionen haben einfaches SQL "wie select * from table, wobei id = @id", SQL in der realen Welt ist normalerweise viel komplizierter)

Sie können es bekommen Lust auf Ihre Eingabe, 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.

Wie auch immer, als ich auf die Verwendung eines Eingabefelds mit über 1k Zeichen umgestiegen bin Ich habe so viel für die SQL-Injektion gefunden.

Wie viele Kommentatoren über mir sagten, Die beste Verteidigung gegen die SQL-Injektion sind vorbereitete Aussagen



Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...