Deutsch
Deutsch
Bei Verwendung von PHP für MySQL -Datenbankvorgänge verwenden Entwickler häufig verwandte Funktionen in der MySQLI -Erweiterung, um Abfragen und Prozessergebnisse auszuführen. Beispielsweise kann MySQLI_Query () mit mySQLi_Result -Objekt verwendet werden, um die Abfrageergebnisse leicht zu erhalten. Wenn die Eingabeparameter jedoch beim Erstellen von SQL -Anweisungen nicht ordnungsgemäß verarbeitet werden, ist es einfach, SQL -Injektionsprobleme zu verursachen, was zu abnormalen Abfragenergebnissen, Datenlecks und sogar Systemverlust führt.
Nehmen wir an, Sie haben eine Seite, auf der die Benutzerinformationen von Querys wie folgt lautet:
<?php
$conn = new mysqli("localhost", "root", "password", "mydb");
$username = $_GET['username']; // Von Benutzereingaben
$sql = "SELECT * FROM users WHERE username = '$username'";
$result = $conn->query($sql);
if ($result && $result->num_rows > 0) {
while ($row = $result->fetch_assoc()) {
echo "Benutzer: " . $row["username"] . "，Post: " . $row["email"] . "<br>";
}
} else {
echo "未找到Benutzer";
}
$conn->close();
?>
Wenn der Benutzer die folgende URL eingibt:
https://m66.net/user.php?username=admin' OR '1'='1
Dann wird die SQL -Anweisung:
SELECT * FROM users WHERE username = 'admin' OR '1'='1'
Dies wird die Authentifizierungsbedingung umgehen und Datensätze für alle Benutzer zurückgeben.
Bei Verwendung des Objekts von MySQLI_Result zur Verarbeitung des Ergebnissatzes hängt die zurückgegebenen Daten vom Ausführungsergebnis der SQL -Anweisung ab. Wenn der Erklärung illegale Bedingungen injiziert wird, was zu dem Ergebnissatz mit unerwarteten Daten führt, wird die Programmlogik voreingenommen:
Fehlurteilsbedingungen : Wie im obigen Beispiel stellt die Logik fest, dass $ result-> num_rows> 0 wahr ist, aber tatsächlich können die zurückgegebenen Daten alles sein.
Datenleck : Angreifer können Bedingungen erstellen, um die Datenschutzinformationen anderer Benutzer zu lesen.
Verwirrte nachfolgende Operationen : Wenn Sie weiterhin Erlaubnisurteile abgeben, Datensätze und andere Vorgänge basierend auf den Ergebnissen ändern, werden die Konsequenzen noch schwerwiegender sein.
Die SQL -Injektion kann durch Verwendung von Prepe () und Bind_param () vollständig verhindert werden:
<?php
$conn = new mysqli("localhost", "root", "password", "mydb");
$username = $_GET['username'];
$stmt = $conn->prepare("SELECT * FROM users WHERE username = ?");
$stmt->bind_param("s", $username);
$stmt->execute();
$result = $stmt->get_result();
if ($result && $result->num_rows > 0) {
while ($row = $result->fetch_assoc()) {
echo "Benutzer: " . $row["username"] . "，Post: " . $row["email"] . "<br>";
}
} else {
echo "未找到Benutzer";
}
$stmt->close();
$conn->close();
?>
Nach Verwendung von Vorverarbeitungsanweisungen werden die Parameter automatisch entkommen und überprüft, wodurch die Injektion von der Quelle verhindert wird.
Obwohl es die Vorverarbeitung nicht ersetzen kann, sollten alle Benutzereingänge als Ergänzung zur Sicherheitsgarantie der erforderlichen Überprüfung unterliegen. Zum Beispiel:
$username = filter_input(INPUT_GET, 'username', FILTER_SANITIZE_STRING);
Oder benutzerdefinierte Filterlogik, um illegale Zeichen und Schlüsselwörter abzulehnen.
Um wiederholte Fehler von Entwicklern in verschiedenen Modulen zu vermeiden, wird empfohlen, die Datenbankzugriffslogik in eine einheitliche Klasse oder Funktion zu integrieren, die Vorverarbeitung immer intern zu verwenden und das Spleißen von SQL -Anweisungen zu verbieten.
MySQLI_Result selbst verursacht keine SQL -Injektionsprobleme, aber wenn sie mit nicht entzündeten SQL -Aussagen verwendet wird, wird es im Abfragestadium schwerwiegende versteckte Gefahren darstellen. Solange die Eingabe von Benutzern beteiligt ist, unabhängig davon, wie harmlos der Abfragebetrieb sein mag, müssen Vorverarbeitungsanweisungen verwendet werden.
Denken Sie daran: ** Vertrauen Sie keine Eingaben, auch wenn es sich nur um einen Benutzernamen handelt. ** In Online -Diensten wie M66.net sind die Daten zumindest abnormal und der Systemabsturz und der Datenverlust im schlimmsten Fall abnormal.
Es ist eine unerschütterliche Verantwortung für jeden PHP -Entwickler, angemessene Schutzmaßnahmen zu ergreifen und die SQL -Injektion von der Codeebene zu beseitigen.
