Embed Size (px)
Citation preview
TECHNISCHER SICHERHEITSSTANDARD FÜR WEBANWENDUNGEN Ein Standard der Secodis GmbHLizensiert unter der Creative Commons LizenzVersion 1.515. August 2017Vorlage
Über TSS-WEBDieses Dokument beschreibt exemplarische Inhalte eines technischen (und 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.
Die Inhalte wurden von der Secodis GmbH erstellt und werden kontinuierlich weiterentwickelt. Die aktuelle Version des Dokuments kann unter https://tss-web.secodis.com in deutsch und englisch heruntergeladen werden. Dort findet sich auch ein Mapping der Anforderungen aus diesem Dokument zur aktuellen OWASP Top Ten sowie eine Kontaktmöglichkeit für Fragen und Anmerkungen.
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 Richtlinien 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
Änderungshistorie
Version Datum Wichtige 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
1.4 31.12.2016 Neue Anforderungen für X.509-Zertifikate (8.17)
Anpassungen an Kapitel 5 in Bezug auf agile Teams
„Verwendung sicherer JavaScript-APIs“ aus 8.4 („Ausgabevalidierung“) nach 8.15 („Clientseitige Sicherheit“) verschoben.
Mehrere Änderungen an Kapitel 6 („Security Tests“).
Security Auditor in Security Officer umbenannt
1.5 15.8.2017 Security Officer wurde in IT-Sicherheitsfunktion umbenannt
Überarbeitung Kapitel 5 („Sicherheit im Entwicklungsprozess“)
Überarbeitung von Kapitel 7 („Zulieferervorgaben“)
OWASP Top Ten Mapping wurde entfernt und wird zukünftig noch noch über die Webseite aktualisiert
Schutzklasse in Assuranceklasse umbenannt und diese angepasst
Anpassungen bzgl. Anforderungen an Dateiupload
Entfernung der Anforderung für HPKP und neue Anforderung für Referer Policy
Sicherheitsstandard fürWebanwendungen
Firma Muster AG
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 Assuranceklassen......................................................................................................................6
2 Beheben von Schwachstellen in Anwendungen...............................................................................7
3 Sicherer Betrieb von Anwendungen.................................................................................................8
4 Sicherheit von Source- und Programmcode...................................................................................10
5 Sicherheit im Entwicklungsprozess................................................................................................11
6 Sicherheitstests...............................................................................................................................13
7 Zulieferervorgaben.........................................................................................................................14
8 Implementierungsvorgaben............................................................................................................15
8.1 Allgemeine Grundsätze..........................................................................................................15
8.2 Eingabevalidierung.................................................................................................................15
8.3 Dateiuploads und -downloads................................................................................................16
8.4 Ausgabevalidierung (Enkodierung & Escaping)....................................................................17
8.5 Authentifizierung & Registrierung von Benutzern................................................................17
8.6 Benutzerpasswörter I: Stärke und Behandlung.......................................................................18
8.7 Benutzerpasswörter II: Änderung und Zurücksetzung...........................................................19
8.8 Authentifizierung am Backend...............................................................................................19
8.9 Service-Authentifizierung am Frontend.................................................................................20
8.10 Absicherung des Session Managements.................................................................................20
8.11 Zugriffskontrollen (Access Controls).....................................................................................21
8.12 Fehlerbehandlung & Logging.................................................................................................21
8.13 Datensicherheit & Kryptographie...........................................................................................22
8.14 Verwaltung technischer Schlüssel..........................................................................................22
8.15 Clientseitige Sicherheit...........................................................................................................22
8.16 Services und XML-Parser-Sicherheit.....................................................................................23
8.17 X.509-Zertifikate („SSL-Zertifikate“)....................................................................................24
Anhang A: Vorgaben für HTTP Security Header..................................................................................25
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.5 (Vorlage) https://tss-web.secodis.com
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.1.2018 Initiales Dokument auf Basis von TSS-WEB v1.5
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 Muster AG 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 Muster AG neuentwickelten, in Auftrag gegebenen oder eingekauften und produktiv eingesetzten webbasierten Anwendungen oder Anwendungskomponenten bzw. der darunterliegenden Infrastruktur. Für alle übrigen Anwendungen besitzen die Vorgaben in diesem Dokument 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“, „IST“, „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-Sicherheitsfunktion 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.
Muster AG Seite 4
- Kritikalität: Hier: Synonym für Geschäftskritikalität.
- 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:
- IT-Sicherheitsfunktion: Organisatorische Einheit oder Person, die für die Erstellung von generellen IT-Sicherheits-Vorgaben und Kontrolle deren Einhaltung zuständig ist.
- Security Champion: Lokaler Koordinator für Applikationssicherheit (z.B. in einem Entwicklungsteam). Dient als Ansprechpartner für Sicherheitsthemen innerhalb des Teams sowie von durch die IT-Sicherheit. Ein Security Champion sollte relevante Sicherheitsanforderungen kennen, deren Umsetzung (bzw. Einhaltung) innerhalb des Teams koordinieren und hierzu vorhandene Sicherheitstools auswerten.
Referenzierungen auf diese Rollen sind in diesem Standard kursiv gekennzeichnet.
Muster AG Seite 5
1.5 Assuranceklassen
Einige Anforderungen in diesem Standard sind von bestimmten Aspekten einer Anwendung abhängig.
Zum einen betrifft diese deren Zugreifbarkeit, ob diese von extern (z.B. aus dem Internet) oder ausschließlich intern aufrufbar ist. Zum anderen deren Geschäftskritikalität:
Zugreifbarkeit der Anwendung
Interne Anwendung(nicht aus dem Internet
erreichbar)
Externe Anwendung(aus dem Internet erreichbar)
(Ges
chäf
ts-)
Krit
ikal
ität d
er
Anw
endu
ng
<= Mittel NIEDRIG STANDARD
Hoch STANDARD HOCH
Sehr Hoch HOCH SEHR HOCH
Tabelle 1-1: Assuranceklassen von Anwendungen
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 erhebliche Zeit erfordert, SOLLTEN zunächst schnell umsetzbare Maßnahmen ergriffen werden, um das von dieser Schwachstelle ausgehende Risiko möglichst weit zu reduzieren. Eine solche Maßnahme DARF immer nur als temporäre Zwischenlösung betrachtet und stets eine ursächliche Behebung der Schwachstelle angestrebt werden.
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ät1 d
er
Anw
endu
ng >= Hochzum nächsten
ArbeitstagInnerhalb von
7 Tagen2
Im Rahmen des nächsten Releases, jedoch spätestens nach 6
Monaten.
<= MittelInnerhalb von
7 TagenInnerhalb von
21 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 >= HochInnerhalb von
7 TagenInnerhalb von
30 Tagen
Im Rahmen des nächsten Releases, jedoch
spätestens nach 12 Monaten.
<= MitelInnerhalb von
21 TagenInnerhalb von
60 Tagen-
Tabelle 2-3: Vorgaben zur Behebung von Schwachstellen für interne Anwendungen
1 Kritikalität = Geschäftskritikalität2 Tage = Kalendertage
Muster AG Seite 7
3 Sicherer Betrieb von AnwendungenDie folgenden Vorgaben gelten für infrastrukturelle Komponenten, auf denen produktive Anwendungen der Muster AG 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. Webserver, Applikationsserver, Content Management Systeme) 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. durch eine chroot-Umgebung oder mittels Virtualisierung) 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 zum Zwecke einer mehrschichtigen Datenseparierung 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 Diensten der Muster AG, 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, TFS), Wikis und auf dem Dateisystem ein.
2. Der Austausch von eigenem Source- oder Programmcode außerhalb der Muster AG DARF NUR über sichere Kanäle (z.B. S/MIME oder per TLS) erfolgen.
3. Source- oder Programmcode DARF NUR nach expliziter Freigabe auf externen Plattformen (z.B. in Internet Foren) veröffentlicht oder Externen Personenkreisen auf sonstige Weise verfügbar gemacht werden.
4. Sicherheit von 3rd-Party-Komponenten
a) Alle 3rd-Party-Komponenten SOLLTEN nur über interne Repositorys verwendet werden dürfen.
b) Werden externe Dependency Repositorys (z.B. Maven Repositorys) angebunden MUSS sichergestellt werden, dass diese vertrauenswürdig sind. Hierfür ist ein entsprechender Freigabeprozess festzulegen.
c) 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.
d) 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.
e) Allgemein SOLLTEN keine 3rd-Party-Komponenten mit einem CVSS3 Scoring >= 7 produktiv gehen. Entsprechende Schwachstellen werden mit als „hoch“ bewerteten in in Custom Code gleichgesetzt.
f) 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 Vulnerabilitys) geprüft werden.
g) Für 3rd-Party-Komponenten SOLLTE ein dedizierter und toolbasierter Patch-Management-Prozess etabliert werden (3rd-Party-Patch-Management).
3 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 Muster AG:
1. Für jedes Entwicklungsteam MUSS ein Security Champion benannt werden. Die gleiche Person kann diese Rolle für mehrere Teams gleichzeitig ausführen.
2. 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.
3. Die Anwendungsentwicklung MUSS in Bezug auf gespeicherte Daten und Systemumgebungen in Test und Produktion separiert werden.
4. Im Rahmen der Initiierung bzw. Genehmigung neuer Projekte MUSS eine Sicherheitsfreigabe durch die relevante IT-Sicherheitsfunktion erfolgen.
5. Die (Sicherheits-)Architektur sowie relevante Teile des Sicherheitskonzepts MÜSSEN, sofern dies durch die relevante IT-Sicherheitsfunktion gefordert wurde, vor Beginn der Implementierung abgenommen und freigegeben werden. Hierfür können durch diese Kriterien festgelegt werden, für welche Arten von Änderungen an der Architektur eine erneute Freigabe erforderlich ist.
6. Jede Anforderung (z.B. User Story) und Change MUSS hinsichtlich seiner Sicherheit bewertet und dies dokumentiert werden, bevor diese für die Umsetzung (z.B. in einem Sprint, Release) eingeplant werden darf.
a. Agil arbeitende Teams SOLLTEN hierzu entsprechende Kriterien in ihre Definition of Ready (DoR) integrieren.
b. Ist eine Anforderung nicht bewertet, gilt eine Anforderung automatisch als Sicherheitsrelevant.
7. Die Korrektheit der Umsetzung sicherheitsrelevanter Anforderungen MUSS durch angemessene Sicherheitstests verifiziert werden.
a. Im Fall von implementierten Sicherheitsfunktionen (z.B. Access Controls oder Krypto-APIs) SOLLTEN automatisiert durchgeführte Sicherheitstests erstellt werden.
b. Agil arbeitende Teams SOLLTEN hierzu entsprechende Kriterien in ihre Definition of Done (DoD) integrieren.
8. Vor der Produktivnahme des ersten Releases einer Anwendung MUSS dieses durch die relevante IT-Sicherheitsfunktion freigegeben werden.
9. Sicherheitsrelevante Mängel mit einer Bewertung >= [HOCH] MÜSSEN vor jeder Produktivnahme eines Releases korrigiert werden.
a. Ist dies nicht möglich, MUSS eine Risikoübernahme durch die verantwortliche Managementfunktion (z.B. den Projektmanager) durchgeführt werden.
b. In Ausnahmefällen (z.B. beim temporären Workarounds) DARF die relevante IT-Sicherheitsfunktion Freigaben unter Vorbehalt erlauben.
10. Alle Freigaben, Risiken und Risikoübernahmen MÜSSEN dokumentiert werden.
Muster AG Seite 11
11. Zu jeder neu entwickelten Anwendung mit der Assuranceklasse >= [HOCH] MUSS eine Sicherheitsdokumentation erstellt und abgenommen werden, bevor die Entwicklung begonnen wird (relevante Aspekte) und eine Anwendung produktiv gehen darf (vollständige Dokumentation). In dieser Dokumentation SOLLTEN, sofern nicht anders mit der relevanten IT-Sicherheitsfunktion abgestimmt, die folgenden Aspekte zu dokumentiert werden:
Systemübersicht (relevante Anwendungskomponenten, Schnittstellen intern/extern, verarbeitete Daten, Datenflüsse)
Zugrundeliegende Sicherheitsvorgaben (z.B. Sicherheitsstandards)
Identifizierte Bedrohungen (z.B. in Form eines Bedrohungsmodells)
Sicherheitsarchitektur, Sicherheitsmaßnahmen / -anforderungen und -Maßnahmen (fachlich und technisch) sowie
Vorgaben für den sicheren Betrieb (erforderlich vor Produktivname)
Muster AG Seite 12
6 SicherheitstestsDie folgenden Vorgaben gelten in Bezug auf die Durchführung von Sicherheitstests von Anwendungen der Muster AG:
1. Die korrekte und vollständige Umsetzung jeder sicherheitsrelevanten Anforderung MUSS durch einen entsprechenden Sicherheitstest verifiziert werden.
2. Wo möglich SOLLTEN Sicherheitstests umfänglich, automatisiert und kontinuierlich (z.B. innerhalb der CI/CD-Pipeline) durchgeführt werden.
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. Anwendungen SOLLTEN auch im Hinblick auf potentielle Sicherheitsprobleme analysiert werden, die nicht durch explizite Sicherheitsanforderungen abdeckt sind (z.B. unsichere Geschäftslogik).
5. Jede Änderung an einer produktiven Anwendung (Change) MUSS im Hinblick auf die Notwendigkeit bewertet werden ob für diese ein Sicherheitstest erforderlich ist.
6. Anwendungen MÜSSEN durch einen Penetrationstest auf Basis der folgenden Security Testing Policy geprüft und durch die relevante IT-Sicherheitsfunktion abgenommen werden:
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 >= HochVor initialer Produktivsetzung
und min einmal jährlich4
Zeitnah zur initialen Produktivsetzung und min. alle drei Jahre
<= MediumVor initialer Produktivsetzung
und min alle zwei Jahre-
Tabelle 6-4: Policy für die Durchführung von Pentests
7. 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.
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. Sicherheitsabnahmen SOLLTEN in einer produktionsnahen Testumgebung durchgeführt werden (z.B. in der Integrationsumgebung).
10. Die Durchführung von Sicherheitstests DARF NICHT durch eine perimetrische Sicherheitskomponente (z.B. eine Webanwendungsfirewall) beeinflußt werden können.
4 Sofern sichergestellt ist, dass in dieser Zeit keinerlei Änderungen an der betreffenden Anwendung durchgeführt wurden, DARF das Intervall um ein weiteres Jahr 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
7 ZulieferervorgabenDie folgenden Vorgaben gelten zusätzlich zu den übrigen Vorgaben dieses Dokuments für Lieferanten, die im Auftrag der Muster AG Software entwickeln und sollten im Rahmen von vertraglichen Vereinbarungen aufzuführen. Der Auftragnehmer MUSS sich zu folgenden Punkten 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. Für Anwendungen der Assuranceklasse >= [HOCH]:
a) Ein Nachweis5, dass Sicherheit im gesamten Entwicklungsprozess angemessen berücksichtigt wurde.
b) Ein gemäß der Anforderungen aus Kapitel 5 dokumentiertes Sicherheitskonzept als Bestandteil des Pflichtenheftes.
3. Zur Umsetzung erforderlicher Sicherheitsmaßnahmen, insbesondere der in diesem Dokument genannten Vorgaben an den sicheren Betrieb (Kapitel 3) sowie Implementierung (Kapitel 8).
4. Einen Ansprechpartner für Sicherheitsfragen in seinem Hause zu benennen, der konstruktiv bei der Bewertung und ggf. Behebung von Sicherheitsbefunden mitarbeitet.
5. Nur autorisierte und erforderliche (Need-to-Know-Prinzip) Personen Zugriff auf den im Auftrag erstellten Sourcecode besitzen.
6. Den im Auftrag erstellten Sourcecode bei Bedarf für die Durchführung einer Sicherheitsuntersuchung zur Verfügung zu stellen („Right to Audit“).
7. Auf eine kostenneutrale und zeitnahe Korrektur identifizierter Sicherheitsprobleme (vgl. Vorgaben in Kapitel 2). Was hierbei ein zu korrigierendes Sicherheitsproblem darstellt, wird einzig durch die Muster AG festgelegt.
5 z.B. auf Basis von https://www.bsimm.com/about/bsimm-for-vendors
Muster AG Seite 14
8 ImplementierungsvorgabenDie folgenden Vorgaben gelten für die Implementierung neuer webbasierter Anwendungen der Muster AG.
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) anstatt 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 Rest-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 server-seitig erfolgen, DÜRFEN jedoch zusätzlich aus Usability-Gründen auch clientseitig durchgeführt werden.
3. Ein positives Sicherheitsmodell (Whitelisting) SOLLTE stets anstelle eines negativen (Blacklisting) 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 Data Binding (bzw. Type Casting) erfolgen.
Muster AG Seite 15
6. Dateipfade MÜSSEN stets normalisiert bzw. kanonisiert werden, bevor gegen diese eine Validierung durchgeführt werden. Hierbei werden Pfadtraversierungen („../../“) bereinigt.6
7. Eingabeprüfungen MÜSSEN auf sämtliche Parameter angewendet werden. Dies schließt neben Benutzerparametern auch Anwendungsparameter (z.B. mittels Hidden Form 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 (z.B. mittels CAPTCHAs) 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 0600“). 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 (z.B. dem Internet) SOLLTEN
a) im Hinblick auf ausführbaren Code geprüft (z.B. Makros) und dieser entfernt werden
b) mittels einer Antiviren-Prüfung auf möglichen Schadcode hin geprüft und im Positivfall verweigert werden.7
6 Häufig existieren hierfür Methoden wie getCanonicalPath()7 Diese Funktion lässt sich mit der EICAR-Testdatei testen (siehe www.eicar.org)
Muster AG Seite 16
9. Dateidownloads SOLLTEN über eine separate Origin erfolgen (z.B. „files.example.com“), um dadurch die Auswirkungen von ausgeführten Skriptcode zu begrenzen.
10. Beim Download von Dateien SOLLTEN entsprechende Security Header gesetzt werden, um 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 Parametrisierung8 abgebildet werden, sofern für den verwendeten Interpreter eine entsprechende API existiert.
2. Unabhängig davon, ob internen oder externen Ursprungs, MÜSSEN sämtliche in Prepared Statements verwendete Variablen stets parametrisiert werden (= explizit als Parameter ausgewiesen werden müssen9). 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 (siehe 8.15).
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 Assuranceklasse 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.
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.
8 Hierbei werden alle Parameter explizit als Parameter ausgewiesen (z.B. mittels einer API-Methode setParam()) oder implizit über ein Framework.9 z.B. mittels API-Methode setParam()oder ähnlichem
Muster AG Seite 17
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 Assuranceklasse 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 210).
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 Auth SOLLTE nur als zusätzliche Zugriffskontrolle zum Einsatz kommen und DARF ausschließlich über HTTPS verwendet 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,
e) nicht protokolliert werden,
f) nur verschlüsselt über unsichere Netze (z.B. dem Internet) übertragen werden,
10 Siehe NIST SP 800-63-1, Electronic Authentication Guideline, IS Electronic Authentication Levels
Muster AG Seite 18
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 bcrypt oder PBKDF2-Algorithmus verwendet 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,
c) vollständig zufällig sein (Erstellung mittels Passwortgenerator empfohlen) sowie
Muster AG Seite 19
d) gemäß den Vorgaben bzgl. kryptographischer Schlüsseln (siehe 8.14) gespeichert werden.
8.9 Service-Authentifizierung am Frontend
Siehe Abschnitt 8.16 („Services und XML-Parser-SicherheitServices und XML-“).
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 ä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 20
eingebaut werden.
b) Eine ä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) Ändernde Anfragen SOLLTEN nur über HTTP POST 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 Indirektionen11 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 Resource 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.12
2. Sicherheitsrelevante Zugriffe und Ereignisse (z.B. Anmeldung eines Administrators) MÜSSEN stets geloggt werden. Dies SOLLTE in einem separaten Security Log erfolgen.
11 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. 12 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 21
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.13
2. Die Übertragung vertraulicher 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-Methode) und nicht innerhalb der URL (Ausnahme: Objekt-IDs) und
c) mittels gesetzter Anti-Caching-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.14
6. Ein HTTPS-Server MUSS aktuelle Cipher und Protokolle mit sehr hoher Sicherheit unterstützen. Unsichere SSL/TLS-Cipher (z.B. RC4-basierte) und -Protokolle (z.B. SSLv2, SSLv3) MÜSSEN deaktiviert und sichere unterstützt 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 oder private Schlüssel bei asymmetrischer Kryptographie sowie Credentials technischer User) MÜSSEN getrennt vom Programmcode (z.B. in einem KeyStore) abgelegt und dort vor unberechtigtem Zugriff geschützt werden (etwa durch restriktive Zugriffsrechte oder einem zusätzlichen Passwortschutz).
2. Vertrauliche kryptographische Schlüssel von Anwendungen ab der Assuranceklasse [HOCH] MÜSSEN zudem verschlüsselt abgelegt werden. Der hierfür verwendete interne Schlüssel darf in diesem Fall innerhalb des Programmcodes enthalten sein.
3. Bei Anwendungen der Assuranceklasse [SEHR HOCH] SOLLTEN kryptographische Schlüssel über ein sicheres Ablagesystem (z.B. eine HSM) geschützt werden.
13 Siehe hierzu BSI Technische Richtlinie TR-02102-1, „Kryptographische Verfahren: Empfehlungen und Schlüssellängen“14 Siehe hierzu 8.15 zu HTTP Strict Transport Security (HSTS)
Muster AG Seite 22
8.15 Clientseitige Sicherheit
1. Verwendung sicherer JavaScript-APIs
a) JSON-Code DARF ausschließlich mit einer sicheren JavaScript-API wie JSON.parse(), nicht jedoch eval(), 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. 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 auf Basis von ActiveX oder Java SOLLTEN generell nicht verwendet und hier stattdessen entsprechende JavaScript-Implementierungen bevorzugt werden.
5. Benutzern SOLLTE die Möglichkeit gegeben werden, browserseitige Security-Plugins zu verwenden.
8.16 Services und XML-Parser-Sicherheit
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çade15 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, welche Daten aus nicht vertrauenswürdiger Quelle parsen, MÜSSEN wie folgt gehärtet werden, um gängige XML-basierte Angriffe zu unterbinden:
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-Schnittstellen MUSS auf einer der folgenden Arten erfolgen:
15 https://de.wikipedia.org/wiki/Fassade_(Entwurfsmuster)
Muster AG Seite 23
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 Kap. 8.8 („Authentifizierung am Backend“). Die Übertragung von API Keys in URLs DARF dagegen nicht erfolgen.
b) Mittels OAuth-Protokoll
c) Mittels X.509-Zertifikat
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 die vertrauliche Daten übertragen 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.
8.17 X.509-Zertifikate („SSL-Zertifikate“)
1. Alle externen HTTPS-Verbindungen MÜSSEN valide und vertrauenswürdige X.509-Zertifikate verwenden.
2. Alle X.509-Zertifikate MÜSSEN eine Schlüssellänge von mindestens 2048 Bit besitzen.
3. Externe Anwendungen mit einer Assuranceklasse >= [HOCH] MÜSSEN eine Schlüssellänge von 4096 Bit besitzen.
Muster AG Seite 24
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 Muster AG beschrieben.
Zentral zu setzende Header:
Response Header Allgemeine Empfehlung Wann?Content-Type ...; charset=utf-8 ImmerStrict-Transport-Security16
max-age=10886400; includeSubDomains; preload
Für alle Webanwendungen, auf denen sich die Verwendung von HTTPS erzwingen lässt.
X-XSS-Protection17 1; mode=block ImmerX-Frame-Options18 SAMEORIGIN ImmerReferrer-Policy same-origin ImmerX-Content-Type-Options19
nosniff Immer
Anwendungsspezifisch zusetzende 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-storeBei Übertragung sensibler Daten.Pragma no-cache
Expires -1
Content-Security-Policy20
script-src 'self' [URL1] [URL2]; style-src 'self' unsafe-inline;object-src 'self'
Allgemeine Empfehlung für neue Anwendungen
16 HTTP Strict Transport Security (HSTS): Forciert, dass 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.17 Additiver Schutz vor Cross-Site Scripting (nur für IE).18 Unterbindung von „Framing“ und Schutz vor Clickjacking19 Deaktiviert MIME-Sniffing in Browsers, wodurch dieser versucht, den MIME-Type anhand des Inhaltes (und nicht des angegebenen MIME-Types) zu identifizieren.20 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.
Muster AG Seite 25
Response Header Allgemeine Empfehlung Wann?Content-Disposition attachment; filename=<dateiname> Bei potentiell nicht
vertrauenswürdigen Dateidownloads.X-Download-Options noopen
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.
Muster AG Seite 26
