Skip to content

Der SDL am Beispiel eines Gästebuchs, Teil 4

Die Demonstration von Microsofts SDL am Beispiel eines PHP-Gästebuchs geht in die vierte Runde. Im ersten Schritt müssen Sie sich über die nötigen Grundlagen wie mögliche Schwachstellen und Angriffe informieren, und im zweiten die nötigen Anforderungen an die Webanwendung festlegen. Darauf aufbauend können Sie ein Bedrohungsmodell erstellen. Und damit machen wir jetzt weiter.

Die möglichen Bedrohungen für das Gästebuch

Für jeden Datenfluss im Bedrohungsmodell (siehe Abb. 1), der eine Vertrauensgrenze überschreitet, und für jedes damit verbundene Element des Diagramms müssen Sie alle sechs Kategorien des STRIDE-Modells überprüfen: Welche Angriffe sind möglich? Wie können sie durchgeführt werden?

Das Ergebnis der Bedrohungsmodellierung
Abb. 1: Das Bedrohungsmodell

Für die praktische Umsetzung bedeutet das: Für jeden Funktionsaufruf und alle vom Benutzer manipulierbaren Daten müssen alle sechs Kategorien des STRIDE-Modells überprüft werden: Welche Angriffe sind möglich? Wie können sie durchgeführt werden?

Fangen wir mit dem Eintragen der Daten, sowohl der Benutzereingaben als auch der (i.A.) vom Webbrowser gelieferten IP-Adresse, an:

  • Spoofing:
    • Generell kann jeder Besucher der Website beliebige Daten eintragen, ein Fälschen dieser Daten ist daher irrelevant.
    • Die normalerweise vom Webbrowser übermittelte IP-Adresse könnte gefälscht werden, um den Ursprung eines Angriffs zu verschleiern.
  • Tampering:
    • Über alle Parameter können SQL-Injection- und XSS-Angriffe durchgeführt werden.
    • Über die E-Mail-Adresse wäre ein SMTP-Injection-Angriff möglich, wenn sie von der Anwendung zum Versand von E-Mails verwendet würde.
  • Repudiation:
    • Da jeder Besucher der Website eine beliebige Identität angeben kann, ist dieser Punkt irrelevant.
  • Information Disclosure:
    • Da die Daten nur eingetragen werden, ist ein unbefugtes Lesen von Daten über eine Missbrauch vorhandener Funktionen nicht möglich.
    • Evtl. ist es aber möglich, über einen SQL-Injection-Angriff beim Speichern der Daten andere Daten zu lesen. Um auf diese Daten zugreifen zu können müssten sie im gleichen Zug in eine Datei geschrieben werden, die danach heruntergeladen werden kann.
      Da SQL Injection schon verhindert werden muss, um Tampering zu verhindern, ist hier aber keine zusätzlicher Schutz nötig.
  • Denial of Service:
    • Benutzereingaben und IP-Adresse könnten so präpariert werden, dass es beim Prüfen oder Eintragen der Daten zu einem übermäßigen Ressourcenverbrauch kommt.
    • Ebenso ist es möglich, die Datenbank durch eine sehr große Anzahl von Einträgen zu (über)füllen.
  • Elevation of Privilege :
    • Da es keine Autorisierung und keine unterschiedlichen Benutzerrechte gibt, ist kein Angriff darauf möglich.

Als nächstes muss die Abfrage der Gästebucheinträge durch die normalen Benutzer geprüft werden. Dabei gibt es nur einen vom Benutzer manipulierbaren Parameter: Die ID $id.

  • Spoofing:
    • Spoofing ist an dieser Stelle nicht möglich.
  • Tampering:
    • Über die ID können SQL-Injection-Angriffe durchgeführt werden.
    • Wird der Parameter im Rahmen einer Fehlermeldung an den Benutzer zurück geliefert ist außerdem XSS möglich.
  • Repudiation:
    • Angriffe sind an dieser Stelle nicht möglich
  • Information Disclosure:
    • Theoretisch könnte eine beliebige ID übergeben und damit auf beliebige Einträge zugegriffen werden. Da alle Einträge zur Veröffentlichung bestimmt sind, ist ein Angriff aber zwecklos.
    • Falls die Einträge moderiert werden und erst nach einer Freischaltung durch den Administrator zugänglich sind, wäre ein Angriff jedoch möglich.
  • Denial of Service:
    • DoS-Angriffe sind durch eine große Anzahl schnell aufeinander folgender Abfragen, ggf. mit unterschiedlichen IDs, möglich.
  • Elevation of Privilege:
    • Da es keine Autorisierung und keine unterschiedlichen Benutzerrechte gibt, ist kein Angriff darauf möglich.

