Vorlage für Web-Security-Standard (TSS-WEB)

Version 1.3.1

Ein Standard der Secodis GmbHLizensiert unter der Creative Commons Lizenz

Über TSS-WEBDieses Dokument beschreibt exemplarische Inhalte eines technische-organisatorischen Sicherheitsstandards für Webanwendungen, der als Grundlage oder Anregung für unternehmensinterne Standards verwendet werden darf. Konkrete Umsetzungshinweise (z. B. in Bezug auf zu setzende Response-Header oder Vorgaben an kryptographische Verfahren) sollten als Anhang oder separat beschrieben werden.

Es wurde von der Secodis GmbH erstellt und kontinuierlich weiterentwickelt. Die aktuelle Version des Dokuments kann unter https://www.secodis.com/tss-web heruntergeladen werden. Wir haben unter https://groups.google.com/d/forum/tss-web ein Forum eingerichtet, an das sich auch direkt mittels tss-web@googlegrooups.com Fragen und Anmerkungen stellen lassen.

Bei den in diesem Dokument beschriebenen Vorgaben handelt es sich um Best Practices, die sich auf Unternehmen eines mittleren Bedrohungspotentials und durchschnittlichen Risikoappetits beziehen. Generell wird empfohlen, die einzelnen Anforderungen vor der Einführung dieses Standards hinsichtlich ihrer Angemessenheit für ein betrachtetes Unternehmen zu prüfen und ggf. anzupassen. Auch kann es empfehlenswert sein, diese Vorlage um konkrete Vorgaben im Hinblick auf die Verwendung vorhandener Infrastruktur oder architektonischer Patterns, die spezifisch zu einem betrachteten Unternehmen (z. B. eine WAF oder ein Access Gateway) oder lokale Umgebung sind, zu ergänzen.

Empfehlung: Verknüpfen Sie bei Bedarf eigene Checklisten, Guidelines, Bugbars und Standards mit diesem Standard. Dokumentieren Sie Ausnahmen zu einzelnen Vorgaben in einem entsprechenden Register sowie im Sicherheitskonzept der entsprechenden Anwendung.

Erklärungen und Hintergrundwissen zu den Inhalten in diesem Dokument finden Sie u.a. in dem Buch „Sicherheit von Webanwendungen in der Praxis“ (www.webappsecbuch.de).

Lizenz

Dieses Dokument ist lizenziert unter der Creative Commons Namensnennung 4.0 International Lizenz (http://creativecommons.org/licenses/by/4.0). Die Vervielfältigung, Verbreitung und Veränderung dieses Dokumentes zu firmeninternen Zwecken, ist gestattet. Geänderte Dokumente müssen nicht unter dieselbe Lizenz gestellt werden (kein Copyleft bzw. Share Alike). Im Gegenzug verpflichtet sich der Lizenznehmer den Autor, den Namen und die Bezugsquelle sowie die Version der verwendeten Vorlage deutlich auszuweisen.

Matthias RohrSecodis GmbH

TSS-WEB v1.3.1 Seite 1

Änderungshistorie

Version Datum Inhaltliche Änderungen

1.0 20.02.2015 Release (siehe Changelog für Anpassungen gegenüber Vorabversionen)

1.01 21.03.2015 Neue Definition „Vertraulicher Programmcode“ und deren konsistente Verwendung im Standard.

1.02 1.7.2015 Korrektur mehrere Typos und Formulierungen ohne inhaltliche Änderungen.

1.1 26.11.2015 Zahlreiche Anpassungen, siehe Changelog

1.2 10.5.2016 Einbau von Anforderungen für Rest Services (8.16.7)

Mehrere sprachliche Anpassungen

Änderung des Titels

Neues Layout

1.3 29.8.2016 Vollständige Überarbeitung im Rahmen der englischen Übersetzung

Einführung neuer Schutzklassen

Anpassungen bzgl. Sicherheit in agilen Projekten

1.3.1 28.11.2016 Anpassung an CSP-Statements

CVSS Scoring für 3rd-Party-Komponenten eingefügt

TSS-WEB v1.3.1 Seite 2

Sicherheitsstandard fürWebanwendungen

Firma [Firma]

Version: 1.0Klassifikation: INTERN

Inhalt1 Einführung........................................................................................................................................4

1.1 Geltungsbereich........................................................................................................................4

1.2 Arten von Vorgaben.................................................................................................................4

1.3 Definitionen..............................................................................................................................4

1.4 Rollen........................................................................................................................................5

1.5 Schutzklassen............................................................................................................................6

2 Beheben von Schwachstellen in Anwendungen...............................................................................7

3 Sicherheit für den Betrieb von Anwendungen..................................................................................8

4 Sicherheit von Source- und Programmcode...................................................................................10

5 Sicherheit im Entwicklungsprozess................................................................................................11

6 Sicherheitstests...............................................................................................................................13

7 Zulieferervorgaben.........................................................................................................................15

8 Implementierungsvorgaben............................................................................................................16

8.1 Allgemeine Grundsätze..........................................................................................................16

8.2 Eingabevalidierung.................................................................................................................16

8.3 Dateiuploads und -downloads................................................................................................17

8.4 Ausgabevalidierung (Enkodierung & Escaping)....................................................................18

8.5 Authentifizierung & Registrierung von Benutzern................................................................18

8.6 Benutzerpasswörter I: Stärke und Behandlung.......................................................................19

8.7 Benutzerpasswörter II: Änderung und Zurücksetzung...........................................................20

8.8 Authentifizierung am Backend...............................................................................................20

8.9 Inter-Komponenten-Authentifizierung (Authentifizierung am Frontend)..............................21

8.10 Absicherung des Session Managements.................................................................................21

8.11 Zugriffskontrollen (Access Controls).....................................................................................22

8.12 Fehlerbehandlung & Logging.................................................................................................22

8.13 Datensicherheit & Kryptographie...........................................................................................23

8.14 Verwaltung technischer Schlüssel..........................................................................................23

8.15 Clientseitige Sicherheit...........................................................................................................24

8.16 Webdienste und XML-Parser.................................................................................................24

Anhang A: Vorgaben für HTTP Security Header..................................................................................26

Anhang B: Häufige Schwachstellen für Webanwendungen (OWASP Top 10).....................................28

Muster AG Seite 2

Dokumenteigenschaften

Ablageort tbd

Owner tbd

Typ Technischer Standard

Klassifikation Nur für internen Gebrauch (INTERN)

Nächster Review tbd

Referenzierte Dokumente

Dokument Ablageort

TSS-WEB Version 1.3.1 (Vorlage) https://www.secodis.com/tss-web

Information Security Policy tbd

Passwort Policy tbd

Ansprechpartner für dieses Dokument

Name E-Mail Bereich

Änderungshistorie

Version Datum Änderungen Geändert von

0.1 20.12.2016 Initiales Dokument auf Basis von TSS-WEB v1.3.1

Max Mustermann

Muster AG Seite 3

1 EinführungDieser Standard beschreibt generelle Sicherheitsvorgaben (Baseline) für alle webbasierten Anwendungen, oder Anwendungskomponenten, die von oder für die [Firma] neu entwickelt werden. Dieses Dokument hat zum Ziel ein Basissicherheitsniveau zu definieren, welches im Bedarfsfall jedoch überschritten werden kann und auch sollte, sofern ein höherer Schutzbedarf (bzw. Gefährdungspotential) für eine Anwendung vorliegt.

1.1 Geltungsbereich

Dieser Standard gilt für alle ab dem [DD].[MM].[JJJJ] von der [Firma] neuentwickelten, in Auftrag gegebenen oder eingekauften und produktiv eingesetzten webbasierten Anwendungen oder Anwendungskomponenten bzw. der darunterliegenden Infrastruktur. Für alle übrigen besitzen diese Vorgaben Empfehlungscharakter.

1.2 Arten von Vorgaben

In diesem Standard werden gemäß RFC2119, zwei grundsätzliche Arten von Vorgaben unterschieden:

- Verbindliche Vorgaben: Kennzeichnung durch Schlüsselworte „MUSS“, „MÜSSEN“, „SIND“, „DARF NICHT“ etc.

- Empfehlungen: Kennzeichnung durch die Schlüsselworte „SOLLTE“, „KANN“, etc.

Von der Verwendung von Empfehlungen, darf im Fall von begründbaren Einwänden abgewichen bzw. abgesehen werden. Empfehlungen, die mit „KANN“ gekennzeichnet sind, beziehen sich vor allem auf Anwendungen, die ein höheres Schutzniveau anstreben.

Ausnahmen zu den Pflichten müssen begründet und durch die IT-Sicherheit genehmigt werden.

1.3 Definitionen

Diesem Standard liegen die folgenden Begriffsdefinitionen zugrunde:

- Anwendung: Hier: Synonym für Webanwendung.

- Webanwendung: Ein Softwareprogram, Service oder eine Kombination aus diesen welches über HTTP oder HTTPS aufrufbar ist.

- Web-basierte Anwendung: Siehe Webanwendung.

- Interne Webanwendung: Eine Webanwendung die nur innerhalb des Unternehmens aufrufbar ist.

- Externe Webanwendung: Eine Webanwendung die von außerhalb des Unternehmens (z. B. über das Internet) aufrufbar ist.

- Service: Hier: Synonym für Web-basierten Dienst, z.B. Web Services oder Rest Services.

- Change: Jede Änderung an einer produktiven Anwendung außerhalb eines Releases.

- Kritikalität: Hier: Synonym für Geschäftskritikalität.

Muster AG Seite 4

- Source Code Repository: System in dem selbstentwickelter Sourcecode abgelegt wird (z.B. SVN, Github).

- Dependency Repository: System, in welchem 3rd-Party-Komponenten (z.B. Bibliotheken, Maven Artefakte) abgelegt sind.

- Vertrauliche Daten: Daten, welche

(1) vertrauliche Informationen enthalten bzw. enthalten könnte (z.B. Patente, sensible Rechenlogik, personenbezogene Daten, Passwörter),

(2) explizit als solcher gekennzeichnet wurden oder

(3) allgemein nur einem eingeschränkten Personenkreis zugänglich sind bzw. sein sollen.

- Vertraulicher Source- oder Programmcode: Source- bzw. Programmcode der -> Vertrauliche Daten darstellt.

- Interner Source- oder Programmcode: Source- bzw. Programmcode, welcher nicht vertraulich oder öffentlich ist (Standard).

1.4 Rollen

In diesem Standard werden die folgenden Rollen verwendet:

- Security Auditor: Sachverständige Person, welche Sicherheitsfreigeben durchführt. Im Fall von agilen Teams kann die Rolle (bzw. bestimmte Aufgabenbereiche) auf einen lokalen Security Champion übertragen werden.

- Security Champion: Lokaler Experte für Applikationssicherheit (z.B. in einem Entwicklungsteam).

- Application Owner: Fachlicher „Eigentümer“ der Anwendung (gewöhnlich der Fachbereich)

Referenzierungen auf diese Rollen sind in diesem Standard kursiv gekennzeichnet.

Muster AG Seite 5

1.5 Schutzklassen

Einige Anforderungen in diesem Standard hängen von bestimmten Aspekten einer Anwendung ab.

Zum einen betrifft diese deren Zugreifbarkeit, ob diese von extern (z.B. aus dem Internet) oder ausschließlich intern aufrufbar ist. Zum anderen den Schutzbedarf der von der Anwendung verarbeiteten Daten im Hinblick auf deren Vertraulichkeit und Integrität:1

Zugreifbarkeit der Anwendung

Interne Anwendung(Nicht aus dem Internet

erreichbar)

Externe Anwendung(Aus dem Internet erreichbar)

Ver

traul

ichk

eit /

Inte

gritä

t

<= MITTEL Niedrig Standard

HOCH Standard Hoch

SEHR HOCH Hoch Sehr Hoch

Tabelle 1-1: Schutzklassen für Anwendungen

1 Die Verfügbarkeit stellt ein weiteres Schutzziel dar, welches hier jedoch keine Betrachtung findet, da diese sich eher auf operative Aspekte als die in diesem Dokument spezifizierten Sicherheitsanforderungen auswirkt.

Muster AG Seite 6

2 Beheben von Schwachstellen in AnwendungenIdentifizierte Sicherheitsprobleme in Anwendungen sind generell zeitnah und ursächlich zu beheben. Sofern die ursächliche Behebung einer Schwachstelle von der ein signifikantes Risiko ausgeht jedoch eine bestimmte Zeit erfordert, SOLLTEN temporäre und schnell umsetzbare Maßnahmen ergriffen werden, um deren Ausnutzbarkeit bis zur tatsächlichen Behebung der Schwachstelle zu unterbinden. Eine solche Maßnahme DARF immer nur als temporäre Maßnahme betrachtet werden, welche das durch eine Schwachstelle ausgehende Risiko verringert, bis eine ursächliche Korrektur erfolgt ist.

In Bezug auf Anwendungen, welche aus dem Internet erreichbar sind, gelten hierbei die folgenden zeitlichen Vorgaben bis zu welchem Zeitpunkt eine Schwachstelle spätestens korrigiert, bzw. deren Ausnutzbarkeit durch eine temporäre Maßnahme zu unterbinden sein MUSS:

Bewertung der Schwachstelle

Als „kritisch“ bewertete Schwachstelle

Als „hoch“ bewertete Schwachstelle

Als „mittel“ bewertete Schwachstelle

Krit

ikal

ität2 d

er

Anw

endu

ng

Kritische Anwendung

zum nächsten Arbeitstag

Innerhalb von 7 Tagen3

Im Rahmen des nächsten Releases, jedoch spätestens nach 6

Monaten.

Nicht-kritische Anwendung

Innerhalb von 7 Tagen

Innerhalb von21 Tagen

-

Tabelle 2-2: Vorgaben zur Behebung von Schwachstellen für externe Anwendungen

In Bezug auf Anwendungen, welche nicht aus dem Internet erreichbar sind (interne Anwendungen), MÜSSEN die folgenden Vorgaben beachtet werden:

Bewertung der Schwachstelle

Als „kritisch“ bewertete Schwachstelle

Als „hoch“ bewertete Schwachstelle

Als „mittel“ bewertete Schwachstelle

Krit

ikal

ität d

er

Anw

endu

ng

Kritische Anwendung

Innerhalb von 7 Tagen

Innerhalb von 30 Tagen

Im Rahmen des nächsten Releases, jedoch

spätestens nach 12 Monaten.

Nicht-kritische Anwendung

Innerhalb von 21 Tagen

Innerhalb von 60 Tagen

-

Tabelle 2-3: Vorgaben zur Behebung von Schwachstellen für interne Anwendungen

2 Kritikalität = Geschäftskritikalität3 Tage = Kalendertage

Muster AG Seite 7

3 Sicherheit für den Betrieb von AnwendungenDie folgenden Vorgaben gelten für infrastrukturelle Komponenten, auf denen produktive Anwendungen der [Firma] ausgeführt werden:

1. Produktivsystemen MÜSSEN strikt von Entwicklungs- und Testsystemen (d.h. infrastrukturell, applikationsseitig sowie bezüglich der Daten) voneinander getrennt werden.

a) Produktivdaten SOLLTEN auf Nicht-Produktivsystemen nicht verwendet werden.

b) Wenn die Verwendung von Produktionsdaten für die Durchführung fachlicher Tests auf Nicht-Produktionssystemen unbedingt erforderlich sein sollte, so MÜSSEN diese Daten zuvor vollständig anonymisiert werden, so dass hierdurch keinerlei Personenbezug (direkt oder indirekt) mehr besteht. Dies kann automatisiert erfolgen.

c) Benutzer MÜSSEN dediziert für alle Umgebungen privilegiert werden.

2. Produktiv eingesetzte Plattformen (z. B. Webservern, Applikationsserver, Content Management Systemen) MÜSSEN nach gängigen Best Practices gehärtet werden. Dies betrifft:

a) Abschaltung von nicht benötigten Diensten, Plugins und sonstigen Funktionen (z.B. Directory Indexing) auf diesen Systemen.

b) Abschalten unsicherer oder nicht benötigter HTTP-Methoden (insb. TRACE und TRACK).

c) Deaktivierung von WebDAV-Funktionen sofern nicht benötigt. Sofern unbedingt erforderlich, Härten der Funktion gemäß Least-Privilege-Prinzip.

d) Abschalten nicht erforderlicher Dateihandler (z. B. „.php“ bei einer Java-Anwendung)

e) Web- und Applikationsserver dürfen keine Details (z.B. Versionsnummern) des serverseitigen Software-Stacks offenlegen. Entsprechende Response Header (z. B. „Server“ oder „X-Powered-By“) sind hierzu genauso zu minimieren bzw. deaktivieren wie in HTML-Code (oder anderer Stelle) eingetragene Informationen.

