Hallo,

ich beschäftige mich gerade mit der Sicherheit von PHP-Anwendungen und habe folgenden Code aus einem Buch:

Es geht hier darum, serverseitiges Cross-Site-Scripting durch URL-Injection zu verhindern.
Im obigen Beispiel sollen nur die dateien "a", "b" oder "c" eingebunden werden dürfen (eine whitelist), andernfalls die().

Es funktioniert aber so nicht ( die() ).

Es gibt natürlich die Dateien a.php etc.
Muss ich für 'skript noch irgendetwas einsetzen oder ist es dort an der richtigen Stelle?

Irgendwie stehe ich auf dem Schlauch.

Hat keiner eine Idee?

was ist die Fehlermeldung?

und probier mal die();

Ich kenne mich mit PHP nicht wirklich aus, von daher schweige ich bei solchen Dingen lieber.

Auf die Entfernung fällt mir zu dem Code ein:

$_GET['skript'] vor der Prüfung einmal ausgeben lassen (mit umgebenden Dummy-Buchstaben), um zu sehen, was tatsächlich übergeben wird.

Eine Funktion ist nicht definiert (in_array?) Ist es legitim, require an so einer Stelle einzufügen?

Da die Adressierung auf die Datei relativ ist: Stimmt das? Sprich: Davor irgendeine Testüberprüfung rein, ob die Datei existiert bzw. sich einmal den aktuellen Pfad ausgeben lassen.

Um diesen Angriff zu vermeiden, nutze ich immer folgende moeglichkeit.
Evtl. hilft es dir ja etwas

MfG
GP

Mir geht es ja darum, die GET-Variable nicht ungeprüft zu nutzen. In deinem Fall sieht es irgendwie nicht so aus. Weiter nutze ich lieber "require" um Dateien einzubinden, der Sicherheit wegen.

die(); bringt eine Fehlermeldung (weiss grad nicht welche, mein lokaler Server läuft bei aktiver Internetverbindung nicht).

Schau mich mal im PHP-Forum um. Danke euch.

in diesem Fall wird die Get Variable ueberprueft
Die Whitelist sind in diesem Fall alle mit "abc_" beginnenden php Dateien in einem vorher fest bestimmten Ordner, welcher per $root festgelegt wird.
Meiner Meinung nach eine recht sichere und sehr leichte Methode (ich lass mich aber gerne eines besseren belehren)

Ob du include oder require verwendest ist dabei erst einmal irrelevant. Ob require sicherer ist als include wage ich aber zu bezweifeln

MfG
GP

Das erklär mir bitte mal, warum das sicherer sein soll?
Ich würde hier eher ein include, als ein require, benutzen, besonders da ich mit PHP 3 angefangen habe:

Na na, da kann man draus ausbrechen, der Programmcode von Dir ist keinesfalls sicher! Auch wenn Du mit $root einen Ordner festlegest, gibt es die Möglichkeit mit /../ ggf. daraus auszubrechen. Auch könnten Exploits genutzt werden, welche Sonderzeichen oder andere Zeichenkodierungen nutzen.

Mal angenommen dein Script-Folder ($root) ist folgender:
http://www.domain.com/php/cms/scripts/

und dort hats Dateien mit den namen abc_dosomething.php und abc_xyz.php.

$_GET['page'] setze ich auf ../../user-uploads/abc_myupload.jpg oder sogar ../../user-uploads/abc_myupload.php (wenn das erlaubt ist). Das hat nichts mehr mit XSS zu tun, sondern ist ein schwerwiegendes Sicherheitsloch.

PS: Hab grad gesehen, dass "Sascha Ahlers" die Sache auch schon beantwortet hat .

Das ist sogar noch schlimmer, da ist auch noch DNS-Spoofing möglich.


Ich würde es eher so schreiben:

Alternativ kann die $_GET['skript'] auch wieder in sich gespeichert werden, wenn man die Isolation zu anderen Variablenen beibehalten möchte, dazu muss diese aber ggf. deklariert werden, wenn dies noch nicht geschehn sein sollte.

Bearbeitet von Sascha Ahlers am So 8.04.2007, 17:22

Ok, ich habe vergessen zu erwaehnen das nur Dateien aus dem bestimmten Ordner geladen werden koenne, daher ist eine moeglichkeit ala ../ ausgeschlossen.
Aber das mit den Sonderzeichen ist richtig. Danke fuer den Hinweis. Ich werd es gleich einmal ueberarbeiten.

MfG
GP

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.

Weil "require" sofort das gesamte Script abbricht und nicht wie "include" nur den fehlerhaften Teil.

Werd deine Ausführung gleich mal mal testen, danke!

Hallo,

ich finde die Ursprungsversion ist doch ziemlich gut. Was kann denn da passieren bzw fälschlicherweise oder boshafterweise eingebunden werden? Eine Whitelist ist ja so ziemlich das schärfste was geht; zumindest kurz nach einem (Parameter-Mapping).

Die Version von GP benutze ich so ähnlich auch, allerdings mit Sonderzeichenmaskierung

@Sascha: Welchen Sinn macht es, den Get-String erst nochmal zu encoden und ihn dann mit einer Whitelist abzugleichen? Reicht nicht der Abgleich mit der Whitelist? Wenn der übergebene Wert "a" lautet, und "a" in der Whitelist zu finden ist und somit "a.php" eingebunden wird, was kann dann noch anderes im Get-String stehen, das gefährlich wäre?

Nur sie funktioniert so nicht??!! Leider!

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. Grundsätzlich finde ich aber solche Ansätze zum Einbinden von Dateien schrecklich, ich schreibe Dateieinbindungen lieber nicht mittels übergebener Variable nieder. Lieber in dieser Form:

Von GPs Version würde ich aber ausdrücklich abraten, entweder direkt darauf achten, dass wirklich nur Dateien in den Ordner aufgerufen werden können oder mit einer Whitelist arbeiten. Es ist sonst sehr einfach möglich daraus auszubrechen. Zu dem Code müsste noch eine Prüfroutine hinzugefügt werden, die darauf achtet, dass niemand versucht aus den Ordner auszubrechen (mittel ../).
Eine Prüfung von file_exists ist schön, ist aber nicht ganz sauber, außerdem lässt sich das einfacher regulieren.
Auf Wunsch schriebe ich dies auch mal etwas ausführlicher in mein Blog nieder, wie man dieses herausspringen verhindern kann.

Von solchen Codes würde ich grundsätzlich die Finger lassen.

Bei diesem Problem - relative Adressen in erlaubte absolute Adressen umrechnen - haben sich bereits einige größere Firmen die Finger dran verbrannt. Bei Microsoft gab es raffinierteste Hacks, die bsp. Unicode-Mehrfachcodierungen von ../ nutzten, die von der aufgerufenen Systemfunktion automatisch korrekt decodiert werden, bei denen die Suche nach ../ aber erfolglos bleibt.

Sprich: Man muß alle Fälle kennen, wie eine Systemfunktion wie 'include' relative Adressen entgegennehmen kann. Und da gibt es in der Regel mehr als nur das, was offenkundig ist. Und übersieht man eine Möglichkeit, dann kann das eine Lücke erzeugen.

Sprich: Whitelist und sonst nichts.

Drum schriebe ich ja auch:

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.

Trotzdem doppelt gemoppelt. 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