Frage:
SQL-Injection - warum sind Escape-Anführungszeichen nicht mehr sicher?
Incognito
2011-05-06 19:44:52 UTC
view on stackexchange narkive permalink

Raw SQL

Wenn Sie SQL schreiben - für alles, was wirklich menschliche Eingaben erfordert, wurden viele Dinge getan, um die Injektion zu vermeiden.

Jeder, der gehört wird of SQL Injection weiß, dass (ich werde PHP als Beispiel verwenden) so etwas nicht sicher ist:

  $ sql = "SELECT * FROM` users`. WHERE `userName `=" {$ _POST ["Benutzername"]} ". AND` pass` = "{$ _POST [" pass "]}"; ";  

Magic

Dann kam natürlich jemand auf die Idee, "magische Fluchtzitate" zu verwenden, um Programmeingaben zu verarbeiten, die aufgrund fehlerhafter Praktiken nicht korrekt bereinigt und direkt in SQL eingefügt wurden. Dies hat das Problem mit der SQL-Injection nicht wirklich gelöst, aber es bedeutete, dass alle Benutzereingaben verstümmelt wurden.

Hinzufügen von Schrägstrichen

Einige Leute haben magische Anführungszeichen deaktiviert. Dann analysierten sie Benutzereingaben vor dem SQL-Punkt durch addslashes () , was theoretisch allen Anführungszeichen entgeht und Ihr Hacker nicht 'OR 1 = 1 ausführen kann, aber Selbst in der Dokumentation für Addslashes heißt es selbst, dass Sie keine Addslashes verwenden sollten. Es heißt, dass Sie die datenbankspezifische Funktion wie mysql_real_escape_string () verwenden, aber dies wird von einigen immer noch als nicht ausreichend bezeichnet.

Hinzufügen von datenbankspezifischen Schrägstrichen

Wir können also keinen DBMS-spezifischen * _real_escape_string verwenden, wir können keine Schrägstriche hinzufügen code verwenden >, die Sache mit den "magischen Zitaten" verursachte viele Probleme, und das Web ist voll von kurz formulierten Zitaten wie:

"Ein engagierter Hacker wird einen Weg finden, durch Ihre Zitat-Flucht zu springen Schleifen, verwenden Sie einfach die von DBAL vorbereiteten Anweisungen "- John Q jeder Programmierer

Okay, das hat mich genug erschreckt, um vorbereitende Anweisungen und eine DBAL zu verwenden. Es hat nichts wirklich erklärt, aber es klingt gut, weil ich es oft gehört habe.

Vorbereitete Anweisungen

Jetzt verwenden wir also PDO oder eine DBAL von a Framework oder etwas anderes, das all unser SQL einschließt und sicherstellt, dass jemand keine SQL-Injection ausführen kann.

Meine Frage ist im Grunde ein "Warum nicht?", kein "Was soll ich verwenden?". Das Web ist voll von Leuten, die Ihnen sagen, dass Sie dies oder das oder was auch immer verwenden sollen, aber keine Erklärungen, warum diese Dinge passieren mussten.

Direkte Fragen

Gezielte Fragen (Erinnerung, ich frage nach SQL, PHP war eine Beispielsprache, weil es schlecht mit SQL zu tun hat, Konzepte sind universell):

  1. Warum können wir nicht allen Benutzereingaben mit entkommen? "Magie"?
  2. Warum waren Addslashes nicht "gut genug"?
  3. Was ist falsch an der Verwendung von DB-spezifischen Escape-Funktionen und warum war es besser als Addslashes?
  4. Warum werden vorbereitete Anweisungen mit Frameworks und PDO als Goldstandard von SQL gefeiert? Warum sind sie besser? Warum kann ich mit diesen keine SQL-Injection durchführen, wo ich es mit den zuvor genannten Mitteln hätte tun können? Kann ein Programmierer es nicht irgendwie schaffen, dies noch zu vermasseln? Worauf sollten sie achten?
  5. Andere Bedenken, die ich nicht angesprochen habe?
  6. ol>