3. Netzwerkdienste (z.B. von Web- und Applikationsserver) MÜSSEN mit einer dedizierten Systemkennung und minimalen Berechtigungen ausgeführt werden. Extern erreichbare Dienste SOLLTEN zusätzlich in einer abgeschotteten Umgebung (z,B. chroot oder Docker) betrieben werden.

4. Aus einer über das Internet zugänglichen Netzwerkbereich (DMZ) DARF NICHT auf das interne Netzwerk zugegriffen werden können. Dies ist Netzwerkseitig zu unterbinden.

5. Administrative Schnittstellen SOLLTEN NICHT über das Internet verfügbar sein. Sofern zwingend erforderlich, MUSS dort eine starke Authentifizierung (z. B. Mehrfaktor-Authentifizierung, X.509-Zertifikat + Passwort) erfolgen.

6. Anwendungen, die sowohl intern als auch extern erreichbar sind SOLLTEN entsprechend in eine interne und externe Instanz separiert werden, wobei Zugriffe von der externen Instanz nicht auf die interne erfolgen dürfen.

Muster AG Seite 8

7. Anwendungen, die aus dem Internet erreichbar sind, KÖNNEN über eine Webanwendungsfirewall (WAF) zusätzlich geschützt werden. Solche Systeme lassen sich auch als Application IDS und der Durchführung von Virtual Patching einsetzen. WAFs (oder vergleichbare Systeme) DÜRFEN jedoch NICHT im Rahmen der Entwicklung oder der Testdurchführung aktiv sein und keinesfalls als Ersatz für anwendungsinterne Sicherheitsmaßnahmen eingesetzt werden.

8. Anwendungen SOLLTEN periodisch und möglichst automatisiert auf mögliche Sicherheitsbedrohungen (z.B. Schwachstellen in eingesetzten Standardkomponenten, unsichere Konfiguration, abgelaufene Zertifikate, Malware) hin geprüft werden.

Muster AG Seite 9

4 Sicherheit von Source- und ProgrammcodeDie folgenden Vorgaben gelten für den Schutz des Source- und Programmcodes von produktiven Anwendungen und Services der [Firma], sowie der Sicherheit dort eingebundener 3rd-Party-Komponenten:

1. Alle Zugriffe auf vertraulichen Source- oder Programmcode MÜSSEN auf berechtigte Personengruppen beschränkt werden (Need-to-Know-Prinzip). Dies schließt die Authentifizierung und Autorisierung entsprechender Zugriffe in Code Repositorys (z.B. SVN, Git), Build-Systeme (z.B. Jenkins), Wikis und auf dem Dateisystem ein.

2. Der Austausch von eigenem Source- oder Programmcode außerhalb der [Firma] DARF NUR über sichere Kanäle (z. B. S/MIME oder per TLS) erfolgen.

3. Source- oder Programmcode DARF NUR nach expliziter Freigabe (z.B. in Internet Foren) veröffentlicht oder Externen ohne entsprechende Freigabe durch den Security Auditor zugänglich gemacht werden.

4. Sicherheit von 3rd-Party-Komponenten

a) Werden externe Dependency Repositorys (z.B. Maven Repositorys) angebunden MUSS sichergestellt werden, dass diese vertrauenswürdig sind. Hierfür ist ein entsprechender Freigabeprozess festzulegen.

b) Bevor eine neue 3rd-Party-Komponente in der Produktion (bzw. der Release Build Umgebung) eingebunden wird, MUSS diese vom das Architektur Board freigegeben werden. Neue Versionen (inkl. Major Releases) bereits freigegebener Komponenten sind hiervon nicht betroffen.

c) 3rd-Party-Komponenten SOLLTEN vor ihrer Verwendung in produktiven Anwendungen automatisiert auf mögliche Schwachstellen (insb. Known Vulnerabilities) geprüft und die Verwendung einer solchen Komponente im Verdachtsfall unterbunden (Abbruch des Builds) werden.

d) Allgemein SOLLTEN keine 3rd-Party-Komponenten mit einem CVSS4 Scoring >= 7 produktiv gehen. Entsprechende Schwachstellen werden mit als „hoch“ bewerteten in in Custom Code gleichgesetzt.

e) 3rd-Party-Komponenten SOLLTEN darüber hinaus auch periodisch innerhalb des Dependency Repositorys (z.B. Nexus) mittels geeigneter Tools im Hinblick auf neu bekanntgewordene Schwachstellen (insb. Known Vulnerabilities) geprüft werden.

f) Für 3rd-Party-Komponenten SOLLTE ein dedizierter und toolbasierter Patch-Management-Prozess etabliert werden (3rd-Party-Patch-Management).

4 CVSS = Common Vulnerability Scoring System (CVSS), https://www.first.org/cvss

Muster AG Seite 10

5 Sicherheit im Entwicklungsprozess Die folgenden Vorgaben gelten für alle im Rahmen von Projekten sowie der Linie entwickelte Anwendungen innerhalb der [Firma]:

1. Sicherheit MUSS im Rahmen des gesamten Entwicklungsprozesses angemessen Betrachtung finden (Anforderungen, Architektur, Implementierung, Test, Deployment und Betrieb); Entscheidungen MÜSSEN laufend auf mögliche Sicherheitsimplikationen hinterfragt werden.

2. Security Gates (Sign-Offs):

a. Die Umsetzung der Vorgaben dieses Standards MUSS für alle externen bzw. allgemein kritischen Anwendungen im Rahmen des Entwicklungsprozesses durch den Security Auditor im Hinblick auf Vollständigkeit und Korrektheit geprüft werden.

b. Im Rahmen der Initiierungs- bzw. Genehmigung neuer Projekte MUSS eine Sicherheitsfreigabe durch den Security Auditor erfolgen.

c. Die (Sicherheits-)Architektur sowie relevante Teile des Sicherheitskonzepts MÜSSEN, sofern dies durch den Security Auditor gefordert wurde, vor Beginn der Implementierung abgenommen werden.5

d. Vor deren Produktivnahme MUSS jede externe oder geschäftskritische interne Webanwendung ein definiertes Security Gate durchlaufen. Dies KANN in Form einer formellen Sicherheitsabnahme durch den Security Auditor erfolgen (erforderlich bei Major Releases). Siehe hierzu Kap. 6). 6

e. Umfang und Tiefe eines Abnahme IST durch den Security Auditor festzulegen und ist allgemein abhängig vom Gefährdungspotential (bzw. Schutzbedarf) einer Anwendung.

f. Sollten im Rahmen eine Freigabe sicherheitsrelevante Mängel (bzw. Abweichungen von diesem Standard) identifiziert werden, MÜSSEN diese beseitigt oder die dadurch entstehenden Sicherheitsrisiken durch den Application Owner akzeptiert werden, bevor die Anwendung produktiv gesetzt werden darf.

g. Alle Freigaben und Risikoübernahmen MÜSSEN dokumentiert werden.

h. Security Gates MÜSSEN ebenfalls im Rahmen des Change Managements für sicherheitsrelevanten Änderungen an Bestandsanwendungen implementiert werden.

3. Zu jeder neu entwickelten geschäftskritischen Anwendung MUSS ein Sicherheitskonzept erstellt und dieses durch den Security Auditor abgenommen werden. In diesem SIND, sofern nicht anders mit dem Security Auditor abgestimmt, die folgenden Aspekte zu dokumentieren:

Systemübersicht (relevante Anwendungskomponenten, Schnittstellen intern/extern, verarbeitete Daten, Datenflüsse)

Zugrundeliegende Sicherheitsvorgaben (z. B. Sicherheitsstandards)

Bekannte Bedrohungen (z. B. in Form eines Bedrohungsmodells)5 Anmerkung zu agil entwickelten Anwendungen: Im Fall von Änderungen bzw. agil entwickelten Projekten können vom Security Auditor Kriterien festgelegt werden, für welche Arten von Änderungen an der Architektur eine erneute Freigabe erforderlich ist.6 Anmerkung zu agil entwickelten Anwendungen: In diesem Fall ist eine explizite Freigabe lediglich bei initialen sowie Major Releases erforderlich. Sonstige Änderungen sind wie unten beschrieben durch den Security Change Management Prozess abgedeckt und erfordern die Prüfung gegen einen Security Indikator.

Muster AG Seite 11

Sicherheitsarchitektur

Sicherheitsmaßnahmen / -Anforderungen (fachlich und technisch)

Sicherheitsumsetzungsplanung (z. B. geplante Pentests)

