Sicherheit: was ich lerne

Sicherheit ist der Teil der Softwareentwicklung, den ich gerade lerne. Ich bin kein Sicherheitsspezialist, und diese Notiz tut nicht so. Sie hält fest, wo ich stehe, mit Beispielen aus meinen Projekten statt mit Absichtserklärungen, und sie wird mit der Zeit wachsen.

Wo ich herkomme

Wer Web-, Mobile- und Backend-Anwendungen baut, steht bei den meisten Sicherheitsproblemen auf der Seite der Verteidigung: Authentifizierung, Nutzereingaben, Datenzugriff, Geheimnisse, Abhängigkeiten. Dort trifft eine Anwendung auf die Außenwelt, also schaue ich zuerst dorthin. Mein Abschlussprojekt im Bachelor, eine Orientierungsplattform mit Konten und Nachrichten, hat mich sogar dazu gebracht, den Datenschutz unter seinen Grenzen aufzuführen.

Was ich schon anwende

Das kann ich zeigen, Projekt für Projekt.

Bei Minguili, einer veröffentlichten App.

Login ohne Passwort über einen Einmalcode: zehn Minuten gültig, als Hash und nicht im Klartext gespeichert, auf fünf Versuche begrenzt, mit einer Wartezeit, bevor ein neuer angefordert werden kann.
Ein Zugriffstoken mit fünfzehn Minuten Laufzeit, nur im Speicher gehalten, ein Erneuerungstoken im sicheren Speicher des Telefons, bei jeder Nutzung erneuert.
Preise kommen nie aus der App: Der Server berechnet das Angebot neu, ein manipulierter Client kann also nicht weniger zahlen.
Authentifizierter Zahlungs-Webhook, Status an der Quelle neu gelesen, idempotente Verarbeitung.
Beim Start weigert sich der Server, mit einer gefährlichen Konfiguration in Produktion zu laufen.

Bei der Anwendung der Basketball-Liga.

Keine Registrierungsseite: Das erste Administratorkonto wird von einem Rechner mit Zugriff auf die Datenbank angelegt.
Zähler gegen Brute-Force in der Datenbank gespeichert, weil bei zustandslosem Hosting der Speicher des Servers nicht reicht.
Hochgeladenes Logo wird an seinen Bytes geprüft und nicht daran, was es zu sein vorgibt, Größe begrenzt, SVG mit Skript abgelehnt.
Das automatische Lesen der Spielberichte schickt das ganze Foto an einen Anbieter: Das habe ich in der Dokumentation schwarz auf weiß festgehalten, damit die Liga in Kenntnis der Lage entscheiden kann.

Bei dieser Website.

Das Dashboard lauscht nur auf dem lokalen Rechner, hasht das Passwort mit scrypt, verlangt ein CSRF-Token und prüft Herkunft und Host-Header.
Hochgeladene Dateien werden an ihrer Signatur geprüft und mit einer Richtlinie ausgeliefert, die jedes Skript verbietet.
Sicherheits-Header, eine security.txt und kein Tracking-Skript.
Ich kopiere nie eine Datei mit Geheimnissen von einem Projekt in ein anderes. Ein Repository darf gelesen werden, seine Schlüssel nicht.

Was ich als Nächstes lernen will

Gute Praxis anzuwenden ist nicht dasselbe, wie wie ein Angreifer zu denken. An diesem Teil will ich arbeiten: die Bedrohungen eines Systems modellieren, bevor ich es schreibe, verstehen, wie verbreitete Schwachstellen ausgenutzt werden, und Code lesen, um sie zu finden.

Der Plan ist einfach: an absichtlich verwundbaren Labs üben und jede Lektion auf den Code anwenden, den ich ausliefere. Die Labs, Kurse und Lektüren trage ich hier ein, sobald ich sie gemacht habe, mit dem, was jedes mich gelehrt hat und was ich danach geändert habe.

Was diese Notiz nicht sagt

Sie sagt nicht, dass meine Anwendungen sicher sind. Ich zeige hier kein unabhängiges Audit dieser Anwendungen, und diese Seite legt als statische Seite sehr wenig offen. Was ich hier vertrete, ist eine Gewohnheit: Sicherheit als Teil der Arbeit zu behandeln und aufzuschreiben, was ich noch nicht weiß.