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.

 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 (§ 53 BDSG-neu) 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 (incidents@d-velop.de).
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 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 darf nur TLS in den Versionen 1.2 und 1.3 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.
5. Datenminimierung und Speicherbegrenzung
   Nur Daten, welche für die Funktion der App unbedingt notwendig sind, dürfen verarbeitet und gespeichert werden. Nach der Verarbeitung müssen nicht mehr benötigte (u.a. personenbezogene) Daten unverzüglich gelöscht werden.
6. Signatur der Mandanten-Header
   Bevor eine Anfrage von einer App bearbeitet werden darf, muss die Signatur geprüft werden (HTTP-Header "x-dv-sig-1"). Anfragen mit ungültigen oder fehlenden Signaturen dürfen nicht bearbeitet werden, da nicht sicher gestellt werden kann, dass diese Anfragen vom Approuter stammen.
7. Prüfung auf aktuelle Versionen der eingesetzten Komponenten
   Keine der eingesetzten Komponenten darf eine bekannte Schwachstellen mit einem hohen oder kritischen CVSS-Wert (>= 7.0) enthalten.

 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).

 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.

 Signatur der Mandanten-Header

Bevor eine Anfrage von einer App bearbeitet werden darf, muss die Signatur geprüft werden (HTTP-Header "x-dv-sig-1"). Anfragen mit ungültigen oder fehlenden Signaturen dürfen nicht bearbeitet werden, da nicht sicher gestellt werden kann, dass diese Anfragen vom Approuter stammen.

 Technische Umsetzung

Unter den Basics zu d.velop cloud-Apps findest Du alle Informationen, wie die Signatur-Prüfung implementiert werden muss.

 Prüfung auf aktuelle Versionen der eingesetzten Komponenten

Um zu verhindern, dass über Sicherheitslücken in den eingesetzten Komponenten das System und die Anwender angegriffen werden können, dürfen für die Versionen dieser eingesetzten Komponenten keine Sicherheitslücken bekannt sein. Sollten neue Sicherheitslücken in den eingesetzten Komponenten bekannt werden, müssen zeitnah aktualisierte Versionen der entsprechenden Komponenten verwendet werden.