Practical Web Application Security – Teil 1

22. August 2017 von Christoph Buchli Veröffentlicht unter Digitale Transformation, Hosting/Zusatzdienste, Know-how/Tipps&Tricks, TYPO3 Website, Intranet & Extensions, Wartung & Support, Web Applications Verschlagwortet mit , , , ,

In diesem zweiteiligen Blogbeitrag möchte ich einen Denkanstoss zum Thema Informationssicherheit von Webapplikationen geben. Im Fokus stehen dabei Webapplikationen im Umfang und Funktionalität, wie sie von snowflake angeboten werden. Die Überlegungen sind auch generell für die Softwareentwicklung relevant und können entsprechend optimiert angewendet werden.

Websites und Applikationen sind ständiger Gefahr durch Hacker ausgesetzt

TL;DR

Informationssicherheit wird im Umfeld von kleinen bis mittelgrossen Webprojekten relativ wenig Aufmerksam zuteil. Dabei wissen viele Beteiligte gar nicht, dass mit relativ geringen Kosten schon ein guter Grad an Sicherheit erreicht werden kann.

Der zweiteilige Artikel zeigt eine Auswahl an Best Practices auf, mit welchen man auch ohne grosse Mehrkosten die Sicherheit einer Webapplikation auf ein solides Level bringen kann. Dazu gehören regelmässige Software-Updates, ein gutes Verständnis des Zusammenspiels der Applikation mit ihrem Umfeld („DevOps“) und ein ganzheitliches Mindset, welches sicherstellt, dass in allen Phasen eines Softwareprojekts auf die Sicherheit geachtet werden muss. Ausserdem finden sich einige Verweise auf Quellen zur Vertiefung in die Thematik.

Aktuelle Situation

Informationssicherheit ist in aller Munde: Kaum eine Woche vergeht, ohne entsprechende Meldungen in den Medien. Seien es Berichte zu Datenschutz-Gesetzen, Daten-Leaks von Offiziellen oder Ausfälle von wichtigen Diensten. Doch trotz dieser gefühlten Allgegenwart wird das Thema im Auftragsverhältnis oft stiefmütterlich behandelt. So kommt es nicht selten vor, dass in Ausschreibungen für Webprojekte zum Thema nichts ausser dem folgenden Standard-Satz zu lesen ist:

„Der Anbieter stellt für alle Ebenen des Software Stacks sicher, dass die OWASP-Richtlinien eingehalten werden.“

Diese wenig konkrete Formulierung eignet sich kaum, um dem Thema Sicherheit die gebührende Aufmerksamkeit zu verschaffen. Trotzdem ist so eine Absichtserklärung besser als nichts und auch damit kann gearbeitet werden.

Ursache

Die Hauptursache für diese Situation liegt meiner Meinung nach darin, dass Sicherheit für die meisten Beteiligten nicht wirklich greifbar ist. Daher erwarten viele Auftraggeber, dass Sicherheit „out of the box“ kommt und bloss nicht zur Sprache gebracht werden darf, weil es sonst schnell teuer wird. Diese Befürchtung ist nicht ganz unberechtigt, steigen doch die Kosten für eine Verbesserung der Informationssicherheit exponentiell an. Dies resultiert dann leider darin, dass der gewünschte Grad an Sicherheit gar nicht erst diskutiert wird, weil es dafür kein allgemein geläufiges Mass gibt.

Standards und Empfehlungen

Ich sage „geläufiges Mass“, weil es durchaus Ansätze gibt, das Thema anzugehen. Der dem Open Source Gedanken entsprechend vielversprechendste Ansatz ist der Application Security Verification Standard (ASVS) des Open Web Application Security Project (OWASP). Dieses Dokument stellt die Grundlage für den vorliegenden Artikel und die darin enthaltenen Empfehlungen dar. Grundsätzlich ist die Lektüre dieses Standards für alle Projektbeteiligten sehr empfohlen, insbesondere auch für Verfasser einer Ausschreibung. Hat man nämlich dieses Dokument durchgelesen, kommt es einem nicht mehr in den Sinn, oben genannten Satz so stehen zu lassen.

Software Lifecycle

