Security Frage (XSS)

QUOTE Zu dem Code müsste noch eine Prüfroutine hinzugefügt werden, die darauf achtet, dass niemand versucht aus den Ordner auszubrechen (mittel ../).

Die Routine steht doch da: Das binary-safe php-eigene "quotemeta", daß genau für sowas gedacht ist.
Und ein herausspringen bei i.R aktiviertem open_basedir aus der Domainumgebung ist ebenfalls nicht möglich.


QUOTE Im Grunde reicht es aus, das muss aber nicht urlrawencode lauten, sondern eigentlich urlrawdecode, da habe ich mich leicht versehen (hab's mal eben geändert). Veraussetzung ist natürlich, dass keine Exploits innerhalb PHP selber vorhanden sind.

Trotzdem doppelt gemoppelt.
tongue.gif
Und es ist schwer eine Sprache zu benutzen oder überhaupt einen Server zu betreiben, wenn Du die internen Funktionen aus Angst vor Exploits nicht nutzen willst. Vielleicht wäre dann ja Assembler eher was
 
QUOTE (MarkusH @ So 8.4.2007, 19:53)[...] Und es ist schwer eine Sprache zu benutzen oder überhaupt einen Server zu betreiben, wenn Du die internen Funktionen aus Angst vor Exploits nicht nutzen willst. Vielleicht wäre dann ja Assembler eher was

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




QUOTE (MarkusH @ So 8.4.2007, 19:53)[...] Und ein herausspringen bei i.R aktiviertem open_basedir aus der Domainumgebung ist ebenfalls nicht möglich. [...]

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

QUOTE (Sascha Ahlers @ So 8.4.2007, 13:12)Das hast Du doch erwähnt, es findet aber keine Filterung statt, darum kann sowas wohl funktionieren, wenn es nicht von den Servereinstellungen abgefangen wird.

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




QUOTE (MarkusH @ So 8.4.2007, 19:53)
QUOTE Zu dem Code müsste noch eine Prüfroutine hinzugefügt werden, die darauf achtet, dass niemand versucht aus den Ordner auszubrechen (mittel ../).

Die Routine steht doch da: Das binary-safe php-eigene "quotemeta", daß genau für sowas gedacht 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.
 
QUOTE [...] Und es ist schwer eine Sprache zu benutzen oder überhaupt einen Server zu betreiben, wenn Du die internen Funktionen aus Angst vor Exploits nicht nutzen willst. Vielleicht wäre dann ja Assembler eher was


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


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.
 
QUOTE (MarkusH @ So 8.4.2007, 19:53)
QUOTE Zu dem Code müsste noch eine Prüfroutine hinzugefügt werden, die darauf achtet, dass niemand versucht aus den Ordner auszubrechen (mittel ../).

Die Routine steht doch da: Das binary-safe php-eigene "quotemeta", daß genau für sowas gedacht ist.

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


QUOTE %2E%2E%2Fhurra.html


angibt? Oder zum Klicken:


QUOTE http://beispiel.server-daten.de/tabellen.html%2F%2E%2E%2F


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:

CODE if ( "false" == 0 ) {
echo "wahr";
} else {
echo "falsch";
}

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)!

CODE if ( "false" === 0 ) {
echo "wahr";
} else {
echo "false";
}


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
 
QUOTE http://beispiel.server-daten.de/tabellen.html%2F%2E%2E%2F

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.
 
QUOTE (MarkusH @ So 8.4.2007, 21:31)
QUOTE http://beispiel.server-daten.de/tabellen.html%2F%2E%2E%2F



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

Das Beispiel darüber


QUOTE %2E%2E%2Fhurra.html


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


QUOTE http://irgendeine-domain.de/script.php?file=


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:

CODE <?php
$whitelist = 'a.php';
$datei = 'a.php';
if($whitelist == $datei)
{
require($datei);
}
else
{
die()
}
?>


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.
 
Sie müssen sich einloggen oder registrieren, um hier antworten zu können.
Zurück
Oben