Das habe ich nicht behauptet, dreh mir meine Wörter nicht im Mund um, das kann ich im Moment überhaupt nicht leiden!

Das ist mir durchaus bewusst, les mal etwas weiter oben.

Trotzdem kann dann noch immer in andere Ordner der Anwendung gesprungen werden, was auch nicht unbedingt ungefährlich ist.

Hmm, das ist mir neu, das war sie jedoch nicht immer:
http://web.archive.org/web/20050831174532/...n.quotemeta.php
Ich glaube das war sogar letztes Jahr noch anderes.

Es lag nicht in meiner Absicht, Dir Deine Worte zu verdrehen. Der Sinn der zusätzlichen decodierung erschließt sich mir trotzdem nicht, da doch ein String-Abgleich stattfindet. Ist mit aber auch wurscht, denn ich stimme ja zu, daß eine whitelist bzw. Dein Mapping oder ein Ähnliches wohl das sicherste System ist.

Was soll 'quotemeta' nutzen, wenn jemand eine Url in der Form

angibt? Oder zum Klicken:

man landet auf der Startseite, nicht auf der Unterseite

Und dieses Problem ist alles andere als trivial. Bei Microsoft gab es damals Bugs, wo in solchen Strings, die natürlich keinen '.' mehr enthalten, zusätzlich das Prozentzeichen noch über eine andere Technik codiert wurde.

Das Problem ist in solchen Fällen, daß die Systemfunktion include usw. bsp. im Rahmen eines Versionsupdates erweitert wird und deshalb plötzlich solche Zeichenketten korrekt auflöst, die früher unaufgelöst geblieben sind. Sprich: Ein Versionsupdate erzeugt einen neuen Bug.

Man kann auch die Daten als UTF-16 übergeben und dort jedes Byte nach so einer Methode codieren.

Neulich hatte mal jemand einen Link gepostet, wie man in mySql über eine entsprechende Codierung das ' so maskiert, daß es von den üblichen Schutzmechanismen gegen Sql-Injektionen nicht gefunden wird, im Sql-Code jedoch trotzdem seine Wirkung entfaltet. Dies hier sind analog tiefgreifende Probleme, nur daß man diese nicht - wie bei Sql-Injektionen - durch den Übergang zum kompilierten Code mit Parameterübergabe umgehen kann, wie ich das in meinem sehr großen System mache.

Mal ein schönes Beispiel:

Die Ausgabe wird hier wahr ausgeben, obwohl es von der Programmierlogik eigentlich falsch sein sollte. Damit dieses Konstrukt funktioniert, muss damit so umgegangen werden - wobei es nur den richtigen Wert gibt, weil die Typen unterschiedlich sind (String und Interger)!

Darum sage ich bei Sicherheitsfragen lieber, wenn kein Exploit existiert.


So sollche sich auch auf open_basedir nicht unbedingt 100% verlassen werden, darauf weißt Stefan Esser hin.


@jAuer:
Schöne Erklärung.
Bei Wordpress gab es bspw. auch mal SQL-Injektions über Trackbacks, weil diese mit UTF-7-Kodierung verschickt wurden [1]. Zeichenkodierungen sind ein wirklich unüberschaubares Problem, was viele leicht übersehen oder verkennen.



[1] PHP-Hardened: Advisory 02/2007: WordPress Trackback Charset Decoding SQL Injection Vulnerability

Bearbeitet von Sascha Ahlers am So 8.04.2007, 20:54

Das ist eine Sache zwischen Browser und Server oder hast Du hier gerade eine Schwachstelle in Deiner Software gezeigt?

Das Ergebnis in PHP lautet ungefiltert file_exists('tabellen.html%2F%2E%2E%2F') und das ist false. Wenn es dann übersetzt ist, greift wieder quotemeta.

Mich würde aber wirklich mal ein String interessieren, der für solche Angriffe benutzt werden kann und zum Beispiel ein "../" faked, daß auch in einen include oder file_exists passt.

Das Beispiel ist ja auch bloß für den Browser, zum Klicken.

Das Beispiel darüber

wäre etwas, das man zum Injizieren testen könnte. Und spätestens dann, wenn das mit einer Url der Form

verknüpft wird, erzeugt %2E einen Punkt und stellt insgesamt eine gültige Zeichenfolge dar.

Ob das PHP auch beim relativen Testen in bezug auf das Dateisystem macht, weiß ich nicht.

Aber das ist ja gerade das Problem: PHP macht es vielleicht heute nicht - und morgen macht es das, im Rahmen eines Updates zur besseren Unterstützung von Sonderzeichen.

So, ich habe es jetzt einfach mal so gelöst:

Ist es so OK oder kann man auch hier ausbrechen? Wenn ja, wie?

Ich wüßte nicht, wie man aus einem Vergleich mit Elementen einer Whitelist ausbrechen könnte.

Denn das sind nur noch Stringvergleiche, die liefern ein eindeutiges Ergebnis. Ich prüfe bei den Aufrufen von Ausgabeseiten (da werden ab und an nicht existente PHP-Seiten aufgerufen als Versuch, die zu hacken) auch, ob dieser Kunde eine solche Ausgabeseite definiert hat - das sind analoge Stringvergleiche über die Datenbank. Und gibt es die Seite nicht, wird ein 404 zurückgeliefert - bei dir ein die().

Sprich: Das ist ok.