MySQL-Injection mit PEAR::DB::escapeSimple()

[Mik3e]

Hi Zusammen,

Wie (hoffentlich) jeder weiß, müssen DB Abfragen vor dem Ausführen vor Injection geschützt werden. Zu diesem Thema gibt es schon massig Beiträge im Forum.

Arbeitet man ohne dem PEAR :: DB Abstraction Layer, wird ja meistens [phpf]mysql_real_escape_string[/phpf] und ähnliches zum "escapen" der Strings genutzt.

Ich arbeite jedenfalls mit der PEAR :: DB Klasse und habe dort die Methode escapeSimple() gefunden.

Diese zu verwenden ist natürlich wesentlich eleganter als wieder nicht abstrahierte Teile für die DB Funktionen reinzumischen.

Meine Frage:
Nach ersten Tests funktioniert diese Methode wunderbar, allerdings verunsichert mit das Wörtchen "...simple()" im Funktionsnamen ein wenig. Hat irgendjemand schon Erfahrung mit dieser Methode? Ist sie wirklich sicher?

Ich hoffe hier gibts ein paar PEAR User (ein eigenes Forum dafür gibts hier ja leider nicht).
Danke vorweg & Ciao,
Mike

 

[hpvw]

Ich zitiere mal:

class DB_common extends PEAR 
{
//...
    function escapeSimple($str)
    {
        return str_replace("'", "''", $str);
    }
//...

class DB_mysql extends DB_common
{
//...
    function escapeSimple($str)
    {
        if (function_exists('mysql_real_escape_string')) {
            return @mysql_real_escape_string($str, $this->connection);
        } else {
            return @mysql_escape_string($str);
        }
    }
//...

Du musst also vorher noch möglicherweise übergebene Backslashes in Abhängigkeit von [phpf]get_magic_quotes_gpc[/phpf] mit [phpf]stripslashes[/phpf] entfernen, bevor Du diese PEAR-Funktion nutzt. Damit hast Du gegenüber der Anwendung von [phpf]mysql_real_escape_string[/phpf] nur noch den Vorteil, dass Du nicht selbst die PHP-Version prüfen musst.

Gruß hpvw

 

[Mik3e]

Hi,

War ja klar das Du mir antwortest )
Die Klasse zerlegen wollte ich nicht, habe gehofft jemand hat Erfahrung damit.. Danke jedenfalls für die Mühe...

Denkst Du, dass Backslashes auch ein ernstes Problem sind? Hochkommata ist klar, aber Slashes? Mir fällt im Moment keine dynamische Abfrage ein, die Probleme bereiten würde...

Ciao,
Mike

 

[hpvw]

Die Klasse zerlegen wollte ich nicht, habe gehofft jemand hat Erfahrung damit.. Danke jedenfalls für die Mühe...

Zerlegen ist gut, einmal im Editor öffnen und nach escape suchen, ist ja noch nicht zerlegt.

Denkst Du, dass Backslashes auch ein ernstes Problem sind? Hochkommata ist klar, aber Slashes? Mir fällt im Moment keine dynamische Abfrage ein, die Probleme bereiten würde...

Ein Backslash "escaped" meines Wissens auch ein Hochkomma. Es könnte also dafür sorgen, dass das Query fehlerhaft wird, da z.B. der Char nicht abgeschlossen wird. Was auf Grund eines fehlerhaften Querys passiert, entscheidet sich in Deinem Skript.
Ein weiteres Problem kann auftreten, wenn maskierte Strings erneut maskiert werden und so Backslashes in der DB landen, die so nicht eingegeben wurden. Aus einem Zeilenumbruch (\n), der maskiert ankommt (\\n), werden durch erneutes Maskieren vier Backslashes und ein n der Datenbank übergeben (\\\\n). Beim Abfragen kommt dann \\n heraus, was nicht zu dem Zeilenumbruch wird, den Du eintragen wolltest.
Die Sicherheitsprobleme sind aber wohl eher theorethischer Natur, da auch die bereits escapen Zeichen erneut escaped werden.

Gruß hpvw

 

[Mik3e]

Da hast Du recht...
Verdammt... ich hab nun in meinem Übereifer sämtliche meiner Methoden aktualisiert und $this->_db->escapeSimple(xxx) eingefügt.

Jetzt kann ich wohl ne neue Methode schreiben die die bestehende überlagert und stripslashes() enthält... Aber ich möchte ehrlich gesagt nicht die bestehenden PEAR Klassen ändern. Ein Update und alles ist wieder weg...

Hast Du ne Idee wie man das lösen kann außer ne eigene Funktion zu schreiben und alle Statements zu korrigieren?

Danke & Ciao,
Mike

P.S. "Zerlegt" war zugegeben übertrieben. Übrigens: Die MPTT Sache läuft noch immer sehr fein ). Und was ich noch gefunden hab (da wir mal über Zeitzonen geschrieben haben): [phpf]date_default_timezone_set[/phpf] ab version 5.1.2 brauchbar...

 

[hpvw]

Hast Du ne Idee wie man das lösen kann außer ne eigene Funktion zu schreiben und alle Statements zu korrigieren?

Was Dir helfen könnte, ist "vollautomatisch" die übergebenen Variablen $_POST, $_GET, etc. von Backslashes zu befreien. Vielleicht sorgt PEAR da ja ohnehin für, dann wäre die Implementation von escapeSimple ja durchaus sinnvoll.

Eine eigene Funktion macht ja auch nur bedingt Sinn, da nicht alle ins Query einfließenden Variablen vom User übergeben sein müssen. Außerdem müssen Backslashes ja nur entfernt werden, wenn die PHP-Konfiguration auch welche hinzugefügt hat.

Und was ich noch gefunden hab (da wir mal über Zeitzonen geschrieben haben): [phpf]date_default_timezone_set[/phpf] ab version 5.1.2 brauchbar...

Interessant, allerdings habe ich 5.1.* gerade wieder durch 5.0.3.3 ersetzt und Online ohnehin wenig Einfluss auf die Version. Ich merk's mir für die Zukunft.

Gruß hpvw