Practical Web Application Security – Teil 2

29. August 2017 von Christoph Buchli Veröffentlicht unter Digitale Transformation, Hosting/Zusatzdienste, TYPO3 Website, Intranet & Extensions, Wartung & Support, Web Applications Verschlagwortet mit , , , ,

Wie ich in meinem Blogbeitrag von vergangener Woche aufgezeigt habe, ist Software-Sicherheit kein Thema, das uns nur während der eigentlichen Implementierung der Lösung beschäftigen sollte. Um die Kosten für Security im Rahmen zu halten, muss zwingend der gesamte Lebenszyklus einer Softwarelösung berücksichtigt werden. Die Lebensabschnitte eines typischen Webprojektes habe ich dementsprechend in die vier Phasen aufgeteilt: Initiierung, Konzeption, Umsetzung und Betrieb. Die ersten beiden Phasen habe ich in Teil 1 des Blogbeitrags detailliert ausgeführt. Zeit also, nun einen kritischen Blick auf die Phasen Umsetzung und Betrieb zu werfen.

Die Websites und Applikationen unserer Kunden sind geschützt

Umsetzung

Während der Umsetzung ist es vor allem wichtig, dass die beteiligten Entwickler die Kriterien im Kopf haben und verstehen. Die meisten Massnahmen zur Einhaltung der Sicherheit lassen sich in die gewohnten Qualitätssicherungs-Prozesse integrieren.

ASVS Checkliste

Die ASVS Checkliste ist ein sehr guter Anhaltspunkt, allerdings für die tägliche Arbeit etwas zu umfangreich und häufig auch etwas abstrakt. Ich würde daher empfehlen, aufgrund der Erkenntnisse aus der Konzeptionsphase für jedes Projekt (oder unternehmensweit für alle Projekte) eine eigene Checkliste zu erstellen. Gegebenenfalls sind sogar für einzelne Komponenten separate Checklisten zu erstellen, wenn sich diese im angestrebten ASVS Level unterscheiden.

Diese Checklisten sollten dann vor allem im Code-Review verwendet werden, dienen aber natürlich auch während der Implementation als Referenz. Eine hilfreiche Methodik ist es beispielsweise, jeweils zu Beginn der Implementation eines Features die Merkmale herauszupicken, welche für das Feature besonders zu beachten sind. So etabliert sich innert kurzer Zeit ein gutes Verständnis für die einzelnen Aspekte; besser als wenn man versucht, alles auf einmal zu berücksichtigen.

Error Handlers

Eigentlich ist dies ein Detail, allerdings für mich ein sehr wichtiges: Ich sehe es immer wieder, dass Error Handler Informationen ausgeben, die sie nicht sollten. Auch ist es sehr hilfreich – insbesondere bei APIs – korrekte HTTP Status Codes zurück zu geben. Im Zusammenhang mit Security ist dies ebenfalls entscheidend, denn sobald man Angriffe mittels eines Tools testen möchte (siehe unten), ist dies wesentlich einfacher, wenn der Server „HTTP 403“ anstatt einer schön gestalteten 404-Seite mit dem Statuscode 200 zurück gibt.

Continuous Integration

Die Integration von Sicherheitschecks in Continuous Integration Abläufe kann in verschiedenen Stufen passieren. Für den Anfang reicht es durchaus, einzelne Unit-Tests für die Überprüfung schädlicher Parameter-Werte zu erstellen. Auch bieten einige statische Codeanalyse-Tools bereits eine gewisse Abdeckung von sicherheitsrelevanten Programmierfehlern.

Als nächste Stufe könnte man regelmässige Tests mit dem OWASP Zed Attack Proxy (ZAP) durchführen und analysieren. Diese Tests können später auch automatisiert in den CI-Prozess integriert werden.

Ebenfalls sehr hilfreich ist es, für die eingesetzten Paketverwaltungssysteme einen Package Vulnerability Test zu verwenden. Für die beiden von uns hauptsächlich verwendeten Tools gibt es dafür einfach zu verwendende Lösungen:

WAF

Dieses Kapitel ist schnell abgehandelt: Verwende eine WAF. Christian Folini gab kürzlich einen guten Talk (auch für Einsteiger geeignet) zum Thema und dieser ist glücklicherweise auf YouTube zu finden. Darin beschreibt er auch, wie man ModSecurity (fast), ohne False Positives zu verursachen, einführen kann.

