Die Sicherheitsprüfung: suchen, belegen, gegenprüfen

Ein Projektmanagementsystem enthält genau die Daten, die in einem Unternehmen niemand nach außen geben will: Projekte, Risiken, Aufwände, Abwesenheiten. Bevor GODAV Pro die Version 1.0.0 trägt, stand deshalb eine Sicherheitsprüfung auf der Roadmap. Nicht als einmaliges Durchschauen, sondern als festgeschriebener Ablauf, den ich vor jeder größeren Auslieferung wiederholen kann.

Diesen Beitrag gibt es zusammen mit dem über das Codereview. Beide liefen am selben Tag im selben Prüflauf, fragen aber etwas Verschiedenes: Hier geht es darum, ob jemand an Daten oder Rechte kommt, die ihm nicht zustehen. Beim Codereview geht es darum, ob der Code auch in einem Jahr noch verständlich und änderbar ist.

Drei der vier Punkte für 1.0.0 sind abgehakt. Die Fehlerbehebungen bleiben bis zum Schluss offen.

Erst verstehen, dann suchen

Die Prüfung beginnt nicht mit der Suche nach Fehlern, sondern mit einer Bestandsaufnahme: Welche Teile gibt es, wie fließen Daten zwischen ihnen, und wo liegen die Vertrauensgrenzen? Das sind die Stellen, an denen etwas von außen hereinkommt, etwa eine Anfrage aus dem Browser, eine hochgeladene Datei oder eine eingehende Mail. Erst danach folgen die eigentlichen Prüfungen, nach Bereichen getrennt:

• Anmeldung und Sitzungen: Wie lange gilt eine Anmeldung, was passiert mit alten Sitzungen?
• Berechtigungen: Prüft jede Schnittstelle, ob der Aufrufer das Projekt überhaupt sehen und die Handlung ausführen darf?
• Eingaben: Kann über ein Textfeld, einen Dateinamen oder eine Adresse etwas eingeschleust werden?
• Datenabfluss: Verraten Fehlermeldungen oder öffentliche Endpunkte mehr als nötig?
• Konfiguration und Abhängigkeiten: Sind die Voreinstellungen sicher, und haben die verwendeten Fremdbibliotheken bekannte Schwachstellen?

Bei den Berechtigungen bin ich gründlich gewesen, weil dort die teuersten Fehler entstehen. Eine vergessene Prüfung erzeugt keinen Absturz, sondern liefert einfach zu viele Daten aus, und niemand merkt es. Deshalb wurden alle Schnittstellen erfasst, und jede öffentliche sowie jede, die Dateien ausliefert, im Volltext gelesen.

Was eine Rolle darf, wird an einer Stelle festgelegt und an einer Stelle geprüft. Genau das hat die Prüfung bestätigt.

Ein Befund braucht einen Beleg

Die wichtigste Regel der Prüfung: Jeder Befund nennt die Datei, die Zeile und den betroffenen Code. Formulierungen wie „könnte unsicher sein” sind nicht erlaubt. Wer nicht sagen kann, was unter welchen Bedingungen mit welchen Daten passiert, hat einen Verdacht und keinen Befund. Verdachte stehen in einem eigenen Abschnitt und sind als solche gekennzeichnet.

Ich hätte mir die Arbeit leichter machen können, indem ich jede auffällige Stelle aufschreibe. Eine solche Liste wäre aber länger und schlechter gewesen. Ein Bericht, dem man nicht trauen kann, kostet genauso viel Lesezeit und führt zusätzlich in die Irre.

Dazu gehört auch, vor dem Urteil die eigenen Entscheidungen zu lesen. Vieles in GODAV sieht auf den ersten Blick wie ein Fehler aus und ist mit Absicht so gebaut, samt Begründung in der Dokumentation. Steht eine Begründung da, ist die Stelle kein Befund, es sei denn, die Begründung trägt nicht mehr.

Eine zweite Regel: Nichts wird bewiesen, indem man es auslöst. Die Prüfung liest Code und Datenbank, sie greift aber nichts an, legt keine Konten an und verändert keine Daten. Wo sich ein Befund nur durch einen aktiven Test sichern ließe, beschreibt der Bericht den Weg dorthin, statt ihn zu gehen.

Was dabei herauskam

Die erfreulichste Zahl: kein Fehler bei den Berechtigungen und keine Einschleusungslücke. Drei Spuren habe ich besonders lange verfolgt, weil sie typische Datenlecks wären. Alle drei waren bereits abgesichert, und die Begründung stand jeweils direkt daneben.

Gefunden habe ich trotzdem etwas, nichts davon kritisch: eine Fehlerauskunft, die im Störungsfall mehr verriet als nötig, eine verschlüsselte Verbindung, die ihre Gegenstelle nicht genau genug prüfte, Sitzungen, die nie aufgeräumt wurden, und ein paar Hinweise zu Fremdbibliotheken. Alle sicherheitsrelevanten Punkte habe ich noch am selben Tag behoben.

Außerdem

• Jeder Befund bekommt eine feste Kennung. Der nächste Lauf vergleicht mit dem vorigen und weist Rückfälle ausdrücklich aus.
• Der Bericht nennt auch, was nicht geprüft wurde. Eine verschwiegene Lücke wäre gefährlicher als ein Befund.
• Ein Abschnitt hält fest, was gut gelöst ist, damit es beim nächsten Umbau nicht versehentlich verschwindet.

Die Prüfung ist kein Häkchen, das einmal gesetzt bleibt. Sie ist so aufgeschrieben, dass ich sie jederzeit wiederholen kann, und beim nächsten Lauf zeigt der Vergleich, ob seitdem etwas zurückgekommen ist.