Ein SDL für PHP-Anwendungen
Kommentare

STRIDE
STRIDE ist ein von Microsoft entwickeltes System zur Einordnung von Bedrohungen in sechs Kategorien. Die Bezeichnung STRIDE wurde aus den Anfangsbuchstaben der Kategorien gebildet:
Spoofing: Angriffe

STRIDE

STRIDE ist ein von Microsoft entwickeltes System zur Einordnung von Bedrohungen in sechs Kategorien. Die Bezeichnung STRIDE wurde aus den Anfangsbuchstaben der Kategorien gebildet:

  • Spoofing: Angriffe auf die Authentifizierung, z. B. Vortäuschen einer falschen Benutzeridentität
  • Tampering: Angriffe auf die Integrität, d. h. die unbefugte Manipulation von Daten
  • Repudiation: Angriffe auf die Nichtabstreitbarkeit (Non-Repudiation), z. B. Abstreiten der Urheberschaft
  • Information Disclosure: Angriffe auf die Vertraulichkeit, z. B. Preisgabe bzw. Ausspähen von Daten
  • Denial of Service: Angriffe auf die Verfügbarkeit
  • Elevation of Privilege: Angriffe auf die Autorisierung, d. h. Privilegieneskalation, das Erlangen höherer Benutzerrechte

Für jeden Datenfluss, der eine Vertrauensgrenze überschreitet, und für jedes damit verbundene Element des Diagramms müssen alle sechs Kategorien des STRIDE-Modells überprüft werden: Welche Angriffe sind möglich? Wie können sie durchgeführt werden? Die praktische Umsetzung dieses Schritts haben Sie bereits in der letzten Ausgabe des Magazins gesehen. Das Ganze läuft auf eine ständige Wiederholung der immer gleichen Schritte hinaus: Für jeden Eingabeparameter muss das STRIDE-Modell durchlaufen werden.

Minimierung der Bedrohungen

Kommen wir zum vierten Punkt der Bedrohungsmodellierung: der Minimierung der Bedrohungen. Mit der Bündelung von Bedrohungen sieht es im Beispiel schlecht aus. Die Anwendung ist so minimal, dass sie sich nicht weiter zusammenschrumpfen lässt (sofern man nicht auf die Speicherung der E-Mail- und IP-Adressen verzichtet, was auch die Funktion zur Abfrage des erweiterten Eintrags obsolet macht). In Ihrer Webanwendung haben Sie vielleicht mehr Glück bei der Suche nach Verbesserungen. Danach müssen für alle im STRIDE-Modell erkannten Angriffe Gegenmaßnahmen festgelegt werden. Gibt es keine Möglichkeit, einen Angriff zu verhindern, müssen seine möglichen Folgen minimiert werden. Zum Beispiel ist es nicht möglich, einen DDoS-Angriff, der die Überlastung des Webservers zum Ziel hat, zu verhindern. Es ist aber möglich, seine Folgen durch das Bereitstellen entsprechender Rechenleistung und gegebenenfalls das Abweisen von HTTP Requests zu mildern. Zu guter Letzt muss das Ergebnis noch überprüft werden: Wurden alle möglichen Bedrohungen berücksichtigt?

Vereinfachung der Bedrohungsmodellierung

Das sieht ziemlich unübersichtlich aus. Vor allem die Modellierung lässt sich aber im Fall von Webanwendungen stark vereinfachen. Der alte Grundsatz der Websicherheit „Traue nie dem Client“ wird dann abgewandelt in „Traue keinen Daten von Dritten“: Alle Daten, die Sie nicht selbst prüfen, können potenziell bösartig sein. Was im Umkehrschluss bedeutet, dass Sie alle Daten, die Sie von Dritten erhalten, auf mögliche Angriffe prüfen müssen. Mit den „Dritten“ sind dabei nicht nur die Benutzereingaben gemeint, sondern auch zum Beispiel im Rahmen eines Mash-ups von anderen Servern gelieferte Daten. Für Webanwendungen lässt sich die Bedrohungsmodellierung folgendermaßen vereinfachen:

  • Für jeden Eingabeparameter STRIDE durchgehen
  • Dafür eine Liste mit Angriffen aufstellen (und aktuell halten!) und diese durchgehen. Vor allem beim Tampering hilft das ungemein, den Überblick zu bewahren
  • Eventuell Authentifizierung/Autorisierung absichern

Ein (gegebenenfalls nur virtuelles) Formular wie in Tabelle 1 kann dabei helfen, den Überblick zu bewahren. Für jedes Skript muss das Formular für jeden von Dritten stammenden Parameter ausgefüllt werden. Nicht enthalten ist hier die Liste möglicher Angriffe, diese befindet sich im Kasten „Angriffe auf Webanwendungen“. Das sieht nach mühsamer Erbsenzählerei aus? Das ist es im Grunde auch. Aber nur so können Sie sicher sein, alle möglichen Angriffe wirklich berücksichtigt zu haben. Keine Angst, es sieht schlimmer aus, als es ist. Für die meisten Angriffe können sie einen mehr oder weniger großen Teil der Angriffe sofort streichen. Wird ein Parameter nicht für SQL-Abfragen verwendet, ist natürlich keine SQL Injection möglich. Das Gleiche gilt entsprechend für alle Injection-Angriffe. Und wie Sie in der letzten Ausgabe gesehen haben, fallen teilweise auch Kategorien komplett weg, zum Beispiel „Elevation of Privilege“, wenn es gar keine Privilegien gibt, die sich ein Angreifer verschaffen könnte, oder „Spoofing“, wenn es keine Authentifizierung gibt. Sie werden am Ende also viele Formulare haben, in denen nur wenige Angriffe eingetragen sind. Und bei den bereits im Formular berücksichtigten Gegenmaßnahmen wird es dann noch einfacher, da Sie natürlich nur dort Gegenmaßnahmen ermitteln müssen, wo es überhaupt Angriffe beziehungsweise Schwachstellen gibt.

Skript: Parameter:
Kategorie Angriffe/Schwachstellen Gegenmaßnahmen
Spoofing
Tampering
Repudiation
Information Disclosure
Denial of Service
Elevation auf Privilege
Tabelle 1: STRIDE-Formular

Themen der kommenden Seiten:

  • Schritt 4: Implementierung
  • Schritt 5: Sichere Default-Installation und -Konfiguration
  • Schritt 6: Schwachstellentests
  • Schritt 7: „Kommunikation“
  • Sieben Schritte zur sicheren Webanwendung
  • Fazit
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -