Über 1800 Aufrufe meiner Webseite Hacker-Versuch?

[dedlfix]

Tach!

In den SQL-Kommandos werden die Daten mit addslashes behandelt.

Das war, ist und wird niemals keine gute Idee (sein). Verwende

• mysqli_real_escape_string richtig

Für die Sicherheit von SQL-Statements bleibt es sich gleich, wenn man mit ASCII-basierter Zeichenkodierung arbeitet.

Die zusätzliche Funktionalität von mysqli_real_escape_string() ist die Beachtung von Zeichenkodierungen, was nur bei einigen "exotischen" Kodierungen wichtig ist. Und es behandelt zusätzlich die Zeichen \n, \r und Ctrl-Z, aber die spielen für SQL-Statements keine Rolle.

Zitat MySQL-Handbuch

• Characters encoded are , ', ", NUL (ASCII 0), \n, \r, and Control+Z. Strictly speaking, MySQL requires only that backslash and the quote character used to quote the string in the query be escaped. mysql_real_escape_string() quotes the other characters to make them easier to read in log files.

Sie sind nur für Logfiles interessant, und das nicht einmal aus Sicherheitsaspekten. Wenn man diese nicht auswertet oder gar nicht eingeschaltet hat, ist es auch egal, ob da zuviele Zeilenumbrüche drin stehen.

Es bleibt sich also gleich, ob man die notwendigen Backslash- und Quote-Zeichen mit mysqli_real_escape_string(), mit addslashes() oder einer beliebigen anderen Funktion maskieren lässt. Wichtig ist nur, dass es korrekt angewendet wird. Das ledigliche (Nicht-)Auftauchen von mysqli_real_escape_string() im Code ist kein Zeichen für fehlende oder enthaltene Sicherheit.

• oder prepared statements

Damit umgeht man die Notwendigkeit des Maskierens, aber auch das muss korrekt verwendet werden. Sprich: alle variablen Werte müssen durch den Prepared-Statements-Mechanismus gehen (oder anderweitig beachtet werden).

dedlfix.