Die wichtigste Voraussetzung dafür, dass die Kosten für Security im Rahmen bleiben, ist, das Thema während des gesamten Lebenszyklus angemessen zu beachten. Denn vernachlässigt man beispielsweise in der Konzeptionsphase die Sicherheit, handelt man sich einen fast nicht mehr aufzuholenden Rückstand ein (jeder hat in diesem Zusammenhang den Begriff der technischen Schuld schon gehört). Aus diesem Grund werden folgend für jeden Lebensabschnitt eines typischen Webprojekts die wichtigsten sicherheitsrelevanten Massnahmen aufgezeigt. Dabei gehe ich von einem vereinfachten Ablauf mit folgenden Tätigkeiten aus:

  1. Initiierung: Kennenlernen der Ziele, der Stakeholder und des groben Umfangs des Projekts
  2. Konzeption: Ausarbeitung des Scopes, des Projektvorgehens und der Lösungsarchitektur
  3. Umsetzung: Implementation der Lösung, üblicherweise iterativ, Go-Live als Abschluss der Phase
  4. Betrieb: Weiterentwicklung, Wartung, Support

Auf die ersten beiden Tätigkeiten werde ich in Rahmen dieses Blogbeitrages detailliert eingehen. Die weiteren Schritte „Umsetzung“ und „Betrieb“ werde ich kommende Woche im zweiten Teil weiter ausführen.

Initiierung

Der wichtigste Schritt in der Projektinitiierung besteht darin, dafür zu sorgen, dass das Thema bei allen Stakeholdern auf dem Radar erscheint. Dabei führt kein Weg daran vorbei, die Informationssicherheit konkret anzusprechen. Da die Diskussion häufig nicht ausdrücklich vorgesehen ist, lohnt es sich, etwas in die Trickkiste zu greifen.

 

Konkrete Schutzziele

Ich erspare dem Leser die Auflistung der Schutzziele für Informationssysteme. Mit etwas Kreativität lassen sich daraus jedoch gute Anhaltspunkte finden, oben kritisierte Stiefmütterlichkeit zu überwinden. Beispielsweise hilft es, sich an einem Workshop mit den richtigen Teilnehmenden eine halbe Stunde Zeit zu nehmen, um auf den Kunden abgestimmte, konkrete Beispiele zu den einzelnen Schutzzielen zu priorisieren. Am effektivsten funktioniert dies, wenn die Risiken aus der Perspektive formuliert werden, wo diese anzutreffen sind. So könnte ein Auszug beispielsweise lauten:

  • Ein User verfasst Kommentare unter dem Pseudonym eines anderen Users.
  • An alle registrierten Benutzer werden Phishing-Mails im Layout der Webseite versendet.
  • Die Kreditkarten-Nummer eines Kunden wird gestohlen.
  • Die Seite ist für einen Arbeitstag nicht erreichbar.
  • Bei Besuchern, welche die Seitensuche nutzen, wird automatisch ein Trojaner installiert.
  • Artikel zeigen dem Besucher andere Informationen an, als vom Redakteur erfasst wurden, etc.

Hinweis: Die Risiken sind bewusst informell gehalten, damit nicht zu viel Anspruch auf Korrektheit entsteht. Alternativ können auch formellere Formulierungen, z.B. nach dem Schema „Es besteht das Risiko, dass…“, diskutiert werden.

Anhand solcher konkreten Beispiele lässt sich relativ einfach ein gemeinsames Verständnis für Informationssicherheit schaffen.

Anforderungen

Nachdem eine lockere Diskussion über die Schutzziele und deren Gewichtung stattgefunden hat, können normalerweise konkretere Anforderungen formuliert werden. Dieses Kapitel könnte ein halbes Buch füllen, aber ich mach’s kurz: Jedes Team erarbeitet und formuliert Anforderungen etwas anders und die Security-Anforderungen sollten sich so normal wie möglich anfühlen. Also können sie in den normalen Prozess einfliessen, allerdings würde ich es am Anfang nicht übertreiben. Mit der Zeit wird es sich so etablieren, dass für die meisten Komponenten ein Grund-Level (siehe nächstes Kapitel) formuliert wird und in den Anforderungen nur noch auf besondere Teile des Systems detaillierter eingegangen werden muss, zum Beispiel, wenn eine Komponente eine höhere Sicherheitsstufe verlangt, weil sie geschäftskritische oder schützenswerte Daten verarbeitet.

Konzeption

