php-resource




Archiv verlassen und diese Seite im Standarddesign anzeigen :
Sammlung von möglichen Sicherheitslücken in PHP gesucht!


 
BananaJo
21-01-2009, 12:06 
 
Hallo,

ich schreibe zur Zeit ein Programm, das sehr sicher sein MUSS!
Und dafür brauche ich alle möglichen Sicherheitslücken die es in PHP gibt...

Also das z.B. PHP_SELF eine sicherheitslücke ist, habe ich gehört.. aber warum ist das so?

Das ist z.B. ein Sache und ich wette es gibt noch ettliche davon, die ich NOCH nicht kenne ;)...

Danke für jede Hilfe!

 
jmc
21-01-2009, 12:19 
 
Warum sollte PHP_SELF eine Sicherheitslücke sein?
Sicherheitslücken einbauen kannst du viele, wenn du willst... aber eine PHP-Sicherheitslücke an sich ist mir beim aktuellen PHP nicht bekannt.

 
ghostgambler
21-01-2009, 12:29 
 
Original geschrieben von jmc
Warum sollte PHP_SELF eine Sicherheitslücke sein?
Per Path-Info kann man da ggf. etwas einschleusen, htmlspecialchars($_SERVER[PHP_SELF]) ist zu empfehlen.

Ansonsten: Eingaben escapen, wenn nötig. Ausgaben escapen, wenn nötig. Google "Sicherheitsücken php". Oder so.

 
fireweasel
21-01-2009, 12:57 
 
Original geschrieben von BananaJo
Hallo,

ich schreibe zur Zeit ein Programm, das sehr sicher sein MUSS!

Verwende kein PHP.
*SCNR*

Und dafür brauche ich alle möglichen Sicherheitslücken die es in PHP gibt...
http://php.net/manual/ listet sie alle auf. ;-)

Nee, im Ernst. Wenn du so kommst:

Also das z.B. PHP_SELF eine sicherheitslücke ist, habe ich gehört.. aber warum ist das so?

... dann solltest du das Schreiben dieses sehr sicheren Programms besser jemanden überlassen, der sich damit auskennt.

Falls du dir das nicht leisten kannst|willst, wären mehr Informationen zum Einsatzbereich des Scripts hilfreich. Sonst bleibts nämlich bei Allgemeinplätzen, wie:
* prüfe alle Eingabedaten (z.B. die superglobalen Arrays) und lasse nur die durch, die du benötigst|verstehst|sicher verarbeiten kannst.
* wandle Daten so um, dass sie in der Zielanwendung (Browserausgabe, Datenbank, etc.) keinen Schaden anrichten können.
* Vermeide PHP-Funktionen, die mit "unerwarteten" Eingabe-Daten nicht umgehen können (wie beispw. parse_url())
* Informiere dich allgemein über Sicherheitsprobleme die bei deinem Projekt auftreten können (bspw. XSS, SQL- und Code-Injections, Directory-Traversal-Attacks, etc. pp.)

Original geschrieben von ghostgambler
Per Path-Info kann man da ggf. etwas einschleusen, htmlspecialchars($_SERVER[PHP_SELF]) ist zu empfehlen.