4. Entwicklertests : Selbstentwickelte sicherheitsrelevante Funktionen (z. B. Access Controls oder Kryptographie-APIs) externer bzw. geschäftskritischer Anwendungen SOLLTEN durch die Entwicklungsteams selbst analysiert und bei Bedarf freigegeben werden. Dies betrifft auch an diesen durchgeführten Änderungen.

a. Automatisiert mittels geeigneten Tools zur statischen Codeanalyse sowie Security Unit Tests.

b. Manuell: Z.B. mittels Peer-Code-Reviews von sicherheitsrelevantem Code unter Entwicklern oder durch den Entwickler selbst, mittels Durchführung von einfachen Sicherheitstests des selbstentwickelten Codes.

Muster AG Seite 12

6 SicherheitstestsDie folgenden Vorgaben gelten in Bezug auf die Durchführung von Sicherheitstests von Anwendungen der [Firma]:

1. Die korrekte und vollständige Umsetzung jeder sicherheitsrelevanten Anforderung MUSS durch einen entsprechenden Sicherheitstest verifiziert werden.

2. Weiterhin SOLLTEN Anwendungen auch im Hinblick auf potentielle Sicherheitsprobleme analysiert werden, die zwar nicht explizit durch Sicherheitsanforderungen adressiert wurden, die jedoch Sicherheitsrisiken zur Folge haben können.

3. Wo dies möglich und sinnvoll ist, SOLLTEN Sicherheitstests bereits frühzeitig (etwa im Rahmen der Entwicklung) durchgeführt werden (siehe hierzu auch entsprechende Vorgaben in Abschnitt „Sicherheit im Entwicklungsprozess“).

4. Jede Änderung an einer produktiven Anwendung (Change) MUSS im Hinblick auf die Notwendigkeit bewertet werden ob für diese ein Sicherheitstest erforderlich ist.

5. Vor jeder Produktivnahname einer externen oder geschäftskritischen internen Anwendung, jeder sicherheitsrelevanten Änderung an einer solchen Anwendung die sich bereits in Produktion befindet sowie periodisch und abhängig von der Kritikalität und Erreichbarkeit einer Anwendung, MUSS ein Pentest durchgeführt werden. Hierfür gilt die folgende Security Testing Policy: 

Erreichbarkeit der Anwendung

Externe Anwendung(Aus dem Internet erreichbar)

Interne Anwendung(Nicht aus dem Internet erreichbar)

Krit

ikal

ität d

er

Anw

endu

ng

Kritische Anwendung

Vor Produktivsetzung und min einmal jährlich7

Zeitnah zur Produktivsetzung und min alle drei Jahre

Nicht kritische Anwendung

Vor Produktivsetzung und min alle zwei Jahre

-

Tabelle 6-4: Policy für die Durchführung von Pentests

6. Bei der Durchführung von fachlichen Tests SOLLTEN auch Sicherheitsaspekte getestet werden.

7. Sicherheitsabnahmen DÜRFEN NUR von Security Auditoren durchgeführt werden.

8. Nach der Korrektur jeder Schwachstelle MUSS im Rahmen eines Retests die Wirksamkeit der Maßnahme verifiziert werden. Idealerweise SOLLTE dieser durch denselben Tester erfolgen, der auch die Schwachstelle ursprünglich identifiziert hatte.

9. Auf Entwicklungs- und Testsystemen DÜRFEN NUR synthetische oder anonymisierte Produktivdaten verwendet werden, die keinerlei Vertraulichkeit, bzw. einen indirekten oder direkten Personenbezug ermöglichen, besitzen.

10. Sicherheitsabnahmen SOLLTEN in einer produktionsnahen Testumgebung durchgeführt

7 Sofern sichergestellt ist, dass in dieser Zeit keinerlei Änderungen an der betreffenden Anwendung durchgeführt wurden, DARF das Intervall um zwei weiteres Jahre verlängert werden. Spätestens dann muss jedoch unabhängig von Änderungen eine neue Sicherheitsprüfung erfolgen, damit bis dahin neu bekanntgewordene Sicherheitsbedrohungen berücksichtigen werden.

Muster AG Seite 13

werden (z. B. in der Integrationsumgebung).

11. Die Durchführung von Sicherheitstests DARF NICHT durch eine perimetrische Sicherheitskomponente (z. B. eine Webanwendungsfirewall) beeinflußt werden können.

Muster AG Seite 14

7 ZulieferervorgabenDie folgenden Vorgaben gelten zusätzlich zu den übrigen Vorgaben dieses Dokuments für Lieferanten, die im Auftrag der [Firma] Software entwickeln und sollten im Rahmen von vertraglichen Vereinbarungen aufzuführen. Der Auftragnehmer MUSS sich zu den folgenden Punkten zu verpflichten:

1. Zur Einhaltung der allgemeinen Sorgfaltspflicht: Alle erforderlichen Maßnahmen innerhalb von Entwicklung, Betrieb und Qualitätssicherung werden umgesetzt, um das Auftreten von Sicherheitsmängeln zu vermeiden und den geltenden „Stand der Technik“ in Bezug auf Sicherheit umzusetzen.

2. Zur Umsetzung der in diesem Dokument genannten Implementierungsvorgaben.

3. Einen Ansprechpartner für Sicherheitsfragen in seinem Hause zu benennen, der konstruktiv bei der Bewertung und ggf. Behebung von Sicherheitsbefunden mitarbeitet.

4. Nur autorisierte und erforderliche (Need-to-Know-Prinzip) Personen Zugriff auf den im Auftrag erstellten Sourcecode besitzen.

5. Den im Auftrag erstellten Sourcecode bei Bedarf für die Durchführung einer Sicherheitsuntersuchung zur Verfügung zu stellen („Right to Audit“).

6. Auf eine kostenneutrale und zeitnahe Korrektur identifizierter Sicherheitsprobleme (vgl. Vorgaben in Kapitel 2). Was hierbei ein zu korrigierendes Sicherheitsproblem darstellt, wird einzig durch die [Firma] festgelegt.

7. Wünschenswert: Auf Umsetzung des in V-BSIMM8 festgelegten organisatorischen Reifegrades seiner Applikationssicherheit.

8 vgl. http://www.bsimm.com/related/

Muster AG Seite 15

8 ImplementierungsvorgabenDie folgenden Vorgaben gelten für die Implementierung neuer webbasierter Anwendungen der [Firma].

8.1 Allgemeine Grundsätze

1. Minimierung der Angriffsfläche: Nicht erforderliche oder benötigte Schnittstellen, Funktionen, Parameter, Dienste und Protokolle MÜSSEN auf extern erreichbaren Systemen und SOLLTEN auf allen sonstigen Systemen deaktiviert werden.

2. Mißtrauensprinzip: Daten, die von einem Client stammen MÜSSEN stets mißtraut und diese daher entsprechend validiert werden.

3. Mehrschichtige Sicherheit (Defense-in-Depth-Prinzip): Es SOLLTE stets eine mehrschichtige Sicherheit implementiert werden.

4. Anpaßbarkeit von Sicherheitseinstellungen: Sicherheit SOLLTE stets deklarativ (= mittels Konfigurationsanweisungen oder Annotationen) statt programmatisch (= mittels Programmcode) parametrisiert werden.

5. Externalisierung von Sicherheitsfunktionen: Wo dies möglich ist, SOLLTEN Sicherheitsfunktionen externalisiert werden (z. B. durch Nutzung vorhandener Authentifizierungssysteme).

6. Konsistenz von Sicherheitsprüfungen: Identische Sicherheitsprüfungen (z. B. einmal im Webfrontend und ein anderes Mal bei einer AJAX-Schnittstelle) SOLLTEN stets über dieselben Sicherheitsfunktionen (= Programmcode) und Policys durchgeführt werden.

7. Prinzip der ausgereiften Sicherheit: Sicherheitsrelevanter Programmcode SOLLTE stets über ausgereifte Technologien, Algorithmen und Implementierungen (APIs, Frameworks, etc.) abgebildet werden.

8. Testbarkeitsprinzip: Vor dem Einsatz neuer Technologien (Protokollen, Frameworks, APIs, etc.) SOLLTE sichergestellt werden, dass sich diese auf mögliche Sicherheitsprobleme hin analysieren lassen (eingesetzte Tools etwa entsprechende Regeln besitzen).

8.2 Eingabevalidierung

1. Alle über externe Schnittstellen eingelesene Eingaben MÜSSEN validiert werden.

2. Eingabeprüfungen MÜSSEN stets serverseitig erfolgen, DÜRFEN jedoch zusätzlich aus Usability-Gründen auch clientseitig durchgeführt werden.

