Quellcode öffentlich erreichbar

Eine Anwendung schützt sich normalerweise auch dadurch, dass ein Angreifer von außen raten muss, wie sie funktioniert. Wird der Quellcode öffentlich erreichbar, entfällt dieses Raten vollständig: Er liest schlicht mit. Und da Versionsverwaltung alles bewahrt, liest er auch bei den Fehlern mit, die Sie längst behoben haben. Im Folgenden lesen Sie, wie das geschieht und warum Aufräumen allein nicht genügt.

Wie wird Quellcode öffentlich?

Quellcode wird öffentlich erreichbar, wenn Dateien, die nur während der Entwicklung benötigt werden, in dem Verzeichnis landen, das Ihr Webserver ausliefert. Es gibt einige wiederkehrende Ursachen, und ihnen ist gemeinsam, dass die Auslieferung durch Kopieren eines Verzeichnisses erfolgte statt durch Veröffentlichen eines Builds.

Die bekannteste ist der .git-Ordner. Er enthält das vollständige Archiv Ihres Projekts: jede Fassung jeder Datei, sämtliche Commit-Nachrichten und alle Namen der Beteiligten. Liegt dieser Ordner unterhalb des Webroots und sperrt der Webserver ihn nicht, kann jemand mit einem einfachen Hilfsmittel das gesamte Projekt rekonstruieren, als hätte er es selbst geklont.

Daneben stehen Sicherungs- und Editordateien: config.php.bak, index.php~, .env.alt, site.zip. Diese entstehen bei Handarbeit auf dem Server und bleiben jahrelang liegen. Das Tückische daran ist, dass eine Datei mit geänderter Endung nicht mehr vom Interpreter ausgeführt, sondern als reiner Text ausgeliefert wird: config.php zeigt nichts, config.php.bak zeigt Ihr Datenbankpasswort.

Denken Sie an eine Architektin, die nach der Übergabe die Baupläne, die Schließpläne und sämtliche früheren Entwurfsfassungen in der Halle liegen lässt. Das Gebäude ist fertig und sicher, doch wer hineingeht, weiß genau, wo die Schwachstellen sitzen.

Wie holt ein Angreifer Ihren Quellcode ab?

Verwundbar:

Die Auslieferung erfolgt mit einem git pull im Webroot. Der Aufbau auf dem Server sieht dann so aus:

/var/www/portal/
├── .git/               ← das vollständige Archiv
├── .env                ← Datenbankpasswort, API-Schlüssel
├── index.php
└── config.php.bak      ← Handsicherung von letzter Woche

Ein Angreifer prüft zunächst, ob das Archiv erreichbar ist:

GET /.git/HEAD HTTP/1.1
Host: portal.example

HTTP/1.1 200 OK
ref: refs/heads/main

Diese Antwort genügt. Mit einem Hilfsmittel, das die Objekte aus .git abholt, rekonstruiert er das vollständige Projekt einschließlich Historie. Anschließend durchsucht er diese Historie:

$ git log -p --all | grep -iE "password|api_key|secret"
+  DB_PASSWORD=Sommer2019!
+  STRIPE_SECRET_KEY=sk_live_51H8xQ2...

Diese Schlüssel wurden vor zwei Jahren aus dem Code genommen, stehen aber noch im Archiv. Und wurde der Datenbankschlüssel damals nicht geändert, funktioniert er weiterhin.

Sicher:

Die strukturelle Lösung besteht darin, nicht aus einem Arbeitsverzeichnis auszuliefern. Veröffentlichen Sie ein gebautes Artefakt oder checken Sie in ein Verzeichnis außerhalb des Webroots aus und richten Sie den Webserver auf ein Unterverzeichnis davon:

/opt/portal/             ← Code, außerhalb des Webroots
├── .git/
├── .env
└── public/              ← nur dies ist der Webroot
    ├── index.php
    └── assets/

Als ergänzende Schicht und ausschließlich als Auffangnetz sperren Sie versteckte Ordner und Sicherungsendungen im Webserver:

# Nie ausliefern, auch wenn versehentlich etwas landet
location ~ /\.(git|svn|hg|env) {
    deny all;
    return 404;
}
location ~ ~$|\.(bak|old|orig|save|swp|zip|tar\.gz)$ {
    deny all;
    return 404;
}