In der Konzeptionsphase geht es primär darum, die Weichen zu stellen, um in der Umsetzung die Sicherheitsmassnahmen zu erreichen. Im Zusammenhang mit dem ASVS kann grob gesagt werden: In der Konzeptionsphase wird für jede Komponente das ASVS Level festgelegt, welches die Komponente erreichen muss. Grundsätzlich gehen wir davon aus, dass das Level 1 überall vorausgesetzt wird, und in seltenen Fällen einzelne Komponenten das Level 2 erreichen müssen. Zu bedenken ist beispielsweise, dass wenn in der fraglichen Applikation die Partei- oder Vereinszugehörigkeit eines Benutzers gespeichert wird, diese Level 2 erreichen müsste, da diese Daten schützenswert sind.

Sicherheitskonzept

Für die meisten Applikationen ist kein dediziertes Sicherheitskonzept notwendig. Im Scope dieses Artikels sind auch die Angriffsvektoren relativ gut bekannt: Für das ASVS Level 1 wird grundsätzlich von automatisierten Angriffen mit relativ geringem spezifischem Aufwand seitens des Angreifers ausgegangen.

Trotzdem sollten einige Überlegungen immer in die Konzeption einfliessen:

  • Gibt es Besonderheiten des Systems gegenüber bereits umgesetzten Systemen?
  • Restore-Möglichkeit: Sind spezielle Backup-Massnahmen nötig?
  • Gibt es spezielle Anweisungen an Umsetzung oder Betrieb?
  • Sind Wissenslücken hinsichtlich Sicherheit im Umsetzungsteam zu beachten?

Systemdesign

Meiner Meinung nach gilt für jedes System folgender Grundsatz: Das Sicherheitsrisiko verhält sich linear zur Komplexität. Daher ist es nie eine gute Idee, aus Sicherheitsgründen ein System komplexer zu gestalten, als es zur Erfüllung des Systemzwecks nötig ist. Konkret heisst dies zum Beispiel: Wenn ein einfaches CMS-System mit einer DB und etwas JavaScript im Frontend auskommt und aus Sicherheitsgründen auf 5 Microservices aufgeteilt wird, welche via Docker auf verschiedenen Servern laufen, dann bist du garantiert auf dem Holzweg.
(Hinweis: Solch eine Lösungsarchitektur kann durchaus Sinn machen, wenn die Applikation entsprechend komplex ist).

Ausserdem ist in Anlehnung an das Kapitel „V1“ des ASVS wichtig, dass für jede Systemkomponente klar und ausdrücklich spezifiziert wird, was ihre Aufgabe ist.

Deployment

Die Verteilungssicht des Systems kann ebenfalls helfen, für Sicherheitsmassnahmen das korrekte Level festzustellen. Grundsätzlich halte ich mich dabei jeweils an folgendes Prinzip: Je mehr Software an einem Ablauf beteiligt ist, desto mehr potentielle Sicherheitslücken können ausgenutzt werden. Wenn man diesem Grundsatz folgt, heisst dies, dass aus Deployment-Sicht Sicherungen auf tieferen Levels zu bevorzugen sind.

Zum Beispiel ist es tendenziell sicherer, wenn der Datenbank-Server eine Firewall-Regel hat, welche auf Level IP sicherstellt, dass nur der Webserver darauf Zugriff hat, als wenn man einen öffentlich erreichbaren Server per Benutzername & Passwort Kombination schützt.

Aus diesem Grund setzen wir insbesondere für APIs oft Reverse Proxies (mittels Varnish und/oder nginx) ein, welche den eingehenden Verkehr mittels Web Application Firewall (WAF) und SSL-Zertifikaten absichern können.

Zwischenfazit und Ausblick auf den zweiten Teil

Wir haben de facto noch keine Zeile Code programmiert, uns aber schon eingehend mit dem Thema Sicherheit beschäftigt. Eine gute Sensibilisierung und die entsprechende Konzeption bilden das Fundament für die anschliessende Programmierung und den sicheren Betrieb der Software-Lösung. Wir können so ohne riesige Mehrkosten die Sicherheit einer Webapplikation auf ein solides Level bringen. Das gelingt aber nur, wenn das Thema Sicherheit bereits zu Beginn eines Software-Projektes als integraler Bestandteil einer Lösung betrachtet wird.

Im zweiten Teil werde ich näher auf die Themen Umsetzung und Betrieb eingehen. Dabei werde ich das Augenmerk auf den Praxiseinsatz legen und auch aufzeigen, wie wir das bei uns im Alltag umsetzen.

 

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.