3. Ein positives Sicherheitsmodell („Was ist erlaubt?“) SOLLTE stets anstelle eines negativen („Was ist verboten?“) verwendet werden.

4. Eingabeprüfungen MÜSSEN (durch Einschränken von Datentyp, Länge und Wertebereich) möglichst restriktiv erfolgen.

5. Eingabeprüfungen SOLLTEN wenn möglich auch implizit mittels Databindung (bzw. Type Casting) erfolgen.

6. Dateifade MÜSSEN stets normalisiert bzw. kanonisiert werden, bevor gegen diese eine

Muster AG Seite 16

Validierung durchgeführt werden. Hierbei werden Pfadtraversierungen („../../“) bereinigt.9

7. Eingabeprüfungen MÜSSEN auf sämtliche Parameter angewendet werden. Dies schließt neben Benutzerparametern auch Anwendungsparameter (z.B. mittels Hidden Fields oder Cookies) mit ein.

8. Die Validierung von Anwendungsparametern SOLLTE, sofern möglich, implizit über Integritätsprüfungen oder Indirektionen erfolgen.

9. HTML-Eingaben MÜSSEN über eine ausgereiften HTML Sanitizer API restriktiv bereinigt werden.

10. XML-Eingaben MÜSSEN mit einem restriktivem XML-Schema oder innerhalb des Modells (z.B. mittels Bean Validation) validiert werden.

8.3 Dateiuploads und -downloads

1. Jeder Upload einer Datei SOLLTE serverseitig authentifiziert werden und nur über den angemeldeten Bereich möglich sein. Dort wo dies nicht möglich ist, MÜSSEN ausreichende Anti-Automatisierungs-Mechanismen implementiert werden, um DoS-Angriffe hinreichend zu unterbinden.

2. Hochgeladene Dateien SOLLTEN in einer zugriffsgeschützten Datenbank abgelegt oder

3. Erfolgt die Ablage auf dem Dateisystem, so MÜSSEN dort die folgenden Vorgaben berücksichtigt werden:

a) Dateiuploads MÜSSEN außerhalb des Document Roots gespeichert werden.

b) Dateiuploads MÜSSEN mit restriktiven Berechtigungen abgelegt werden (z. B. mittels des Unix-Kommandos „chmod 0644“). Abgelegte Dateien DÜRFEN NICHT ausführbar sein. Jeder Dateiupload SOLLTE die Erstellung einer neuen Datei zur Folge haben.

4. Die Größe hochgeladener Dateien MUSS auf einen sinnvollen Wert (z.B. 5 MB) beschränkt werden.

5. Die Anzahl hochgeladener Dateien SOLLTE auf einen sinnvollen Wert beschränkt werden (z. B. 8 Dateien pro Stunde und Benutzter).

6. Dateitypen, die ausführbaren Code enthalten können (z. B. „.html“, „.js“, ".exe“ oder „.bat“) DÜRFEN NICHT hochgeladen werden können. Die Prüfung SOLLTE auf Basis von Whitelisting (nur erlaubte Dateitypen werden zugelassen) durchgeführt werden.

7. Zusätzlich zur Dateierweiterung MUSS der angegebene MIME-Type einer Datei verifiziert werden.

8. Hochgeladene Dateien von nicht-vertrauenswürdigen Quellen SOLLTEN mittels einer Antiviren-Prüfung auf möglichen Schadcode hin geprüft und im Positivfall verweigert werden.10

9. Dateidownloads SOLLTEN über eine separate Origin erfolgen (z.B. „files.example.com“), um dadurch die Auswirkungen von ausgeführten Skriptcode zu begrenzen.

10. Bei Dateidownloads SOLLTEN entsprechende Security Header gesetzt werden, um

9 Häufig existieren hierfür Methoden wie „getCanonicalPath()“10 Diese Funktion lässt sich mit der EICAR-Testdatei testen (www.eicar.org)

Muster AG Seite 17

damit z.B.: das MIME Type Sniffing im Browser zu deaktiviert (siehe Anhang).

8.4 Ausgabevalidierung (Enkodierung & Escaping)

1. Backend-Zugriffe (z. B. auf Datenbanken) MÜSSEN mittels Prepared Statements, ORM (Object-Relational Mapping, z.B. Hibernate), oder einem vergleichbaren Verfahren zur Parametrisierung11 abgebildet werden, sofern für den verwendeten Interpreter eine entsprechende API existiert.

2. Unabhängig davon, ob diese intern oder externen Ursprunges sind, MÜSSEN sämtliche in Prepared Statements verwendete Variablen stets parametrisiert werden (= explizit als Parameter ausgewiesen werden müssen12). Eine Konkatenierung (Aneinanderhängen) von Parametern ist in Interpreter-Aufrufen generell zu vermeiden.

3. Sollte keine API zur Parametrisierung zur Verfügung stehen oder deren Einsatz nicht möglich sein, MÜSSEN Parameter mit einer geeigneten API enkodiert werden (z. B. SQL Encoding).

4. Bevor benutzerkontrollierte Parameter in HTML-Seiten ausgegeben werden, MÜSSEN diese zuvor mit einer für den jeweiligen Ausgabekontext geeigneten API und Methoden enkodiert werden:

a) HTML-Kontext: HTML Entity Encoding

b) JavaScript-Kontext: JavaScript Escaping

c) CSS-Kontext: CSS Escaping

5. Verwendung sicherer JavaScript-APIs

a) JSON-Code DARF ausschließlich mit einer sicheren JavaScript-API wie JSON.parse() (nicht jedoch eval()) im Browser interpretiert werden.

b) Anstelle der JavaScript-APIs mit „.innerHTML“ im Namen, SOLLTEN stets sichere APIs wie „.innerText“ und „.textContent“ genutzt werden, sofern nicht explizit HTML-Markup ausgegeben werden soll. Gleiches gilt auch für Webframeworks, die entsprechende APIs zur Verfügung stellen.

6. Für die Durchführung der Ausgabevalidierung SOLLTEN ausschließlich ausgereifte APIs und Frameworks zum Einsatz kommen.

7. Hierzu SOLLTE stets eine implizite Validierung durchgeführt werden. Im Frontend wird eine solche etwa durch viele Webframeworks (bzw. Template-Technologien) zur Verfügung gestellt, im Backend z. B. durch den Einsatz eines ORM-Frameworks.

8.5 Authentifizierung & Registrierung von Benutzern

1. Im Rahmen einer Registrierung MUSS sich ein Benutzer mit einem für der Schutzklasse der Anwendung geeigneten Verfahren identifizieren:

a) <= STANDARD : E-Mail-Adressen DÜRFEN verwendet werden.

b) HOCH : Ein zusätzlicher Faktor (z.B. Handy) SOLLTE zum Einsatz kommen.

11 Hierbei werden alle Parameter explizit als Parameter ausgewiesen (z.B. mittels einer API-Methode setParam()) oder implizit über ein Framework.12 z.B. mittels API-Methode setParam()oder ähnlichem

Muster AG Seite 18

c) SEHR HOCH : Eine persönliche Identifikation MUSS erfolgen

2. Die Identifikation eines Benutzers MUSS abgeschlossen sein, bevor sich dieser an der Anwendung anmelden darf.

3. Bei der Registrierung und Authentifizierung von externen Benutzern MÜSSEN auf externen Anwendungen geeignete Verfahren zum Einsatz kommen, die automatisierte Angriffe (z.B. Brute Forcing) unterbinden. Beispiele hierfür sind eingebaute Delays, oder CAPTCHAs (Anti-Automatisierungs-Techniken).

4. Für die Authentifizierung von Benutzern MÜSSEN der jeweiligen Schutzklasse angemessene Verfahren zum Einsatz kommen:

a) <= STANDARD : Passwort-basierte Authentifizierung über sicheres Verfahren bzw. Protokoll. Passwörter müssen konform zur Passwort-Policy sein (NIST Level 213).

b) HOCH : Wie beim normalen Schutzbedarf, jedoch in Verbindung mit einem zusätzlichen (Authentifizierungs-)Faktor. Der zusätzliche Faktor MUSS über einen anderen Kanal oder Kommunikationsschicht übertragen werden, darf sich jedoch auf demselben System befinden („Soft Crypto Token“). Beispiele hierfür sind: X.509-Zertifikate, oder Codes die per SMS oder E-Mail zugesendet werden (NIST Level 3).

c) SEHR HOCH : Wie hoher Schutzbedarf, jedoch muss der zusätzliche Faktor über ein separates Gerät vom Benutzer generiert werden, welches speziell für diesen Zweck dient und freigegeben wurde („Hard Crypto Token“). Beispiele sind: Secure ID Tokens (NIST Level 4).