Learning Modes

Wir verwenden bei uns die naxsi WAF mit einem erweiterten Core Rule Set, welches an dem ModSecurity Ruleset für die OWASP Top Ten angelehnt ist. naxsi – aber auch ModSecurity – bieten einen Learning Mode um Whitelists von gültigen Requests zu erfassen. Dieser Learning Mode wird am besten während einer gewissen Zeit aktiviert, in welcher intensive Systemtests laufen, aber die Lösung noch nicht öffentlich erreichbar ist. Dabei dürfen auch realistische Backend-Arbeiten nicht vergessen werden, aber der Learning Mode darf natürlich nicht während laufenden Penetration Tests – z.B. mit dem ZAP – aktiviert sein.

Skillset

Der Kenntnisstand der Entwickler hinsichtlich sicheren Codes und – für den Anfang – den OWASP Top Ten ist für ein Gelingen des ganzen Vorhabens offensichtlich ziemlich entscheidend. Ausserdem sollte jeder Entwickler mindestens ein Mal das Dokument des OWASP Proactive Controls Projekts (V3 Preview) durchgearbeitet haben.

Darauf aufbauende Erweiterung des Skillsets ist von Team zu Team unterschiedlich organisiert. Daher gebe ich hier nur einige kleine Denkanstösse, welche mir persönlich sehr geholfen haben:

  • Austausch: Nur schon einen Slack-Channel mit dem Namen #cig-security zu erstellen, wirkt Wunder.
  • Konkrete, greifbare Checkliste:  Die oben erwähnte Security Checkliste sollte so formuliert sein, dass sie von jedem nachvollzogen werden kann. Auch hier gilt es, eine Plattform für Klärungen zu schaffen.
  • Inhaltliche Verbesserung: Individuelle Vertiefungen in ein Unterthema sollten durch (interne) Techtalks allen zugänglich gemacht und gefördert werden (zum Beispiel mit einem gefüllten Kühlschrank für den Talk).
  • Ausführliche Kommentare bei Code-Reviews: Insbesondere fortgeschrittene Entwickler sollten sich ein bisschen Zeit nehmen, bei festgestellten Security Validations eine ausführlichere Erklärung zu geben. Vor allem auch bei festgestellten False Positives!
  • DevOps: Ich bin überzeugt davon, dass ein reger Austausch und ein gutes Verständnis aller am Software-Lebenszyklus beteiligten Personen die Sicherheit der Lösung erheblich steigert.
  • Meetups: Das Schweizer Chapter von OWASP organisiert regelmässig Treffen mit meetup.com, welche für alle offen sind. Ausserdem ist eine Mitgliedschaft bei OWASP eine gute Sache, denn OWASP unterhält neben den hier vorgestellten Hilfsmitteln noch viele weitere sehr hilfreiche Tools und Dokumentationen.
  • JavaScript MVC: Spezifisch für JavaScript Frontend Frameworks gibt es noch das Projekt mustache-security von Google, eine Sammlung von Tipps und Tricks für sicheres JavaScript-Templating.

Zum Abschluss möchte ich noch ein kleines Tool empfehlen, welches den Spieltrieb weckt und in die OWASP Top Ten optimal einführt: Das WebGoat Project bzw. NodeGoat – die Node.js Implementation. Mit einem Heroku Account ist diese Security Spielwiese innert Sekunden aufgesetzt und zur individuellen Vertiefung perfekt; auch für Einsteiger.

Betrieb

Für den Betrieb gibt es ein einfaches, uraltes Mantra als oberste Regel: Software Updates.

Software Updates

So trivial diese Aussage auch erscheint, in der Realität gestaltet es sich insbesondere bei Projekten mit wenig Ausbauvolumen manchmal etwas schwierig. Für sehr oft eingesetzte Software lohnt es sich, ein automatisches Update-System zu haben. So werden bei uns bei allen von snowflakeOps gehosteten Systemen automatisch die wichtigsten Grund-Applikationen per Puppet täglich mehrfach aktualisiert. Dazu zählen:

  • Alle Debian Pakete
  • nginx, naxsi inkl. Ruleset, Varnish, Apache
  • Node.js und npm
  • PHP inkl. aller Libraries und Composer
  • Alle Datenbanksysteme, also u.A. MongoDB, MariaDB, PostgreSQL, Elasticsearch
  • TYPO3

