Die offene Community mit kostenlosen Informationen und Schulungen zum Thema Applikationssicherheit ist für seine OWASP Top 10 bekannt, eine Liste mit aktuellen gefährlichen Sicherheitsrisiken für Web-Applikationen. Wer in Sachen Applikationssicherheit bisher noch nicht viel unternommen oder sich auf Ad-hoc-Maßnahmen beschränkt hat, für den sind die OWASP Top 10 ein ausgezeichneter Ansatzpunkt.
OWASP hat ausreichende Dokumentation für die Top 10 vorgelegt und eine Website für jede Schwachstelle von A1 bis A10 eingerichtet. Diese erläutert, worum es sich bei jeder Schwachstelle handelt, und gibt einen Risikowert an, der bei der Priorisierung und Selektierung möglicher Schwachstellen hilft.
In den OWASP Top 10 findet sich eine Unmenge an kostenlos verfügbarer und laufend aktualisierten Informationen, Schulungsmaterial und Ratschlägen. Man erfährt etwas über gängige Sicherheitsprobleme sowie über Strategien, um diese Probleme zu detektieren und teils komplett zu umgehen.
Konformität bedeutet auch, dass man genau wissen muss, welches spezielle Element des Toolkits welchen Teil des Standards unterstützt. Im Fall der statischen Analyse weiß man also, welche(r) Checker welche Elemente des Standards unterstützen, und ob es Elemente im Standard gibt, die mehr als die statische Analyse erfordern (z.B. Peer Code Review oder Software Composition Analysis).
Am Ende beginnen
Am einfachsten geht man an das Thema Security heran, indem man am Ende anfängt und externe, in einer späten Phase des Zyklus ansetzende und das gesamte System erfassende Tests einsetzt, wie etwa Penetration-Tests: Diese sind ideal für den Nachweis, dass die Applikation bzw. das System keine der vom OWASP aufgezählten Schwachstellen enthält. Allerdings ist dieses Testen nach dem Blackbox-Prinzip keineswegs die effizienteste Methode zum Produzieren eines Codes, der sicherer ist. Besser ist es also, sich nicht auf Blackbox-Tests zu verlassen, um die Software abzusichern, Bugs aufzudecken oder den Nachweis zu erbringen, dass die Software sicher ist.
Findet man mit Penetration-Tests eine Sicherheitslücke, sollte man sich fragen, warum das so ist, um anschließend der Ursache des Problems auf den Grund zu gehen. Anstatt durch Testen für Sicherheit zu sorgen, sollten Sicherheitskomponenten beim Design gleich mit eingebaut werden.
Hierfür gibt es SAST-Tools mit Support für OWASP, wie zum Beispiel die statische Codeanalyse.
Aber ist SAST
nicht ein Ärgernis?
Die Eleganz der statischen Analyse liegt darin, dass man in einer sehr frühen Phase des Zyklus mit der Überprüfung auf Sicherheitsprobleme beginnen kann, etwa durch eine zeitliche Vorverlegung der Sicherheitstests. Befasst man sich mit dem Thema Security erst spät oder ganz am Ende der Entwicklung (DevOpsSec), lässt sich die statische Analyse dafür nutzen, das Thema Security früher zu behandeln, noch bevor die Tests beginnen und während der Code gerade erst geschrieben wird (DevSecOps).
Nachteilig an der statischen Analyse ist ihr Ruf, sehr viel ‚Noise‘ zu produzieren, beispielsweise Hunderte oder gar Tausende Regelverletzungen, obwohl man gerade dachte, man wäre fertig für die Freigabe. Zum Glück gibt es einige gute Strategien, um hiermit umzugehen:
¶ Sicherheitstests nicht bis zum Schluss aufsparen. Es empfiehlt sich, mit den statischen Analysen zu starten sobald man mit dem Coding anfängt. Wartet man dagegen ab und führt die statischen Analysen nur im Rahmen der CI/CD-Pipeline aus, so summieren sich zu viele Meldungen und überfordern das Entwicklungsteam. Man sollte also die Analyse am Desktop laufen lassen, um Probleme zu finden, und sie im CI/CD-Kontext ausführen, um einfach zu verifizieren, dass der Code korrekt erstellt wurde.
· Feinabstimmung an der Konfiguration. Einige statische Analyse-Checker sind im Kontext des Codes vielleicht gar nicht erforderlich. Man sollte die Applikation prüfen und entscheiden, welche Sicherheitsrisiken relevant sind. Es macht Sinn, sich nur mit diesen zu befassen und niemals Ausschau nach Problemen zu halten, deren Beseitigung ohnehin nicht geplant ist.
¸ Das Alter des Codes. Der mittlerweile uralte Grundsatz ‚If it ain’t broken, don’t fix it‘ sollte auch auf Bestandscode angewandt werden. Das heißt: Ältere Codes nur mit den wichtigsten Security-Scannern prüfen. Kleinere Probleme bedeuten nur Zeitverschwendung, und die damit einhergehenden Änderungen bergen ihrerseits Risiken. Ein Code, den man nicht zu reparieren beabsichtigt, sollte auch nicht geprüft werden.
Es geht um die Risiken. SAST-Tools decken sowohl reale als auch potenzielle Schwachstellen auf, allerdings ist nicht mit allen Resultaten das gleiche potenzielle Risiko verbunden. OWASP hat hier geholfen, indem für jeden Eintrag in der Top-10-Liste das Risiko im Hinblick darauf definiert wurde, wie einfach sich eine Schwachstelle ausnutzen lässt, wie leicht die Schwachstelle zu entdecken ist und welche tatsächlichen Folgewirkungen ein Exploit haben kann.
Vermeidung
ist wirkungsvoll