GSB 7.0 Standardlösung

Springe direkt zu:

Version: GSB 7Tomcat

Beim GSB wird der Open Source Applikationsserver Tomcat zur Generierung von HTML-Seiten eingesetzt, die dann im Internet vom Apache ausgeliefert werden. Insbesondere bei dynamischen Anfragen, wie der Bearbeitung von Formularen oder Suchanfragen, leitet der Webserver die Anfragen aus dem Internet an den Applikationsserver weiter. Damit ist auch der Applikationsserver prinzipiell für Angreifer aus dem Internet erreichbar und muss ebenso wie der Webserver gegen deren unterschiedlichen Attacken abgesichert werden.

Sichere Konfiguration des Betriebssystems

Die in Kapitel 6.1 vorgestellten Maßnahmen für den Webserver Apache können für den Betrieb des Applikationsservers Tomcat entsprechend adaptiert werden.

Absicherung des Applikationsservers: Hinweise und Maßnahmen

Um für Tomcat-Server bzw. den zugehörigen Webapplikationen eine gesicherte Umgebung aufzubauen, sollten insbesondere die folgenden Maßnahmen auf ihre Umsetzbarkeit bzw. Einsetzbarkeit untersucht werden.

Eingeschränkte Benutzerkennung

Wenn nicht besondere Gründe dagegen sprechen, sollte der Applikationsserver ebenso wie der Webserver mit einer eigenen Benutzer- und Gruppenkennung laufen (vgl. Kapitel 6.2.1).

Java Security Manager

Auf einer GSB-Hosting-Plattform können verschiedene GSB-Mandanten gleichzeitig betrieben werden. Die Java Virtual Machine (JVM) bietet ausgereifte Sicherheitsmechanismen, die beim Betrieb von Tomcat-Servern die Möglichkeit geben, für den Tomcat-Server bzw. die zugehörigen Webapplikationen eine gesicherte Umgebung aufzubauen.

Um den Betrieb eines Tomcats durch Sicherheitsregeln abzusichern kann der Security Manager der Java Virtual Maschine (JVM) eingesetzt werden. Dazu muss der Tomcat mit einem aktivierten Security Manager der JVM gestartet werden. Danach werden alle sicherheitsrelevanten Aktionen zunächst an den Security Manager umgeleitet. Dieser vergleicht die Aktion mit den Regeln in der Policy-Datei und entscheidet dann, ob die angeforderte Aktion erlaubt wird oder nicht.

Falls der Security Manager aktiviert ist, darf eine Java-Klasse zunächst keine Aktionen mehr ausführen, d.h. Aktionen wie z.B. das Lesen/Schreiben von Properties, Dateisystemzugriffe, Socket-Zugriffe sind verboten. Mit der Policy-Datei wird jede notwendige bzw. zulässige Aktion mittels entsprechender Regeln wieder freigegeben, so dass die entsprechende Klasse einwandfrei arbeiten kann.

Grundsätzlich haben sich in der Praxis folgende, sicherheitsrelevante Regeln als minimaler Schutz bewährt:

  • Webanwendungen dürfen nur Dateien in ihrem eigenen ${docBase} lesen.
  • Webanwendungen sind ausschließlich im ${docBase} und nicht verstreut über das Dateisystem zu finden.
  • Protokolldateien (AccessLog und SystemLog) werden für jeden virtuellen Host in einem speziellen Verzeichnis logs geschrieben, das außerhalb des ${docBase} liegt.
  • Es dürfen nur Daten der eigenen Anwendung verändert werden.
  • Temporäre Dateien werden in einen dafür vorgesehen Ordner geschrieben und gelesen.
  • Systemeinstellungen werden nicht verändert.