Für lokale Abhängigkeiten der Projekte – zum Beispiel npm-Packages oder TYPO3 Extensions – empfiehlt es sich, regelmässige Security-Checks durchzuführen. Dank den oben vorgestellten Tools kann innert einiger Minuten festgestellt werden, ob Erweiterungen mit bekannten Sicherheitslücken im Einsatz sind.

Regelmässige Checks

Wenn regelmässige Checks durchgeführt werden, gibt es noch ein paar weitere Arbeiten, welche im Security-Kontext sinnvoll sind. Dazu zählen:

  • Backup Check: Funktioniert das Backup noch überall?
  • Kapazitäten: Gibt es auffällig grosse Tabellen oder Ordner? Ist noch genügend Platz?
  • Latenzen: Stimmen die Besucherzahlen und Antwortzeiten mit der Serverlast überein?
  • Benutzer: Sind noch Accounts von ehemaligen Kollegen vorhanden?
  • Passwörter: Gibt es User mit Blacklisted Passwörtern?
  • Log-Analyse: Gibt es auffällige Aktivitäten? Wie ist die WAF-Hitrate?
  • Malware: Ist die Applikation bei Google Safe Browsing gelistet?

Monitoring

Nicht nur für Denial of Service (DoS/DDos) Angriffe, sondern auch für viele andere der oben genannten Gefahren kann ein ausführliches Monitoring helfen. Als Beispiel ist es erstaunlich nützlich, die Qualität und die Laufzeit von SSL-Zertifikaten und Domain-Namen automatisch zu überwachen, sodass bei Erneuerungen keine Lücken entstehen können.

Supportprozess

Dieses Kapitel ist möglicherweise etwas überraschend, jedoch ist es sehr wichtig zu beachten. Ich habe schon einige Angriffe erfolgreich analysiert und dabei festgestellt, dass zumindest teilweise – häufig aber entscheidend – die Prozesse Ursache für den Erfolg eines Angriffs waren.

Als Denkanstoss möchte ich hier einige aus der Erfahrung gesammelte Beispiele geben:

  • Keine Anfragen von unbekannten Personen beantworten und schon gar nicht erledigen.
  • Bei Anfragen hinsichtlich Passwörtern, DNS-Änderungen.
  • Keine Passwörter in E-Mails versenden. Niemals.
  • Niemals Private Keys versenden. Weder SSH- noch SSL-Private Keys gehören jemals woanders hin als auf den Computer, auf welchem Sie erstellt worden sind.
    • Ausnahme: Unter Umständen kann es nötig sein, SSL Private Keys auszutauschen. Dies darf aber auf keinen Fall über einen ungesicherten Kanal passieren.
  • Keinen FTP-Server installieren
    • Falls es doch nötig ist, dann nur verschlüsselt
  • Wenn möglich, kritische E-Mails verschlüsseln oder zumindest signieren.

Agil?!

Im agilen Umfeld lässt sich das oben Beschriebene beispielsweise in die Definition of Done (DoD) integrieren. So könnte folgender Satz darin stehen:

„Die Arbeiten wurden mit allen anwendbaren Kapiteln der Security Checkliste abgeglichen und entsprechende Massnahmen wurden implementiert.“

Fazit

Wie Sie sehen, ist das Thema umfangreich und vielschichtig. Zu vernachlässigen ist es aber nie! So können kleine pragmatische Sicherheitskonzepte oder hoch komplexe zum Einsatz gelangen, je nach Anforderung.

Anregungen nehmen wir gerne entgegen. Und falls zu einem spezifischen Thema oder Kapitel noch mehr Ausführungen oder Klärungen gewünscht sind, lassen Sie doch einfach einen Kommentar da, auf den wir antworten. Oder vielleicht sehen wir uns ja demnächst an einem Meetup.

Zum Autor: Christoph Buchli ist Senior Web Developer bei snowflake und für den Bereich Web Application Security zuständig.

 

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.