raum]für[raum stellt durch geeignete Architekturen, Maßnahmen, Coding-Guidelines und Best-Practice-Empfehlungen sicher, dass folgende Schutzziele umgesetzt werden:

  • Vertraulichkeit
  • Integrität
  • Authentizität
  • Verfügbarkeit
  • Verbindlichkeit

Diese Ziele müssen auf mehreren Ebenen sichergestellt werden:

  • Applikations-Ebene (raum]für[raum)
  • Server-Ebene (Web- und Datenbankserver)
  • Infrastruktur-Ebene (Netzwerk, Rechenzentrum etc.)

An dieser Stelle werden lediglich die Sicherheitskonzepte auf Applikations-Ebene beschrieben. Für die Server- und Infrastruktur-Ebene ist in der Regel der Kunde verantwortlich. mediaDIALOG kann aber beratend mit Empfehlungen zu Best-Practices zur Seite stehen und diese auch gemeinsam mit dem Kunden implementieren.

Grundlagen des Sicherheitskonzeptes

Die Sicherheitskonzepte orientieren sich unter anderem an Empfehlungen des Bundesamtes für Sicherheit in der Informationstechnik und gängigen Industriestandards.

Weiterführende Informationen

Angriffsszenarien

Unter anderem werden Maßnahmen für folgende Angriffsszenarien umgesetzt:

  • SQL-Injection
  • XSS (Cross-Site-Scripting)
  • Session Hijacking/Spoofing/Riding
  • Clickjacking

Maßnahmen

Security by Default

raum]für[raum verfolgt grundsätzlich den Grundsatz "Security by Default". Das heißt, dass die Standard-Konfiguration und Maßnahmen-Empfehlungen laut den Grundlagen des Sicherheitskonzeptes als sicher erachtet werden können.

In einigen Ausnahmefällen kann es allerdings triftige Gründe geben, von dieser Maxime abzuweichen. Sei es durch spezielle Konstellationen, durch die Angriffsvektoren unwahrscheinlich werden oder ausgeschlossen werden können. Diese Ausnahmen werden aber entweder an den entsprechenden Stellen dokumentiert und/oder erfolgen durch explizite Absprache/Anforderung durch den Kunden.

Die nachfolgend beschriebenen Maßnahmen sind nicht ausschließlich zu betrachten.

Prepared Statements und Parameter Binding

Alle Parameter in SQL-Statements werden über Prepared Statements gebunden, um SQL-Injections zu verhindern.

Sessions und Cookies

  • Sessions werden ausschließlich auf dem Server verwaltet, lediglich die Session-ID wird auf dem Client in einem Cookie gespeichert
  • Die Session-ID wird ausschließlich per HTTP-Header geschickt
  • Das Session-Cookie ist möglichst restriktiv abgesichert (Einschränkung auf Domain/Pfad der RFR-Instanz, nach Bedarf Einschränkung auf HTTPS, nur über HTTP auslesbar, Vergabe von Gültigkeiten)
  • Die Session-ID wird bei Login und Logout neu generiert und damit neue Webserver-Sessions erzeugt
  • Cookies enthalten keine sensiblen Daten

Clickjacking

Um Clickjacking wirkungsvoll zu verhindern, wird der HTTP-Header X-Frame-Options: SAMEORIGIN mitgesendet. Dadurch unterbindet der Browser die Darstellung von raum]für[raum auf Frames fremder Domains.

Dieser Antwort-Header wird sowohl durch eine entsprechende Webserver-Konfiguration als auch zusätzlich durch die von PHP dynamisch generierten Ausgaben gesetzt.

Maskierung von Sonder- und Steuerzeichen

Je nach Ausgabeformat (HTML, CSS, Javascript, PDF, XML, JSON, CSV, ...) werden potentiell gefährlichen Steuer- und Sonderzeichen von variable Inhalte wie Benutzereingaben entfernt bzw. maskiert.

Restriktive Beschränkung der Webserver- und DBMS-Berechtigungen (Least-Privilege-Prinzip)

Der (technische) Benutzer, unter welchem der Webserver läuft, wird möglichst restriktiv entsprechend der Verzeichnisstruktur konfiguriert. So enthält dieser z.B. Schreibrechte ausschließlich auf tatsächlich benötigte Ordner.

Das gleiche gilt für die Berechtigungen, welche der (technische) Benutzer des Datenbank-Management-Systems benötigt.

Einschränkung der öffentlichen Erreichbarkeit / Authentifizierung und Berechtigungsprüfung

Nur Ressourcen (Skripte, Dateien, ...) die zwingend öffentlich über den Webserver erreichbar sein müssen, liegen im sogenannten Webroot. Ressourcen wie Log-Dateien, Exporte, PHP-Klassen, Konfigurationsdateien oder CLI-Skripte liegen außerhalb des Webroots.

Statische Dateien, welcher der Webserver ohne weitere Prüfung ausliefert, enthalten keine sensiblen Daten oder deren URL ist nicht herleitbar.

Dynamische Seiten und Skripte stellen sicher, dass nur berechtigte Nutzer und Applikationen mit geeigneten Authentifizierungsmaßnahmen auf die jeweiligen Funktionen zugreifen können.

raum]für[raum bietet des Weiteren ein fein granulierbares Rollen und Rechte, um diese Berechtigungen definieren zu können.

HTTPS everywhere

Sofern eine gesicherte Verbindung zu raum]für[raum oder einem Drittsystem gewünscht und möglich ist, wird diese zwingend und ausschließlich benutzt. Das umfasst:

  • Eine über HTTPS geladene Webseite liefert auch die zugehörigen Ressourcen wie Bilder, JavaScript- und CSS-Dateien verschlüsselt aus
  • ungesicherte HTTP-Verbindungen werden geblockt oder auf die HTTPS-Verbindung umgeleitet
  • SSL/TLS-Zertifikate werden korrekt bis zu den als vertrauenswürdig definierten Root-CAs validiert

Empfehlungen für Webserver-Konfiguration 

Es wird eine speziell für raum]für[raum optimierte Webserver-Konfiguration mitgeliefert, welche auch relevante Sicherheitsaspekte mit abdeckt.

Sicherheit Dritt-Applikationen und integrierter Bibliotheken

Grundsätzlich unterstützt raum]für[raum nur Drittapplikationen, die ihrerseits eine aktive Unterstützung durch den Hersteller erfahren.

Integrierte Bibliotheken werden zum Auslieferungszeitpunkt von raum]für[raum immer mit der jeweils aktuellsten Version integriert.