Die Ausgabe der Einträge könnte auch blockweise erfolgen, so dass die ID vom Server verwaltet wird und nicht vom Benutzer manipuliert werden kann. Allerdings müsste dann der anzuzeigende Block über einen vom Benutzer manipulierbaren Parameter ausgewählt werden, für den die gleichen Bedrohungen wie für die ID gelten.

Kommen wir zum letzten Punkt: Der Abfrage der erweiterten Einträge durch einen Administrator. Auch hier kann der Parameter $id manipuliert werden, außerdem sind Angriffe auf die privilegierte Stellung des Administrators möglich.

  • Spoofing:
    • Ein Angreifer könnte sich als Administrator ausgeben.
  • Tampering:
    • Über die ID können SQL-Injection-Angriffe durchgeführt werden.
    • Wird der Parameter im Rahmen einer Fehlermeldung an den Benutzer zurück geliefert ist außerdem XSS möglich.
  • Repudiation:
    • Angriffe sind an dieser Stelle nicht möglich
  • Information Disclosure:
    • Der Administrator darf definitionsgemäß auf alle Daten zugreifen, ein Angriff ist also nicht möglich.
  • Denial of Service:
    • DoS-Angriffe sind durch eine große Anzahl schnell aufeinander folgender Abfragen, ggf. mit unterschiedlichen IDs, möglich.
  • Elevation of Privilege:
    • Privilegieneskalation ist möglich, wenn sich ein normaler Benutzer als Administrator ausgeben kann.

Datenschutz ist nicht vorgesehen

Im STRIDE-Modell nicht berücksichtigt werden Datenschutzforderungen. Da Name, E-Mail-Adresse und ggf. die IP-Adresse personenbezogene Daten darstellen (können), sind die einschlägigen Datenschutzbestimmungen einzuhalten. Auf die hier ausführlich einzugehen, würde den Rahmen sprengen.

Allerdings möchte ich etwas zur Speicherung der IP-Adresse zur möglichen Verfolgung von Angreifern zu Bedenken geben: Verzichten Sie darauf, es lohnt sich (in diesem Fall) nicht. Ein Angreifer, der einen unerwünschten Gästebucheintrag einstellt, kann sie problemlos fälschen. Dann erreicht ihn zwar die Antwort des Webservers nicht, aber die interessiert ihn ja auch gar nicht. Oder er nutzt einen Anonymisierungsdienst. Im Zweifelsfall ist die IP-Adresse also sowieso falsch - warum sollte man sich also die Mühe machen, sie zu speichern?

Nun kennen Sie alle möglichen Bedrohungen. Sie kennen ja sicher den alten Spruch "Gefahr erkannt, Gefahr gebannt". So ist es auch hier, jedenfalls fast. Denn als nächstes gilt es, die erkannten Bedrohungen so weit wie möglich zu minimieren. Wie, erfahren Sie in der nächsten Folge.

Carsten Eilers

>
        </div>
                
        <footer class= Kategorien: Grundlagen

Trackbacks

Dipl.-Inform. Carsten Eilers am : Der SDL am Beispiel eines Gästebuchs, Teil 3

Vorschau anzeigen
Die Demonstration von Microsofts SDL am Beispiel eines PHP-Gästebuchs geht in die dritte Runde. Nachdem Sie sich im ersten Schritt über die nötigen Grundlagen wie mögliche Schwachstellen und Angriffe informiert und die nöt

Dipl.-Inform. Carsten Eilers am : Der SDL am Beispiel eines Gästebuchs, Teil 5

Vorschau anzeigen
Die Demonstration von Microsofts SDL am Beispiel eines PHP-Gästebuchs geht in die fünfte Runde. Im ersten Schritt haben Sie sich über die nötigen Grundlagen wie mögliche Schwachstellen und Angriffe informiert, und im zweit