5. HTTP Basic SOLLTE nur als zusätzliche Zugriffskontrolle zum Einsatz kommen und DARF ausschließlich über HTTPS verwendete werden können.

6. Benutzernamen SOLLTEN frei wählbar und personen-spezifisch sein

7. Schlägt eine Anmeldung fehl, so MUSS eine neutrale Fehlermeldung ausgegeben werden, die keinen Aufschluss auf die Fehlerursache (Passwort oder Benutzername falsch) liefert. Positives Beispiel einer solchen: „Benutzername oder Passwort fehlerhaft“.

8. Die Autovervollständigung in Anmeldefeldern SOLLTE stets unterbunden werden. In den entsprechenden HTML-Input-Feldern ist hierzu das Attribut autocomplete="off" zu setzen.

8.6 Benutzerpasswörter I: Stärke und Behandlung

1. Benutzerpasswörter MÜSSEN der Passwort-Policy entsprechen. Dies MUSS sowohl bei der Registrierung, als auch beim Neusetzen des Passwortes durch den Benutzer geprüft werden.

2. Sofern durch eine Passwort-Policy nicht anders vorgegeben, MÜSSEN Benutzerpasswörter

a) mindestens 8 Zeichen Länge besitzen,

b) sowohl aus Buchstaben, Zahlen und Sonderzeichen enthalten,

c) nicht identisch mit dem Benutzernamen sein,

d) maskiert mittels HTML-Passwort-Feldern eingegeben werden,

13 Siehe NIST SP 800-63-1, Electronic Authentication Guideline, IS Electronic Authentication Levels

Muster AG Seite 19

e) nicht protokolliert werden,

f) nur verschlüsselt über unsichere Netze übertragen werden,

g) nur mittels sicheren Verfahren, vorzugsweise als Salted Hash und mittels Key Stretching gespeichert werden, so dass diese auch dann noch ausreichend geschützt sind, wenn sie in die Hände Unbefugter gelangen sollten. Hierzu SOLLTE der PBKDF2-Algorithmus mit idealerweise 100.000 Iterationen eingesetzt werden.

3. Initialpasswörter MÜSSEN beim ersten Login durch den Benutzer geändert werden.

4. Standardpasswörter (= durch den Hersteller festgelegt) DÜRFEN NICHT verwendet werden und SIND durch individuelle Passwörter zu ersetzen.

8.7 Benutzerpasswörter II: Änderung und Zurücksetzung

1. Benutzerpasswörter MÜSSEN durch den Benutzer geändert werden können.

2. Bei Änderung eines Passwortes durch einen Benutzer SOLLTE diesem die aktuelle Stärke des eingegebenen Passwortes visuell angezeigt werden (Passwort-Stärke-Funktion).

3. Sollte ein Benutzerpasswort an mehreren Stellen geändert oder gesetzt werden können MUSS die Prüfung im Hintergrund stets mit demselben technischen Verfahren erfolgen.

4. Beim Ändern seines Passwortes MUSS ein Benutzer sein altes Passwort zur Bestätigung eingeben.

5. Passwort-Vergessen-Funktionen

a) MÜSSEN das gleiche Sicherheitsniveau wie die Anmeldefunktion besitzen und genauso vor mißbräuchlicher Verwendung geschützt werden.

b) MÜSSEN über die E-Mail-Adresse (oder ein anderes Verfahren mit einem vergleichbaren oder höheren Sicherheitsniveau) durch den Benutzer autorisiert werden.

c) SOLLTEN mittels hinterlegtem Wissen (z.B. Abfrage einer durch den Benutzer festgelegte Sicherheitsfrage) geschützt werden.

d) DÜRFEN KEINE Änderung des Profils eines Benutzers zur Folge haben (z. B. dessen Deaktivierung), solange diese Autorisierung nicht erfolgreich war.

8.8 Authentifizierung am Backend

1. Verteilte Anwendungskomponenten SOLLTEN sich stets gegenseitig authentifizieren.

2. Dies SOLLTE auf mehreren Ebenen durchgeführt werden (z.B. IP-Adressen, X.509-Zertifikate, Passwörter).

3. Hierfür SOLLTE ein Verfahren zum Einsatz kommen, welches nicht auf Basis geheimer Schlüssel (Passwörter) arbeitet. Besser geeignet sind etwa X.509-Zertifikate (Public-Key-Authentifizierung oder der Einsatz von Ticket-basierten Authentifizierungssystemen wie Kerberos).

4. Passwörter von technischen Benutzern (Systemkennungen) MÜSSEN

a) für jeden Dienst (bzw. Anwendung) unterschiedlich sein,

b) mindestens eine Länge von 20 Zeichen haben,

Muster AG Seite 20

c) vollständig zufällig sein (Erstellung mittels Passwortgenerator empfohlen) sowie

d) gemäß der Vorgaben zu kryptographischen Schlüsseln (8.14) gespeichert werden.

8.9 Inter-Komponenten-Authentifizierung (Authentifizierung am Frontend)

Siehe 8.16 („Webdienste und XML-Parser“).

8.10 Absicherung des Session Managements

Wird das Session Management über Standardkomponenten abgebildet? Dann hier entsprechend erwähnen.

1. Für die Abbildung des Session Managements MUSS eine Standardimplementierung (z. B. die des Application Servers oder Web Containers) eingesetzt werden.

2. Session-IDs MÜSSEN

a) mindestens 120 Bit Länge besitzen,

b) mit einem sicheren Pseudo Random Number Generators (PRNGs) erstellt werden und vollständig zufällig sein,

c) immer über sichere Kanäle (TLS/HTTPS)

d) nach jeder Authentisierung durch den Benutzer (insbesondere beim Login) neu gesetzt werden,

e) ausschließlich mittels HTTP Cookies (nicht in URLs) zwischen Benutzer und Anwendung transportiert werden.

3. Session Cookies MÜSSEN in ihrer Gültigkeit weitestgehend eingeschränkt werden:

a) Verwendung der Security-Flags wie „httpOnly“ und „secure“,

b) Vermeidung von persistenten Cookies (kein gesetztes Expire-Flag) sowie

c) über das Path-Flag eingeschränkt werden, wenn mehre Anwendungen auf dem gleichen Host ausgeführt werden.

4. Serverseitige Sessions (Authentifiziert)

a) MÜSSEN invalidiert werden, nachdem sich ein Benutzer abgemeldet hat,

b) MÜSSEN spätestens nach 30 Minuten Inaktivität (Idle- oder Soft-Logout) invalidiert werden,

c) SOLLTEN spätestens nach 24 Stunden invalidiert werden (Hartes Timeout, bzw. Session Lifetime) und

d) SOLLTEN pro Benutzer nur einmal existieren. Meldet sich ein Benutzer erneut an der Anwendung an, SOLLTEN alle bestehenden Session-Objekte für diesen Benutzer invalidiert werden.

5. Bei State ändernden Anfragen (Create, Update, Delete), die über eine authentifizierte Benutzersession durchgeführt werden, MUSS das Wiedereinspielen (Session Replay) sowie Unterschieben von Anfragen durch Dritte (Cross-Site Request Forgery, CSRF) verhindert werden.

a) Hierfür lassen sich z. B. zufällige Anti-Replay-Tokens (bzw. Anti-CSRF-Tokens) verwenden, die als zusätzlicher Parameter (z.B. als zusätzliches Hidden-Field)

Muster AG Seite 21

eingebaut werden.

b) Eine State ändernde Anfrage DARF NUR in Verbindung mit einem gültigen Token zugelassen werden.

c) Viele Webframeworks bieten bereits entsprechende Schutzfunktionen die bevorzugt statt der Implementierung eigener Funktionen verwendet werden SOLLTEN.

d) State ändernde Anfragen SOLLTEN nicht über HTTP GET möglich sein.

8.11 Zugriffskontrollen (Access Controls)

Werden Standardkomponenten gegen die oder durch die Anwendungen Benutzer authentifizieren (Policy Decision Point) oder von denen Sie Rollen abrufen (Policy Information Point)? Dann hier entsprechend erwähnen.

1. Jeder sensible Objektzugriff (z.B. auf ein Datenbankobjekt) SOLLTE stets dediziert autorisiert werden (Complete-Mediation-Prinzip).

2. Zugriffsprüfungen SOLLTEN sowohl auf URL-, also auch auf Datei-, Methoden- und Objekt-Ebene durchgeführt werden.