Sieben antworten:
#1
+53
Hendrik Brummermann
2011-05-07 04:16:16 UTC
view on stackexchange narkive permalink

Warum können wir nicht alle Benutzereingaben mit "magic" umgehen?

Zum Zeitpunkt der Anwendung der Magie ist nicht bekannt, wo die Daten landen werden. Magische Anführungszeichen zerstören also Daten, die nicht in eine Datenbank geschrieben werden.

Sie können nur in der an den Client zurückgesendeten HTML-Antwort verwendet werden. Stellen Sie sich ein Formular vor, das nicht vollständig ausgefüllt wurde und dem Benutzer daher erneut angezeigt wird. Bei magischen Anführungszeichen werden die beim ersten Versuch eingegebenen Daten jetzt mit SQL-Escapezeichen versehen, was auf einer HTML-Seite bedeutungslos ist. Noch schlimmer: Bei der zweiten Übermittlung werden die Daten erneut mit SQL-Escapezeichen versehen.

Warum waren Addslashes nicht "gut genug"?

Es gibt Probleme mit Multibyte Zeichen:

  '27 \ 5c 뼧 bf 5c  

Dies sind zwei Bytes, aber nur ein Unicode-Zeichen.

Seit addiert Schrägstriche weiß nichts über Unicode, konvertiert die Eingabe bf 27 in bf 5c 27 . Wenn dies von einem Unicode-fähigen Programm gelesen wird, wird es als 뼧 'angesehen. Boom.

Eine gute Erklärung für dieses Problem finden Sie unter http://shiflett.org/blog/2006/jan/addslashes-versus-mysql-real-escape-string

Was ist falsch an der Verwendung von DB-spezifischen Escape-Funktionen und warum war es besser als das Hinzufügen von Schrägstrichen?

Sie sind besser, weil sie sicherstellen, dass das Escape die Daten auf die gleiche Weise wie die Datenbank (siehe letzte Frage).

Aus Sicherheitsgründen sind sie in Ordnung, wenn Sie sie für jede einzelne Datenbankeingabe verwenden. Sie haben jedoch das Risiko, dass Sie einen von ihnen irgendwo vergessen.

Bearbeiten : Wie getahobby hinzugefügt hat: Oder Sie verwenden xxx_escape_strings für Zahlen, ohne sie in SQL in Anführungszeichen zu setzen Anweisung und ohne sicherzustellen, dass es sich um tatsächliche Zahlen handelt, indem die Eingabe in den entsprechenden Datentyp /Edit

umgewandelt oder konvertiert wird

Aus Sicht der Softwareentwicklung sind sie schlecht, weil sie das Hinzufügen von Unterstützung für andere SQL-Datenbankserversoftware erheblich erschweren.

Warum werden vorbereitete Anweisungen mit Frameworks und PDO als die bezeichnet? Goldstandard von SQL? Warum sind sie besser?

PDO ist aus Gründen des Software-Designs meistens eine gute Sache. Dies erleichtert die Unterstützung anderer Datenbankserversoftware erheblich. Es verfügt über eine objektorientierte Schnittstelle, die viele der kleinen datenbankspezifischen Inkompatibilitäten abstrahiert.

Warum kann ich mit diesen [vorbereiteten Anweisungen] keine SQL-Injection durchführen, wie ich es mit den vorherigen hätte tun können? Erwähnte Mittel?

Der Teil " konstante Abfrage mit variablen Parametern " vorbereiteter Anweisungen ist hier wichtig. Der Datenbanktreiber maskiert automatisch alle Parameter, ohne dass der Entwickler darüber nachdenken muss.

Parametrisierte Abfragen sind aus syntaktischen Gründen häufig leichter zu lesen als normale Abfragen mit maskierten Parametern. Abhängig von der Umgebung können sie etwas schneller sein.

Die Verwendung vorbereiteter Anweisungen mit Parametern kann von statischen Code-Analyse-Tools überprüft werden. Ein fehlender Aufruf von xxx_escape_string wird nicht so einfach und zuverlässig erkannt.

