nicht angemeldet
Tach!
$db = mysqli_connect('xxx', 'xxx', 'xxx', 'xxx') or exit;
Findest du es für Benutzer sonnvoll, bei einem Datenbankfehler die Arbeit sang- und klanglos einzustellen?
if(!empty($_POST['input1']))
{
$benutzer = htmlspecialchars($_POST['input1']);
}
Hast du hier einen HTML-Kontext vorliegen? Ich meine jetzt, nicht erst irgendwann später. Sieht nicht so aus, also ist an der Stelle das htmlspecialchars() falsch.
$input1sql = mysqli_real_escape_string($db, $benutzer);
Zusätzlich dazu habe ich folgende Codezeile eingegeben, um zu testen, was mysqli_real_escape_string verändert:
echo $benutzer . '<br />' . $input1sql;
Jedoch zeigen beide Variablen das Gleiche ein, egal was ich eingebe. Ich habe es mit der Eingabe: testnutzer" OR 1 OR " versucht. Der echo ergab zwei identische Strings. Wie sicher ist der Code?
Nun, dein fehlerhaftes htmlspecialchars() hat die " zu " verwurstet. " enthält kein Zeichen, das von mysqli_real_escape_string() verändert wird. Du schaust dir beides im Browser an, und da kein HTML-Element geöffnet ist, in dem " eine Bedeutung hätte, zeigt der die " an, und aus dem " macht er auch wieder ein ". Damit sieht beides gleich aus. Ein Blick in die Quelltextansicht oder die Ausgabe mit var_dump() hätte Unterschiede aufgezeigt. Bei var_dump() hätte die unterschiedliche Stringlänge auffallen müssen, auch wenn das Anzeigeergebnis dasselbe gewesen wäre, weil wieder das " vom Browser weginterpretiert wird.
Derzeit habe ich noch nicht durchblickt, wie prepared Statements funktionieren. Bringt das deutlich mehr Sicherheit für die Abfrage?
Damit kann aus Prinzip keine SQL-Injection erfolgen, weil Code und Daten getrennte Wege gehen - wenn du sie konsequent einsetzt und nicht an ihnen vorbei variable Codeteile in die Query einsetzt.
dedlfix.