Web Application Security Tips   (V1.00 - 2. April 2004)

In vielen frei verfügbaren Quellen wie z.B. dem BSI IT-Grundschutzhandbuch finden Sie qualifizierte Empfehlungen zum sicheren Betrieb von Netzwerken, Betriebssystem und Datenbanken. Konkrete Vorgaben zur sicheren Programmierung und Konfiguration von Web Applikationen sind aber nach wie vor ein Spezialgebiet, welches von anerkannten Standards naturgemäss oft nur allgemein behandelt wird. Die hier publizierten Web Application Security Tips sollen ein Teil dieser Lücke schliessen und beziehen sich hauptsächlich auf die sichere Programmierung und Konfiguration von Web Applikationen wie z.B. E-Commerce Shops, Web Portale oder E-Banking Lösungen. Die Empfehlungen sind aus der täglichen Praxis entstanden und bewusst in der Sprache der Programmierer formuliert, jedoch soweit wie möglich Technologie-neutral gehalten. Für den oft etwas imperativen Text möchten wir uns im Voraus entschuldigen. Überlegen Sie immer auch selbst, ob der entsprechende Vorschlag für Sie Sinn macht. Wir sind jedoch fast sicher, dass Sie bei der genauen Durchsicht - nebst vielen bekannten Empfehlungen - auch eine Reihe von neuen, interessanten Security-Aspekten entdecken. Zum Offline-Lesen sind vorliegenden Web Application Security Tips sind auch als PDF-Datei verfügbar: WebApplicationSecurityTipsV1-00.pdf Inhalt: Basic Security: minimale Schutzmassnahmen für Web Applikationen Server unprivilegiert starten Default MIME-Type dekonfigurieren Tailoring der Server Funktionalitäten realisieren Keine internen Informationen im Fehlerfall preisgeben Log-Files und Applikation gegen Download sichern Alle CGI und Form Input-Parameter bei jedem HTTP Request neu prüfen Daten-Import von externen Quellen auch prüfen Unzulässige Requests verzögern Unzulässige Requests separat aufzeichnen Server Administrations-Port von Web Service-Port trennen Betrieb ohne Log-Aufzeichnungen verunmöglichen Standard Security: für persönliche Daten und einfache Geschäftstransaktionen Nur verschlüsselte HTTPS-Verbindungen verwenden Web Applikationen nicht im Browser integrieren Nur offiziell ausgestellte SSL Server-Zertifikate verwenden Session(-ID) beim Login wechseln Temporäre Cookies als Session-Kontext erzwingen Keine zusätzlichen Session-Kontexte verwenden Keine sensitiven Daten in permanenten Cookies speichern Kein initiales Standard-Passwort setzen Passwort-Speicherung im Web Browser unterdrücken Passwort-Änderung zulassen Logout ermöglichen Passwörter nur als Hashwert speichern Benutzer Accounts bei mehrmaligem falschen Login automatisch sperren Zugriffsverletzungen des Rollenkonzepts immer prüfen und loggen Keine Preise als CGI- oder hidden Formular-Parameter übergeben Login- und Logout-Vorgang der Benutzer protokollieren Business-Transaction Log separat führen Log-Files nicht auf dem eigenen Rechner speichern Remote IP-Adresse vom Reverse Proxy an den Applikationsserver weiterleiten High Security: für E-Banking sowie für besonders schützenswerte Daten Verschlüsselungs-Tiefe und -Protokoll kontrollieren Immer vollständige Zertifikats-Kette des SSL Server-Zertifikats übertragen SSL Client-Zertifikate verwenden SSL Server-Zertifikat in spezieller Hardware speichern "Trusted" SSL Library verwenden Starke Authentisierung verwenden URL Whitelist-Filter implementieren Keine Hyperlinks auf fremde Web-Seiten integrieren Session-Timeout kurz halten Keine endlosen Surf-Sessions erlauben Mehrfaches Login des gleichen Benutzers ausschliessen Initial-Authentisierung nicht über ungesicherte Kanäle übertragen Gesperrte Accounts nur nach sorgfältiger Authentisierung wieder entsperren Kryptologische Zufallszahlen-Generatoren verwenden Limiten setzen und Risk-Management implementieren GMT als applikations-interne Zeitbasis verwenden Anonyme Benutzer von authentisierten Benutzern trennen Schutzmassnahmen auf Kundeseite fördern Benutzeranfragen und Störungsmeldungen richtig behandeln Angriffsversuche periodisch Auswerten Shutdown-Kriterien und Notfall-Konzepte vorbereiten Weitere Empfehlungen Alle Team-Mitglieder sensibilisieren Qualitätssicherung mit einbeziehen Umsetzung von Security-Massnahmen bei Aufwandschätzungen mit berücksichtigen Auf ausgewogene Sicherheit achten Hilfe anfordern, Übersicht behalten und Risiken delegieren Hyperlinks Feedback I  Basic Security: minimale Schutzmassnahmen für Web Applikationen Dieses Unterkapitel beschreibt grundlegende Schutzmassnahmen, welche in jeder Web Applikation realisiert werden sollten. Selbst wenn diese "nur" einen öffentlichen Bereich enthält und sich die Benutzer nicht anmelden müssen. Server unprivilegiert starten Der Server sollte immer unter einem unprivilegierten System-Account gestartet werden. Dies verhindert, dass bei einer eventuellen Sicherheitslücke wie z.B. "Buffer-Overflow" der Angreifer direkt die volle Kontrolle über das gesamte Betriebssystem erhält. Bei den HTTP Server-Ports unter 1024 ist ein Starten unter einem privilegierten System-Account (leider) nötig, doch kann in der Konfiguration des Servers (fast) immer noch ein zusätzlicher, unprivilegierter Account spezifiziert werden, unter dessen Kontext die eigentliche Verarbeitung der HTTP Requests erfolgt. Default MIME-Type dekonfigurieren Konfigurieren Sie den Server so, dass dieser bei statischem Content (z.B. Bilder, Text-Files), im Zusammenhang mit unbekannten Datei-Erweiterungen (z.B. ".dat"), nicht einfach die verlangte - und gefundene - Ressource mit einem Default-MIME Type wie z.B. "TEXT/PLAIN" liefert, sondern in einem solchen Fall stattdessen eine Fehlermeldung an den Endbenutzer ausgibt. Durch die genaue Kontrolle der zulässigen MIME-Typen, welche vom Server überhaupt geliefert werden können, verringern Sie die Wahrscheinlichkeit ganz erheblich, dass unerwünscht interne Daten preisgegeben werden. Tailoring der Server Funktionalitäten realisieren Deaktivieren bzw. dekonfigurieren Sie auf dem Server gezielt alle Funktionalitäten, welche nicht benötigt werden. Beispiel: falls eine Remote-Administration nicht nötig ist, so sollten Sie diese dekonfigurieren. Dekonfigurieren Sie im Server auch die Unterstützung exotischer HTTP Request Methoden wie z.B. HEAD, TRACE und DELETE. Üblicherweise wird nur GET und POST benötigt. Falls sich unerwünschte HTTP Request Methoden nicht direkt dekonfigurieren lassen, so stehen oft alternative Möglichkeiten/Schnittstellen auf dem Server zur Verfügung, die HTTP Request Methode zu Prüfen und gegebenenfalls die Netzwerk-Verbindung zum Web Browser ohne Antwort zu schliessen. Keine internen Informationen im Fehlerfall preisgeben Konfigurieren bzw. Programmieren Sie den Server so, dass beim Auftreten eines Fehlers nie interne Fehler-Details wie z.B. einen Stack-Dump oder lokale Umgebungsvariablen im Browser Fenster preisgegeben werden. Bei Applikations-Servern sollten Sie stattdessen nur eine eindeutige Fehler-Id ausgeben, welche mit einer genauen, internen Fehler-Aufzeichnung korrespondiert. Wichtig ist auch, dass der fehlerhafte URL-Request nicht in der Antwort repetiert wird, denn dies kann eventuell dazu führen, dass der Server seine eigene HTML-Antwort vor der Ausgabe selbst (dynamisch) interpretiert und über diesen Mechanismus sich z.B. beliebige Server Side Includes oder Java Server-Pages ausführen lassen (mittels server-seitigem Script Code in der Anfrage). Log-Files und Applikation gegen Download sichern Legen Sie die Log-Files des Servers nicht im HTTP Request Path ab, damit diese in jedem Fall vor einem unerwünschten Download geschützt sind. Konfigurieren Sie zudem den Server so, dass direkt ausführbarer Code niemals herunter geladen werden kann. Deaktivieren Sie unbedingt auch "Directory-Browsing". Alle CGI und Form Input-Parameter bei jedem HTTP Request neu prüfen Prüfen Sie die Input-Parameter bei jedem HTTP Request. D.h. es darf nicht möglich sein, HTML-, Javascript-, ActiveX oder SQL-Code als Input in die Applikation einzuschleusen. Es besteht sonst die Gefahr, dass dieser Code direkt von der Web Applikation ausgeführt wird (z.B. bei SQL) bzw. dass über die Datenbank der Web Applikation dieser Code im Kontext eines anderen Benutzers in dessen Web Browser ausgeführt wird. Beachten Sie auch, dass der Wert von HTML Form Feldern auf Client-Seite sehr einfach "böswillig" gefälscht werden kann und z.B. in Formular Input-Feldern, in welchen sich üblicherweise nur Zahlen selektieren lassen, Cross-Scripting oder SQL-Code auftritt. Besondere Beachtung benötigt auch die oft unterlassene Server-Seitige Prüfung von hidden HTML Form-Parametern oder Parametern von Auswahllisten, Radiobuttons und Checkboxen. Daten-Import von externen Quellen auch prüfen Prüfen Sie beim automatisierten Datenimport von externen Quellen die Daten genau so sorgfältig, wie die Input-Parameter eines HTTP Requests (siehe vorhergehendes Unterkapitel). Dies ist besonders wichtig, wenn die importierten Daten bzw. Fragmente davon direkt im Browser-Fenster Ihrer Endbenutzer ausgegeben werden. Bei einem Unterlassen dieser Massnahme besteht sonst die Gefahr, dass über den Daten-Import böswilliger Code im Browser-Context der Endbenutzer ausgeführt wird. Dazu Ergänzend sollte bei dynamischen erzeugten HTML Text-Fragmenten - welche z.B. aus einer Datenbank stammen - deren Inhalt immer über eine Wrapper-Methode bzw. -Funktion ausgegeben werden, welche alle "exotischen" ASCII-Zeichen wie z.B. ", &, <, >, ", ' und : vor jeder Ausgabe konsequent in die entsprechenden dezimalen HTML Unicode-Zeichen umcodiert (z.B. &#039; statt '). Dadurch stelle Sie sicher, dass ein ausgegebener Text niemals als Script von einem Web Browser interpretiert wird, sondern in jeden Fall "nur" dargestellt wird. Unzulässige Requests verzögern Falls ein unzulässiger bzw. fehlerhafter URL-Aufruf erkannt wird, so sollte die entsprechende Fehlermeldung einige Sekunden (5..10) verzögert ausgegeben werden. Dadurch reduzieren Sie die Bandbreite von Hacking-Versuchen gegenüber der Web Applikation und verringern so die Wahrscheinlichkeit eines erfolgreichen Angriffs. Unzulässige Requests separat aufzeichnen Zeichnen Sie unzulässige URL Requests in einer separaten Log-Datei auf - damit Sie die "Schwarzen Schafe" unter den Endbenutzern besser erkennen können. Zur Aufzeichnung gehört in jedem Fall die genaue Zeit, die remote IP-Adresse sowie das genaue URL des unzulässigen Requests. Bei angemeldeten Benutzern sollte auch die eindeutige Benutzer-Identifikation in die Aufzeichnung mit einfliessen. Server Administrations-Port von Web Service-Port trennen Viele Server verfügen oft über interne "Service-Funktionalitäten", welche z.B. "online Konfigurationsänderungen" oder ein Remote-Shutdown über einen Web Browser zulassen. Trennen Sie den Server Port dieser internen "Service-Funktionalitäten" vom "gewöhnlichen" Server Port, damit Ihre Firewall diese "Service-Funktionalitäten" für (externe) Internet-Benutzer blockieren kann. Beachten Sie in diesem Zusammenhang, dass auch eine spezielle Authorisierung - besonders bei unverschlüsselten HTTP Verbindungen - kein wirksamer Schutz ist und ein Trennen der beiden Server Ports nie ersetzen kann. Betrieb ohne Log-Aufzeichnungen verunmöglichen Stellen Sie sicher, dass der Server seinen Dienst verweigert, wenn keine Log-Aufzeichnungen mehr geschrieben werden können (.z.B. wenn kein Disk-Platz mehr zur Verfügung steht). II  Standard Security: für persönliche Daten und einfache Geschäftstransaktionen Dieses Unterkapitel enthält - ergänzend zur Basic Security - zusätzliche Sicherheits-Empfehlungen. Z.B. für E-Commerce Shops oder auch für Web Applikationen, welche die Speicherung und Verwaltung persönlicher Daten erlauben. Nur verschlüsselte HTTPS-Verbindungen verwenden Verwenden Sie ausschliesslich das verschlüsselte HTTPS-Protokoll, um persönliche Daten zwischen dem Endbenutzer und der Web Applikation auszutauschen. Die Verschlüsselungs-Tiefe sollte dabei mindestens 128 Bit betragen (bzw. 112 Bits bei 3DES). Web Applikationen nicht im Browser integrieren Liefern Sie die einzelnen Elemente eines Browser-Fensters (HTML-Seite inkl. referenzierte Bilder, HTML-Frames und Animationen, etc.) ausschliesslich von einem Web Server. Bei "zusammengesetzten" HTTP/HTTPS Seiten von mehreren Web Servern vermeiden Sie so die Warnung "Diese Seite enthält sowohl unsichere wie auch sichere Elemente". Ein Mix der Elemente, von zwei oder mehreren HTTPS Servern im gleichen Browser-Fenster, wird zur Zeit von keinem Browser richtig unterstützt - d.h. es wird vom Browser immer nur ein Server-Zertifikat dem Endbenutzer angezeigt, was verunmöglicht, dass der Benutzer die Gültigkeit aller Elemente einer Web Page verifizieren kann. Viele Web Browser kollabieren zudem unter solchen Bedingungen - einzig der Microsoft Internet Explorer "überlebt" eine solche Situation, jedoch auch nur unter der Voraussetzung, dass alle Server-Zertifikate vom Browser als "gültig" betrachtet werden und keine (implizite) Nachfrage nach der Gültigkeit beim Endbenutzer nötig ist. Nur offiziell ausgestellte SSL Server-Zertifikate verwenden Verwenden Sie nie selbst erzeugten SSL Server-Zertifikate, da diese eine Warnungsmeldung im Web Browsers des Endbenutzers zur Folge haben. Die Endbenutzer gewöhnen sich unter solchen Umständen an diese Warnungsmeldung und ein realer Entschlüsselungs-Angriff mit einer "Man in the Middle" Attacke wird später nicht erkannt, d.h. es besteht die Gefahr, dass die vermeintlich gut verschlüsselte Verbindung zur Laufzeit von unberechtigten Dritten abgehört und dechiffriert wird. Das richtige Verhalten bei einer solchen Warnungsmeldung währe eigentlich, dass der Endbenutzer z.B. per Telefon beim Ihrem Support nachfragt, ob ein technischer Grund für eine solche Warnung besteht. Vermeiden Sie darum unbedingt solche Situationen. Das "Importieren" von selbst erstellten Root CA Zertifikaten in den Web Browser ist zwar auf den ersten Blick eine mögliche Lösung. Diese hat jedoch aus der Sicht des Endbenutzers den unerwünschten und eventuell (fatalen) Effekt, dass von nun an der Web Browser jedes abgeleitete (weitere) Zertifikat der neu importierten Root CA ungeprüft akzeptiert und so die Sicherheit gegenüber gefährlichen Web-Inhalten aus der Sicht des Endbenutzers stark reduziert wird. Verwenden Sie keine inoffiziellen Root CA Zertifikaten, welche von Software-Lieferanten zur Inbetriebnahme Ihrer Web Applikation abgegeben wurden. Session(-ID) beim Login wechseln Falls Ihr Applikationsserver bereits vor dem Login-Vorgang eine anonyme Session erzeugt, so sollten der Applikationsserver während des Login-Vorgangs - nach der erfolgreichen Eingabe der Benutzer-Authentisierung - dem Benutzer eine neue Session(-ID) zuweisen. Dies ist besonders wichtig, wenn dabei gleichzeitig ein Übergang vom unverschlüsselten HTTP- Protokoll hin zum verschlüsselten HTTPS-Protokoll erfolgt. Temporäre Cookies als Session-Kontext erzwingen Erzwingen Sie durch eine entsprechende Programmierung und Konfiguration des Applikationsservers, dass ausschliesslich temporäre Session-Cookies als Session-Kontext verwendet werden. Sämtliche anderen Verfahren zum Halten des Session-Kontexts führen zu Sicherheitslücken oder sind zu vielen Web Browser-Produkten inkompatibel. Dekonfigurieren Sie auch URL-Rewriting als alternatives Verfahren zum Halten des Session-Kontexts. Programmieren Sie den Applikationsserver so, dass dieser Browser erkennt, bei denen temporäre Session-Cookies deaktiviert wurden: geben Sie in einem solchen Fall dem Endbenutzer eine Fehlermeldung mit der Aufforderung aus, temporäre Session-Cookies für Ihre Web Applikation zuzulassen. Stellen Sie sicher, dass das Secure-Flag im Session-Cookie gesetzt ist. Keine zusätzlichen Session-Kontexte verwenden Halten Sie Ihre Programmierer dazu an, auch in schwierigen Situationen ausschliesslich die server-seitigen Speicher-Strukturen zum Führen von benutzerspezifischen Session-Informationen zu verwenden (sog. server-seitiger Session Context). Das Ergänzen eines Session-Cookies mit zusätzlichen, unabhängigen Kontext-Verfahren wie z.B. FORM/CGI-Parametern, oder auch zusätzlichen Cookies, enthält immer ein zusätzliches Sicherheitsrisiko. Keine sensitiven Daten in permanenten Cookies speichern Speichern Sie in permanenten Cookies nur allgemeine, nicht sensitive Daten, wie z.B. die bevorzugte Sprache des Endbenutzers. Jedoch nie Daten, welchen einen direkten persönlichen oder geschäftlichen Bezug darstellen. Kein initiales Standard-Passwort setzen Vergeben Sie für neue Benutzer-Accounts kein Passwort, welches immer gleich lautet oder aus dem Benutzer-Account Namen leicht abgeleitet werden kann. Verwenden Sie stattdessen ein zufällig generiertes Passwort welches für jeden neunen Benutzer unterschiedlich ist. Lässt sich dies aus betrieblichen Gründen nicht realisieren so müssen Sie mindestens erzwingen, dass ein neuer Benutzer beim der ersten Anmeldung sein Passwort ändern muss. Passwort-Speicherung im Web Browser unterdrücken Verwenden Sie immer die Option AUTOCOMPLETE="off" bei Passwort-Eingabefeldern eines HTML-Formulars. Dadurch wird verhindert, dass das Passwort im Browser (lokal) permanent gespeichert wird, und ein unberechtigter Dritter, welcher sich an den PC setzt, das vom Browser gespeicherte Passwort "automatisch" benutzen kann. Passwort-Änderung zulassen Geben Sie dem Benutzer immer die Gelegenheit, sein Passwort jederzeit - jedoch erst nach einer erfolgreichen Authentisierung - zu ändern. Verlangen Sie bei der Passwort-Änderung zur Sicherheit nochmals das alte Passwort. Logout ermöglichen Geben Sie dem Benutzer immer die Gelegenheit, sich bei der Applikation abzumelden. Passwörter nur als Hashwert speichern Speichern Sie die Passwörter der Benutzer nie im Klartext und auch nicht verschlüsselt in der Datenbank, sondern nur deren Hashwerte bzw. Prüfsummen (z.B. MD5 Algorithmus verwenden). Dadurch kann ein Passwort nicht ohne weiteres "intern" eingesehen werden oder versehentlich an unberechtigte Dritte "verraten" werden. Programmieren Sie den Login-Vorgang so, dass dieser die Prüfsumme des Passworts jeweils neu berechnet und diese danach mit der gespeicherten Prüfsumme vergleicht. Benutzer Accounts bei mehrmaligem falschen Login automatisch sperren Bei mehrmaligen, fehlgeschlagenen Anmeldeversuchen eines Benutzers innert kürzerer Zeit sollte der Benutzer-Account automatisch gesperrt werden. Geben Sie auch nach einer automatischen Sperre die gleiche Fehlermeldung aus, wie wenn ein falsches Passwort eingegeben würde. Dadurch verhindern Sie mindestens eine gewisse Zeit, dass ein potentieller Angreifer die Sperre als solche erkennt und dadurch auf andere Arten von Attacken ausweicht. Je nachdem, wie schützenswert die Daten Ihrer Web Applikation sind, kann eine Sperre nur temporär für einige Zeit gelten - oder auch abschliessend sein. Zeichnen Sie jeden falschen Authentisierungs-Versuch eines Benutzers in den Logdaten auf, inkl. der genauen Zeit und der Remote-IP Adresse. Zugriffsverletzungen des Rollenkonzepts immer prüfen und loggen Prüfen Sie bei jedem HTTP-Request (immer wieder), ob der Benutzer wirklich die Berechtigung hat, die entsprechende Aktion durchzuführen. Besonders dann, wenn im weiteren Sinn nur "Nummern" in Request-Parametern über die Berechtigung entscheiden. Es gibt auf dem Markt auch Tools (z.B. @stake WebProxy), mit denen sich hidden HTML Form-Parameter und andere HTTP-Request Daten zu Testzwecken leicht fälschen lassen. Damit können Sie auf einfache Weise selbst prüfen, ob die Web Applikation das Rollenkonzept und die Autorisierung des Benutzers immer - auf jeder Web Page - berücksichtigt. Keine Preise als CGI- oder hidden Formular-Parameter übergeben Falls Sie einen E-Commerce Shop programmieren so achten Sie darauf, dass während der Zusammenstellung des Warenkorbs sowie auch bei Checkout/Bezahlen niemals die Preise sondern immer nur die Artikel-Nummer und die Anzahl Artikel als CGI- oder hidden Formular-Parameter dem nächsten URL-Aufruf übergeben werden - und berechnen Sie daraus den Totalpreis jeweils immer neu. Es besteht sonst die Gefahr, dass ein Kunde die HTTP-Parameter bzw. Preise zu seinen Gunsten fälscht und zu ungewollt tiefen Preisen einkauft. Führen Sie den Warenkorb falls immer möglich nur in einem Server-Seitigen Context. Login- und Logout-Vorgang der Benutzer protokollieren Zeichnen Sie jede An- und Abmeldung eines Endbenutzers inkl. remote IP-Adresse und genaue Zeit auf. Business-Transaction Log separat führen Trennen Sie das Business-Transaction Log, d.h. die Aufzeichnung der Geschäftstransaktionen, vom "gewöhnlichen" Applikations- und Fehler-Log. Der Nachvollzug von Geschäftstransaktionen wird so einfacher. Über längere Zeit gesehen sparen Sie auch Backup/Archiv-Kosten, da nur die Geschäftstransaktionen über Jahre gespeichert werden müssen. Eine gute Idee ist auch, das Business-Transaction Log direkt mittels Datenbank-Triggern zu realisieren und in der Datenbank selbst zu führen. Dies erlaubt u.a. die schnelle Suche nach Geschäftstransaktionen und bildet auch eine gute Grundlage für spätere statistische Auswertungen. Der Hauptnutzen aus Security-Sicht besteht bei der Verwendung von Datenbank-Triggern jedoch darin, dass Geschäftstransaktionen unter allen Umständen automatisch protokolliert werden. Log-Files nicht auf dem eigenen Rechner speichern Leiten Sie den Log-Output des Applikationsservers und gegebenenfalls des vorgeschalteten Reverse-Proxys auf ein "write-only" Netzwerk-Device eines besonders sicheren "Log Servers" um, so dass die die Log-Dateien niemals lokal veränderbar sind. Dadurch sind die Log-Dateien auch bei einem Einbruch wesentlich besser geschützt, so dass das "Verwischen von Spuren" schwieriger bis unmöglich wird. Bei UNIX-Systemen sollte natürlich auch mit dem syslog so verfahren werden (syslogd) - und ebenso mit den Log-Dateien der Datenbank. Remote IP-Adresse vom Reverse Proxy an den Applikationsserver weiterleiten Falls ein Reverse Proxy dem eigentlichen Applikationsserver vorgeschaltet ist, so sollte der Reverse Proxy so konfiguriert werden, dass dieser die remote IP-Adresse des Endbenutzers an den Applikationsserver weiterreicht. Damit im Log des Applikationsservers auch die ursprüngliche remote IP-Adresse des Benutzers gespeichert werden kann III  High Security: für E-Banking sowie für besonders schützenswerte Daten Dieses Kapitel enthält zusätzliche Sicherheitsempfehlungen welche bei E-Banking Applikationen sowie für Web Applikationen mit besonders Schützenswerten persönlichen Daten (z.B. Patientendaten, Gerichtsakten etc.) zur Anwendung kommen. Nebst vielen, rein technischen Massnamen sind auf dieser Sicherheitsstufe auch organisatorische Massnahmen nötig, um einen entsprechende Sicherheit erfolgreich zu gewährleisten. Vorausgesetzt wird, dass die Empfehlungen für Basic Security und Standard Security bereits realisiert worden sind. Verschlüsselungs-Tiefe und -Protokoll kontrollieren Kontrollieren Sie am Server-Seitigen Verschlüsselungs-Endpunkt die zwischen Web Browser und Web Server ausgehandelte Verschlüsselungstiefe. Leiten Sie alle Benutzer, bei welchen nur eine Verbindung mit einer geringen Verschlüsselungstiefe zustande kommt (kleiner 128 Bit, bzw. 112 Bit), auf eine Fehlerseite um. Kontrollieren Sie auch am Verschlüsselungs-Endpunkt die zwischen Web Browser und Web Server ausgehandelte Version des SSL Protokolls. Leiten Sie alle Benutzer, bei welchen nur eine Verbindung mit dem veralteten SSL Protokoll der Version 2 zustande kommt, auf eine Fehlerseite um. Immer vollständige Zertifikats-Kette des SSL Server-Zertifikats übertragen Da bei vielen Web Browsern korrekterweise nur die Zertifikate der Root-CA (wie z.B. VeriSign) - jedoch nicht deren Zwischenzertifikate lokal gespeichert werden - muss der HTTPS Server so konfiguriert sein, dass beim ersten Verbindungsaufbau, bei der sog. Handshake-Phase, nebst den eigentlichen Server-Zertifikat auch die Zwischenzertifikate der Root-CA mit an den Web Browser gesendet werden. Geschieht dies nicht, so können viele Web Browser Produkte das Server-Zertifikat nicht überprüfen und geben eine Warnungs-Meldung an den Endbenutzer aus, welche fälschlicherweise suggeriert, dass die Verbindung nicht sicher ist. Die Endbenutzer gewöhnen sich damit an diese Warnungsmeldung und reagieren später falsch, wenn z.B. eine echte "Man in the Middle" Attacke auftritt bzw. eine ähnliche Warnungsmeldung (aus anderen Gründen) zurecht vom Web Browser angezeigt wird. Aktuell sind noch immer ca. 30% aller HTTPS Web Server diesbezüglich falsch konfiguriert. Mit dem auf unserer Web Page integrierten Web Server SSL Check im linken Navigationsbalken können Sie selbst überprüfen, ob Ihr HTTPS Server diesen Mangel enthält. Alternativ können sie z.B. mit einem aktuellen Mozilla Browser die entsprechende Fehlermeldung selbst verifizieren. Beim Microsoft Internet Explorer sind die Zwischenzertifikate jedoch bereits (fälschlicherweise) auf dem lokalen PC abgelegt. Aus diesem Grund wird darum keine Fehlermeldung ausgegeben. Beim Klicken auf das Schloss-Symbol -> Zertifizierungspfad wird dieser Pfad bei fehlenden Zwischenzertifikaten automatisch den lokal gespeicherten Zwischenzertifikaten ergänzt, so dass leider nicht festgestellt werden kann, welches Zertifikat nun vom Web Server stammt und welches lokal ergänzt wurde. SSL Client-Zertifikate verwenden Sichern Sie die verschlüsselte Verbindung zusätzlich mit einem Client-Zertifikat. Nur dadurch können Sie Ihre Endbenutzer vor einer relativ leicht zu realisierenden "Man in the Middle" Attacke schützen. Ihre Endbenutzer sind so auch vor gefälschten E-Mails sicher, welche diese dazu verleiten, sich bei einer vorgetäuschten Web Site anzumelden. Es ist technisch nicht möglich durch einen vorgetäuschten HTTPS Web Server ein Client-Zertifikat zu kopieren oder weiterzugeben. Halten Sie das Client-Zertifikat auf dem Endbenutzer-PC am besten in einer eigenen Hardware mit integriertem Crypto-Prozessor (z.B. spezieller USB-Token oder Smartcard) - damit dieses nicht von der Festplatte gestohlen werden kann. SSL Server-Zertifikat in spezieller Hardware speichern Halten Sie das Server-Zertifikat nie auf der Harddisk des Servers sondern immer in einer speziellen Hardware mit einem integrierten, leistungsfähigen Crypto-Prozessor (sog. HSM Modul). Die Hardware sollte zudem so beschaffen sein, dass in dieser das Zertifikat bzw. dessen private Key wohl gespeichert, jedoch niemals zurückgelesen werden kann. Der integriere Crypto-Prozessor dient einem ähnlichen Zweck: dadurch muss das Zertifikat nie in den Arbeitsspeicher des Servers geladen werden sondern bleibt unter allen Umständen innerhalb der speziellen Hardware. Dies verhindert, dass durch Kopieren unbemerkt ein Duplikat des Server-Zertifikats bzw. dessen Private-Key erzeugt werden kann. Ein solches Duplikat ist ideal dazu geeignet, eine perfekte "Man in the Middle" Attacke durchzuführen, ohne dass irgendeine Warnung im Browser-Fenster des Endbenutzers erscheint. "Trusted" SSL Library verwenden Damit sichergestellt ist, dass die verwendete SSL-Library auch keine (gewollt) eingebaute Backdoors oder "geheime Schwachpunkte" enthält, sollten Sie nur OpenSource Libraries oder "Clean Room Implementationen" verwenden. Wie z.B. OpenSSL oder das kommerzielle Produkt IAIK-iSaSiLk der TUG Graz. Dabei sollten Sie Produkte vorziehen, deren Source-Code Sie zumindest einsehen können. Starke Authentisierung verwenden Verwenden Sie zur Authentisierung eines Benutzers mindesten (zusätzlich) ein komplexes Sicherheitselement, welches nicht bereits im PC selbst gespeichert ist. Z.B. der vorhergehend erwähnte USB-Token. Auch TAN-Nummern/Zugangs-Nummernliste oder SecureID Cards können diesen Zweck erfüllen. Biometrische Verfahren sind im Prinzip auch gut geeignet. Zurzeit lassen sich diese (alle) jedoch noch sehr einfach austricksen und genügen darum den Sicherheitsanforderungen noch nicht. URL Whitelist-Filter implementieren Unterdrücken Sie mit einem speziellen Filter im Reverse Proxy oder im Applikations-Server sämtliche URL-Aufrufe (URL Request Paths), welche nicht zu Ihrer Web Site gehören. Da nie ganz klar ist, welche URL’s von der "eingebauten Intelligenz" eines Web- bzw. Applikations-Servers beantwortet werden, ist die Realisierung eines URL Whitelist-Filters ein muss. Der zulässige URL Request Path einer Web Applikation kann durchaus auch Wildcards ("*") enthalten. Alternativ unterstützen sog. Web Application Firewalls, welche das HTTP Protokoll inkl. sämtlicher zulässiger CGI- und Form-Parametern kontollieren u.a. auch die Realisierung von URL Whitelist-Filtern. Keine Hyperlinks auf fremde Web-Seiten integrieren Setzen Sie in der Web Applikation keine Hyperlinks auf andere Web Sites. Auch nicht auf eigene Web Sites, wenn diese wiederum Hyperlinks auf fremde Web Sites enthalten. Sobald beim Endbenutzer die Situation auftritt, dass weitere Browser Fenster zu anderen Web Applikationen bzw. Web Sites offen sind, kann ein "bösartig" programmierter Web Server speziellen Code an den Web Browser übermitteln, welcher durch Client-Side Cross-Scripting Mechanismen z.B. die Session-ID Ihrer Web Applikation ausliest oder die Web Applikation ohne Zutun des Endbenutzers "fernbedient". Falls es unumgänglich ist, Daten von fremden Anbietern darzustellen, so sollten diese Daten mittels Ihrer Web-Applikation zuerst Server-Seitig geladen werden, wobei auch eine vollständige Prüfung gegenüber Cross-Scripting Code erfolgen muss. Erst danach erfolgt die Ausgabe dieser fremden Daten im Kontext Ihrer eigenen Web Applikation. Session-Timeout kurz halten Halten Sie den Session-Timeout, d.h. die Inaktivitäts-Zeitdauer bei deren Überschreitung der Endbenutzer automatisch abgemeldet wird, kurz. Empfohlen sind Zeiten im Bereich von fünf bis zehn Minuten. Durch eine geschickte Programmierung Ihrer Web Applikation können sie zudem erreichen, dass ein automatisch abgemeldeter Benutzer nach einer erneuten Authentisierung sich wieder auf demselben Menüpunkt befindet, wo er letztmals - vor der automatische erzwungenen Abmeldung - war. Dies reduziert die Komforteinbusse des Endbenutzers durch den kurzen Session-Timeout ganz erheblich. Keine endlosen Surf-Sessions erlauben Setzen Sie eine maximale Zeitdauer der Session - unabhängig vom inaktivitäts Session-Timeout. D.h. wie lange ein Endbenutzer sich maximal innerhalb der Web Applikation aufhalten kann, ohne sich neu zu Authentisieren. Empfohlen sind Zeiten um 2 bis 4 Stunden. Dies verhindert z.B., dass "Man in the Middle" Attacken und Trojanische Programme Session-ID’s sammeln und durch automatisierte, periodische Requests die gesammelten Sessions "warm halten" und weiterleiten können. Mehrfaches Login des gleichen Benutzers ausschliessen Dieser Fall sollte "theoretisch" eigentlich gar nicht vorkommen, da eine stake Authentisierung verwendet wird. Allenfalls hat sich der Endbenutzer versehentlich zweimal angemeldet - oder seine Internet-Verbindung wurde unterbrochen. Vielleicht wurde aber auch TAN-Nummern oder die Zugangs-Nummernliste inkl. der zusätzlichen Sicherheitselemente unbemerkt kopiert. Löschen Sie in jedem Fall im Applikations-Server die alte Session desselben Benutzers. Geben Sie zudem bei der neuen, doppelten Authentisierung dem Benutzer eine Warnungs-Meldung aus, dass eine bereits bestehende, aktive Session terminiert wurde. Initial-Authentisierung nicht über ungesicherte Kanäle übertragen Übertragen Sie die Sicherheitselemente zum Zugriff auf die Applikation nie über ungesicherte Kanäle (wie z.B. E-Mail) an die Benutzer. Auch nicht in "dringenden Fällen" und auch nicht an eigene Support-Personen vor Ort beim Kunden. Gesperrte Accounts nur nach sorgfältiger Authentisierung wieder entsperren Instruieren Sie Ihr Support-Personal dahingehend, dass gesperrte Benutzer-Accounts nur nach sorgfältiger, erneuter, nicht Computer-gestützter Authentisierung entsperrt werden. Kann keine vollständige Authentisierung durchgeführt werden (z.B. am Telefon), so sollte "höchstens" die Entsperrung unter Beibehaltung des alten Passworts vorgenommen werden - ohne dieses zu erwähnen. Noch besser ist, wenn Sie die gleichen Vorsichtsmassnahmen (wieder) anwenden, wie wenn der Benutzer zum ersten Mal in Ihrem System erfasst würde. Alternativ zu einer Entsperrung können auch neu erzeugte Sicherheitselemente an den Endbenutzer (erneut wieder) übertragen werden (neues Passwort etc.). Analog einer Initial-Authentisierung - wiederum über einen gesicherten Kanal. Kryptologische Zufallszahlen-Generatoren verwenden Nebst der sauberen Implementation und der hohen Verschlüsselungstiefe hängt die Qualität einer sicheren Verbindung direkt mit den dazu nötigen Zufallszahlen-Generatoren sowohl auf Client- wie auch auf Server-Seite ab. Ein möglicher Angriffspunkt kann z.B. sein, dass auf Client-Seite der SSL-Library bzw. dem Web Browser ein Zufallszahlen-Generator "untergeschoben" wird, welcher vorhersagbare Zahlen liefert. In einem solchen Fall wird auch eine 128-Bit Verschlüsselungstiefe nicht davor schützen, dass der Datentransfer abgehört werden kann. Während Sie auf Client-Seite in der Regel wenig Einfluss auf die Qualität des Zufallszahlen-Generators haben, so sollten Sie dennoch auf Server-Seite qualitativ hochwertige Zufallszahlen-Generatoren verwenden, um den Session-Context bzw. die Session-Id zu erzeugen. Limiten setzen und Risk-Management implementieren Setzen Sie innerhalb der Web Applikation immer Limiten, bei deren Überschreitung eine manuelle Kontrolle nötig ist. Dies ist eine mächtige Massnahme im grösseren "Ereignissen" vorzubeugen. Bei einem E-Commerce Shop welcher nur Blumen verkauft, welche mittels Kreditkarte bezahlt werden, könnte die Limite für einen maximalen Einkauf z.B. 500 Euro betragen - oder z.B. 2000 Euro pro Kunde und Tag. Bei E-Banking Applikationen sollten diese Limiten eher aus der Transaktions-History des Kunden oder Begünstigten selbst berechnet werden: so könnten z.B. ungewöhnlich hohe Zahlungen aus oder nach fremden Ländern ein Grund für eine vertiefte Kontrolle sein. Überlegen sie auch selbst, welche weiteren Limiten für Ihre Web Applikation Sinn machen. GMT als applikations-interne Zeitbasis verwenden Damit die Nachvollziehbarkeit der aufgezeichneten Daten auch während des Übergangs Sommerzeit/Winterzeit gewährleistet ist, sollten sie applikations-intern alle Zeiten in GMT führen, und den Endbenutzern die Zeit jeweils umgerechnet in deren lokale Zeit darstellen (lokale Zeitzone im Benutzerprofil speichern). Dies verhindert bei Software-Komponenten auch ungewollte Rückwärts-Zeitsprünge, bei der Rückstellung der Zeit um eine Stunde und hat den zusätzlichen Vorteil, dass bei "internationalen Kunden" Daten mit Zeitangaben in der gewohnten Zeitzone des Kunden dargestellt werden können. Der tiefere Sinn bezüglich Security besteht jedoch darin, dass die zeitliche Nachvollziehbarkeit der Log-Daten und Transaktionen auch bei der Umstellung Sommerzeit/Winterzeit nicht durcheinander gerät. Anonyme Benutzer von authentisierten Benutzern trennen Einen besseren Schutz vor anonymen Hacking-Versuchen erreichen Sie dadurch, dass dem eigentlichen Applikationsserver eine Reverse Proxy Server vorgeschaltet wird, welcher den Endbenutzer Authentisiert und erst bei einer erfolgreichen Authentisierung des Endbenutzers den Datentransfer zum eigentlichen Applikationsserver weiterleitet. Schutzmassnahmen auf Kundeseite fördern Halten Sie Ihre Endbenutzer dazu an, einen Firewall sowie einen Virenscanner einzusetzen. Publizieren Sie den Fingerprint Ihres SSL-Server Zertifikats auch auf anderen Medien als dem Internet (z.B. auf Papier in Mailings). Sensibilisieren Sie Ihre Kunden dahingehend, dass diese Ihren Help-Desk per Telefon anrufen, wenn neu unübliche Fehlermeldungen im Web Browser ausgegeben werden. Benutzeranfragen und Störungsmeldungen richtig behandeln Schulen Sie Ihr Supportpersonal dahingehend, dass diese mit den Symptomen der wahrscheinlichsten Angriffsversuchen auf Ihre Endbenutzer vertraut sind, und in einem solchen Fall einen Angriffsversuch erkennen und direkt Ihre Interne IT Security-Abteilung kontaktieren. Angriffsversuche periodisch Auswerten Protokollieren Sie "mutwillige" Angriffe auf das Rollenkonzept der Web Applikation (z.B. mittels manipulierten HTML Form-Parametern) mit einer besonderen Kennzeichnung und werten Sie solche Angriffsversuche regelmässig aus. Dadurch können Sie gezielt die wenigen Schwarzen Schafe unter Ihren Endbenutzern eliminieren. Shutdown-Kriterien und Notfall-Konzepte vorbereiten Legen Sie im vornherein definierte Kriterien fest, unter welchen Umständen Sie die Web Applikation temporär vom Netz nehmen, wie Sie am effizientesten auf Angriffsversuche (auch gegen Ihre Kunden) reagieren, und wie Sie in einem solchen Fall mit Ihren Kunden kommunizieren. IV  Weitere Empfehlungen Alle Team-Mitglieder sensibilisieren Sensibilisieren Sie alle Team-Mitglieder bezüglich Security. Es nützt nicht viel, wenn Ihr Kollege über keine Kenntnisse der notwendigen Vorkehrungen verfügt. Teile Sie gemeinsam das Wissen in diesem Bereich und kommunizieren Sie auch, welche Konsequenzen das Unterlassen von Sicherheitsmassnamen für die Beurteilung Ihres Teams und Ihrer Firma haben könnte. Qualitätssicherung mit einbeziehen Oft werden von der klassischen Qualitätssicherungs-Abteilung die Security-Aspekte zuwenig geprüft. Verlangen Sie auch in diesem Bereich entsprechende Tests. Legen Sie besonderen Wert darauf, dass Angriffsversuche auf das Rollenkonzept der Applikation mittels gefälschter HTTP-Parametern sowie korrekte Überprüfung aller HTML Formular Input-Parameter ausführlich getestet wird. Umsetzung von Security-Massnahmen bei Aufwandschätzungen mit berücksichtigen Schätzen Sie den Projekt-Aufwand so, dass alle Aufwände zum Erreichen der notwendigen Sicherheitsmassnamen bereits inbegriffen sind. Falls Sie bereits wissen, dass ein Security-Audit Bestandteil der Abnahme ist, so sollten Sie auch eine Reserve für unvorhergesehene Fehlerbehebungen mit einplanen. Auf ausgewogene Sicherheit achten Falls die Umsetzung einer einzelnen Massnahme zu hohen Kosten führt, so sollten Sie zuerst überlegen, ob die Realisierung - um Vergleich zu anderen Massnahmen bzw. Bedrohungen - wirklich berechtigt ist. Oder als Metapher formuliert: wenn Sie Ihr Haus vor Überschwemmungen schützen möchten - so nützt eine 2 Meter hohe Mauer nur auf der Hinterseite nichts - viel besser währe, wenn sie nur eine 50 Zentimeter hohe Mauer bauen würden - dafür rund um das Haus. Hilfe anfordern, Übersicht behalten und Risiken delegieren Fordern Sie interne oder externe Hilfe an, wenn Sie bei der Beurteilung oder bei der Umsetzung von Sicherheitsmassnamen unsicher sind. Es ist nicht so einfach, eine reale Bedrohung von einer rein theoretischen, unwahrscheinlichen Bedrohung zu unterscheiden. Informieren Sie sich im Web über tatsächlich, bereits realisierte Vorkommnisse und legen Sie den Schwerpunkt Ihrer Sicherheits-Massnahmen auf die Abwehr dieser realen Angriffe. Falls Sie zur Überzeugung gelangt sind, dass in Ihrer Web Applikation ein grösseres Sicherheitsleck bereits besteht - bei welchem zur Behebung ein zusätzlicher Aufwand nötig ist - so sollten Sie Ihren Vorgesetzen umgehend mit einer schriftlichen Beschreibung informieren und gleichzeitig die nötigen Mittel und Ressourcen anfordern, um dieses Risiko zu eliminieren. Werden die Ressourcen oder Mittel nicht freigegeben, so müssen Sie das Risiko nicht selbst tragen. Dies entspricht auch dem üblichen Vorgehen bei allen Qualitätssicherungs-Massnahmen. Es ist Schlussendlich ein Entscheid des Managements, welche Risiken tragbar sind. Voraussetzung ist jedoch, dass die entsprechenden Entscheidungsträger genügend gut informiert wurden. V  Hyperlinks Link-Sammlung zum Thema Web Application Security in Englischer Sprache: - SecurityTechNet.com Hyperlinks zum Thema IT-Security in Deutscher Sprache: - Deutsches Bundesamt für Sicherheit in der Informationstechnik (BSI) - Security Portal des heise Verlags Hyperlinks zum Thema HTTPS/SSL in Deutscher Sprache: - SSL-Studie (BSI, PDF-Datei) - Angriffe in der Praxis: Verschlüsselungs-Algorithmen (heise Security) VI  Feedback Ihre Kritik, Kommentare, Fragen oder Ergänzungen sind willkommen und werden von uns in der Regel innerhalb von drei Arbeitstagen beantwortet. Gegebenfalls erweitern oder ergänzen wir dabei auch die hier vorliegenden Web Application Security Tips. Senden Sie bitte Ihre Nachricht an security@d-fischer.com. Beachten Sie bitte, dass Ihre Nachricht gegebenenfalls anonymisiert publiziert wird (ohne Ihren vollen Namen und ohne Ihre E-Mail Adresse). Wir sichern Ihnen verbindlich zu, Ihre Nachricht rein fachlich zu behandeln, Ihre Namen und Ihre E-Mail Adresse nicht an Dritte weiterzureichen und Ihnen keinerlei Werbe-Mails zuzustellen. Aus urheberrechtlichen Gründen können wir Ihnen jedoch kein Copyright auf Ihre Nachricht gewähren.