Comments on: Directory Traversal kurz erklärt http://burnachurch.com/71/directory-traversal-kurz-erklaert/ Zucht und Ordnung from hell Sat, 31 Jul 2010 16:40:42 +0000 http://wordpress.org/?v=2.7 hourly 1 By: Arno http://burnachurch.com/71/directory-traversal-kurz-erklaert/#comment-1797 Arno Wed, 03 Jun 2009 22:46:18 +0000 http://burnachurch.com/?p=71#comment-1797 Das ist allerdings auf manche Dateien nicht möglich. Gerade auf manche Systemdateien benötigt jeder Benutzer Leserechte, <tt>/etc/passwd</tt> ist ein Beispiel hierfür. Das ist im übrigen auch der Grund, dass halbwegs moderne Linux-Distributionen das Passwort selbst nicht mehr da ablegen, sondern in <tt>/etc/shadow</tt>. Das ist allerdings auf manche Dateien nicht möglich. Gerade auf manche Systemdateien benötigt jeder Benutzer Leserechte, /etc/passwd ist ein Beispiel hierfür. Das ist im übrigen auch der Grund, dass halbwegs moderne Linux-Distributionen das Passwort selbst nicht mehr da ablegen, sondern in /etc/shadow.

]]> By: michi7x7 http://burnachurch.com/71/directory-traversal-kurz-erklaert/#comment-1796 michi7x7 Wed, 03 Jun 2009 14:54:05 +0000 http://burnachurch.com/?p=71#comment-1796 Hier sollte noch gesagt sein, dass das Dateisystem mit den Benutzerrechten von Haus aus eine gute Möglichkeit zur Zugriffsbeschränkung bietet. Hierzu muss nur verhindert werden, dass Apache als wwwrun auf die Verzeichnisse zugreift. Hier sollte noch gesagt sein, dass das Dateisystem mit den Benutzerrechten von Haus aus eine gute Möglichkeit zur Zugriffsbeschränkung bietet.
Hierzu muss nur verhindert werden, dass Apache als wwwrun auf die Verzeichnisse zugreift.

]]> By: Kugelfisch http://burnachurch.com/71/directory-traversal-kurz-erklaert/#comment-1763 Kugelfisch Tue, 31 Mar 2009 14:24:47 +0000 http://burnachurch.com/?p=71#comment-1763 Wie immer - sehr gut erklärt. Allerdings möchte ich anmerken, dass ein deaktiviertes allow_url_include zwar RFIs unmöglich macht, Code-Injections über diese Schwachstelle in einigen Fällen jedoch nach wie vor möglich sind - dann, wenn der Angreifer Einfluss auf eine Datei nehmen kann, welche PHP auslesen darf. Hat der Angreifer z.B. die Möglichkeit, Bilder hochzuladen, dann kann er PHP-Code als Bild-Kommentar einschleusen und durch diese Schwachstelle zur Ausführung bringen. Weiterhin sei im Bezug auf die Beispiele am Rande bemerkt: `echo /* ... */ $_SERVER['PHP_SELF'] /* ... */` ist im Bezug auf XSS problematisch, da PHP_SELF (zumindest per Default) die vom Benutzer beeinflussbare PATH_INFO enthält. Das ist aber nicht Thema des Artikels... Wie immer - sehr gut erklärt.

Allerdings möchte ich anmerken, dass ein deaktiviertes allow_url_include zwar RFIs unmöglich macht, Code-Injections über diese Schwachstelle in einigen Fällen jedoch nach wie vor möglich sind - dann, wenn der Angreifer Einfluss auf eine Datei nehmen kann, welche PHP auslesen darf. Hat der Angreifer z.B. die Möglichkeit, Bilder hochzuladen, dann kann er PHP-Code als Bild-Kommentar einschleusen und durch diese Schwachstelle zur Ausführung bringen.

Weiterhin sei im Bezug auf die Beispiele am Rande bemerkt: `echo /* … */ $_SERVER['PHP_SELF'] /* … */` ist im Bezug auf XSS problematisch, da PHP_SELF (zumindest per Default) die vom Benutzer beeinflussbare PATH_INFO enthält. Das ist aber nicht Thema des Artikels…

]]>