Meine eigenen Ergebnisse korrigieren: ein Sanierungsplan, nach Risiko geordnet

In meinem Bedrohungsmodell des Kontaktformulars dieser Seite endete ich mit vier Schwächen, die ich in meinem eigenen Design gefunden hatte. Probleme zu finden ist die einfache Hälfte. Die schwierigere Hälfte ist es, zu entscheiden, was zuerst zu beheben ist, wie und was überhaupt nicht zu beheben ist.

Dieser Beitrag ist die zweite Hälfte: ein kleiner, realer Behebungsplan.

Wie ich sie bewertet habe

Ein einfacher Weg, um Risiken zu vergleichen, ist, zwei Fragen über jedes zu stellen:

• Wahrscheinlichkeit: wie wahrscheinlich ist es, dass diese Schwäche tatsächlich ausgenutzt wird oder Schaden verursacht?
• Auswirkung: wenn es passiert, wie schlimm ist es und für wen?

Die Matrix oben ist mein eigenes Urteil, keine Messung. Das ist normal: die meisten realen Risikobewertungen sind informiertes Urteil, das aufgeschrieben wird, damit andere es in Frage stellen können. Der Wert liegt darin, die Begründung sichtbar zu machen.

1. Nachrichten, die für immer gespeichert werden: zuerst beheben

Das Risiko. Jede über das Formular gesendete Nachricht bleibt unbefristet in der Datenbank. Jede enthält einen Namen, eine E-Mail-Adresse und alles, was die Person mir mitteilen wollte. Wenn die Datenbank jemals durch ein ausgetauschtes Passwort oder einen Fehler von mir exponiert wird, wird alles, was jemals gesendet wurde, mit ihr exponiert.

Warum es an erster Stelle steht. Die Auswirkung betrifft andere Menschen, die mir ihre Daten anvertraut haben. Und die Wahrscheinlichkeit, dass irgendwann über viele Jahre hinweg ein Datenbestand irgendwo exponiert wird, ist nicht gering. Daten, die man nicht speichert, können nicht leaken.

Die Behebung. Ein geplanter Job, der Nachrichten älter als einen festen Zeitraum löscht. Cloudflare Workers unterstützen cron-Auslöser, sodass der gleiche Worker, der Nachrichten empfängt, eine tägliche DELETE FROM messages WHERE created_at < …-Abfrage ausführen kann. Zwölf Monate fühlen sich richtig an: lang genug, um ein Gespräch fortzusetzen, kurz genug, um zu begrenzen, was ein Datenleck preisgeben könnte. Dies bringt die Seite auch näher an das Speicherbegrenzungsprinzip im Data Protection Act von Ghana, 2012 (Act 843).

2. 'unsafe-inline' in der Skript-Richtlinie

Das Risiko. Die Content-Security-Policy der Seite erlaubt Inline-Skripte. CSP ist ein Sicherheitsnetz gegen Cross-Site-Scripting (XSS): wenn ein Angreifer jemals ein Skript in eine Seite injizieren könnte, würde eine strenge Richtlinie es daran hindern, ausgeführt zu werden. Mit 'unsafe-inline' hat das Netz ein Loch genau an der falschen Stelle.

Warum es an zweiter Stelle steht. Die Wahrscheinlichkeit ist gering: die Seite ist statisch und zeigt keine benutzergenerierten Inhalte an, also gibt es heute keinen offensichtlichen Injektionspunkt. Aber die Auswirkung eines erfolgreichen XSS auf jeden Besucher wäre hoch, und Verteidigung in der Tiefe bedeutet nicht, sich auf „es gibt heute keinen Bug heute“ zu verlassen.

Die Behebung. Ersetzen von 'unsafe-inline' durch einen Hash für jedes Inline-Skript. Bei der Build-Zeit den SHA-256-Hash jedes Inline-Skripts berechnen und diese Hashes in der Richtlinie auflisten. Der Browser führt dann nur Skripte aus, deren genauen Inhalt ich genehmigt habe. Da die Seite statisch ist, ändern sich die Hashes nur, wenn ich ein Skript ändere, sodass dies im Build automatisiert werden kann.

3. Eine Rate-Limitierung, die geracet werden kann

Das Risiko. Der Limit von fünf Nachrichten pro Stunde pro IP wird in Cloudflare KV gespeichert, der letztendlich konsistent ist, und der Code liest den Zähler und schreibt ihn dann als zwei separate Schritte. Ein Burst von Anfragen, die parallel gesendet werden, kann alle den gleichen alten Zählerstand lesen und leicht die Limit überschreiten.

Warum es den dritten Platz belegt. Es ist leicht auszulösen, aber die Auswirkung ist gering: einige zusätzliche Spam-Nachrichten, die immer noch die Turnstile-Bot-Überprüfung passieren müssen. Für ein Kontaktformular ist eine ungefähre Grenze akzeptabel. Es wäre nicht akzeptabel für etwas wie Login-Versuche.

Die Lösung. Verschieben Sie den Zähler auf etwas mit atomaren Updates: entweder Cloudflares integrierte Rate-Begrenzung für Workers oder ein Durable Object, das Anfragen für einen bestimmten Schlüssel nacheinander verarbeitet. Beides entfernt das Rennen.

4. Shared IPs teilen eine Grenze: akzeptieren, dokumentieren, überwachen

Das Risiko. Viele Mobilfunknetze platzieren eine große Anzahl von Benutzern hinter einem kleinen Pool gemeinsam genutzter öffentlicher IP-Adressen. In einem solchen Netzwerk könnte ein missbräuchlicher Benutzer das Stundenlimit für unschuldige Personen aufbrauchen, die ihre Adresse teilen.

Warum ich es akzeptiere. Jede Alternative hat einen Kostenfaktor. Eine Begrenzung per E-Mail-Adresse ist leicht zu umgehen, indem man erfundene Adressen verwendet. Die Entfernung der IP-Begrenzung würde den Schutz vor Überflutungen schwächen. Eine erhebliche Erhöhung der Begrenzung würde mehr Spam durchlassen. Da ein blockierter Besucher einfach später noch einmal versuchen oder mich direkt per E-Mail kontaktieren kann, ist der Schaden gering.

Was „akzeptieren“ bedeutet. Die Akzeptanz eines Risikos ist eine legitime Entscheidung, aber nur, wenn sie bewusst und dokumentiert ist. Ich schreibe es also hier auf, mit der Begründung, und werde es überprüfen, wenn ich jemals echte Besucher blockiert sehe. Wenn dies ein Dienst für Tausende von Mobile-Money-Nutzern und nicht ein persönliches Kontaktformular wäre, würde ich es viel höher einstufen.

Was mir diese Übung beigebracht hat

Zwei Lektionen:

• Nicht jeder Fund ist dringend. Die Bewertung nach Wahrscheinlichkeit und Auswirkung hinderte mich daran, meine Zeit für die interessanteste technische Korrektur (das Ratenlimit-Rennen) aufzuwenden, bevor ich mich derjenigen widmete, die tatsächlich Menschen schützt (das Löschen alter Daten).
• „Beheben“, „mildern“ und „akzeptieren“ sind alle gültige Ergebnisse, solange die Wahl bewusst getroffen wird. Ein Sicherheitsplan, der behauptet, alles zu beheben, ist normalerweise einer, der nicht genau genug hingeschaut hat.

Ich werde diesen Beitrag aktualisieren, sobald jeder Fix veröffentlicht wird.

Stimmen Sie meiner Bewertung nicht zu? Ich würde gerne hören, warum.