Verwunderung über QB_SECURE_MYSQL_PARAM

Diese QuiBui-Funktion zieht Kreise und erzeugt in vielen Foren durchweg negative Reaktionen Verwirrung: Das ding schaut krausig aus
, „QB_SECURE_MYSQL_PARAM“ WTF??? Woher hast du das?, meine Funktion irgendwie auf meinem Server nich funzt.

Es ist für mich interessant, diese Entwicklung zu sehen. Leider scheint noch eine obfuszierte (schwer leserlich gemachte) Version im Umlauf zu sein, wie ich sie heute nicht mehr publik machen würde. Daher hier der Code der Funktion, in Klartext:
<br />
<?php
function QB_SECURE_MYSQL_PARAM($param_ = '') {
    if (get_magic_quotes_gpc()) {
        $param_ = stripslashes($param_);
    }
    $param_ = mysql_real_escape_string($param_);

    return $param_;
}
?><br />


Wie die Skeptiker sehen können, entspricht das dem, was in diesen Foren sowieso empfohlen wird. Der Vorteil beim Einsatz der Funktion besteht darin, dass mit einem Sicherheitsupdate auch der Schutz automatisch wieder verbessert wird. Verwendet man an allen nötigen Stellen direkt die PHP-eigene „mysql_real_escape_string“ so ist eine spätere Änderung nur mit erheblichen Aufwand möglich.

Was sollte man an diesen überall empfohlenen Code ändern wollen?

Nun, die Schwächen dieser einfachen Kapselung sind unter anderem:

1. „stripslashes“ macht auch Strings kaputt, die gar nicht geändert werden sollen. Zum Beispiel: „DOMAIN\username“ oder „c:\windows\“. Daraus wird: „DOMAINusername“ und „c:windows“.
2. „mysql_real_escape_string“ schützt gegen SQL-Injections, weil es einige wenige Zeichen maskiert. Wird das maskierte Ergebnis aber ohne umschließende Hochkommas in die SQL eingefügt, ist der ganze Schutz dahin. Dann kann z.B. anstatt eines Nutzernamens, die Datenbank mit langen „blind SQL-Injections“ verlangsamt oder Tabelleninhalte ausgelesen werden. Dagegen kann man sich etwas schützen, wenn man die erlaubte Eingabe etwas genauer definiert: Eine Zeichenkette oder eine Zahl? Wie lang/groß sollte es mindestens und höchstens sein?
3. „mysql_real_escape_string“ benötigt eine Datenbankverbindung. Es gibt kein Fallback nach „mysql_escape_string“ falls die Verbindung zur DB erst später im Skript aufgebaut wird.

Die Lösung dieser Probleme heißt „SEQ_MYSQL“ und kommt mit der PHP SSEQ-LIB – Sicherheitsbibliothek. Ich empfehle daher denjenigen, die ihre Skripte schützen wollen aber nicht recht was davon verstehen, diese Funktion zu verwenden.

SEQ_MYSQL verwenden

1. Zuerst muss die PHP SSEQ-LIB – Sicherheitsbibliothek heruntergeladen und auf dem Server kopiert werden.
2. Die Bibliothek im Skript einbinden: include_once(’sseq-lib/seq_lib.php‘);
3. SEQ_MYSQL aufrufen: $username_clean = SEQ_MYSQL($username, ‚STR‘, 3, 20);

SEQ_MYSQL Parameterliste