Ein SDL für PHP-Anwendungen
Kommentare

Schritt 6: Schwachstellentests
Jetzt muss Ihre Webanwendung beweisen, dass sie sicher ist. Prüfen Sie für jeden Parameter und jedes Skript, ob wirklich alle ermittelten Angriffe abgefangen werden. Führen

Schritt 6: Schwachstellentests

Jetzt muss Ihre Webanwendung beweisen, dass sie sicher ist. Prüfen Sie für jeden Parameter und jedes Skript, ob wirklich alle ermittelten Angriffe abgefangen werden. Führen Sie die Tests sowohl manuell, das heißt mit bekannten Testmustern, als auch mit einem oder mehreren Tools durch. Sie finden zwar nicht unbedingt alle Schwachstellen, dafür aber vielleicht eine, die Sie übersehen haben. Testen Sie die Webanwendung sowohl in der Default-Konfiguration als auch in einer unsicheren Konfiguration, sofern das möglich ist; damit prüfen Sie quasi das Worst-Case-Szenario. Im Fall von PHP-Anwendungen ist es keine schlechte Idee, die Anwendungen auf einer unsicheren PHP-Installation zu testen, die zum Beispiel das Einbinden von URLs erlaubt (php.ini-Optionen allow_url_open und allow_url_include aktiviert). Ist Ihre Anwendung auch mit der PHP-Vorversion 5.4.0 lauffähig, testen Sie sie auch mit aktivierter php.ini-Option register_globals. Sie ist zwar seit PHP 4.2.0 in der Default-Einstellung aus und wird in PHP 5.4.0 entfernt, viele Shared Hoster schalten die Option aber ein, da manche alten Anwendungen sonst nicht laufen und man sich auf diese Weise Supportanfragen erspart.

Schritt 7: „Kommunikation“

Schwachstellen entstehen nicht, wenn sie gefunden werden, sondern wenn sie programmiert werden. Es gilt also sinngemäß „Ihre Anwendung, Ihr Fehler, Ihre Schwachstelle!“. Stellen Sie sich der Verantwortung und versuchen Sie gar nicht erst, die Fehler zu vertuschen! Wenn eine Schwachstelle gefunden wird, sind Sie unter Umständen der Letzte, der davon erfährt. Kaum jemand wird sich zum Beispiel die Mühe machen, sich in Ihrem Forum zu registrieren, nur um eine Schwachstelle zu melden. Machen Sie das Melden von Schwachstellen einfach. Eine entsprechende E-Mail-Adresse ist schnell eingerichtet und an passenden Stellen, zum Beispiel dem Impressum, der Kontaktseite Ihrer eigenen Website oder der Webanwendung veröffentlicht. Warten Sie nicht, bis die Schwachstelle zu Ihnen kommt! Beobachten Sie zumindest die Exploit Database [10]. Nicht jeder, der eine Schwachstelle findet, meldet sie an die Entwickler der betroffenen Anwendung, selbst wenn sie diese Meldung einfach machen. Wird Ihnen eine Schwachstelle bekannt, informieren Sie die Benutzer (bevor es ein anderer tut). Veröffentlichen Sie eine entsprechende Meldung sowohl auf der Website der Anwendung als auch gegebenenfalls in einer existierenden Mailingliste. Es empfiehlt sich, für diesen Zweck eine spezielle Mailingliste einzurichten. Wenn dort nie Schwachstellen oder Sicherheitsupdates veröffentlicht werden müssen, ist das wunderbar. Niemand wird sich über zu wenig Traffic beklagen. Wichtig ist auch, dass Sie die Benutzer ausführlich informieren: Was kann passieren? Gibt es einen Workaround? Wann erscheint ein Patch?

  1. Angriffe und Schwachstellen kennen
  2. Anforderungen festlegen
  3. Bedrohungsmodellierung
  4. Sichere Implementierung
  5. Sichere Default-Installation und -Konfiguration
  6. Schwachstellentests
  7. „Kommunikation“
Fazit

Es ist gar nicht so schwer, bei der Entwicklung einer Webanwendung von Anfang an auf deren Sicherheit zu achten. Wie Sie diese Schritte am besten in Ihre Arbeitsweise integrieren, sofern Sie sie nicht sowieso schon berücksichtigen, können nur Sie selbst beurteilen. Aber vielleicht hilft Ihnen die folgende starke Vereinfachung des Grundgedankens:

  • Alles, was Sie entwickeln, wird ein Angreifer gegen sie verwenden.
  • Überlegen Sie bei jedem Schritt während der Entwicklung auch, wie er sich missbrauchen lässt.
  • Sorgen Sie dafür, dass dieser Missbrauch nicht möglich ist.
  • Und schon entwickeln Sie quasi automatisch sichere Webanwendungen.
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -