Unsere Kunden vertrauen darauf, dass ihre Daten bei uns sicher sind. Aus diesem Grund legen wir großen Wert darauf, dass die auf der d.velop cloud Plattform angebotenen Apps entsprechende Sicherheitsstandards erfüllen, die zuverlässig vor unberechtigtem Zugriff und Datenverlust schützen.

Da du als App Builder der Einzige bist, der sowohl die Fachlichkeit als auch den Code deiner App kennt, kannst letztendlich auch nur du dafür sorgen, dass deine App auch wirklich sicher ist. Wir unterstützen dich aber bei dieser Aufgabe, indem wir Sicherheitsstandards definieren und diese auch gemeinsam mit dir überprüfen. Für diese Überprüfung beauftragen wir eine externe Firma, die den Penetrationstest deiner App in der d.velop cloud durchführt.

Hinweis

Bitte beachte, dass sich diese Anforderungen im Laufe der Zeit ändern, da sich auch beim Thema Security ständig neue Angriffsvektoren und entsprechende Gegenmaßnahmen ergeben. Außerdem sind wir gerade dabei, unsere internen Richtlinien ins Developer Portal zu überführen, so dass sich insbesondere in den kommenden Wochen etliche Ergänzungen ergeben werden. Überprüfe also am besten in regelmäßigen Abständen, ob Änderungen an deiner App notwendig sind.

 Sicherheitsstandards

Im Folgenden sind kurz und knapp die Anforderungen an die Informationssicherheit aufgeführt, die deine Organisation und deine App erfüllen müssen.
Ausführlichere Informationen zu der entsprechenden Anforderung sind jeweils verlinkt.

 Organisation

  1. Datenschutzbeauftragter
    Es ist ein betrieblicher Datenschutzbeauftragter gemäß Art. 37 DSGVO bestellt.
  2. Verpflichtung zur Wahrung des Datengeheimnisses
    Sämtliche involvierte Personen sind auf das Datengeheimnis, Art. 32 Abs. 1 b) DSGVO, verpflichtet.
  3. Kommunikation von Sicherheitsvorfällen
    Sicherheitsrelevante Ereignisse, die negative Auswirkungen für die d.velop und deren Kunden haben können (z. B. Verdacht auf Malware oder Informationsdiebstahl), werden protokolliert und unverzüglich an die d.velop berichtet.
  4. Ausscheiden von Mitarbeitern
    Beim Ausscheiden von Mitarbeitern sind sämtliche Zugänge und Berechtigungen unverzüglich zu entziehen. Alle Passwörter, von denen der Mitarbeiter Kenntnis hatte, sind unverzüglich zu ändern. Alle ihm zur Verfügung gestellten Daten und Endgeräte sind einzuziehen. Dies ist in einer Sicherheitsrichtlinie dokumentiert.
  5. Zutrittskontrolle
    Es ist sichergestellt, dass nur berechtigte Personen Zutritt zu relevanten Arbeitsplätzen haben. Der Zutritt wird protokolliert.
  6. Passwortschutz
    Es gibt eine entsprechende Passwortrichtlinie (z.B. mit einer maximalen Anzahl von von Fehllogins und einer definierten Komplexität) und Passwörter werden nur sicher abgelegt. Dies ist in einer Sicherheitsrichtlinie dokumentiert.
  7. Endgerätesicherheit
    Sämtliche Endgeräte erhalten regelmäßig Sicherheitspatches und verfügen über einen stets aktuellen Virenschutz, aktivierte Betriebssystem-Firewall, aktivierte Laufwerksverschlüsselung und eine Bildschirmschoner-Policy mit Kennwortschutz. Dies ist in einer Sicherheitsrichtlinie dokumentiert.
  8. Spamfilter
    Zum Schutz vor Schadsoftware ist eine unternehmensweite Schutzlösung installiert, welche alle eingehenden E-Mails automatisiert überprüft und ggf. blockiert.
  9. Trennung von Entwicklungs- und Produktivumgebungen
    Softwareentwicklung und -tests erfolgen auf getrennten nicht produktiven Umgebungen mit separaten Datenbeständen.

 Applikationssicherheit

  1. Weiterleitung beschränken
    Weiterleitungen, die von außen steuerbar sind, müssen auf die ursprünglich aufgerufene Origin (Scheme, Domain und Port) beschränkt sein. Sollte dies aus fachlichen Gründen nicht möglich sein, muss die App die Möglichkeit bieten, eine Whitelist mit erlaubten Weiterleitungszielen zu definieren.
    Ansonsten wäre es möglich, den Benutzer unbemerkt (z.B. durch eine manipulierte URL) auf eine bösartige Seite zu lenken.
  2. HTTP-Methoden gemäß der Spezifikation verwenden
    Die HTTP-Methoden müssen gemäß ihrer spezifizierten Semantik verwendet werden. Insbesondere darf sich der serverseitige Zustand bei Verwendung von Methoden, die als Safe Methods definiert sind (z.B. GET) nicht ändern.
    Ansonsten würden bestimmte Sicherheitsmaßnahmen, die wir in der d.velop cloud implementiert haben, unter Umständen nicht greifen.
  3. Sichere Transportverschlüsselung
    Der mandantenfähige HTTPS-Endpunkt muss als Mindestversion TLS in der Version 1.2 unterstützen.
  4. Benutzereingaben und Werte aus anderen Quellen vor der Anzeige maskieren
    Wenn Eingaben eines Benutzers oder Werte aus anderen Quellen im Browser zur Anzeige gebracht werden, ohne dass diese Werte zuvor für die Anzeige in einem Browser aufbereitet wurden, ist es möglich beliebigen JavaScript-Code im Browser auszuführen.

 Datensicherheit und Betrieb

  1. Betrieb im Rechenzentrum
    Das Rechenzentrum, in dem die App betrieben wird, ist ISO/IEC 27001 oder vergleichbar zertifiziert.
  2. Verschlüsselung
    Alle persistenten Daten werden (auf Dateiebene) verschlüsselt abgelegt oder auf verschlüsselten Speichermedien (z.B. Laufwerksverschlüsselung) gespeichert.
  3. Firewall
    Nur die notwendigen Schnittstellen (z.B. HTTPS) der App sind direkt aus dem Internet erreichbar. Der Zugriff auf andere Ports (z.B. SSH zur Administration) sind auf IP Adressen eingeschränkt oder nur per VPN erreichbar.
  4. Berechtigungsvergabe
    Die Vergabe von Berechtigungen für Zugriffe auf app-relevante IT-Systeme erfolgt restriktiv und personenbezogen und wird dokumentiert. Benutzer erhalten nur die für ihre Tätigkeit erforderlichen Rechte.
  5. Patchmanagement
    Sämtliche app-relevante IT-Systeme und eingesetzte Softwarekomponenten erhalten regelmäßig Sicherheitsupdates.
  6. Monitoring
    Die Erreichbarkeit und Funktionsfähigkeit der App wird kontinuierlich überwacht. Relevante Ereignisse lösen Alarme (z.B. in Form von E-Mail-Benachrichtigungen) aus.
  7. Löschkonzept
    Bei Kündigung der App durch den Endkunden muss auf entsprechende Benachrichtigungen reagiert werden um daraufhin sämtliche gespeicherten Daten des Kunden zu löschen.
  8. Datensicherungskonzept
    Die Erstellung der Backups erfolgt mindestens einmal pro Tag (RPO: 24 Stunden). Auch bei Kündigung der App durch den Endkunden werden die Backups 30 Tage vorgehalten. Der Wiederherstellungsprozess ist dokumentiert und wird halbjährlich getestet und protokolliert. Das Protokoll umfasst auch Maßnahmen die aus den Ergebnissen abgeleitet werden.
  9. Notfallkonzept
    Ein Disaster-Recovery-Plan beschreibt die Wiederherstellung der App beim Ausfall wesentlicher Komponenten. Das Deployment der App sollte daher vollständig automatisiert und/oder die einzelnen Schritte dokumentiert sein, um die Zeitspanne bis zur Wiederherstellung (RTO) möglichst gering zu halten.

 Ausführliche Informationen zur entsprechenden Anfoderung

 Weiterleitung beschränken

 Angriffsszenario: Unsafe-Redirect

Hierbei wird der Benutzer unbemerkt (z.B. über eine präparierte URL) mit einem Redirect auf die Seite eines Angreifers geleitet. Auf dieser wird er dann zur Eingabe von vertraulichen Informationen wie z.B. Benutzername und Passwort aufgefordert. Da der Redirect von einer d.velop cloud App stammt, d.h. die zuerst angeklickte bzw. eingegebene URL auf eine vertrauenswürdige Origin verweist und der Browser dem Redirect automatisch folgt, sieht es für den Benutzer so aus, als ob die Eingabeaufforderung aus einer vertrauenswürdigen App stammt. Welcher Benutzer achtet schon darauf, dass sich die Adresszeile des Browsers zwischenzeitlich geändert hat und man sich ggf. auf einer ganz anderen Origin befindet, wenn man nach den vertraulichen Daten gefragt wird. Für den Angriff ist es notwendig, dass der Angreifer das Ziel des Redirects direkt oder indirekt beeinflussen kann, um den Benutzer auf die eigene Seite zu leiten.

 Gegenmaßnahmen

Weiterleitungen, die von außen steuerbar sind, müssen auf die ursprünglich aufgerufene Origin (Scheme, Domain und Port) beschränkt sein. Sollte dies aus fachlichen Gründen nicht möglich sein, muss die App die Möglichkeit bieten, eine Whitelist mit erlaubten Weiterleitungszielen zu definieren.

 Technische Umsetzung

Wenn eine Weiterleitung zu absoluten URLs möglich sein soll, muss serverseitig eine Whitelist gepflegt werden können, die zum Filtern der erlaubten URLs verwendet wird.

Wenn nur eine Weiterleitung auf relative URLs möglich sein soll, reicht es aus, den Aufbau der URL im Query-Parameter zu prüfen. Relative URLs beginnen immer mit einem Schrägstrich (Forward slash, 0x2F). In der HTTP-Spezifikation wird allerdings auch definiert, dass eine URL beginnend mit einem doppelten Schrägstrich, gefolgt von http(s):// (oder anderen Schemata), eine gültige Schreibweise für eine absolute URL darstellt. Daher reicht eine einfache Prüfung auf einen Schrägstrich am Anfang des Strings nicht aus, um eine relative bzw. absolute URL zu erkennen.

Zusätzlich dazu, können die Schrägstriche auch in URL-Hex-Notation (%2F) angegeben werden. Daher reicht es nicht aus, auf zwei führende Schrägstriche zu prüfen.

Folgende URLs könnten bei unsauberer Validierung als relative URLs identifiziert werden, stellen aber absolute URLs dar und müssen geblockt werden:

  • //https://evil.com
  • /%2Fhttps://evil.com
  • %2F/https://evil.com
  • %2F%2Fhttps://evil.com

 HTTP-Methoden gemäß der Spezifikation verwenden

Wenn die HTTP-Methoden falsch verwendet werden, hat dass eine Vielzahl von potentiellen Problemen zur Folge. Beispielsweise cachen HTTP-Proxies unter bestimmten Umständen die Antworten auf GET-Requests, so dass nachfolgende GET-Requests auf die selbe Ressource ggf. gar nicht mehr bis zur eigenen App gelangen. Es ist offensichtlich, dass dies problematisch ist, wenn man fälschlicherweise GET verwendet, um Änderungen am serverseitigen Zustand abzubilden und Folge-Requests aufgrund des Caches gar nicht mehr zur App durchdringen.
Als App Builder kann man gar nicht wissen, welche Zwischenstationen ein HTTP-Request durchläuft, bevor er die eigene App erreicht. Der o.g. Proxy könnte beispielsweise ein Teil der Infrastruktur beim Kunden sein. Aus diesem Grunde ist es wichtig, sich an die HTTP-Spezifikation zu halten.

Darüber hinaus haben wir einige grundlegende Sicherheitsmaßnahmen implementiert, die als 1. Verteidigungslinie dienen und darauf basieren, dass die HTTP-Methoden korrekt verwendet werden.

 Basismaßnahme gegen CSRF

Eine dieser Maßnahmen richtet sich gegen Cross-Site-Request-Forgery (CSRF)-Attacken und ist zentral an der HttpGateway App implementiert.

Diese prüft bei HTTP-Methoden, die den serverseitigen Zustand verändern (POST, PUT, PATCH und DELETE), ob der Origin Header im Request mit der Ziel-Origin übereinstimmt und lehnt den Request mit dem Statuscode 403 Forbidden ab, wenn dies nicht der Fall ist (vgl. auch OWASP Cheat Sheet).

Hinweis

Dies ist im Übrigen auch der Grund, warum der Origin Header programmatisch gesetzt werden muss, wenn die API einer App direkt, also nicht über den Browser, aufgerufen wird. Dies gilt allerdings nur, wenn beim Aufruf der API POST, PUT, PATCH oder DELETE verwendet werden.

 Benutzereingaben und Werte aus anderen Quellen vor der Anzeige im Browser maskieren

 Gegenmaßnahmen

Alle im Browser angezeigten Werte müssen maskiert werden, unabhängig von der Quelle, aus der sie stammen.

Folgende Liste zeigt viele, aber nicht zwingend alle Quellen für Werte, die maskiert werden müssen:

  • Konfigurationen
  • Datenbanken
  • Benutzereingaben
  • URL-Parameter
  • Dokumentinhalte
  • API-Schnittstellen
  • Web-Storage

Weitere Informationen findest du auf der Seite Cross-site Scripting (XSS).

 Technische Umsetzung

Apps, die ihre Webseiten im Backend rendern, müssen beim Rendern bereits maskierte Werte einfügen. Alle gängigen Programmiersprachen bieten Maskierungsfunktionen an.

Moderne Frontend-JavaScript-Frameworks übernehmen dies i.d.R automatisch. Es muss aber sichergestellt werden, dass nur die dafür vorgesehenen Funktionen der Frameworks verwendet werden und keine Inhalte auf andere Art und Weise eingefügt werden.