Welche Auswirkungen hat öffentlich erreichbarer Quellcode?

Der Schweregrad ist hoch bis kritisch, und zwar wegen der Verbindung zweier Dinge: vollständiger Kenntnis der Anwendung und unmittelbarem Zugriff auf Geheimnisse.

Die Kenntnis allein wiegt bereits schwer. Mit dem Quellcode sieht ein Angreifer genau, wie die Autorisierung aufgebaut ist, welche Endpunkte es gibt, die in der Oberfläche nirgends vorkommen, wie Token erzeugt werden und wo die Prüfungen sitzen, die er umgehen muss. Jede andere Schwachstelle in der Anwendung wird dadurch erheblich leichter auffindbar und ausnutzbar.

Die Geheimnisse machen es akut. Konfigurationsdateien enthalten in der Praxis Datenbankpasswörter, Schlüssel für Zahlungsdienste, Token für E-Mail-Dienste und den Schlüssel, mit dem Sitzungstoken signiert werden. Letzterer ist besonders schwerwiegend: Wer den Signaturschlüssel besitzt, kann gültige Token für jeden Nutzer erzeugen, auch für Administratoren, ohne je ein Passwort erraten zu müssen.

Besonders schwierig macht es die Reichweite in der Zeit. Das Archiv enthält nicht nur, was heute darin steht, sondern alles, was je darin stand. Ein Schlüssel, der vor drei Jahren versehentlich festgehalten und ordentlich entfernt wurde, ist weiterhin lesbar.

Wie spürt man öffentlich erreichbaren Quellcode auf?

Die Prüfung der bekanntesten Pfade ist schnell erledigt: /.git/HEAD, /.git/config, /.env, /.svn/entries. Eine Antwort mit Inhalt statt einer 404 ist sofort ein Treffer. Ein wichtiges Detail: Ein 403 bedeutet, dass der Ordner existiert, aber gesperrt wird, was darauf hinweist, dass der Code sehr wohl im Webroot liegt und der Schutz allein an einer Konfigurationszeile hängt.

Zusätzlich wird nach Dateien gesucht, die nicht zur Anwendung gehören, aber dennoch vorhanden sind. Kandidaten leitet ein Tester aus den bekannten Dateinamen ab: Zu jeder seite.php werden Varianten wie seite.php.bak, seite.php~ und seite.php.old ausprobiert, und es wird nach Archiven mit vorhersehbaren Namen wie backup.zip oder site.tar.gz gesucht. Ebenso wird geprüft, ob Directory Listing eingeschaltet ist, denn dann ist Raten gar nicht nötig. Auch Source Maps von JavaScript erhalten Aufmerksamkeit: Eine mitveröffentlichte .map-Datei gibt den ursprünglichen Frontend-Code einschließlich Kommentaren zurück. AssistSec berücksichtigt das standardmäßig in der Erkundungsphase eines Penetrationstests, denn ein Fund an dieser Stelle verändert den weiteren Verlauf der Untersuchung grundlegend.

Wie verhindert man öffentlich erreichbaren Quellcode?

• Liefern Sie mit einem gebauten Artefakt oder einem Export aus, nie durch Kopieren eines Arbeitsverzeichnisses mit Versionsverwaltung.
• Legen Sie den Code außerhalb des Webroots ab und richten Sie den Webserver ausschließlich auf ein public-Unterverzeichnis.
• Sperren Sie in Ihrem Webserver versteckte Ordner und Sicherungsendungen als Auffangnetz.
• Bewahren Sie Geheimnisse nicht im Code auf, sondern in Umgebungsvariablen oder einem Schlüsseltresor.
• Rotieren Sie jedes Geheimnis, das je in der Versionsverwaltung stand, auch wenn es später entfernt wurde.
• Setzen Sie einen Scanner für Geheimnisse in Ihrer Entwicklungsstrecke ein, damit Schlüssel nicht erneut festgehalten werden.
• Veröffentlichen Sie in der Produktion keine Source Maps von JavaScript oder begrenzen Sie den Zugriff darauf.
• Legen Sie nie Handsicherungen im Webroot an; verwenden Sie dafür einen eigenen Ort.
• Prüfen Sie regelmäßig, was tatsächlich im Webroot liegt, statt dessen, was dort liegen sollte.