3. Zugriffsprüfungen MÜSSEN neben der erforderlichen Rolle einer Entität auch die erforderlichen Rechte prüfen, um auf ein bestimmtes Datenobjekt zuzugreifen.

4. Jeder Prozess DARF NUR die notwendigen Berechtigungen auf Ressourcen (Dateisystem, Datenbank, etc.) besitzen (Least-Privilege-Prinzip).

5. Zugriffsprüfungen MÜSSEN serverseitig erfolgen.

6. Zugriffe KÖNNEN zur Erreichung eines höheren Schutzniveaus über Indirektionen14 abgebildet werden.

7. Jede privilegierte Benutzerberechtigung SOLLTE mit einer zeitlichen Gültigkeit versehen werden.

8. Cross-Domain-Zugriffe

a) MÜSSEN über sichere Verfahren (z. B. Cross Origin Sharing, CORS) und minimaler Berechtigungen durchgeführt werden.

b) MÜSSEN serverseitig im Hinblick auf ihre Herkunft autorisiert werden (z.B. durch Auswerten des Origin Headers).

8.12 Fehlerbehandlung & Logging

1. Es MUSS sichergestellt werden, dass die Anwendung beim Auftreten eines Fehlers niemals in einen unsicheren Zustand fallen kann und Benutzern in einem solchen Fall keine technischen Details (z. B. durch Ausgabe von Stack Traces) angezeigt werden.15

2. Sicherheitsrelevante Zugriffe und Ereignisse (z. B. Anmeldung eines Administrators) MÜSSEN stets geloggt werden. Dies SOLLTE in einem separaten Security Log erfolgen.

14 Unter einer Indirektion ist in diesem Zusammenhang ein indirekter Objektzugriff zu verstehen. Dadurch greift ein Benutzer nicht mehr auf die tatsächlichen (direkten) Objekt-IDs eines Hintergrundsystems (z.B. einer Datenbank) zu. Stattdessen werden diese über eine Mapping-Tabelle über lokale (Benutzer- oder Session-spezifische IDs) abgebildet. Dadurch ist es einem Angreifer nicht mehr möglich, auf Objekt-IDs zuzugreifen, die nicht im Frontend verlinkt sind. 15 Ein unsicherer Zustand ist dadurch gekennzeichnet, dass Sicherheitsfunktionen nicht mehr wie vorgesehen arbeiten und etwa einem nicht autorisierten Benutzer Zugriff auf sensible Daten gewährt wird.

Muster AG Seite 22

3. Anwendungen SOLLTEN Mechanismen besitzen um Mißbrauch und Angriffe erkennten zu können (Application IDS).

8.13 Datensicherheit & Kryptographie

Existieren bereits Kryptovorgaben im Unternehmen? Dann hier referenzieren.

1. Es DÜRFEN nur ausgereifte und standardisierte kryptographische Algorithmen, Betriebsmodi, Schlüsselstärken, SSL/TLS-Ciphers und Implementierungen eingesetzt werden.16

2. Die Übertragung sensibler Daten MUSS

a) über unsichere Netze (z. B. dem Internet) verschlüsselt (mittels TLS/HTTPS) erfolgen (auch bei internen Übertragungen SOLLTE dies der Fall sein),

b) im HTTP Request Body (z.B. mittels HTTP POST) und nicht innerhalb der URL (Ausnahme: Objekt-IDs) und

c) mittels gesetzter Anti-Cache-Header (siehe Anhang) erfolgen

3. Generell SOLLTEN alle externen Webinhalte über HTTPS abrufbar sein.

4. Alle Zugriffe aus sensible Daten (intern oder extern) MÜSSEN über HTTPS erfolgen.

5. Erfordert eine Anwendung die Verwendung von HTTPS, MÜSSEN alle Zugriffe mittels http auf den entsprechenden HTTPS-Kontext weitergeleitet werden. Hierzu SOLLTE eine permanente Weiterleitung verwendet werden.17

6. Ein HTTPS-Server MUSS aktuelle Cipher und Protokolle mit sehr hoher Sicherheit unterstützen. Unsichere HTTPS-Cipher oder Protokolle (z. B. SSLv2 oder RC4) MÜSSEN deaktiviert werden.

7. Perfect Forward Secrecy (PFS) MUSS auf allen HTTPS-Servern unterstützt werden.

8. Benutzerpasswörter MÜSSEN durch geeignete kryptographische Verfahren gespeichert werden (siehe 8.6).

8.14 Verwaltung technischer Schlüssel

1. Vertrauliche kryptographische Schlüssel (geheime Schlüssel bei symmetrischer und private Schlüssel bei asymmetrischer Kryptographie sowie Accounts technischer User) MÜSSEN

a) getrennt vom Programmcode (z.B. in einem KeyStore) abgelegt und vor unberechtigtem Zugriff geschützt werden (restriktive Zugriffsrechte, passwort-geschützter KeyStore).

2. Vertrauliche kryptographische Schlüssel von Anwendungen ab der Schutzklasse HOCH MÜSSEN zudem verschlüsselt werden. Der hierfür verwendete interne Schlüssel darf in diesem Fall innerhalb des Programmcodes enthalten sein.

3. Im Falle von vertraulichen kryptographischen Schlüsseln von Anwendungen der Schutzklasse SEHR HOCH SOLLTE anstelle des oben beschriebenen Verfahrens ein

16 Siehe hierzu BSI Technische Richtlinie TR-02102-1, „Kryptographische Verfahren: Empfehlungen und Schlüssellängen“17 Siehe hierzu 8.15 zu HTTP Strict Transport Security (HSTS)

Muster AG Seite 23

hardware-basierter Speicher (HSM) zum Einsatz kommen.

8.15 Clientseitige Sicherheit

1. HTTP-Security-Header wie Strict Transport Security (HSTS) oder Content Security Policy (CSP) MÜSSEN entsprechend der Spezifikation in Anhang A implementiert werden.

2. Clientseitig DARF KEINE sensible Geschäftslogik (z.B. Berechnung von Tarifen, Generierung von IDs) offengelegt werden.

3. Clientseitig (z. B. im Browser) DÜRFEN sensible Daten nur dann abgelegt werden, wenn diese dem Benutzer selbst gehören (z. B. eigene personenbezogene Daten).

4. Browser-Plugins wie ActiveX oder Java SOLLTEN nicht verwendet werden (Stattdessen sollten z.B. Funktionen in JavaScript statt als ActiveX-Control umsetzen).

5. Benutzern SOLLTE die Möglichkeit gegeben werden, browserseitige Security-Plugins zu verwenden.

8.16 Webdienste und XML-Parser

Existieren bereits Webdienste / Services im Unternehmen über welche bestimmte (perimetrische) Standardkomponenten wie XML-Firewalls / -Gateways abgebildet werden? Dann hier entsprechend erwähnen.

1. Werden interne Webdienste von extern zugreifbar gemacht, so MUSS dies stets über eine Façade18 erfolgen, über welche ausschließlich erforderliche Funktionalität des internen Webdienste gekapselt und von extern zugreifbar ist.

2. XML-Daten aus nicht vertrauenswürdigen Quellen (z.B. empfangen von externen Webservices) MÜSSEN stets restriktiv auf Modelebene (z.B. Bean Validation) oder durch ein XML-Schema validiert werden. Das verwendete Schema SOLLTE hierzu so weit möglich eingeschränkt werden. Beispiele hierzu sind:

a) Integer statt String-Datentyp,

b) Min/Max-Einschränkung für numerische Datentypen oder

c) eingeschränkte String-Typen.

3. XML-Parser, die Daten aus nicht vertrauenswürdiger Quelle verarbeiten, MÜSSEN gehärtet werden, um gängige Angriffe:

a) Setzen restriktiver Limits (z. B. im Hinblick auf Verschachtelungstiefe oder Dokumentgröße).

b) Deaktivierung externer XML Entitäten („External XML Entities“).

4. Die Authentifizierung bei REST-Services MUSS auf einer der folgenden Arten durchgeführt werden:

a) Mittels generierten, vollständig zufälligen Schlüssel mit ausreichender Entropie („API Key“) welcher durch den Client im HTTP Header (z.B. als X-Header) übertragen wird (siehe Anforderungen in 8.8 („Authentifizierung am Backe“). Die Übertragung von API Keys in URLs DARF dagegen nicht erfolgen.

b) Mittels OAuth

18 https://de.wikipedia.org/wiki/Fassade_(Entwurfsmuster)

Muster AG Seite 24

c) Mittels X.509 Client Zertifikaten

