Ein SDL für PHP-Anwendungen
Kommentare

Schritt 1: Angriffe und Schwachstellen kennen
Microsoft verdonnert sein technisches Personal zu Sicherheitstrainings. Sie können sich selbst aussuchen, wie Sie sich informieren möchten. Wichtig ist,

Schritt 1: Angriffe und Schwachstellen kennen

Microsoft verdonnert sein technisches Personal zu Sicherheitstrainings. Sie können sich selbst aussuchen, wie Sie sich informieren möchten. Wichtig ist, dass Sie ein Grundwissen über mögliche Schwachstellen und Angriffe erwerben. Dieses Grundwissen besitzen Sie zum größten Teil bereits, wenn Sie die bisherigen Folgen des Security-Workshops verfolgt haben. Auch online finden Sie die entsprechenden Informationen, zum Beispiel in vielen Folgen von „About Security“. Eine Übersicht der relevanten Artikel finden Sie auf der Heft-CD des PHP Magazins 1.2012. Aber damit ist es nicht getan. Nachdem Sie sich einmal ein Grundwissen erworben haben, müssen Sie sich danach auf dem Laufenden halten. Denn es werden immer wieder neue Angriffe oder Schwachstellen entdeckt, denen Ihre Anwendungen schutzlos ausgeliefert sind, solange Sie keine Schutzmaßnahmen implementieren. Ein gutes Beispiel ist in diesem Zusammenhang das Clickjacking [8]: Das wurde 2008 entdeckt, und keine Webanwendung enthielt Schutzmaßnahmen gegen den neuen Angriff (wenn man mal davon absieht, dass Framebuster, die in manchen Anwendungen aus anderen Gründen vorhanden waren, anfangs Schutz boten). Erst nach Bekanntwerden des Angriffs konnten Gegenmaßnahmen entwickelt und implementiert werden.

Schritt 2: Anforderungen festlegen

Die Anforderungen sind bei Webanwendungen im Grunde immer gleich: Es dürfen keine bekannten Angriffe möglich sein und die geltenden Datenschutzvorschriften müssen eingehalten werden. Mit den Datenschutzvorschriften dürfen sich die Rechtsanwälte herumschlagen. Damit reduzieren sich die Anforderungen für Sie als Entwickler auf einen Punkt: Jeder bekannte Angriff muss abgewehrt werden. Ist das nicht möglich, müssen die potenziellen Folgen eines Angriffs minimiert werden. In diesem Zusammenhang lohnt es sich, einmal die Angriffsfläche der Anwendung zu betrachten, eventuell lässt sie sich verkleinern. Die Angriffsfläche besteht aus den Punkten, an denen Daten eingegeben werden. Je kleiner sie ist, desto leichter fällt die Verteidigung. Wie das im Beispiel aussieht, haben Sie schon im PHP Magazin 1.2012 nachvollziehen können. Womit wir schon beim Entwurf sind, bei dem sich alles um die Frage nach den bestehenden Bedrohungen dreht.

Schritt 3: Ein Bedrohungsmodell erstellen

Um alle möglichen Bedrohungen für eine Webanwendung zu erfassen, kann zum Beispiel die so genannte „entwurfsgesteuerte Bedrohungsmodellierung“ verwendet werden. Zur Bedrohungsmodellierung (Threat Modeling [9]) gibt es ausreichend Fachliteratur, sodass die folgenden fünf Schritte, aus denen sie besteht, stark vereinfacht und zusammengefasst ausgeführt werden:

  1. Vision: Welche Sicherheitsanforderungen muss die Anwendung in der geplanten Einsatzumgebung erfüllen?
  2. Model: Erstellen Sie ein Diagramm ihrer Anwendung mit allen Datenflüssen. Üblich ist die Verwendung von Kreisen für Code, Kästen für externe Dinge wie Personen, Servern usw., Zylindern (oder einfach paralleler Linien) für Datenspeicher wie Datenbanken etc. und Pfeilen für Datenflüsse. Zeichnen Sie Vertrauensgrenzen zwischen den Komponenten ein. Vertrauensgrenzen befinden sich überall dort, wo mehr als eine Person oder ein Prozess auf ein Objekt, z. B. eine Datei oder einen Prozess, zugreifen kann. Kreuzen Vertrauensgrenzen etwas anderes als Datenflüsse, wird eine Aufteilung in zwei logische Komponenten notwendig. Gegebenenfalls muss das Diagramm verfeinert werden.
  3. Identify Threats: Ermitteln Sie für jeden Datenfluss, der eine Vertrauensgrenze überschreitet, mögliche Bedrohungen.
  4. Mitigate: Minimieren Sie die erkannten Bedrohungen. Prüfen Sie, ob sich die möglichen Bedrohungen bündeln lassen. Sind die Bedrohungen über alle oder zumindest viele Komponenten verstreut, müssen Sie sie an vielen Stellen abwehren. Können Sie sie in einer oder wenigen Komponenten bündeln, müssen Sie nur diese schützen. Verwenden Sie, soweit möglich, Standardgegenmaßnahmen. Entwickeln Sie, falls notwendig, neue Gegenmaßnahmen. Prüfen Sie, ob die verbleibenden Risiken akzeptiert werden können.
  5. Validate: Prüfen Sie das Ergebnis. Prüfen Sie, ob die Diagramme korrekt sind. Prüfen Sie, ob für jeden Datenfluss, der eine Vertrauensgrenze überschreitet, und für jedes damit verbundene Element alle Bedrohungen ermittelt wurden. Prüfen Sie, ob für jede Bedrohung Gegenmaßnahmen ergriffen wurden oder das Risiko akzeptabel ist. Gegebenenfalls geht es dann wieder beim zweiten Punkt los.

Im Fall des Gästebuchbeispiels aus dem PHP Magazin 1.2012 ist das Ganze recht einfach. Fangen wir mit dem ersten Punkt an: Welche Sicherheitsanforderungen muss die Anwendung in der geplanten Einsatzumgebung erfüllen? Hier gilt zunächst eine Abwandlung des altbekannten Grundsatzes „Traue nie dem Client“, bösartige Daten dürfen nicht gespeichert werden. Dann muss sichergestellt werden, dass nur die dazu befugten Benutzer Zugriff auf die zusätzlichen Informationen erhalten. Und natürlich müssen die Datenschutzvorschriften am Einsatzort eingehalten werden. Damit kommen wir zum zweiten Schritt, der Modellierung. Ein mögliches, sehr einfaches Ergebnis sehen Sie in Abbildung 1. Als Nächstes müssen alle möglichen Bedrohungen, das heißt Angriffe, ermittelt werden. Dazu kann zum Beispiel das so genannte STRIDE-Modell verwendet werden.

Abb. 1: Ergebnis der Modellierung

Themen der kommenden Seiten:

  • STRIDE
  • Minimierung der Bedrohungen
  • Vereinfachung der Bedrohungsmodellierung
  • 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 -