RIPS – Sucht im Quelltext nach Sicherheitslücken

Es lebe die statische Code-Analyse, welche nicht nur schönen sondern auch sicheren Code liefern kann dank RIPS. Dieses Tool ist in PHP geschrieben und sucht im Quelltext nach möglichen Schwachstellen.

RIPS lässt sich sehr einfach Installieren und prüft zum Beispiel das eigene Plugin oder das Theme schnell auf mögliche Schwachstellen. Es ist seit Anfang des Jahres sogar in einem Paper an der Ruhr-Universität Bochum weiter ausgearbeitet worden und eine neue noch bessere Version von diesem Tool ist bereits in Entwicklung (http://syssec.rub.de/media/emma/veroeffentlichungen/2014/01/21/rips-NDSS14.pdf).

Nachdem RIPS von http://rips-scanner.sourceforge.net/ heruntergeladen und in einen neuen Ordner auf dem lokalen Server entpackt worden ist, kann es per Browser aufgerufen werden. Die Bedienung ist sehr intuitiv und leicht, wie hier zu sehen:

Screenshot Selection 2014-11-04 05Der Pfad zu der eigenen WordPress-Instanz oder sogar nur dem Plugin reicht völlig aus. Ein klick auf „Scan“ und ein paar Sekunden später steht ein Report zur Verfügung, dessen Länge einen im ersten Moment Angst einjagt.

Screenshot Selection 2014-11-04 06In dem hier gezeigten Fall, hatte RIPS recht. Es wäre wirklich möglich gewesen die komplette Dateistruktur auszulesen, wenn der Benutzer die richtigen Eingaben macht – und das können Hacker gut! Ein Grund zur Sorge und der Anstoß dieses Problem zu beheben. Allerdings gibt es auch sogenannte „false negative“, was bedeutet, dass eine als sicherheitskritisch dargestellte Code-Zeile („negative“) bei genauerer Betrachtung keine Bedrohung ist („false negative“). Dies kann vorkommen, da wir als Mensch besser den Code deuten können und alle Zusammenhänge kennen. Das Tool stellt nur Vermutungen an oder zeigt Zeilen, die wir nochmal genau prüfen sollen.

Darüber können wir in Summe froh sein, denn es achtet auf sehr viele Sachen:

  • Code Execution (z.B. über ein einfaches Formular lässt sich PHP-Code ausführen)
  • Command Execution (z.B. das Ausführen von Befehlen über die URL, welche sogar die Festplatte formatieren können)
  • Cross-Site Scripting (z.B. Einbinden von fremden Inhalten bei der Kommentar-Funktion)
  • Header Injection (z.B. das heimliche Weiterleiten von allen Mails an den Hacker)
  • File Disclosure (das auslesen der Verzeichnisstruktur, um zu Wissen welche Plugins und Themes angreifbar sind)
  • File Inclusion (das einbinden einer fremden Datei, um so eigenen Schadcode einzuschleusen)
  • File Manipulation (Schadcode in bestehende Dateien einschleusen, was aktuell sehr häufig bei WordPress-Plugins Möglich ist)
  • SQL Injection (verändern oder löschen von Posts/Pages und mehr in der Datenbank, um z.B. überall Werbung einzublenden)
  • XPath Injection (ähnlich der SQL-Injection bezieht sich nur auf XML-Dateien)

Mit der Prüfung auf die obigen Sicherheitslücken und insgesamt 232 verschiedenen Variationen von diesen Sicherheitslücken ist der eigene Code eine Spur besser dran, als viele Plug-Ins von wordpress.org/plugins , themeforest.net und anderen Schmieden. Es ist mehr ein sicheres und beruhigendes Gefühl, während RIPS einem in Sachen Sicherheit über die Schulter schaut. Die Gewissheit, dass der Code damit „undurchdringbar“ ist kann auf Dauer allerdings nur durch den Programmierer selbst garantiert werden.

Hinterlasse einen Kommentar

*

1 comment

  1. Pingback: Monitoring: Warum wurde mein WordPress gehackt? › shortcodes - Das Blog für WordPress-Entwickler

Nächster ArtikelWordPress Template-Hierarchie