Kann ein Programmierer dies nicht irgendwie noch vermasseln? Worauf sollten sie achten?

"Vorbereitete Anweisungen" implizieren, dass die konstant sind. Das dynamische Generieren vorbereiteter Anweisungen - insbesondere mit Benutzereingaben - weist immer noch alle Probleme mit der Injektion auf.

Dies sehr ausführlich und nicht realistisch. 99,9% der Webanwendungen sind nicht von Sprachcodierungsproblemen betroffen. ~ 0,1% der SQL-Injektion werden mit statischer Code-Analyse gefunden. Es gibt weitaus bessere Techniken, die von Fachleuten eingesetzt werden. Aus Erfahrung kann ich Ihnen sagen, dass die Themen, die ich behandelt habe, ** weitaus häufiger ** sind.
Ich bin nicht einverstanden, dass @Rook, Hendriks Antwort sehr realistisch ist. Das PDO-Mantra ist größtenteils nicht erforderlich, da viele Webanwendungen so erstellt sind, dass sie eine bestimmte Datenbank bis zu ihrem Lebensende verwenden. Daher hätte der Entwickler genauso gut die relevanten Funktionen verwenden können, anstatt eine Anwendung zu komplizieren, um 2% der Funktionen einer Erweiterung zu verwenden.
Es gibt nur 4 Sprachsätze, die Probleme mit "addslashes ()" haben, darunter gbk.
@Rook - Sie greifen erneut auf Beleidigungen zurück, anstatt Fragen zu beantworten. Das ist nicht akzeptabel. Sie müssen entweder Ihren Kommunikationsstil und Ihr Kommunikationsverhalten regeln, oder wir müssen auf eine Suspendierung zurückgreifen. Bitte nehmen Sie dies als höfliche Warnung.
In Bezug auf die neueste Frage "Kann es ein Programmierer nicht irgendwie schaffen, dies noch zu vermasseln?" Wollte ich nur auf ein [aktuelles SQL-Injection-Problem] (http://drupal.stackexchange.com/questions/133795/what-kind) verweisen -von-Angriffen-macht-den-Patch-für-sa-Core-2014-005-drupal-7-32-verhindern), die den Drupal-CMS-Inhalt unter Umgehung des PDO-Schutzes beeinflussten.
#2
+13
Christian
2011-05-08 12:45:57 UTC
view on stackexchange narkive permalink

[1.] Warum können wir nicht alle Benutzereingaben mit "magic" umgehen?

Weil magische Anführungszeichen in zweierlei Hinsicht gebrochen werden:

  1. Nicht alle $ _ (REQUEST / GET / POST) -Daten werden in die Datenbank aufgenommen. Und damit Sie einen Sinn daraus machen können, müssen Sie die Eingabe entziehen.
  2. Sie sind das Äquivalent zu addslashes (siehe meinen Hinweis zu [2.]). Daher sind sie nicht wirklich sicher.
  3. ol>

    [2.] Warum waren Addslashes nicht "gut genug"?

    Es gibt viele Möglichkeiten, um aus der Einschränkung addslashes herauszukommen, daher ist sie grundlegend fehlerhaft, jedoch versuchen Sie, sie zu verwenden.

    [3.] Was ist falsch an der Verwendung von DB-spezifischem Escape? Funktionen, und warum war es besser als Addslashes?

    Nichts wirklich. Das ist einfach das Mantra, warum PDO / vorbereitet "besser" sind. Sie sind viel besser als Addslashes , da sie viele Faktoren berücksichtigen, einschließlich der Codierung. Hier ist ein kleines Geheimnis; PDO verwendet sie intern, aber nicht addslashes ...

    [4.] Warum werden vorbereitete Anweisungen mit Frameworks und PDO als Goldstandard gepriesen? von SQL? Warum sind sie besser? Warum kann ich mit diesen keine SQL-Injektion durchführen, wo ich es mit den zuvor genannten Mitteln hätte tun können?

    Sie sind nicht der Goldstandard , sie Sie sind nicht "sicherer" als DB-spezifische Funktionen, und Sie können auch mit diesen SQL-Injection ausführen. Und nein, Sie können keine SQL-Injection mit ordnungsgemäß bereinigten Eingaben durchführen.

    Wie bei allen Technologien neigen Entwickler dazu, religiöse (fanatische?) Tendenzen für etwas "Neues" zu entwickeln. Aus diesem Grund erhalten Sie erfahrene Zend Certified Engineers (TM), die Ihnen raten, nicht zu vorbereiteten Anweisungen zu wechseln.

    Die Realität ist jedoch, dass alles davon abhängt, zu wissen, was Sie tun. Wenn Sie einen Artikel anhand seiner numerischen ID laden, müssen Sie nicht entkommen, noch weniger PDO. Sie müssen lediglich sicherstellen, dass ID tatsächlich eine Ganzzahl ist.

    Aus einer realistischeren Perspektive besteht die allgemeine Regel nicht darin, PDO / vorbereitete Anweisungen zu verwenden, sondern die richtigen Funktionen zu verwenden, dh Sie muss mysql_real_escape_string () anstelle von addslashes () oder mysql_escape_string() verwenden.

    [5.] Kann ein Programmierer das nicht irgendwie noch vermasseln? Worauf sollten sie achten?

    Natürlich! Aber es ist nicht "worauf zu achten ist", sondern "zu wissen, was Sie tun".

    Sie sehen, eval ($ _ GET ['code']) * ist völlig legitim, wenn es an der richtigen Stelle verwendet wird (z. B. bei einem lokalen PHP-Testläufer).

    Wenn Sie ein ORM zum Ausführen einer bedingten Abfrage verwenden, geben Sie Code direkt ein, daher kann es einen geben Chance auf SQL-Injection, wenn Sie es nicht richtig machen (hängt vom jeweiligen ORM ab). (Hypothetisch) Beispiel:

      // update () setzt den Wert einer Spalte unter der Bedingung //// .-- Escape ist hier automatisch // | - hypothetische SQL-Injection // v vDb () - >update ('name', $ _ GET ['neuer Name']) - >where ('id ='. $ _ GET ['id']);  

    (* Ich kann mir nur vorstellen, dass die unzähligen Profis ihren Kopf darüber schlagen)

+1. insbesondere, um auf die Gefahr von APIs hinzuweisen, die parametrisierte Abfragen mit dynamischen Teilen mischen.
Eine nützliche Technik zum Speichern von Webanforderungen oder codierten Daten besteht darin, sie in base64 zu codieren und als Zeichenfolge zu speichern.Es verhindert nicht die SQL-Injection oder fehlerhafte Daten, stellt jedoch zumindest sicher, dass nichts, was eingegeben wurde, unverändert verwendet wird.
#3
+9
rook
2011-05-08 01:25:29 UTC
view on stackexchange narkive permalink

Am Ende des Tages muss die Eingabe maskiert werden, um Ihre Abfragen vor SQL Injection zu schützen. Parametrisierte Abfragebibliotheken wie PDO und ADODB verwenden Escape . Sie setzen diese Vorgehensweise lediglich auf implizit sichere Weise durch. Durch die Einschränkung, dass magic_quotes_gpc NICHT ausführt, ist dies eine grundlegend fehlerhafte Herangehensweise an das Problem.

1) Das Entkommen kann problematisch sein, wenn Sie nicht verstehen, was Sie tun. Diese Art von Problem kann weiterhin ausgenutzt werden, wenn magic_quotes_gpc aktiviert ist.

  mysql_query ("Wählen Sie * von Benutzern aus, bei denen id =". Addslashes ($ _ GET [id]));  