d) Mittels HTTP Basic Auth und der Verwendung von HTTPS

5. Enthält die Antwort eines Webdienstes Skriptcode (z. B. JSON bzw. JavaScript), so MUSS sichergestellt werden, daß dieser nicht direkt ausführbar ist.

6. Für alle Webdienste (inkl. HTTP-basierter APIs), bei denen über eine authentifizierte Session ändernde Anfragen durchgeführt werden, MUSS ein CSRF-Schutz implementiert werden (vgl. Kap. 8.10).

7. WebSockets, über welche vertrauliche Daten übermittelt werden, MÜSSEN das wss://-Schema verwenden und eine Prüfung des Origin-Headers durchführen.

8. Webdienste MÜSSEN dieselben Zugriffe stets auch mit denselben Sicherheitsvorgaben (im Hinblick auf Authentifizierung, Validierung etc.) durchführen wie für das Web-GUI-Frontend. Hierfür SOLLTEN dieselben Sicherheitsfunktionen (Programmcode, APIs) verwendet werden.

Muster AG Seite 25

Anhang A: Vorgaben für HTTP Security HeaderIn moderne Browsern lassen sich verschiedene Schutzfunktionen über gesetzte HTTP Response Header aktivieren und dadurch das Sicherheitsniveau einer Webanwendung erhöhen. Im Folgenden sind entsprechende Vorgaben und Empfehlungen für extern erreichbare produktive Webanwendungen der [Firma] beschrieben.

Zentral gesetzte Header:

Response Header Allgemeine Empfehlung Wann?Content-Type ...; charset=utf-8 ImmerStrict-Transport-Security19

max-age=10886400; preload[;includeSubDomains]

Für alle Webanwendungen, auf denen sich die Verwendung von HTTPS erzwingen lässt.

Public-Key-Pins20 pin-sha256="base64+primary=="; pin-sha256="base64+backup=="; ; max-age=2592000 [; includeSubdomains]

Für alle über HTTPS erreichbaren Webseiten.

X-XSS-Protection21 1; mode=block ImmerX-Content-Type-Options22

nosniff Immer

Anwendungsspezifisch gesetzte Header und Attribute:

Response Header Allgemeine Empfehlung Wann?Set-Cookie … ;httpOnly; secure Übertragung sensibler Daten in

Cookies (z. B. Session-IDs).Cache-Control no-cache, no-store

Bei Übertragung sensibler Daten.Pragma no-cache

Expires -1Content-Security-Policy23

script-src ‘self’ [URL1] [URL2]; style-src ‘self’ unsafe-inline;

Allgemein Empfehlung für neue Anwendungen

19 HTTP Strict Transport Security (HSTS): Forciert, das der Benutzer die Webseite zukünftig und entsprechend des angegebenen Zeitraums nur noch mittels HTTPS aufruft. Bei Verwendung dieses Headers muss sichergestellt sein, dass alle Zugriffe auf den Host (bzw. auch alle Subdomains bei Verwendung von „includeSubDomains“) per HTTPS möglich sind. Hiermit werden bestimmte Man-in-the-Middle-Angriffe abgewehrt.20 Bei Public Key Pinning Extension for HTTP (HPKP) wird mittels des Header “Public Key Pinning” der Client (Browser) angewiesen über den definierten Zeitraum nur Zertifikate vom Server zu akzeptieren, welche eine der Base64-enkodierten SHA256-Hashwerte besitzen. Hiermit werden ebenfalls bestimmte Man-in-the-Middle-Angriffe abgewehrt.21 Additiver Schutz vor Cross-Site Scripting (nur für IE)22 Deaktiviert MIME-Sniffing in Browsers, wodurch dieser versucht, den MIME-Type anhand des Inhaltes (und nicht des angegebenen MIME-Types) zu identifizieren.

Muster AG Seite 26

Response Header Allgemeine Empfehlung Wann?object-src ‘self‘

X-Frame-Options24 SAMEORIGIN (oder DENY)25 Immer26

X-Download-Options noopen Dort wo Benutzer nicht-vertrauenswürdige Dateien herunterladen können.

Achtung: Das Setzen dieser Header kann Auswirkungen auf die korrekte Funktionsfähigkeit einer Webanwendung zur Folge haben. Daher SOLLTE die Verwendung eines neuen Headers stets nur in Verbindung mit ausführlichen funktionalen Tests erfolgen.

23 Content Security Policy (CSP): Additiver, aber sehr wirksamer Schutz vor Cross-Site Scripting und anderen clientseitigen Angriffen, der jedoch eine Kompatibilität des eingesetzten Frameworks erfordert und bereits frühzeitig innerhalb der Entwicklung berücksichtigt werden muss.24 Unterbindung von „Framing“ und Schutz vor Clickjacking25 „DENY“: kein Framing möglich, „SAMEORIGIN“: Framing nur innerhalb der gleichen Origin erlaubt. Generell bietet „DENY“ zwar die höhere Sicherheit, führt jedoch bei vielen Anwendungen/Frameworks dazu, dass diese mit der Einstellung nicht mehr funktionieren. 26 Alternativ kann an dieser Stelle auch ein Content-Security-Header mit „frame-ancestors ‘self’ [URL1] [URL2];“ verwendet  werden, wenn der Zugriff von mehreren Webseiten möglich sein soll. Dieser Header wird aktuell lediglich von neueren Browsern unterstützt. 

Muster AG Seite 27

Anhang B: Häufige Schwachstellen für Webanwendungen (OWASP Top 10)Die OWASP Top 10 (http://www.owasp.org/index.php/Top_10) stellt eine Rangliste von Sicherheitsbedrohungen für Webanwendungen dar. Die 2013er-Version weist dabei die folgenden Bedrohungen aus, die auf entsprechende Sicherheitsanforderungen aus diesem Standard abgebildet wurden:

OWASP Top Ten 2013 Relevante Sicherheitsanforderungen

A1-Injection Primär: Einsatz von (1) Parametrisierung / ORM-Frameworks (SQL Injection) und (2) Enkodierungs-APIs (vgl. Kap. 10). Sekundär: Restriktive Eingabevalidierung (vgl. Kap. 8.2)

A2-Broken Authentication and Session Management

Verwenden sicherer und starker Authentifizierungsverfahren (vgl. Kap. 8.5) und Härten des Session Managements (vgl. Kap. 8.10.).

A3-Cross-Site Scripting (XSS)

Primär : Kontextabhängige Ausgabevalidierung (vgl. Kap. 10, Anf. 4), idealerweise implizit über ein Webframework. Sekundär: Einsatz von Security-Headern (vgl. Kap 8.15 sowie sowie Anhang A) und restriktive Eingabevalidierung (vgl. Kap. 8.2).

Sonderfälle: Wird HTML-Markup als Eingabe zugelassen, muss dieser über spezielle APIs validiert werden, JSON-Code darf ausschließlich mit einer sicheren API wie JSON.parse() (nicht eval()) interpretiert werden. Statt der JavaScript-API „.innerHTML“ sollten sichere APIs wie „.innerText“ und „.textContent“ genutzt werden, gleiches gilt auch für Webframeworks, die entsprechende APIs zur Verfügung stellen.

A4-Insecure Direct Object References

Prüfung jedes sensiblen Objektzugriffes (auch auf Funktions- und Objektebene) sowie Einsatz von Indirektionen (vgl. Kap. 3).

A5-Security Misconfiguration

Härtung der Konfiguration des Application Servers (vgl. Kap. 3).

A6-Sensitive Data Exposure

Härtung der Konfiguration (vgl. Kap. 3), restriktive Fehlerbehandlung (vgl. Kap. 8.12), Maßnahmen zur Datensicherheit (vgl. Kap. 8.13).

A7-Missing Function Level Access Control

Prüfung jedes sensiblen Objektzugriffes (auch auf Funktions- und Objektebene) sowie Einsatz von Indirektionen (vgl. Kap. 8.11).

A8-Cross-Site Request Forgery (CSRF)

Verwendung von Anti-CSRF-Tokens bei allen schreibenden Anfragen innerhalb einer angemeldeten Session (vgl. Kap. 8.10, Anf. 10).

A9-Using Components with Known Vuln.

Etablierung eines Patch Managements für 3rd-Party-Komponenten (vgl. Kap. 4).

A10-Unvalidated Validierung von Eingaben, idealerweise mittels Indirektionen

Muster AG Seite 28

Redirects and Forwards

oder Integritätsprüfungen wie z. B. Hashvergleiche (vgl. Kap. 8.2).

Muster AG Seite 29