Wir bauen uns ein Sicherheitsloch.

Abgelegt unter:

Es gibt Nachrichten, die möchte nicht kurz nach 22 Uhr erhalten, nachdem man gerade sein Essen verdrückt hat und ein Bierchen trinkt. Die nebenstehende gehört dazu...

Glücklicherweise waren die Folgen doch nicht ganz so schlimm, denn die App hatte bei Twitter nur Lese-Zugriff. Sie konnte also weder in meinem Namen schreiben noch Direktnachrichten lesen. Aber der Bug ist ein typisches Beispiel dafür, wie man eine Sicherheitslücke baut.

Historie

Vor fast drei Jahren wollte ich rausfinden, wann ich meinen Twitter-Account angelegt habe. Damals war das nicht so, dass diese Info direkt über das Profil abrufbar war. Also habe ich ein wenig gebastelt.

Ich hatte mir sogar, zwecks Erhöhung der Sicherheit, ein Drupal-Modul dafür gebaut. Aus Gründen, die ich nicht mehr nachvollziehen kann, habe ich das aber für die verlinkte Seite nicht verwendet. Dort kommt stattdessen eine eigentlich ganz unverfängliche Kombination aus JavaScript und PHP zum Einsatz. Und schon nimmt ein klassicher #Fail seinen Lauf.

Bei der Implementierung habe ich eine Reihe sehr dummer Fehler gemacht:

  1. Im PHP-Code sind die Zugangsdaten für die App gespeichert. Das ist pfui-bah und davon wird nicht nur in den Twitter-Docs extrem abgeraten. Denn sollte mal der PHP-Code uninterpretiert ausgeliefert werden, könnte die ja jeder sehen.
  2. Das JavaScript gibt es direkt die Antwort vom Server aus.
  3. Der PHP-Code lag im files-Ordner meiner Drupal-Installation. Dieser ist eigentlich für Dateien gedacht, die von angemeldeten Benutzern hochgeladen werden.
  4. In meiner doch etwas angestaubten Drupal-Version gab es einen Bug. Durch diesen können PHP-Dateien im files-Ordner ausgeführt werden. Natürlich habe ich den entsprechenden Patch eingebaut.

Wer aufmerksam mitgelesen hat, hat den finalen fatalen Fehler sicherlich sofort entdeckt. Durch das Einspielen des Patches gegen die Sicherheitslücke wurde das Auführen von PHP-Code im files-Ordner deaktiviert.

Da das JavaScript den Rückgabetyp des Servers nicht prüft, sondern die Antwort direkt ausliefert, stand so der PHP-Code inklusive Zugangsdaten nach einem Klick im Klartext auf der Webseite.

So wäre es richtig gewesen

  1. Zugangsdaten gehören nicht hartkodiert in den Quellcode
  2. Scripte müssen immer den Rückgabetyp prüfen und dürfen niemals Antworten vom Server direkt ausgeben. Das hätte zwar nicht verhindert, dass der Server die Daten verschickt hätte, aber es wäre nicht so offensichtlich gewesen.
  3. Ausführbarer Code gehört nicht in Ordner, die von angemeldeten Nutzern beschrieben werden können. Er gehört in ein Modul verpackt.

Das bittere ist, dass der letzte Punkt sogar umgesetzt war. Aber wie geschrieben, aus irgendeinem Grund habe ich noch die Version gebaut, in der so ziemlich alles falsche gemacht wurde, was falsch gemacht werden kann.

Danke an CptMeddl Cyberschiss fürs Melden.

Trackback URL for this post:

https://blog.christian-hufgard.de/trackback/563
Your rating: Keine Average: 5 (1 vote)

Bewerte dies

Your rating: Keine Average: 5 (1 vote)