PoC Exploit: http: //localhost/vuln.php? id = sleep (30)

Patch:

  mysql_query ("Wählen Sie * von Benutzern aus, bei denen id = '". fügt Schrägstriche hinzu ($ _ GET [id]). "'");  

Lektion: Sie benötigen keine Anführungszeichen, um die SQL-Injection auszunutzen.

2) Nehmen wir an, Sie entkommen nur Anführungszeichen:

  mysql_query ("Wählen Sie * von Benutzern aus, bei denen name = '". htmlspecialchars ($ _ GET [name], ENT_QUOTES). "' und id = '". htmlspecialchars ($ _ GET [id], ENT_QUOTES). "'");  

PoC Exploit: http: //localhost/vuln.php? name = \ &id = + oder + sleep (30) / *

Patch:

  mysql_query ("Wählen Sie * von Benutzern aus, bei denen name = '". addiert Schrägstriche ($ _ GET [name]). " ($ _GET [id]). "'");  

Lektion : Backslashes sind genauso gefährlich als Anführungszeichen.

3) Was ist mit der Sprachcodierung?

  mysql_query ("SET CHARACTER SET 'gbk'"); mysql_query ("select * from user where name = '". addiert Schrägstriche ($ _ GET [name]). "'");  

PoC Exploit: http: //localhost/vuln.php? name =% bf% 27 = sleep (30) / *

