Vorlage eines technisch-organisatorischen Sicherheitsstandards für Webanwendungen (TSS-WEB)

Transkript

1 Vorlage eines technisch-organisatorischen Sicherheitsstandards für Webanwendungen (TSS-WEB) Version v1.01 (21. März 2015) Matthias Rohr (Secodis GmbH, Hamburg) 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 heruntergeladen werden. Anmerkungen und Fragen bitte an 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 ( Dieses Dokument ist lizenziert unter der Creative Commons Namensnennung 4.0 International Lizenz ( 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.

2 Änderungshistorie Version Datum Änderungen Release (siehe Changelog für Anpassungen gegenüber Vorabversionen) v Neue Definition Vertraulicher Programmcode und deren konsistente Verwendung im Standard. Muster AG Seite 2

3 Sicherheitsstandard für Webanwendungen Firma Muster AG Version: 1.0 Klassifikation: Muster AG Seite 3

4 Inhalt 1 Einführung Geltungsbereich Arten von Vorgaben Definitionen Rollen Beheben von Schwachstellen in Anwendungen Sicherheit beim Betrieb Sicherheit von Programmcode Sicherheit im Entwicklungsprozess Sicherheitstests Zulieferervorgaben Implementierungsvorgaben Allgemeine Grundsätze Eingabevalidierung Dateiuploads und -downloads Ausgabevalidierung (Enkodierung & Escaping) Authentifizierung & Registrierung von Benutzern Benutzerpasswörter I: Stärke und Behandlung Benutzerpasswörter II: Änderung und Zurücksetzung Inter-Komponenten-Authentifizierung (Authentifizierung am Backend) Absicherung des Session Managements Zugriffskontrollen (Access Controls) Fehlerbehandlung & Logging Datensicherheit & Kryptographie Verwaltung kryptographischer Schlüssel Clientseitige Sicherheit Webdienste und XML-Parser Anhang A: Vorgaben für Security Header Anhang B: Häufige Schwachstellen für Webanwendungen (OWASP Top 10) Muster AG Seite 4

5 Dokumenteigenschaften Ablageort Owner Typ Klassifikation Technischer Standard Nur für internen Gebrauch (intern) Nächster Review Referenzierte Dokumente Dokument TSS-WEB Version 1.01, Autor: M. Rohr, Secodis GmbH (Vorlage) Information Security Policy Passwort Policy Ablageort tbd tbd Ansprechpartner für dieses Dokument Name Bereich Änderungshistorie Version Datum Änderungen Geändert von Initiales Dokument auf Basis von TSS-WEB v1.01 Max Mustermann Muster AG Seite 5

6 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. AJAX- Schnittstellen) besitzen. - 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. - Kritikalität: Hier: Synonym für Geschäftskritikalität. - Vertrauliche Daten: Daten, welche (1) vertrauliche Informationen enthalten bzw. enthalten könnte (z.b. Patente, sensible Rechenlogik, personenbezogene Daten, Paßwörter), Muster AG Seite 6

7 (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 Programmcode: Source- bzw. Programmcode, welcher nicht sensibel ist (Standard). 1.4 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

8 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 Als kritisch bewertete Als hoch bewertete Als mittel bewertete Schwachstelle Schwachstelle Schwachstelle Kritikalität 1 der Anwendung Kritische Anwendung Nicht kritische Anwendung zum nächsten Arbeitstag Innerhalb von 7 Tagen Innerhalb von 7 Tagen 2 Innerhalb von 21 Tagen Im Rahmen des nächsten Releases, jedoch spätestens nach 6 Monaten. - 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: Bewertung der Schwachstelle Als kritisch bewertete Als hoch bewertete Als mittel bewertete Schwachstelle Schwachstelle Schwachstelle Kritikalität der Anwendung Kritische Anwendung Nicht kritische Anwendung Innerhalb von 7 Tagen Innerhalb von 21 Tagen Innerhalb von 30 Tagen Innerhalb von 60 Tagen Im Rahmen des nächsten Releases, jedoch spätestens nach 12 Monaten. - Tabelle 2-2: Vorgaben zur Behebung von Schwachstellen für interne Anwendungen 1 Kritikalität = Geschäftskritikalität 2 Tage = Kalendertage Muster AG Seite 8

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

10 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 Patch- Management-Prozess etabliert werden (3rd-Party-Patch-Management). 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

11 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 Krypto- Muster AG Seite 11

12 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

13 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: Erreichbarkeit der Anwendung Externe Anwendung Interne Anwendung (Aus dem Internet erreichbar) (Nicht aus dem Internet erreichbar) Kritikalität der Anwendung Kritische Anwendung Nicht kritische Anwendung Vor Produktivsetzung und min einmal jährlich 3 Vor Produktivsetzung und min alle zwei Jahre Zeitnah zur Produktivsetzung und min alle drei 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

14 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-BSIMM 4 festgelegten organisatorischen Reifegrades seiner Applikationssicherheit. 4 vgl. Muster AG Seite 14

15 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): Es SOLLTE stets eine mehrschichtige Sicherheit implementiert werden. 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. DOM- Based 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 von Datentyp, Länge und Wertebereich) möglichst restriktiv erfolgen. 5. Eingaben SOLLTEN stets kanonisiert und normalisiert (insb. Dateipfade) werden bevor eine Validierung durchgeführt werden. Muster AG Seite 15

16 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 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 ( Muster AG Seite 16

17 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 2 6 ). 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 , Electronic Authentication Guideline, IS Electronic Authentication Levels Muster AG Seite 17

18 demselben System befinden ( Soft Crypto Token ). Beispiele hierfür sind: X.509- Zertifikate, oder Codes die per SMS oder 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 E- Mail-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-Komponenten- Authentifizierung ). 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) -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 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

19 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) 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 PBKDF2- Algorithmus 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 -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

20 8.8 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, SSL- 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 SSL-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 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