Ergänzende Informationen zum allgemeinen Aufbau einer Policy-Datei des Security Manager befinden sich in Sicherheitsdokumentation des Herstellers Suns (vgl. http://java.sun.com/j2se/1.4.2/docs/guide/security/PolicyFiles.html).

Tomcat-Installation in einem chroot-Behälter

Ebenso wie der Webserver sollte auch der Applikationsserver in einem chroot-Behälter laufen (vgl. Kapitel 6.2.5).

Auswerten der Log-Dateien

In den Logdateien lassen sich unter Umständen Angriffe auf den Applikationsserver feststellen, wenn sie über die HTTP-Schnittstelle auf ungecachte Seiten erfolgen.

Sessionmanagement: Hinweise und Maßnahmen

Das Session Management ist – unabhängig vom GSB – immer eine der problematischsten Stellen für die Sicherheit von Webanwendungen. Für den Schutz der SessionID sollten daher – in Abhängigkeit der angebotenen Funktionalitäten und des Schutzbedarfs eines Mandanten – entsprechend wirksame Maßnahmen zur Anwendung kommen.

Zum Session-Management werden im Folgenden einige wichtige Sicherheitsmaßnahmen skizziert. In Abhängigkeit der angebotenen Funktionalitäten eines konkreten Mandanten sind zusätzlich zu den hier skizzierten Hinweisen unter Umständen weitergehende Maßnahmen notwendig. Ergänzende Hinweise und Maßnahmen, etwa wie eine Session durch Verwendung weiterer identifizierender Merkmale des Clients zusätzlich geschützt werden kann, befinden sich beispielsweise im Dokument

  • „Sicherheit von Webanwendungen – Maßnahmenkatalog und Best Practices“ des BSI (

http://www.bsi.de/literat/studien/websec/WebSec.pdf).

Session-ID nach Authentisierung erneuern

Beim GSB besteht die Möglichkeit geschützte Zugriffsbereiche mithilfe der Autorisierungs- und Authentifikationsmechanismen des Applikationsservers Tomcat einzurichten.

Falls ein Mandant einen geschützten Zugriffsbereich innerhalb seines Webauftritts anbietet, ist nach der erfolgreichen Authentisierung (Login) eines Benutzers die schon bestehende Session-ID durch eine neue Session-ID zu ersetzen. In der Java Servlet-Umgebung, wie sie beim GSB eingesetzt wird, ist eine Änderung der Session-ID in direkter Weise nicht möglich. Der Applikationsserver Tomcat stellt stattdessen die folgende Variante zur Verfügung:

  • Sessiondaten speichern
  • alte Session invalidieren
  • neue Session erstellen
  • gespeicherte Daten in neue Session kopieren.

Da insbesondere beim ersten und beim letzten Schritt für jeden Mandanten bzw. deren spezifische Funktionalitäten spezielle Informationen (bspw. über den Login-Bereich) in der Session abgespeichert werden, sind diese Schritte innerhalb des jeweiligen Mandantenprojekts zu lösen.

Session beenden

Jede Session sollte aktiv beendet werden. Beim GSB besteht eine Möglichkeit, dem (angemeldeten) Benutzer einen Logout-Button anzubieten, damit er die Session beenden kann. Da man sich aber nicht auf ein bestimmtes bzw. gewünschtes Verhalten des Benutzers (z.B. Verwendung des Logout-Button) verlassen darf, bietet der GSB darüber hinaus auch eine fest eingestellte (innerhalb des Tomcat konfigurierbare) maximale Lebensdauer einer Session.

Insgesamt sollten folgende Kriterien beachtet werden:

  • maximale Lebensdauer einer Session (Timeout)
  • maximale Dauer, in der keine Aktion in einer Session stattfinden (Idletime)
  • Logout durch Benutzer
  • Logout durch Fehlersituationen

Da der GSB nur temporäre Cookies verwendet, wird nach dem Logout im Browser des Benutzers ein möglicherweise vorhandenes SessionID-Cookie automatisch gelöscht.

Cookies einschränken

Beim GSB wird in einem Cookie vom Server eine eindeutige Session-ID gespeichert, um genau diesen Client bei weiteren Aufrufen wieder zu erkennen. Als Träger von sensitiven Informationen sind die Cookies auf einen minimalen "Aktionsradius" zu beschränken, um die Gefahr zu minimieren, dass sie von nicht vertrauenswürdiger Seite aufgefangen werden.

Der Pfad ist auf die Anwendungen einzuschränken, die innerhalb eines Mandanten bereitgestellt werden. Beim GSB ist der Pfad beispielsweise initial auf die so genannte Bund-Applikation /bund eingeschränkt. Damit diese Pfad-Einschränkung (auch für anderen Anwendungen) möglich ist, sind alle an der Anwendung beteiligten Ressourcen unterhalb der für diese Anwendungen genannten Einstiegspfade zu platzieren.

Falls ein GSB-Mandant eine SSL-Verschlüsselung benötigt, sollte das Session-Cookie mit dem secure-Flag definiert werden. Damit wird sichergestellt, dass der Browser das Cookie niemals über eine unverschlüsselte Verbindung überträgt.