Patch:

  mysql_query ("SET CHARACTER SET 'gbk'"); mysql_query ("Wählen Sie * vom Benutzer aus, wobei name = '". mysql_real_escape_string ($ _ GET [name]). "'") ;  

Fazit:

Escaping ist unbedingt erforderlich, um eine SQL-Injektion in einer Anwendung zu verhindern. In PHP sind PDO und ADOB großartige parametrisierte Abfragebibliotheken, die das Entkommen von Benutzereingaben erzwingen. Das Problem ist, dass viele Programmierer nicht verstehen, was Flucht ist. Eine Bibliothek zur Durchsetzung dieser Sicherheitsrichtlinie ist die beste Verteidigungsmethode, da Sie das Entkommen von Regeln nicht verstehen müssen.

"Escaping ist unbedingt erforderlich, um eine SQL-Injektion in einer Anwendung zu verhindern", das ist einfach falsch. Ein weitaus weniger fehleranfälliger Ansatz als die Verwendung von Escapezeichen besteht darin, parametrisierte Abfragen mit einem konstanten Abfrageteil und allen nicht vertrauenswürdigen Daten in Parametern zu verwenden. Da die Daten niemals Teil der SQL-Abfragezeichenfolge sind, ist kein Escapezeichen erforderlich, und die Datenbank macht genau das Richtige. /// Bitte schlagen Sie nicht vor, Addslashes zu verwenden, da eine PHP-Anwendung für den Zeichensatzangriff anfällig sein kann, auch ohne den Zeichensatz explizit festzulegen, beispielsweise aufgrund von MySQL-Standardkonfigurationen.
So nehmen Sie den mysqli-Treiber als Beispiel: Die Funktion [mysqlnd_stmt_execute_store_params] (http://codesearch.google.com/codesearch/p?hl=de#ceArhxvuL0U/Oem/php/ext/mysqlnd/mysqlnd_ps_code.c&q=m_ 1 & ct = rc) sendet die Parameter als Binärdaten außerhalb der Abfragezeichenfolge an den Server.
@Hendrik Brummermann Welche parametrisierte Abfragefunktion der obersten Ebene (http://php.net/manual/en/book.mysql.php) wird von dieser Funktion unterstützt? Ich denke, Sie irren sich über die Funktionalität dieses Codes. Ich weiß, dass es eine falsche Bezeichnung ist, zu sagen, "Flucht ist schlecht und Sie sollten stattdessen PDO verwenden".
Die zugehörigen Abfragefunktionen auf hoher Ebene, die diese interne Treiberfunktion aufrufen, sind [prepare] (http://www.php.net/manual/en/mysqli.prepare.php), [bind_param] (http: //) www.php.net/manual/en/mysqli-stmt.bind-param.php) und [execute] (http://www.php.net/manual/en/mysqli-stmt.execute.php). In den meisten Fällen verwende ich den Escape-Weg selbst, aber die Verwendung parametrisierter Abfragen ist eine gültige Alternative. Und während es einige Frameworks gibt, die die Parameter in die SQL-Anweisung einsetzen (mit ordnungsgemäßem Escapezeichen), übertragen die Datenbankfunktionen sie zusammen mit der Abfrage.
@Hendrik Brummermann Ich bin sehr skeptisch. Hauptsächlich, weil der [mysqli-Code] (http://codesearch.google.com/codesearch/p?hl=de#ceArhxvuL0U/Oem/php/ext/mysqli/mysqli.c&q=mysqlnd_stmt_execute_store_params&d=3) nicht einmal [call diese Funktion] (http://codesearch.google.com/codesearch?q=mysqlnd_stmt_execute_store_params&exact_package=http%3A%2F%2Fsvn.osgeo.org%2Fmapguide%2Ftrunk%2FMgDev&hl=de)
"Eine Bibliothek zur Durchsetzung dieser Sicherheitsrichtlinie zu haben, ist die beste Verteidigungsmethode, da Sie das Entkommen von Regeln nicht verstehen müssen." - Und deshalb, meine Freunde, versagen wir bei der Sicherheit. Die Wahrheit ist, dass der Programmierer wissen muss, was er tut. ** Nicht wissen ist ein Sicherheitsproblem für sich. ** Die Verwendung von PDO usw. ist wie die Verwendung von OSX. Sie wissen, dass Sie sicher sind, bis genug von Ihnen vorhanden sind, um Hacker dazu zu bringen, ihre Strategie zu überdenken - und wenn dieser Virus ausfällt, ist alles Windows 98 erneut.
@Christian Sciberras Ich stimme zu. Leider sind die Leute, die diese Probleme wirklich verstehen, sehr ungewöhnlich und sehr teuer.
@Rock, Ihre Google-Suche in dieser Datei hat keinen Treffer, da der Aufruf in verschiedenen Dateien verschachtelt ist: mysqlnd_stmt_execute_store_params in mysql_ps_codec.c wird von [mysqlnd_stmt_execute_generate_request] aufgerufen (http://goo.gl/QlqHk) exportierte Methode [mysqlnd_stmt_execute] (http://goo.gl/c9GY4). [mysqli_mysqlnd.h] (http://goo.gl/9e42S) und [mysqlnd_libmysql_compat.h] (http://goo.gl/OnUa7) erstellen die Zuordnung aus den mysql-Funktionen.
@Hendrik Brummermann Und der mysqli-Code verwendet nichts von diesem Rauschen. Wenn Sie sich den mysqli-Code ansehen, baut er eine eigene MY_STMT-Struktur auf, in der durch die einzelnen Parameter * getrennt * von der Rohabfrage übertragen werden kann. Sie haben also teilweise Recht, es gibt eine andere Option als das Escape-Zeichen für MySQL, aber die meisten parametrisierten Abfragebibliotheken verwenden sie nicht. Darüber hinaus gibt es keinen Unterschied in der Sicherheit zwischen diesen beiden Ansätzen, jedoch wird die MY_STMT-Struktur etwas weniger Bandbreite / CPU-Zeit verwenden.
#4
+5
Cut Copy
2011-08-18 02:15:49 UTC
view on stackexchange narkive permalink

Informationen zu den DB-spezifischen Escape-Funktionen. Es gibt viele Szenarien, in denen SQL-Injection auftreten kann, obwohl mysql_real_escape_string () verwendet wurde. LIMIT und ORDER BY sind wirklich schwierig!

Diese Beispiele sind anfällig für SQL-Injection:

  $ offset = isset ($ _ GET ['o'])? $ _GET ['o']: 0; $ offset = mysql_real_escape_string ($ offset); $ sql = "SELECT Benutzer-ID, Benutzername FROM sql_injection_test LIMIT $ offset, 10";  

oder

  $ order = isset ($ _ GET ['o'])? $ _GET ['o']: 'userid'; $ order = mysql_real_escape_string ($ order); $ sql = "SELECT userid, Benutzername FROM sql_injection_test ORDER BY` $ order` ";  

In beiden Fällen können Sie 'nicht verwenden, um die Kapselung zu schützen.

Quelle: Die unerwartete SQL-Injection (wenn das Escaping nicht ausreicht) <-- Lesen Sie diese

#5
+4
atdre
2011-05-06 21:57:56 UTC
view on stackexchange narkive permalink

Filter können umgangen werden und Daten, die in SQL-Anweisungen eingehen, können von mehr Stellen als nur Benutzereingaben stammen. Die Einstiegspunkte in eine von SQL beeinflusste Quelle / Senke können beispielsweise gespeichert werden (höherer Ordnung), aber HTTP-GET-Parameter und POST-Parameter aus HTML-Formularen sind eindeutig nicht die einzigen Möglichkeiten zur Benutzereingabe.

Parametrisierte Abfragen machen Ihre SQL-Anweisungen nicht unbedingt frei von Injektionen. Sie erfordern auch eine variable Bindung, das Entfernen von Zeichenfolgenoperationen / -verkettungen und die Vermeidung bestimmter Sicherheitsprobleme mit einer Vielzahl von SQL-Klauseln.

Die meisten Entwickler vergessen auch, ihre Komponenten von Drittanbietern und andere Abhängigkeiten zu überprüfen SQL-Injection-Probleme, und manchmal ist nicht klar, dass diese Einschlüsse den eigenen Code anfällig machen können.

Am besten beauftragen Sie ein Beratungsunternehmen für Anwendungssicherheit, um Ihre Anwendung (en) auf die Produktionsbereitschaft vorzubereiten und um Ihre Appdev-Teams darin zu schulen, Anwendungssicherheitskontrollen in ihre Prozess- und Entwicklungstechnologie einzubauen.

#6
+3
getahobby
2011-05-07 05:00:29 UTC
view on stackexchange narkive permalink

Um Hendricks Antwort zu erweitern. Es ist leicht, sich real_escape_string als Wundermittel vorzustellen, wenn dies in Wirklichkeit nicht der Fall ist. Ich habe gesehen, dass Leute diese Funktion verwenden, wenn sie intval verwenden oder die Eingabe stattdessen in eine Ganzzahl umwandeln möchten. Sie können immer noch injiziert werden, wenn Sie die Escape-Zeichenfolge im falschen Kontext verwenden.

#7
-3
xlinex
2014-10-09 03:48:51 UTC
view on stackexchange narkive permalink

Da es darum geht, Ihnen zu helfen, das Schreiben von anständigem Code zu lernen und nicht nur ein Rezept zu kopieren, werde ich einige Hinweise hinterlassen.

  • Wenn wir Codierungsmaterial hinterlassen, gibt es solche Viele Möglichkeiten, SQL einzufügen, und nicht alle erfordern das Hinzufügen von "oder 'oder'. Daher ist Addslashes im Grunde eine lahme Lösung, die von lahmen und ungelernten Entwicklern verwendet wird ... (Die, von denen Sie keinen Code lesen sollten).

  • Dies passiert nicht oft, aber es gibt tatsächlich einen Vektor, in dem der Angreifer eine vorbereitete Anweisung in einigen DB-Engines ausnutzen kann. Es ist nicht üblich, aber Sie können sich daran erinnern Die vorbereitete Anweisung verwendet eine Anweisung, jedoch mit dem Spaltentyp der Tabellenmetatdaten, der Größe ....

  • Ein anderer üblicher lahmer Fehler ist die Behandlung von Suchvorgängen in Abfragen mit Likes ..... Wenn Sie finden Wie es funktioniert, können Sie einige interessante Dinge tun ...

Recherchieren Sie, vertrauen Sie niemals einer Eingabe, verwenden Sie niemals etwas anderes als eine vorbereitete Aussage, ignorieren Sie jemanden, der dies tut fordert Sie auf, Escape Fu zu verwenden ...

Und Sie sollten sicher sein e, denken Sie daran, dass es keinen Sinn macht, etwas anderes als das zu bekommen, was Sie erwarten. Eine so stark getippte API ist Ihr Freund;).

Sie müssen diese Antwort bereinigen - Rechtschreibung, Grammatik, ungerade Formatierung - bitte nehmen Sie sich etwas mehr Zeit für Ihre Antworten


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...