Vorlage eines technisch-organisatorischen Sicherheitsstandards für

Commentaren

Transcriptie

Vorlage eines technisch-organisatorischen Sicherheitsstandards für
Vorlage eines
technisch-organisatorischen
Sicherheitsstandards für
Webanwendungen
(TSS-WEB)
Version 1.0 (20. Februar 2015)
Matthias Rohr (Secodis GmbH, Hamburg)
https://www.secodis.com/tss-web
Dieses 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. Die aktuelle Version der Vorlage kann
von https://www.secodis.com/tss-web heruntergeladen werden. Anmerkungen und Fragen
bitte an [email protected] richten.
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 architektureller 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 in dem
Buch „Sicherheit von Webanwendungen in der Praxis“ (www.webappsecbuch.de).
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.
Sicherheitsstandard für Webanwendungen – Version 1.0
INTERN
Änderungshistorie
Version
Datum
Änderungen
1.0
20.02.2015
Release (siehe Changelog für Anpassungen gegenüber
Vorabversionen)
Muster AG
Seite 2
Sicherheitsstandard für Webanwendungen – Version 1.0
INTERN
Sicherheitsstandard für
Webanwendungen
Firma Muster AG
Version: 1.0
Klassifikation: INTERN
Muster AG
Seite 3
Sicherheitsstandard für Webanwendungen – Version 1.0
INTERN
Inhalt
1 Einführung ....................................................................................................................................... 6 1.1 Geltungsbereich ....................................................................................................................... 6 1.2 Arten von Vorgaben ................................................................................................................ 6 1.3 Definitionen ............................................................................................................................. 6 1.4 Rollen ...................................................................................................................................... 7 2 Beheben von Schwachstellen in Anwendungen .............................................................................. 8 3 Sicherheit beim Betrieb ................................................................................................................... 9 4 Sicherheit von 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 ..................................................................... 19 8.7 Benutzerpasswörter II: Änderung und Zurücksetzung .......................................................... 19 8.8 Inter-Komponenten-Authentifizierung (Authentifizierung am Backend) ............................. 20 8.9 Absicherung des Session Managements ................................................................................ 20 8.10 Zugriffskontrollen (Access Controls) .................................................................................... 21 8.11 Fehlerbehandlung & Logging................................................................................................ 21 8.12 Datensicherheit & Kryptographie.......................................................................................... 21 8.13 Verwaltung kryptographischer Schlüssel .............................................................................. 22 8.14 Clientseitige Sicherheit.......................................................................................................... 22 8.15 Webdienste und XML-Parser ................................................................................................ 23 Anhang A: Vorgaben für Security Header ............................................................................................ 24 Anhang B: Häufige Schwachstellen für Webanwendungen (OWASP Top 10).................................... 26 Muster AG
Seite 4
Sicherheitsstandard für Webanwendungen – Version 1.0
INTERN
Dokumenteigenschaften
Ablageort
Owner
Typ
Technischer Standard
Klassifikation
Nur für internen Gebrauch (intern)
Nächster Review
Referenzierte Dokumente
Dokument
Ablageort
TSS-WEB Version 1.0, Autor: M. Rohr, https://www.secodis.com/tss-web
Secodis GmbH (Vorlage)
Information Security Policy
tbd
Passwort Policy
tbd
Ansprechpartner für dieses Dokument
Name
E-Mail
Bereich
Änderungshistorie
Version
Datum
Änderungen
0.1
24.03.2015
Initiales Dokument auf Basis von Max Mustermann
TSS-WEB v1.0
Muster AG
Geändert von
Seite 5
Sicherheitsstandard für Webanwendungen – Version 1.0
INTERN
1 Einführung
Dieser Standard beschreibt generelle Sicherheitsvorgaben (Baseline) für alle webbasierten
Anwendungen oder Anwendungskomponenten die von oder für die Muster AG 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. Die Implementierungsvorgaben sind dabei nur für solche Anwendungen
verpflichtend, die ab diesem Zeitpunkt neu entwickelt oder ausgeschriebenen werden, für alle
übrigen besitzen diese Vorgaben generell 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: Eine Anwendung auf Basis von Webtechnologien, vor allem HTTP
und HTML. Eine Webanwendung kann verschiedene Webdienste (z.B. AJAXSchnittstellen) besitzen.
-
Interne Webanwendung: Eine Webanwendung die nur innerhalb des Unternehmens
aufrufbar ist.
-
Externe Webanwendung: Eine Webanwendung
Unternehmens (z. B. über das Internet) aufrufbar ist.
-
Kritikalität: Hier: Synonym für Geschäftskritikalität.
-
Sensibler Source- oder Programmcode: Source- bzw. Programmcode, welcher
die
von
außerhalb
des
(1) vertrauliche Informationen enthält bzw. enthalten könnte (z.B. Patente, sensible
Rechenlogik, personenbezogene Daten, Paßwörter),
Muster AG
Seite 6
Sicherheitsstandard für Webanwendungen – Version 1.0
INTERN
(2) explizit als solcher gekennzeichnet wurde oder
(3) allgemein nur einem eingeschränkten Personenkreis zugänglich ist.
-
1.4
Interner Programmcode: Source- bzw. Programmcode, welcher nicht sensibel ist
(Standard).
Rollen
In diesem Standard werden die folgenden Rollen verwendet:
-
Security Auditor: Sachverständige Person, welche Sicherheitsfreigeben durchführt.
-
Application Owner: Fachlicher „Eigentümer“ der Anwendung (gewöhnlich der
Fachbereich)
Referenzierungen auf diese Rollen sind in diesem Standard kursiv gekennzeichnet.
Muster AG
Seite 7
Sicherheitsstandard für Webanwendungen – Version 1.0
INTERN
2 Beheben von Schwachstellen in Anwendungen
Identifizierte Sicherheitsprobleme sind generell zeitnah und ursächlich zu beheben. Sofern die
ursächliche Behebung einer Schwachstelle 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
Kritikalität1 der
Anwendung
Als „kritisch“ bewertete
Schwachstelle
Als „hoch“ bewertete
Schwachstelle
Als „mittel“ bewertete
Schwachstelle
Kritische
Anwendung
zum nächsten
Arbeitstag
Innerhalb von
7 Tagen2
Im Rahmen des
nächsten Releases,
jedoch spätestens
nach 6 Monaten.
Nicht
kritische
Anwendung
Innerhalb von
7 Tagen
Innerhalb von
21 Tagen
-
Tabelle 2-1: 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:
Kritikalität der
Anwendung
Bewertung der Schwachstelle
Als „kritisch“ bewertete
Schwachstelle
Als „hoch“ bewertete
Schwachstelle
Als „mittel“ bewertete
Schwachstelle
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-2: Vorgaben zur Behebung von Schwachstellen für interne Anwendungen
1
2
Kritikalität = Geschäftskritikalität
Tage = Kalendertage
Muster AG
Seite 8
Sicherheitsstandard für Webanwendungen – Version 1.0
INTERN
3 Sicherheit beim Betrieb
Die folgenden Vorgaben gelten für infrastrukturelle Komponenten, auf denen produktive
Anwendungen der Muster AG ausgeführt werden:
1. Produktions-, Entwicklungs- und Testsysteme MÜSSEN strikt voneinander getrennt
werden.
2. Produktiv eingesetzte Plattformen (z. B. Webservern, Application Servern, 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 JavaAnwendung)
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. Systemprozesse MÜSSEN mit minimalen Berechtigungen, und idealerweise in einer
abgeschotteten Umgebung (chroot), und mit einer dedizierten Systemkennung ausgeführt
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 entsprechend starke Authentifizierung (z. B.
Mehrfaktor-Authentifizierung, SSL-Zertifikat + Passwort) erfolgen.
6. Anwendungen, die sowohl intern als auch extern erreichbar sind SOLLTEN entsprechend
in eine interne und externe Instanz (bis herunter zur Datenhaltung) separiert werden.
7. Webanwendungen, 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.
Muster AG
Seite 9
Sicherheitsstandard für Webanwendungen – Version 1.0
INTERN
4 Sicherheit von Programmcode
Die folgenden Vorgaben gelten für den Schutz des gespeicherten Sourcecodes der Muster
AG, sowie der Sicherheit eingebundener 3rd-Party-Komponenten:
1. Alle Zugriffe auf sensiblen Sourcecode MÜSSEN auf erforderliche Personengruppen
beschränkt werden (Need-to-Know-Prinzip). Hierzu MÜSSEN alle Zugriffe auf diesen
Code von dem Repository-System entsprechend authentifiziert und autorisiert werden.
2. Der Austausch von sensiblem und internem Sourcecode DARF NUR über sichere Kanäle
(z. B. S/MIME oder per SSL/TLS) erfolgen.
3. Sourcecode DARF NUR nach expliziter Freigabe (z.B. in Internet Foren) veröffentlicht oder
Externen zugänglich gemacht werden.
4. Werden externe Code Repositorys angebunden MUSS sichergestellt werden, dass diese
vertrauenswürdig sind. Hierfür ist ein entsprechender Freigabeprozess festzulegen.
5. 3rd-Party-Komponenten (Maven-Artefakte, APIs, Frameworks, etc.) SOLLTEN vor ihrer
Verwendung in produktiven Anwendungen auf mögliche Schwachstellen (insb. Known
Vulnerabilities) hin geprüft und die Einbindung einer solchen Komponente im Verdachtsfall
(Abbruch des Builds) unterbunden werden. Dies SOLLTE automatisiert mittels geeigneter
Tools erfolgen.
6. 3rd-Party-Komponenten SOLLTEN darüber hinaus periodisch auch innerhalb des
Repositorys mittels geeigneter Tools im Hinblick auf neu bekanntgewordene
Schwachstellen (insb. Known Vulnerabilities) geprüft werden.
7. Für 3rd-Party-Komponenten SOLLTE ein dedizierter und toolbasierter
Management-Prozess etabliert werden (3rd-Party-Patch-Management).
Patch-
8. Bevor eine 3rd-Party-Komponente in der Produktion (bzw. der Release Build Umgebung)
eingebunden wird, MUSS diese über einen entsprechenden Prozess explizit hierfür
freigegeben werden.
Muster AG
Seite 10
Sicherheitsstandard für Webanwendungen – Version 1.0
INTERN
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. Sicherheit MUSS im Rahmen des gesamten Entwicklungsprozesses angemessen
Betrachtung finden (Anforderungen, Architektur, Implementierung, Test 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 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.
d. Vor deren Produktivnahme MUSS jede neu entwickelte externe oder
geschäftskritische interne Webanwendung einer finalen Sicherheitsabnahme durch
den Security Auditor unterzogen und durch diesen freigegeben werden (siehe hierzu
Kap. 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 (Verarbeitete Daten, Schutzbedarf/Kritikalität, Schnittstellen)

Sicherheitsannahmen (z. B. „Ausgelegt für den internen Einsatz und Verwendung
mit maximal vertraulichen Daten“)

Zugrundeliegende Sicherheitsvorgaben (z. B. Sicherheitsstandards)

Relevante Bedrohungen (z. B. in Form eines Bedrohungsmodells)

Sicherheitsarchitektur

Sicherheitsmaßnahmen / -Anforderungen (fachlich und technisch)

Sicherheitsumsetzungsplanung (z. B. geplante Pentests)
4. Selbstentwickelte sicherheitsrelevante Funktionen (z. B. Access Controls oder KryptoMuster AG
Seite 11
Sicherheitsstandard für Webanwendungen – Version 1.0
INTERN
APIs) SOLLTEN mittels eines Code Reviews analysiert und freigegeben werden. Dies
betrifft auch an diesen durchgeführten Änderungen.
5. Produktive
Webanwendungen
SOLLTEN
periodisch
auf
mögliche
Sicherheitsbedrohungen (z.B. Schwachstellen, abgelaufene Zertifikate, Malware) hin
geprüft werden.
Muster AG
Seite 12
Sicherheitsstandard für Webanwendungen – Version 1.0
INTERN
6 Sicherheitstests
Die folgenden Vorgaben gelten in Bezug auf die Durchführung von Sicherheitstests von
Anwendungen der Muster AG:
1. Die korrekte Umsetzung jeder sicherheitsrelevanten Anforderung MUSS über einen
entsprechenden Sicherheitstest verifiziert werden.
2. Wo dies möglich und sinnvoll ist, SOLLTEN Sicherheitstests bereits frühzeitig (etwa im
Rahmen der Entwicklung) und automatisiert durchgeführt werden.
3. Jede Änderung an einer Anwendung (Change) MUSS im Hinblick auf die Notwendigkeit
bewertet werden ob für diesen ein Sicherheitstest erforderlich ist.
4. Für jeder Produktivnahname einer geschäftskritischen oder externen Anwendung und
jeder sicherheitsrelevanten Änderung sowie periodisch und abhängig von ihrer Kritikalität,
MUSS ein Pentest durchgeführt werden. Hierfür gilt die folgende Testing Policy: Kritikalität der
Anwendung
Erreichbarkeit der Anwendung
Externe Anwendung
(Aus dem Internet erreichbar)
Interne Anwendung
(Nicht aus dem Internet erreichbar)
Kritische
Anwendung
Vor Produktivsetzung und
min einmal jährlich3
Zeitnah zur Produktivsetzung und
min alle drei Jahre
Nicht kritische
Anwendung
Vor Produktivsetzung und
min alle zwei Jahre
-
Tabelle 6-1: Vorgaben für die Durchführung von Pentests 5. Bei der Durchführung von fachlichen Tests SOLLTEN auch Sicherheitsaspekte getestet
werden.
6. Sicherheitsabnahmen DÜRFEN NUR von Security Auditoren durchgeführt werden.
7. Nach der Korrektur jeder als hoch bewerteten 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.
8. Auf Entwicklungs- und Testsystemen DÜRFEN NUR synthetische oder anonymisierte
Produktivdaten verwendet werden, die keine Vertraulichkeit besitzen.
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.
3
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
Sicherheitsstandard für Webanwendungen – Version 1.0
INTERN
7 Zulieferervorgaben
Die folgenden Vorgaben gelten für Lieferanten, die im Auftrag der Muster AG Software
entwickeln und sollten im Rahmen von vertraglichen Vereinbarungen aufzuführen. Der
Auftragnehmer verpflichtet sich:
1. Zur Einhaltung der allgemeinen Sorgfaltspflicht: Alle notwendigen 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 Vorgaben an die Implementierung,
den Betrieb und die Dokumentation.
3. Einen Ansprechpartner für Sicherheitsfragen in seinem Hause zu benennen.
4. Nur autorisierte und erforderliche (Need-to-Know-Prinzip) Personen Zugriff auf den im
Auftrag erstellten Sourcecode besitzen.
5. Den im Auftrag erstellten Sourcecode (Individualcode) 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).
7. Auf Umsetzung des in V-BSIMM4 festgelegten organisatorischen Reifegrades seiner
Applikationssicherheit.
4
vgl. http://www.bsimm.com/related/
Muster AG
Seite 14
Sicherheitsstandard für Webanwendungen – Version 1.0
INTERN
8 Implementierungsvorgaben
Die 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. Misstrauensprinzip: Daten, die von einem Client stammen MÜSSEN stets mißtraut und
diese daher entsprechend validiert werden.
3. Mehrschichtige Sicherheit (Defense-in-Depth-Prinzip):
mehrschichtige Sicherheit implementiert werden.
Es
SOLLTE
stets
eine
4. Anpassbarkeit von Sicherheitseinstellungen: Sicherheit SOLLTE stets deklarativ (=
mittels Konfigurationsanweisungen) 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 immer serverseitig erfolgen, DÜRFEN jedoch zusätzlich aus
Usability-Gründen auch clientseitig durchgeführt werden. Clientseitige Validierung dient
aus Sicherheitssicht ausschließlich dem Schutz vor clientseitigen Angriffen (z. B. DOMBased XSS).
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
Wertebereich) möglichst restriktiv erfolgen.
von
Datentyp,
Länge
und
5. Eingaben SOLLTEN stets kanonisiert und normalisiert (insb. Dateipfade) werden bevor
eine Validierung durchgeführt werden.
Muster AG
Seite 15
Sicherheitsstandard für Webanwendungen – Version 1.0
INTERN
6. Eingabeprüfungen SOLLTEN wenn möglich implizit mittels Databindung (bzw. Type
Casting) erfolgen.
7. Eingabeprüfungen MÜSSEN auf sämtliche Parameter angewendet werden. Dies schließt
neben Benutzerparametern auch Anwendungsparameter (werden durch den Benutzer
nicht selbst eingegeben) 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 sichere API restriktiv validiert werden.
10. XML-Eingaben MÜSSEN mit restriktivem XML-Schemas 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.
2. Hochgeladene Dateien SOLLTEN in einer zugriffsgeschützten Datenbank abgelegt
werden.
3. Erfolgt die Ablage stattdessen auf dem Dateisystem, so MÜSSEN die folgenden Vorgaben
berücksichtigt werden:
a) Jeder Dateiupload SOLLTE die Erstellung einer neuen Datei zur Folge haben.
b) Dateiuploads MÜSSEN außerhalb des Document Roots gespeichert werden
c) Dateiuploads MÜSSEN mit restriktiven Berechtigungen abgelegt werden (z. B.
mittels des Unix-Kommandos „chmod 0644“). Abgelegte Dateien DÜRFEN NICHT
ausführbar sein.
4. Dateiuploads SOLLTEN über den angemeldeten Bereich abgebildet werden. Dort wo dies
nicht möglich ist, MÜSSEN ausreichende Anti-Automatisierungs-Mechanismen
implementiert werden, um DoS-Angriffe hinreichend zu unterbinden.
5. Die Größe hochgeladener Dateien MUSS auf einen sinnvollen Wert (z. B. 5 MB)
beschränkt werden.
6. Die Anzahl hochgeladener Dateien MUSS auf einen sinnvollen Wert beschränkt werden
(z. B. 8 Dateien pro Stunde).
7. 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.
8. Zusätzlich zur Datei-Erweiterung MUSS der angegebene MIME-Type einer Datei verifiziert
werden.
9. Hochgeladene Dateien SOLLTEN mittels einer Antiviren-Prüfung auf möglichen
Schadcode hin geprüft und im Positivfall verweigert werden.5
10. Dateidownloads SOLLTEN über eine separate Origin erfolgen (z.B. „files.example.com“),
um dadurch die Auswirkungen von ausgeführten Skriptcode zu begrenzen
11. Bei Dateidownloads SOLLTEN entsprechende Security Header gesetzt werden, um damit
5
Diese Funktion lässt sich mit der EICAR-Testdatei testen (www.eicar.org)
Muster AG
Seite 16
Sicherheitsstandard für Webanwendungen – Version 1.0
INTERN
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,
oder einem vergleichbaren Verfahren zur Parametrisierung 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 Parameter stets parametrisiert werden. Eine
Konkatenierung (Aneinanderhängen) von Parametern in solchen Interpreter-Aufrufen ist
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 enkodiert werden:
a) Im HTML-Kontext mittels HTML Entity Encoding
b) Im JavaScript-Kontext mittels JavaScript Encoding
c) Im CSS-Kontext mittels CSS Escaping
5. JSON-Code DARF ausschließlich mit einer sicheren API wie JSON.parse() (nicht jedoch
eval()!) interpretiert werden.
6. Statt JavaScript-APIs die „.innerHTML“ im Namen tragen 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.
7. Sofern vorhanden, SOLLTEN für die Durchführung der Ausgabevalidierung nur
ausgereifte APIs und Frameworks zum Einsatz kommen.
8. 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. Für die Authentifizierung von Benutzern und Systemen MÜSSEN dem Schutzbedarf
angemessene Verfahren zum Einsatz kommen.
2. Es gelten die folgenden Anforderungen für Authentifizierungs-Verfahren:
a) Normal Schutzniveau (Standardwert): Passwort-basierte Authentifizierung über
sicheres Verfahren. Passwörter müssen konform zur Passwort-Policy sein (NIST Level
26).
b) Hohes Schutzniveau: Wie beim normalen Schutzniveau, jedoch in Verbindung mit
einem zusätzlichen (Authentifizierungs-)Faktor. Der Faktor muss über einen anderen
Kanal oder Kommunikationsschicht übertragen werden, darf sich jedoch auf
6
Siehe NIST SP 800-63-1, Electronic Authentication Guideline, IS Electronic Authentication Levels
Muster AG
Seite 17
Sicherheitsstandard für Webanwendungen – Version 1.0
INTERN
demselben System befinden („Soft Crypto Token“). Beispiele hierfür sind: X.509Zertifikate, oder Codes die per SMS oder E-Mail zugesendet werden (NIST Level 3).
c) Sehr hohes Schutzniveau: Wie hohes Schutzniveau, jedoch muss der zusätzliche
Faktor über ein separaten 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).
3. Sofern sich ein erweitertes Schutzniveau nicht über eine Mehrfaktor-Authentifizierung
abbilden lässt DARF hierzu alternativ eine Passwort-basierte Authentifizierung in
Verbindung mit einer IP-Adress-Prüfung verwendet werden.
4. Unsichere Authentifizierungs-Verfahren wie HTTP Basic SOLLTEN nicht zum Einsatz
kommen. Lässt sich dies nicht vermeiden, so DARF dies nur in Verbindung mit HTTPS
erfolgen.
5. Bei Benutzerregistrierung und Authentifizierung MÜSSEN auf extern erreichbaren
Systemen geeignete Verfahren zum Einsatz kommen, die automatisierte Angriffe (z. B.
Brute Forcing) unterbinden. Beispiele hierfür sind eingebaute Delays, Throttling oder
CAPTCHAs (Anti-Automatisierungs-Techniken).
6. Zur Registrierung MUSS sich ein Benutzer über ein angemessenes Verfahren
identifizieren. Bevor diese Identifikation erfolgt ist, darf der Benutzer sich nicht an der
Anwendung anmelden dürfen.
7. Zur Authentifizierung eines Benutzers sind dem Schutzbedarf der Anwendung
angemessene Verfahren einzusetzen. Bei normalem Schutzbedarf KÖNNEN hierzu EMail-Adressen verwendet, bei erweitertem SOLLTE ein zusätzlicher Faktor (z.B. Handy)
zum Einsatz kommen, bei einem sehr hohem Schutzbedarf MUSS eine persönliche
Identifikation erfolgen
8. Hintergrundsysteme MÜSSEN stets authentifiziert werden (siehe „Inter-KomponentenAuthentifizierung“).
9. Anforderungen an Benutzernamen:
a) Default-Accounts (z. B. „admin“) MÜSSEN deaktiviert werden
b) Benutzernamen SOLLTEN frei wählbar und personen-spezifisch sein.
c) E-Mail-Adressen als Benutzernamen lassen sich einfach ermitteln und SOLLTEN
daher nicht verwendet werden.
d) Zum Login verwendete Benutzernamen SOLLTEN anderen Benutzernamen nicht
angezeigt werden, ist dies doch erforderlich SOLLTE hierzu ein zusätzlicher Alias
verwendet werden.
10. 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.“.
11. Die Autovervollständigung in Anmeldefeldern SOLLTE stets unterbunden werden. In den
entsprechenden HTML-Input-Feldern ist hierzu das Attribut autocomplete="off" zu setzen.
Muster AG
Seite 18
Sicherheitsstandard für Webanwendungen – Version 1.0
8.6
INTERN
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
Benutzerpasswörter
Passwort-Policy
nicht
anders
vorgegeben,
MÜSSEN
a) mindestens 8 Zeichen Länge besitzen,
b) sowohl aus Buchstaben, Zahlen und Sonderzeichen enthalten
c) nicht identisch mit dem Benutzernamen sein,
d) eine eingeschränkte Gültigkeit besitzen (z. B. 12 Monate) und danach durch den
Benutzer neu gesetzt werden müssen,
e) nicht angezeigt oder ausgegeben werden,
f)
nur verschlüsselt über unsichere Netze übertragen werden,
g) nur mittels sicheren Verfahren, vorzugsweise Salted Hash und 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 PBKDF2Algorithmus eingesetzt werden.
3. Initialpasswörter MÜSSEN beim ersten Login durch den Benutzer geändert werden.
4. Standardpasswörter 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 MÜSSEN das gleiche Sicherheitsniveau wie die
Anmeldefunktion besitzen und genauso vor mißbräuchlicher Verwendung geschützt
werden.
6. Passwort-Vergessen-Funktionen MÜSSEN über die E-Mail-Adresse (oder ein anderes
Verfahren mit einem vergleichbaren oder höheren Sicherheitsniveau) durch den Benutzer
autorisiert werden. Solange dies nicht erfolgt ist, darf der Aufruf der Funktion keinerlei
Änderung am Profil des Benutzers und seines Passwortes zur Folge haben (z. B. dessen
Deaktivierung).
7. Passwort-Vergessen-Funktionen SOLLTEN mittels hinterlegtem Wissen (z. B. Abfrage
einer durch den Benutzer festgelegte Sicherheitsfrage) geschützt werden.
Muster AG
Seite 19
Sicherheitsstandard für Webanwendungen – Version 1.0
8.8
INTERN
Inter-Komponenten-Authentifizierung (Authentifizierung am Backend)
1. Verteilte Anwendungskomponenten SOLLTEN sich stets gegenseitig authentifizieren.
2. Dies SOLLTE auf mehreren Ebenen durchgeführt werden (z. B. IP-Adressen, SSLZertifikate, 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 SSL-Zertifikate (Public-KeyAuthentifizierung 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
d) gemäß der Vorgaben zu kryptographischer Schlüssel (8.13) gespeichert werden.
8.9
Absicherung des Session Managements
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) 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
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.
Muster AG
Seite 20
Sicherheitsstandard für Webanwendungen – Version 1.0
INTERN
e) Bei ändernden Anfragen innerhalb einer Session MUSS das Wiedereinspielen
(Session Replay) sowie Unterschieben von Anfragen durch einen Dritten (Cross-Site
Request Forgery) verhindert werden. Hierfür lassen sich z. B. zufällige Anti-ReplayTokens (bzw. Anti-CSRF-Tokens) verwenden, die als zusätzlicher Parameter (in URL
oder Hidden-Field) eingebaut werden. Eine solche Anfrage DARF NUR in Verbindung
mit einem gültigen Token zugelassen werden.
8.10 Zugriffskontrollen (Access Controls)
1. Jeder sensible Objektzugriff SOLLTE stets dediziert autorisiert werden (CompleteMediation-Prinzip)
2. Zugriffsprüfungen MÜSSEN serverseitig erfolgen.
3. Zugriffsprüfungen SOLLTEN sowohl auf URL-, also auch auf Datei-, Methoden- und
Objekt-Ebene durchgeführt werden.
4. Jeder Prozess DARF NUR die notwendigen Berechtigungen auf Ressourcen
(Dateisystem, Datenbank, etc.) besitzen (Least-Privilege-Prinzip).
5. Benutzer SOLLTEN auf sensible Datenbankobjekte über Indirektionen7 zugreifen.
6. Jede privilegierte Benutzerberechtigung SOLLTE mit einer zeitlichen Gültigkeit versehen
werden.
7. Cross-Domain-Zugriffe MÜSSEN über sichere Verfahren (z. B. Cross Origin Sharing,
CORS) und minimaler Berechtigungen durchgeführt werden. Bei jedem Cross-DomainZugriff MUSS eine Prüfung des Herkunft der Anfrage (z.B. durch Auswerten des Origin
Headers) erfolgen.
8.11 Fehlerbehandlung & Logging
1. Es MUSS sichergestellt werden, dass die Anwendung beim Auftreten eines Fehlers
niemals in einen unsicheren Zustand fallen kann. 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.
2. Im Falle eines aufgetretenen Fehlers DÜRFEN Benutzern KEINE technischen Details
angezeigt werden (z. B. durch Ausgabe von Stack Traces).
3. Sicherheitsrelevante Zugriffe und Ereignisse (z. B. Anmeldung eines Administrators)
MÜSSEN stets geloggt werden. Dies SOLLTE in einem separaten Security Log erfolgen.
4. Anwendungen SOLLTEN Mechanismen besitzen um Mißbrauch und Angriffe erkennten
zu können (Application IDS).
8.12 Datensicherheit & Kryptographie
1. Es DÜRFEN nur ausgereifte und standardisierte kryptographische Algorithmen,
7
Unter einer Indirektion ist hier 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.
Muster AG
Seite 21
Sicherheitsstandard für Webanwendungen – Version 1.0
INTERN
Betriebsmodi, Schlüsselstärken, Ciphers und Implementierungen eingesetzt werden.8
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) mittels HTTP POST und DÜRFEN NICHT innerhalb der URL und
c) mittels gesetzter No-Cache-Header (siehe Anhang) erfolgen
3. Zugriffe auf geschützte Bereiche mittels des HTTP-Protokolls MÜSSEN auf den HTTPSKontext weitergeleitet werden. Hierzu SOLLTE eine permanente Weiterleitung verwendet
werden.
4. Generell SOLLTEN alle externen Webinhalte über HTTPS abrufbar sein.
5. Ein SSL/TLS-Server MUSS aktuelle Cipher und Protokolle mit sehr hoher Sicherheit
unterstützen. Unsichere SSL/TLS-Cipher oder Protokolle (z. B. SSLv2) MÜSSEN
deaktiviert werden.
6. Perfect Forward Secrecy MUSS auf allen SSL/TLS-Servern unterstützt werden.
7. HTTPS-Webseiten SOLLTEN HTTP Strict Transport Security (HSTS) verwenden (siehe
8.14).
8. Benutzerpasswörter MÜSSEN durch geeignete kryptographische Verfahren gespeichert
werden (siehe 8.6).
8.13 Verwaltung kryptographischer Schlüssel
1. Vertrauliche kryptographische Schlüssel (geheime Schlüssel bei symmetrischer und
private Schlüssel bei asymmetrischer Kryptographie) MÜSSEN vor unberechtigtem Zugriff
geschützt werden.
2. Kryptographische Schlüssel MÜSSEN getrennt vom Programmcode und restriktivem
Zugriffsschutz abgelegt werden.
3. Kryptographische Schlüssel SOLLTEN ebenfalls verschlüsselt werden. Der hierfür
verwendete interne Schlüssel darf in diesem Fall innerhalb des Programmcodes abgelegt
werden.
4. Für Schlüssel mit besonders hohem Schutzbedarf SOLLTE ein hardware-basierter
Speichert (HSM) eingesetzt werden oder deren Eingabe manuell durch eine oder mehrere
Personen (im Falle eines geforderten Mehr-Augen-Prinzips) erfolgen.
8.14 Clientseitige Sicherheit
1. Konkrete Vorgaben im Hinblick auf zu setzende HTTP-Header und entsprechender Werte
sind dem Anhang zu entnehmen.
2. Clientseitig DARF KEINE sensible Geschäftslogik offengelegt werden.
3. Für extern erreichbaren Webanwendungen, die ausschließlich über HTTPS erreichbar
sein sollen, MUSS HTTP Strict Transport Security (HSTS) verwendet werden. Dafür MUSS
der Header „Strict-Transport-Security“ mit jeder HTTP-Antwort mitgesendet werden.
8
Siehe hierzu BSI Technische Richtlinie TR-02102-1, „Kryptographische Verfahren: Empfehlungen und
Schlüssellängen“
Muster AG
Seite 22
Sicherheitsstandard für Webanwendungen – Version 1.0
INTERN
4. 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).
5. Zum Schutz vor Cross-Site Scripting und anderen Bedrohungen SOLLTE bei externen
Webanwendungen eine Content Security Policy (CSP) verwendet werden und deren
Auswirkungen bereits im Rahmen der Entwicklung berücksichtigt werden. Im Besonderen
SOLLTE durch die CSP die Ausführung von Inline-Skriptcode unterbunden werden
(Default-Wert).
6. Sofern dies nicht explizit gefordert ist, MUSS eine externe Webanwendung verhindern,
dass sie als Frame von anderen Seiten eingebunden werden kann. Für ein solcher FrameBusting-Schutz SOLLTE der Header „X-Frame-Options“ bei jeder HTTP-Antwort
mitgesendet werden.
7. Zusätzlich KANN ein JavaScript-basierter Frame-Busting-Schutz implementiert werden
um auch Benutzer mit älteren Browser zu schützen.
8. Zur Absicherung von Dateidownload-Funktionen SOLLTE der Header „X-DownloadOptions“ verwendet werden.
9. Browser-Plugins wie ActiveX oder Java SOLLTEN nicht verwendet werden (Beispiel:
Funktionen in JavaScript statt als ActiveX-Control umsetzen).
10. Benutzern SOLLTE die Möglichkeit gegeben werden, browserseitige Security-Plugins zu
verwenden.
8.15 Webdienste und XML-Parser
1. XML-basierte Dienste SOLLTEN stets mittels eines restriktiven XML-Schemas 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.
2. Enthält die Antwort eines Webdienstes Skriptcode (z. B. JSON bzw. JavaScript), so MUSS
sichergestellt werden, daß dieser nicht direkt ausführbar ist.
3. Für alle Dienste (inkl. HTTP-basierter APIs), bei denen über eine authentifizierte Session
ändernde Anfragen durchgeführt werden, MUSS ein CSRF-Schutz implementiert werden
(vgl. Kap. 8.9).
4. WebSockets, über die vertrauliche Daten übermittelt werden, MÜSSEN das wss://Schema verwenden und eine Prüfung des Origin-Headers durchführen.
5. Eingesetzte XML-Parser SOLLTEN gehärtet werden, um gängige Angriffe:
a) Setzen von Limits (z. B. im Hinblick auf Verschachtelungstiefe oder Dokumentgröße)
b) Deaktivierung von extern (setzbaren) DTDs, Schemas, Doctype-Definitionen, Entitys.
6. Webdienste MÜSSEN dieselben Zugriffe stets auch mit denselben Sicherheitsvorgaben
(im Hinblick auf Authentifizierung, Validierung etc.) durchführen wie für das Web-GUIFrontend. Hierfür SOLLTEN dieselben Sicherheitsfunktionen (Programmcode, APIs)
verwendet werden.
Muster AG
Seite 23
Sicherheitsstandard für Webanwendungen – Version 1.0
INTERN
Anhang A: Vorgaben für Security Header
In 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.
Response Header
Allgemeine Empfehlung
Wann
Content-Type
...; charset=utf-8
Immer
Set-Cookie
… ;httpOnly; secure
Übertragung sensibler Daten in Cookies
(z. B. Session-IDs).
Cache-Control
no-cache
Pragma
no-cache
Expires
-1
Content-Security-Policy9
X-Content-Security-Policy
script-src ‘self’ [URL1] [URL2];
style-src ‘self’ unsafe-inline *
Allgemein Empfehlung für neue
Anwendungen10
Strict-Transport-Security11
max-age=10886400
[;includeSubDomains; preload]
Auf allen HTTPS-Webanwendungen,
auf denen sich die Verwendung von
HTTPS erzwingen lässt.
X-Frame-Options12
SAMEORIGIN (oder DENY)13
Immer
X-XSS-Protection14
1; mode=block
Immer
X-Content-Type-Options15
nosniff
Immer
X-Download-Options
noopen
Dort, wo Benutzer nichtvertrauenswürdige Dateien
herunterladen können.
Bei Übertragung sensibler Daten.
Achtung: Das Setzen dieser Header kann Auswirkungen auf die korrekte
Funktionsfähigkeit einer Webanwendung zur Folge haben. Daher SOLLTE die
9
Content Security Policy (CSP): Additiver, aber sehr wirksamer Schutz vor Cross‐Site Scripting und anderen clientseitigen Angriffen.
10
Die konkrete Policy kann im Zweifel angepasst werden, wichtig ist vor allem die Verhinderung von Inline‐Skriptcode („script‐src: unsafe‐inline“ sollte unbedingt vermieden werden. Mittels einer CSP lassen sich zahlreiche clientseitige Sicherheitsprobleme (vor allem XSS) als sekundäre Maßnahme wirksam auf vielen Browsern unterbinden. Allerdings setzt die Verwendung einer CSP voraus, dass die Anwendung entsprechend darauf ausgerichtet ist. 11
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. 12
Unterbindung von „Framing“ und Schutz vor Clickjacking 13
„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. 14
Additiver Schutz vor Cross‐Site Scripting (nur für IE) 15
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 24
Sicherheitsstandard für Webanwendungen – Version 1.0
INTERN
Verwendung eines neuen Headers stets nur in Verbindung mit ausführlichen
funktionalen Tests erfolgen.
Muster AG
Seite 25
Sicherheitsstandard für Webanwendungen – Version 1.0
INTERN
Anhang B: Häufige Schwachstellen für Webanwendungen (OWASP
Top 10)
Die OWASP Top 10 (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 10 2013
Relevante Sicherheitsanforderung(en)
A1-Injection
Primär: Einsatz von (1) Parametrisierung / ORM-Frameworks
(SQL Injection) und (2) Enkodierungs-APIs (vgl. Kap. 11).
Sekundär: Restriktive Eingabevalidierung (vgl. Kap. 8.2)
A2-Broken
Verwenden sicherer und starker Authentifizierungsverfahren (vgl.
Authentication
and Kap. 8.5) und Härten des Session Managements (vgl. Kap. 8.9.).
Session Management
A3-Cross-Site Scripting Primär : Kontextabhängige Ausgabevalidierung (vgl. Kap. 11, Anf.
(XSS)
4), idealerweise implizit über ein Webframework. Sekundär:
Einsatz von Security-Headern (vgl. Kap 8.14 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 Prüfung jedes sensiblen Objektzugriffes (auch auf Funktions- und
Object References
Objektebene) sowie Einsatz von Indirektionen (vgl. Kap. 3).
A5-Security
Misconfiguration
A6-Sensitive
Exposure
Härtung der Konfiguration des Application Servers (vgl. Kap. 3).
Data Härtung der Konfiguration (vgl. Kap. 3), restriktive
Fehlerbehandlung (vgl. Kap. 8.11), Maßnahmen zur
Datensicherheit (vgl. Kap. 8.12).
A7-Missing
Function Prüfung jedes sensiblen Objektzugriffes (auch auf Funktions- und
Level Access Control
Objektebene) sowie Einsatz von Indirektionen (vgl. Kap. 8.10).
A8-Cross-Site Request Verwendung von Anti-CSRF-Tokens bei allen schreibenden
Forgery (CSRF)
Anfragen innerhalb einer angemeldeten Session (vgl. Kap. 8.9,
Anf. 10).
A9-Using Components Etablierung eines Patch
with Known Vuln.
Komponenten (vgl. Kap. 4).
Managements
für
3rd-Party-
A10-Unvalidated
Validierung von Eingaben, idealerweise mittels Indirektionen oder
Redirects and Forwards Integritätsprüfungen wie z. B. Hashvergleiche (vgl. Kap. 8.2).
Muster AG
Seite 26

Vergelijkbare documenten