Es gibt $_SERVER['SCRIPT_NAME'] (http://www.php.net/manual/de/reserved.variables.server.php) für den relativen Pfad zum ausgeführten Script und notfalls $_SERVER['REQUEST_URI'] für die angehängten GET-Parameter. Das sollte für die Freunde des Affenformulars eigentlich ausreichen. ;-)

Und was soll das HTML-Escapen eines Dateipfades bringen?
Dass man (nur) bei der HTML-Ausgabe (für "CDATA") htmlspecialchars() benutzt, ist schon klar -- aber das gilt nicht nur für diese eine Variable ...

 
jmc
21-01-2009, 14:52 
 
Was sollte man den bei PHP_SELF einschleusen können, was jemand anderen oder das interne Script beeinflusst? Kannst du mir ein nachvollziehbares Beispiel nennen? Dass es möglich ist damit eine Sicherheitslücke zu erstellen glaube ich gerne, aber da muss man sich schon ziemlich Mühe geben und die Variable auf eine abartige Weise benutzen, oder etwa nicht?

 
ghostgambler
21-01-2009, 15:00 
 
Nein, XSS-Attacken sind damit ganz einfach möglich.
Per Path-Info lassen sich z.B. Konstruktue wie
/meinephpdatei/aktion/snostwas/
bilden, wobei meinephpdatei eine Datei ohne .php-Endung ist.
Wenn man dann ein switch für aktion mit default macht und überall nur PHP_SELF ausgibt, kann man z.B.
/meinephpdatei/" /><script type="text/html">document.location = "test.htm"</script><
aufrufen, und das im Formular eingesetzt macht dann offensichtlich irgendwas ekliges raus, wenn man nicht htmlspecialchars darauf anwendet.

 
jmc
21-01-2009, 15:07 
 
Die Formulare kannst du ja auch ganz einfach selbst erstellen und abschicken und ausserdem würdest du damit ja wohl nur die Ausgabe bei dir selbst beeinflussen. Was stört es also, ausser dass dîe Anzeige (oder was auch immer), bei dir selbst dadurch fehlerhaft wird?
Bei deinem Beispiel ja wohl nichts.
Und bei der Verarbeitung eines Formulares, von welchem Daten auch für andere Benutzer gespeichert werden oder so muss die Eingabe ja wohl so oder so geprüft/bearbeitet werden, ob PHP_SELF oder nicht macht keinen Unterschied.

 
ghostgambler
21-01-2009, 15:09 
 
Bitte informiere dich darüber was eine XSS-Attacke ist.
Wenn du das getan hast, formuliere eventuell weitere Rückfragen - NACHDEM du das Beispiel mal ausprobiert hast - bitte erneut.

 
jmc
21-01-2009, 15:33 
 
Ich weiss was ne XSS Attacke ist, aber die wirkt sich hier auf niemanden aus, ausser auf den, welcher die Attacke gestartet hat.Damit das bei jemand anderem "irgendwas ekliges ausmacht" müsste man zumindest einige andere Fehler bei der Verarbeitung der empfangenen Daten machen, den interne Fehler entstünden sonst keine und auch keine Ausgabefehler ausser beim Verursacher.
Das selbe gilt bei QUERY_STRING und ä.

 
Kropff
21-01-2009, 18:17 
 
vielleicht ist hier (http://www.peterkropff.de/tutorials/sicher_programmieren/sicher_programmieren.htm) was bei?

peter

 
ghostgambler
21-01-2009, 19:36 
 
Allein schon die Weiterleitung auf eine andere Seite kann bei unbedarften Benutzern ein Sicherheitsproblem sein.

 
jmc
21-01-2009, 20:51 
 
Wer hat etwas von einer Weiterleitung gesagt? Ausserdem wird ja höchstens der Verursacher der Weiterleitung (wenn z.B. javascript mit Absicht in den Query eingefügt) selbst weitergeleitet.

Wenn du mir ein konkretes Beispiel geben kannst, wo nicht nur das der Fall ist und PHP_SELF eine Sicherheitslücke darstellt kannst du mir sehr gerne eines zeigen.

@Peter Kropff -> Ich finde bei deinen Beispielen nur Fehler - die noch etwas mit diesem Thema zu tun haben, welche aufgrund von nicht verarbeiteten Daten, die wiederum anderen Benutzern zur Verfgung gestellt werden, entstehen. Und dass diese Daten geprüft/bearbeitet werden müssen ist ja wohl so oder so klar, aber das hat eigentlich nichts mit dem Gebrauch der variable $_SERVER['PHP_SELF'] zu tun.

 
ghostgambler
21-01-2009, 21:48 
 
Original geschrieben von jmc
Wer hat etwas von einer Weiterleitung gesagt? Ausserdem wird ja höchstens der Verursacher der Weiterleitung (wenn z.B. javascript mit Absicht in den Query eingefügt) selbst weitergeleitet.
Hast du dir mein Beispiel überhaupt mal angesehen? Geschweige denn ausprobiert (oder auch wenigstens nur verstanden)?!
Sagt dir der Begriff Phishing etwas?

Wenn du das Potential der Attacke nicht erkennen vermagst, und das selbst erkannt hast, arbeite an deinem Wissen. Wenn du der Meinung bist das ist vollkommen irrelevant und ungefährlich, soll mir auch recht sein.

 
CadEx
23-01-2009, 13:14 
 
Sprachunabhängige Sicherheitslücken sind deutlich häufiger. Du suchst ganz bestimmt die.

Kurz: http://www.sans.org/top25errors/
Details: http://cwe.mitre.org/top25/

edit: BananaJo, spielst du Q3?

 
phpguru42
25-01-2009, 13:52 
 
Original geschrieben von jmc
Wer hat etwas von einer Weiterleitung gesagt? Ausserdem wird ja höchstens der Verursacher der Weiterleitung (wenn z.B. javascript mit Absicht in den Query eingefügt) selbst weitergeleitet.
Du hast XXS nicht ganz verstanden. Die manipulierte URL kann Dir z.B. per E-Mail geschickt werden, bei einer HTML-Mail siehst Du das nichtmal.

Hier ist auch noch ein "nettes" Beispiel:

http://blog.oncode.info/2008/05/07/php_self-ist-boese-potentielles-cross-site-scripting-xss/

Wenn das ein Login-Formular wäre, hätte der Angreifer die Zugangsdaten Deines Kontos.

 
jmc
25-01-2009, 14:52 
 
Doch habe ich. Du hast nicht genau gelesen.
Die Daten die weiterverarbeitet werden (dazu gehört auch ein Verschicken der E-Mail) müssen natürlich überprüft/bearbeitet werden, aber das ist das Selbe wie mit allen anderen Daten auch (GET, POST oder was auch immer). Jedoch bei einer direkten ausgabe schadet es niemandem. Wenn du sagst PHP_SELF ist ne Sicherheitslücke, dann sind es $_GET, $_POST und weitere ebenfalls. Die einzige Sicherheitslücke hier, die entstehen kann, liegt an unachtsamer/fehlerhafter Weiterverwendung der von Client gesendeten Daten nicht an der Verwendung von PHP_SELF!


Alle Zeitangaben in WEZ +2. Es ist jetzt 04:38 Uhr.