Examine

	Beschreibung
O.Arch 4	Backups und Cloud-Backups DÜRFEN KEINE sensiblen Daten im Klartext beinhalten. Die Web-Anwendung muss daher so gestaltet sein, dass sensible Daten auch durch den Browser nicht etwa in dessen Cache persistiert werden.
O.Arch 6	Die Architektur der Web-Anwendung SOLL einem minimalistischen Ansatz folgen und mit einer serverseitig lokalisierten Verarbeitungslogik realisiert sein, d.h. es SOLLEN keine komplexen aktiven Inhalte (Java Applets, ActiveX-Plugin, o.ä.) verwendet werden.
O.Auth 2	Die Web-Anwendung MUSS für die Anbindung an das Hintergrundsystem eine geeignete Authentifizierung und Autorisierung unterstützen. Die effektive Durchsetzung dieser Mechanismen MUSS im Falle der Web-Anwendung ausschließlich im Hintergrundsystem erfolgen. Insbesondere stellt der Autorisierungsmechanismus sicher, dass der authentifizierte Benutzer autorisiert ist auf die sensiblen Daten zuzugreifen.
O.Auth 3	Jeder Authentifizierungsvorgang des Nutzers MUSS in Form einer Zwei-Faktor-Authentifizierung umgesetzt werden.
O.Auth 4	Für die Bewertung eines Authentifizierungsvorgangs SOLLEN zusätzliche Informationen (z. B. das verwendete Endgerät, der verwendete IP-Adresse oder die Zeit des Zugriffs) mit einbezogen werden.
O.Auth 8	Die Authentisierungsdaten DÜRFEN NICHT ohne eine ausreichende Authentifizierung des Nutzers geändert werden.
O.Cryp 1	Beim Einsatz von Verschlüsselung in der Web-Anwendung DÜRFEN KEINE fest einprogrammierten geheimen, bzw. privaten Schlüssel eingesetzt werden.
O.Cryp 2	Die Anwendung MUSS auf bewährte Implementierungen zur Umsetzung krypto-graphischer Primitive und Protokolle zurückgreifen.
O.Cryp 3	Die Wahl kryptographischer Primitive MUSS passend zum Anwendungsfall sein und dem aktuellen Stand der Technik entsprechen.
O.Cryp 4	Kryptographische Schlüssel DÜRFEN NICHT für mehr als genau einen Zweck eingesetzt werden.
O.Cryp 5	Die Stärke der kryptographischen Schlüssel MUSS dem aktuellen Stand der Technik entsprechen.
O.Data 10	Sensible Daten DÜRFEN NICHT aus der Komponente, auf der sie erzeugt wurden, exportiert werden.
O.Data 3	Die Web-Anwendung DARF Ressourcen, die einen Zugriff auf sensible Daten ermöglichen, gegenüber Dritten NICHT verfügbar machen.
O.Data 8	Bei der Erhebung von sensiblen Daten durch die Verwendung von Aufnahmegeräten (z.B. Kamera), MUSS vorgebeugt werden, dass andere Anwendungen darauf Zugriff erlangen könnten, etwa über eine Mediengalerie.
O.Data 9	Bei der Eingabe sensibler Daten über die Tastatur SOLL die Web-Anwendung unterbinden, dass Aufzeichnungen für Dritte erkennbar werden.
O.Ntwk 1	Jegliche Netzwerkkommunikation der Web-Anwendung MUSS durchgängig mit TLS verschlüsselt werden.
O.Ntwk 2	Die Konfiguration der TLS-Verbindungen MUSS dem aktuellen Stand der Technik entsprechen und aktuellen Best-Practice-Empfehlungen folgen.
O.Ntwk 3	Die Web-Anwendung MUSS die Sicherheitsfunktionalität der jeweilig verwendeten Betriebssystem-Plattform mit Browser verwenden, um sichere Kommunikationskanäle aufzubauen.
O.Ntwk 4	Die Web-Anwendung DARF Zertifikate NICHT akzeptieren, deren Zertifikatskette dem Hersteller nicht vertrauenswürdig erscheint.
O.Paid 6	Die Anwendung SOLL die Transaktionshistorie von kostenpflichtigen Leistungen im Hintergrundsystem ablegen. Die Transaktionshistorie, einschließlich der Metadaten, MUSS als sensibles Datum gemäß O.Purp_8 behandelt werden.
O.Paid 9	Die Validierung von getätigten Bezahlvorgängen MUSS im Hintergrundsystem vorgenommen werden.
O.Pass 2	Für die Authentifizierung mittels Benutzername und Passwort KANN die Stärke des verwendeten Passworts dem Nutzer angezeigt werden. Informationen über die Stärke des gewählten Passworts DÜRFEN NICHT in der Web-Anwendung oder im Hintergrundsystem persistiert werden.
O.Plat 4	Die Web-Anwendung DARF KEINE sensiblen Daten in erweiterten Meldungen oder Benachrichtigungen, die nicht vom Nutzer explizit eingeschaltet wurden (siehe O.Plat_5),anzeigen.
O.Plat 6	Die Web-Anwendung MUSS das Ausführen von JavaScript aus Quellen außerhalb der Kontrolle des Herstellers ablehnen.
O.Sess 2	Der Session-Identifier SOLL in einem sicheren Speicherbereich liegen.
O.Sess 4	Wird eine Anwendungssitzung beendet, MUSS die Anwendung den Session-Identifier sicher löschen und das Hintergrundsystem informieren. Dies gilt sowohl für das aktive Beenden durch den Benutzer (log-out), als auch für das automatische Beenden durch die Anwendung (vgl. O.Auth_6 und O.Auth_7).
O.Source 4	Potenzielle Ausnahmen im Programmablauf (Exceptions) MÜSSEN abgefangen, kontrolliert behandelt und dokumentiert werden. Technische Fehlerbeschreibungen (z.B. Stack Traces) DÜRFEN dem Nutzer NICHT angezeigt werden.
O.Source 5	Bei Ausnahmen im Programmablauf (Exceptions), mit sicherheitskritischen Auswirkungen, SOLL die Web-Anwendung Zugriffe auf sensible Daten abbrechen und diese im Speicher sicher löschen.
O.Source 6	Alle Optionen zur Unterstützung der Entwicklung (z. B. Log-Aufrufe, Entwickler-URLs, Testmethoden etc.) MÜSSEN in der Produktiv-Version mindestens deaktiviert oder besser vollständig entfernt sein.
O.Source 7	Der Hersteller MUSS sicherstellen, dass keinerlei Überreste von Debug-Mechanismen in der Produktiv-Version verbleiben.
O.Source 8	Nutzt die Web-Anwendung URL-Weiterleitungen (URL-Redirects), MUSS diese kontrolliert erfolgen.
O.Source 9	Die Web-Anwendung MUSS Maßnahmen vorsehen, die verhindern, dass Funktionalitäten, die nicht in der Entwicklungshoheit des Herstellers liegen, in die Web-Anwendung eingeschleust und zur Ausführung gebracht werden.
O.Tokn 1	Das Authentifizierungstoken MUSS in einem sicheren Speicherbereich liegen (vgl. O.Sess_2).