Wikipedia

Sicherheit von Webanwendungen

Überblick über die Sicherheit von Webanwendungen
Dies ist eine alte Version dieser Seite, zuletzt bearbeitet am 29. Dezember 2011 um 01:06 Uhr durch Mmovchin (Diskussion | Beiträge). Sie kann sich erheblich von der aktuellen Version unterscheiden.

ToDo[1]

Ebenenmodell

Ein Ebenenmodell dient dazu, die Zuständigkeiten für die einzelnen Teilaufgaben bei der Sicherheitskonzeption und Realisierung von Webanwendungen zuordnen. Ausgangspunkt ist eine Unterteilung in 5 Ebenen: Der Semantik, Logik, Implementierung, Technologie, System sowie der Ebene "Netzwerk & Host".

Angriffsmethoden

Es gibt unzählige Möglichkeiten, Schwachstellen in einer Webanwendung zu finden und diese auszunutzen. Im Folgendem findet sich eine Beschreibung allgemein bekannter und oft benutzter Angriffsmöglichkeiten im Zusammenhang mit Webanwendungen.

SQL-Injection

Bei einer SQL-Injection sendet der Angreifer Verbindungsanfragen an den Webserver, wobei die Anfrage-Parameter mit SQL-Steuerzeichen versehen sind. Fängt die Webanwendung diese Steuerzeichen nicht ab, sondern sendet sie als Teil einer SQL-Abfrage an die Datenbank, kann der Angreifer entweder für ihn auf herkömmlichem Weg nicht zugängliche Daten auslesen oder Daten verändern.

Cross-Site-Scripting

Hinter der Bezeichnung Cross-Site Scripting (XSS) verbergen sich zwei (manchmal wird noch ein dritter Typ unterschieden) grundsätzlich verschiedene Angriffe. Beim clientseitigen XSS schleust der Angreifer HTML-Steuerzeichen und Code einer clientseitigen Skriptsprache, wie z. B. JavaScript, in eine Webseite ein, die in dem Webbrowser des Opfers ausgeführt wird. Dieser Angriff nutzt dabei Sicherheitslücken bei der lokalen Ausführung der Skripte aus oder leitet eine Cross-Site Request Forgery ein. Unter serverseitigem XSS versteht man das Einschleusen von manipulierten Informationen in eine auf dem Webserver ausgeführte Scriptsprache, so dass diese beispielsweise bei einem dynamisch generierten include() eine vom Programmierer nicht vorgesehene Datei (ggf. sogar von einem anderen Server) ausführt.

Session Hijacking

Da HTTP ein verbindungsloses Protokoll ist, muss die Webanwendung selbst die Identifikation eines Benutzers feststellen. Dies geschieht anhand einer Session-ID, die als Basic/Digest Authentication, Cookie, URL-Rewriting oder HTTP-Form-Parameter (GET oder POST) jedem Request mitgegeben wird. Beim Session Hijacking versucht der Angreifer Kenntnis von der Session-ID des Benutzers zu erlangen, um dann die Identität des Opfers vorzutäuschen und mit dessen Rechten auf die Webanwendung zuzugreifen.

Cross-Site Request Forgery

Cross-Site Request Forgery setzen eine bestehende Session zwischen dem Benutzer und der Webanwendung voraus. Dabei versucht der Angreifer über verschiedene Techniken (ggf. XSS) den Benutzer oder über ein clientseitiges Script auch direkt den Browser zum Aufruf einer manipulierten URL zu bewegen. Anders als beim Session-Hijacking erlangt der Angreifer selbst aber keine Kenntnis von der Session-ID, da der Angriff ausschließlich im Browser des Benutzers stattfindet.

Directory Traversal

Bei einem Directory Traversal Angriff nutzt der Angreifer die fehlende Prüfung der Webanwendung auf manipulierte Pfadangaben aus. Erwartet die Webanwendung beispielsweise einen Parameter wie item=datei1.html kann dieser ggf. mit item=../../../Config.sys missbraucht werden

E-Mail-Injektion

Bei einer E-Mail-Injektion fügt der Angreifer in ein Kontaktformular manipulierte Daten ein, so dass anstelle der Nachricht an den vom Betreiber der Webanwendung beabsichtigten Empfänger nun beliebige E-Mails an beliebige Empfänger gesendet werden. Diese Möglichkeit wird meist für den Versand von Spam missbraucht.

Man-In-The-Middle-Angriff

Bei einem Man-In-The-Middle-Angriff (MitM) zielt der Angreifer darauf ab, dass der Benutzer anstatt mit dem Webserver direkt vielmehr mit dem Rechner des Angreifers eine Verbindung aufbaut, ohne dies zu bemerken. Der „In-the-middle“-Rechner startet bei jeder Anfrage des Benutzers seinerseits eine Anfrage an den echten Webserver und gibt dessen Antwort an den Benutzer weiter. Der Nutzwert besteht für den Angreifer darin, Anfragen an oder Rückgaben der Webanwendung beliebig manipulieren zu können. Gegen diese Art von Angriff bietet nur die Verschlüsselung der Datenübertragung mittels SSL Schutz. Dieser Schutz wird aber auch unwirksam, wenn sich der Angreifer ein SSL-Zertifikat der betroffenen Webseite verschaffen kann, zu dem ein Root-Zertifikat im Browser des Opfers installiert ist.

Denial of Service

Bei einem Denial of Service (DoS) Angriff versucht der Angreifer dem Webserver durch eine Vielzahl von Verbindungsanfragen die Ressourcen für reguläre Anfragen zu entziehen. Wird der Angriff gleichzeitig von mehreren (ggf. mehrere tausend) Computern gleichzeitig durchgeführt, spricht man auch von einem Distributed-Denial-of-Service-Angriff (DDoS). Ein DoS ist nicht auf Webanwendungen beschränkt, sondern kann sich gegen jede Art von Server richten.

Mustererkennung

Grundlegendes Problem jeder Maßnahme zur Verhinderung von DoS-Angriffen ist die Unterscheidung eines solchen Angriffs von legitimen Zugriffen, sowie die gezielte Blockierung des Angreifers, ohne legitime Benutzer in Mitleidenschaft zu ziehen. Ein automatisierter DoS-Angriff kann wirksam dadurch verhindert werden, dass der Benutzer nach Erreichen einer festgelegten Toleranzschwelle von erlaubten Wiederholungen aufgefordert wird, eine Eingabe zu tätigen, die ein Programm nicht liefern kann. Wird die Eingabe korrekt gegeben, kann davon ausgegangen werden, dass kein automatisierter Angriff stattfindet. Folgende Verfahren kommen in Frage:

  • Captcha (Beim Einsatz von Captchas und der Auswahl einer Captcha-Bibliothek ist zu beachten, dass die Sicherheit dieses Verfahrens mit der maschinellen Nichtlösbarkeit der Aufgabe steht und fällt. Fortschritte in der Mustererkennung oder die Entdeckung von Algorithmen können diese Art von Schutz mit einem Schlag wertlos machen.)
  • Rätselfrage (Dem Benutzer wird eine Frage gestellt, die eine Maschine nicht interpretieren und damit nicht beantworten kann.)

Phishing / Identitätsdiebstahl

Beim Phishing handelt es sich nicht um eine Sicherheitslücke einer Webanwendung; es gehört vielmehr in den Bereich des Social Hacking. Hierbei fordert der Angreifer seine potentiellen Opfer meist massenweise per E-Mail auf, Zugangsdaten, wie z. B. PIN und TAN zum Online-Banking, auf einer Webseite einzugeben. Diese sieht in der Regel äußerlich so aus, wie die des Betreibers der Webanwendung, unterliegt aber der Kontrolle des Angreifers. Nimmt das Opfer diese Fälschung nicht wahr und gibt seine Zugangsdaten preis, kann der Angreifer diese zu seinen Gunsten verwenden.

Identitätsprinzip

Das Identitätsprinzip ist eine Art, Webanwendungen und Internetseiten so zu gestalten und darzustellen, dass Benutzer bei einem Phishing-Angriff die gefälschte Seite wahrnehmen und sensible Daten nicht angeben. Dazu muss aus dem Umgang mit der Website, aber auch aus der gesamten Kommunikation mit dem Internetauftritt erkennbar sein, dass der Internetdiensteanbieter bestimmte Muster durchgängig einhält.

Generelle schützende Maßnahmen

Data Validation

Die Validierung von Input und Output, vor allem Input ist das wichtigste Bestandteil einer sicheren Webanwendung. Der Datenfluss ist nicht nur vom Benutzer zur Anwendung und umgekehrt, sondern auch zu den verschiedenen Subsystemen und von dort aus in die Ausgabe, zu untersuchen. Im Idealfall werden alle Input-/Output-Daten von einem zentralen Data-Validation-Modul geprüft. In PHP lässt sich sowas mit Funktionen lösen. Neben den offensichtlichen Eingabedaten in Form-Variablen existieren eine Reihe weiterer Quellen. Alternativ lässt sich Filterung einsetzten. Dies ist immer dann angebracht, wenn keine Nebeneffekte zu befürchten sind oder wenn die Art der Datenverwendung gefährliche Zeichen oder Zeichenketten auf­grund ihrer Natur erlauben muss. Beispiel: Ein Forum, in dem über JavaScript diskutiert wird, kann nicht die Eingabe von <script> verbieten, muss dieses aber als HTML-Tag validieren. Bei der Filterung ist mit großer Umsicht vorzugehen, denn man läuft permanent der Gefahr, eine Variante zu übersehen.

Whitelisting statt Blacklisting

Sofern der Input klar definierbar ist, ist es meist sinnvoller, nur bestimmte Eingaben zuzulassen, als bestimmte andere Angaben nicht zuzulassen. Beim Blacklisting werden die Muster definiert, die aus der Eingabd herausgefiltert werden, alles andere wird durchgelassen. Beim Whitelisting ist es umgekehrt: Werde, die nicht ausdrücklich erlaubt sind, sind verboten. Black­listing ist dann problematisch, wenn als "nicht kritisch" erkannte Zeichen im Verlaufe der weiteren Verarbeitung zu einem ungewollten Systemverhalten oder auch Fehlern führen. Werden allerdings problematische Muster vergessen oder nicht erkannt oder kommen neue pro­blematische Muster hinzu, so werden sie beim Whitelist-Ansatz hingegen automa­tisch geblockt. Beim Blacklist-Ansatz werden sie solange durchgelassen, bis die Re­geln angepasst werden. Blacklist- und/oder Whitelist-Verfahren können nicht nur mit festen Schlüs­selwörtern benutzt werden. Auch ein Einsatz mit regulären Ausdrücken kann sinnvoll erscheinen.

Behandlung von manipulierten Eingaben

Bei der Behandlung von ungültigen Eingaben sollte zwischen nachfolgenden zwei Fällen unterschieden werden: Fehleingaben des Benutzers und bewusste Manipulation. Im ersten Fall ist in benutzerfreundlicher Weise zu reagieren – unter Wahrung des Minimali­tätsprinzips. Der Benutzer ist auf den Fehler hinzuweisen. Im zweiten Fall sollte die Reaktion in geeigneter Weise den Manipulationsversuch abwehren. Dann ist zu entscheiden, ob eine Filterung erfolgt oder ob die Weiterverar­beitung abgelehnt wird. Eine erfolgreiche Filterung könnte eine Weiterverarbeitung implizieren. Ein sicheres Kriterium für den Abbruch der Verarbeitung mit einer Fehlermeldung ist immer dann gegeben, wenn die Eingabedaten mit bestimmungsgemäßer Browserbe­dienung nicht eintreten können, wie z.B.:

  • Zusätzliche oder fehlende Form-Variablen
  • Das Session-Cookie enthält Zeichen, die von der Anwendung nicht vergeben werden oder es entspricht nicht dem definierten Format
  • In HIDDEN-, SELECT- oder CHECKBOX-Variablen transportierte Werte wurden ver­ändert oder entsprechen nicht dem Muster, welches die Anwendung gesetzt hat
  • Die Quelle der Variablen (z.B. GET, POST, Cookie) stimmt nicht mit der Vorga­be der Anwendung überein

Zu den möglichen Reaktionen auf derartige Fehler können je nach Situation zählen:

  • Die weitere Verarbeitung ist zu stoppen. Es ist zu erwägen, statt einer Fehlermel­dung eine Reaktion in dieser Weise vorzunehmen: Dem Benutzer – dem in die­sem Fall ein Angriff unterstellt wird – wird der korrekte Umgang mit der Einga­be vorgetäuscht, um seinen Angriffsversuch zu unterlaufen und weiteres Suchen nach Schwachstellen zu erschweren. So würde die Antwort auf das manipulierte Absenden eines Kontaktformulars beispielsweise genauso wie im korrekten Fall lauten: Vielen Dank für Ihre Anfrage, die wir umgehend bearbeiten.
  • Es ist zur Hauptseite oder der (neutralen) Seite, die auch bei Zu­griffen auf nicht vorhandene Seiten angezeigt wird, zurückzukehren.
  • Es ist eine explizite Warnung auszugeben, dass ein Angriffsversuch festgestellt worden ist und dass alle Zugriffsversuche protokolliert werden bzw. anderweiti­ge Maßnahmen ergriffen werden. Ob dies allerdings überhaupt sinnvoll ist, muss bei der jeweiligen Anwendung einzeln entschieden werden.
  • Zusätzlich bei bestehender Session: Der Benutzer ist auszuloggen und die Sessi­on zu invalidieren.

Nicht korrekt sind diese häufig anzutreffenden Reaktionen:

  • ungefilterte Ausgabe der Fehlermeldung, insbesondere eine SQL-Fehlermeldung (liefert u. U. für einen Angriff verwert­bare Informationen)
  • Server Error 500 (daraus lässt sich schließen, dass die Anwendung nicht alle Fäl­le korrekt abfängt)

• "Die Anwendung ist momentan wegen Wartungsarbeiten nicht verfügbar" (gibt dem Angreifer u. U. einen Anreiz, die Anwendung weiter zu untersuchen, da er vermutet, dass er die Anwendung tatsächlich kurzzeitig lahm gelegt hat.)

Gänzlich abzuraten ist in solchen Fällen von Versuchen, fehlerhafte Eingaben zu kor­rigieren. Derartige Versuche weisen das unnötige Risiko auf, doch nicht fehlerfrei zu sein und einen Angriff dadurch überhaupt erst zu ermöglichen.

Prepared Statements

Durch Verwendung von Prepared Statements anstatt dynamisch zusammengebauter SQL-Statements kann dem Problem der SQL-Injection aus dem Weg gegangen wer­den. Software-Entwickler müssen sich im Rahmen des Designs einer Funktion oder hat bzw. was die Menge aller möglichen Abfragestrukturen ist, die in Abhängigkeit vom Input zur Ausführung gelangen können. Diese Abfragen sind in Form von Pre­ pared Statements auszuformulieren. Dabei kann mit den Mitteln der Prepared State­ments (also in der Regel entsprechenden WENN-Abfragen und dem Zusammensetzen von Abfragen) allen Bedingungen, die durch unterschiedlichen Input zu prüfen sind, Rechnung getragen werden. Es besteht also in aller Regel keinerlei Notwendigkeit, in die Formulierung des Statements zusätzlich eine Dynamik hineinzubringen, die nur mit dem Mittel der Dynamic Statements erreichbar wäre.

Stored Procedure

Stored Procedures haben im Hinblick auf ihre Sicherheit gegenüber SQL-Injection ähnliche Eigenschaften wie Prepared Statements. Auch hier ist zu beachten, dass bei Übergabe von unvalidierten Parametern an eine Stored Procedure möglicher proble­matischer Input nicht automatisch abgefangen wird.[2]

Diverse weitere Maßnahmen und Hinweise

Serverseitig validieren

Alle Eingabedaten sind von der Anwendung auf dem Server zu validieren. Prüfungen auf dem Client (Browser) z.B. mittels JavaScript können allenfalls zusätzlich aus Gründen der Benutzerfreundlichkeit erfolgen, aber niemals um Annahmen über die Beschaffenheit der Eingabedaten sicherzustellen. Prüfungen im Browser könnten vom Benutzer ab­geschaltet und beliebig manipuliert werden.

Namen von Form-Variablen validieren

Genauso wie der Wert einer Form-Variablen kann auch ihr Name beliebig manipu­liert werden. Daher sind auch die Namen von Form-Variablen der Filterung zu unter­ziehen. Da alle Form-Variablen in der Anwendung bekannt sind, ist hier ein einfaches StringMapping sehr effektiv.

Länge/Größe der Eingabedaten begrenzen

Alle Eingabedaten sind auf ihre Größe zu überprüfen, bevor sie verwendet (insbeson­dere kopiert) werden. Die genaue Realisierung dieser Prüfung ist von der jeweiligen Programmiersprache abhängig. Beispiel in PHP: 

if (strlen($parameter) > 42) { return; };

Achtung: die PHP-Funktionen geben im String enthaltene Null-Bytes direkt als sol­che weiter. Null-Bytes müssen zuvor entfernt werden.

Abwägung von POST- und GET-Requests

Die Ausnutzung einer XSS-Lücke zum Zwecke des URL-Spoofings ist dann am einfachsten durchführbar, wenn der manipulierende Code einfach an den Aufruf an­gehängt werden kann. Ein Session-Riding-Angiff lässt sich dann in einem IMG-Tag verstecken und unbemerkt ausführen. Ähnliches gilt für andere Angriffsformen. Möglich ist dies immer dann, wenn der Request von der Anwendung als GET-Request behandelt wird. Verwendet die Anwendung an dieser Stelle jedoch die POST-Metho­de, ist ein Einbau in die URL nicht mehr möglich. Es empfiehlt sich daher, HTML-Forms per POST-Methode zu übertragen, so dass im Falle einer vorhandenen XSS-Lücke wenigstens eine kleine zusätzliche Hürde gesetzt wird. Allerdings abstrahieren viele heutige Frameworks und Komfortfunktionen über der Request-Methode, d.h. sie liefern die übergebenen Parameter, egal ob diese per GET oder POST geschickt worden sind. Selbst dann, wenn in der Form ein POST als Request-Methode angegeben ist, kann ein Angreifer die Daten an die URL hängen und per GET übertragen, da die Anwendung nicht unterscheidet. Der Ausschluss von GET ist daher von der Anwendung zu erzwingen oder zumindest vorzuziehen.[3]

Escape-Funktionen

Als Anhaltspunkte sind hier Escape-Funktionen verschiedener Programmiersprachen (Ausschnitt) aufgeführt:

ASP 

Request.Form()
Request.QueryString()
Request.Cookies()
RangeValidator()
RegularExpressionValidator()
Server.HTMLEncode()
Server.URLEncode()

Java 

class java.sql.PreparedStatement
java.net.URLEncoder.encode()

Perl 

CGI::autoEscape()
CGI::escapeHTML()

PHP 

addslashes()
quote_meta()
mysql_real_escape_string()
strip_tags()
htmlentities()
utf8_decode()

Minimalitätsprinzip

ToDo

URL-Weiterleitungen kontrollieren und einschränken

Weiterleitungen sind generell durch geeignete Maßnahmen vor Missbrauch zu schützen.

Linkeinschränkung

Sind die Links, auf die weitergeleitet wird, konkret bekannt, so ist die Weiterleitung auch nur für diese zu erlauben. Alle anderen Parameter sind abzulehnen. Das ist am besten dadurch zu erreichen, wenn nicht die Ziel-Seite selbst als Parameter übergeben wird, sondern ein Index in einer Datenbank, die serverseitig gehalten wird, und in der alle in Frage kommenden URLs enthalten sind.

Weiterleitungshinweis

Statt die Umlenkung direkt und für den Benutzer transparent durchzuführen, ist sie indirekt über eine Seite zu führen, die dem Benutzer angezeigt wird. Damit kann dieser den Link vor dem aktiven Klick prüfen und selbst entscheiden, ob er diesem vertraut. Beispiel: 

Sie werden auf die Folgende externe Webseite weitergeleitet:
http://www.example.tld/angriff.foo
Aus Sicherheitsgründen führen wir die Weiterleitung nicht automatisch durch. Bitte kontrollieren Sie den Link und 
setzen Sie die Weiterleitung gegebenenfalls durch einen Klick fort.

Referrer-Test

Der Referrer kann als zusätzliches Merkmal beachtet werden. Diesem Ansatz liegt die Annahme zugrunde, dass ein Request nur dann legitim ist, wenn er durch einen Klick auf einer zur Anwendung gehörenden Seite ausgelöst worden ist. Und immer dann ist auch der Referer-Header mit der URL dieser Seite belegt. Die Anwendung muss also prüfen, ob der übergebene Referrer in der Liste der in Frage kommenden URLs vorhanden ist und kann im Positiv-Fall davon ausgehen, dass es sich um die legitime Verwendung handelt. Dabei ist es wichtig, die gesamte URL zu matchen und nicht nur den Host-Anteil,denn der so erreichte Schutz kann durch eine XSS-Schwachstelle auf derselben Seite – ggf. auch außerhalb der Anwendung selbst – wieder zunichte gemacht werden. Zwar lässt sich der Referrer per JavaScript nicht direkt manipulieren, über den Umweg des Cross-Site Scripting ist es dann aber doch möglich. Außerdem ist der Referrer nicht immer verfügbar, da ihn manche Content-Filter auf der Client-Seite herausfiltern.

Lokale Weiterleitungen einschränken

Erfolgt die Weiterleitung auf eine Seite der selbigen Website, so ist vor der Ausführung zu prüfen, dass als Parameter keine URL übergeben worden ist, die auf eine externe Seite führt. Am einfachsten werden lokale Weiterleitungen ausschließlich mit relativen Pfaden durchgeführt und der Host-Teil statisch hinzugefügt. Statt also die Weiterleitung so zu programmieren, dass ein vollqualifizierter Link übergeben werden muss, sollte der Parameter lediglich den internen Ziel-Pfad enthalten, wobei die Domain statisch hinzugefügt wird.

Session Management

Das Session Management ist eine der problematischsten Stellen für die Sicherheit von Webanwendungen. Für den Schutz der SessionID sollten daher entsprechend wirksame Maßnahmen zur Anwendung kommen.[4]

Bindung von zusätzlichen Parametern an die Session

Eine Session kann durch Einbeziehung von zusätzlichen Parametern (z.B. der IP-Adresse des Clients) als kennzeichnendes Merkmal zusätzlich geschützt werden, sofern die daraus resultierenden Probleme in Kauf genommen werden können. Als Beispiel hinterlegt die Anwendung bei der Instanziierung der Session die IP-Adresse des Clients und überprüft bei jedem Zugriff, ob diese mit der hinterlegten IP-Adresse weiterhin übereinstimmt. Ist das nicht der Fall, wird die Session invalidiert.

Nachteilig an diesem Lösungsansatz sind deutliche Beschränkungen in Bezug auf mögliche Einsatzumgebungen: Die Bindung der IP-Adresse an die Session funktioniert nicht oder nur eingeschränkt für all jene Benutzer, die sich hinter einem Proxy befinden. Das trifft z.B. auf größere Organisationen oder auch auf Kunden eines Internet-Access-Providers zu, der eine Proxy-Architektur einsetzt. In einer solchen Umgebung kann es vorkommen, dass im Verlaufe einer Applikations-Session der ausgehende Proxy oder Router bzw. die IP dessen wechselt und damit bei der Webanwendung eine andere IP-Adresse registriert wird. Als weitere Hindernisse sind software- und netzwerktechnische Gegebenheiten zu nennen, die dazu führen können, dass bei der Webanwendung die IP-Adresse des zugreifenden Benutzers gar nicht ankommt, sondern nur diejenige eines vorgeschalteten Reverse-Proxy oder einer anderen Komponente im eigenen Netz. Eingesetzt werden kann der vorgeschlagene Lösungsansatz jedoch in jenen Anwendungssituationen, in denen die oben genannten Nachteile nicht eintreten oder toleriert werden können. So z.B. sind die beschriebenen Hindernisse in der Regel in Intranet-Bereichen nicht vorhanden, so dass hier die Bindung der Session an die IP-Adresse bei Anwendungen mit erhöhtem Schutzbedarf als eine zusätzliche Sicherheitsmaßnahme erfolgen kann.

Session Riding

Session Riding ist durch Einführung eines SessionCodes oder durch eine andere Schutzmaßnahme zu verhindern.

Dialogtracking

Privilege Escalation

Hashes

URL-Rewriting

Logout erzwingen

Jede Anwendung, die eine Login-Funktion hat, sollte auch eine Logout-Funktion besitzen. Das Logout hat das korrekte Invalidieren der Session sicherzustellen. Bei zahlreichen Webanwendungen ist zu beobachten, dass eine Logout-Funktion zwar vorhanden ist und der Benutzer nach Ausführung auch die Bestätigung erhält, nun abgemeldet zu sein, dass die Session aber nicht invalidiert wird. Zu erkennen ist das meist daran, dass die Betätigung des Zurück-Buttons des Browsers bis zu einer Seite innerhalb der Anwendung ein Weiterarbeiten darin nach wie vor ermöglicht. Mit einer gestohlenen SessionID könnte in einem solchen Fall weitergearbeitet werden (zum Beispiel in einem Internet-Café).

Der Benutzer ist darin zu animieren, das Logout auch wirklich auszuführen. Dies kann die folgt durchgeführt werden:

  • Einfache und klare Darstellung des Logout-Buttons
  • Hinweis nach dem Login
  • Hinweis nur dann nach dem Login, falls dies beim letzten Mal nicht geschehen ist

Schließt der Benutzer das Browser-Fenster in der Annahme, sich dadurch auch automatisch auszuloggen (was aber nicht der Fall ist), so sollte die Anwendung den Benutzer beim nächsten Login darüber informieren, dass ein automatisches Ausloggen erfolgte, und in Zukunft ein explizites Ausloggen stattfinden sollte.

Diverse weitere Maßnahmen und Hinweise

Enumerationen

Erkennung

[5]

Blocken

Benutzer

Umgang mit Benutzerkennungen

Um die Sicherheit erheblich zu steigern sollte die Benutzerkennung als nicht-öffentliche Information behandelt werden. Insbesondere sind E-Mail-Adressen sowie Schematas wie vorname.nachname zu vermeiden. Es wird empfohlen, stattdessen nicht ableitbare Zeichenketten zu verwenden oder eine Kombination aus externen Merkmalen mit einer nicht-erratbaren Komponente zu gestallten. Zudem ist darauf zu achten, dass die Anwendung keine Hinweise über das Vorhandensein von Benutzerkennungen gibt. Häufig anzutreffen ist diese Art der Implementierung einer "Passwort vergessen"-Funktion: Der Benutzer wird aufgefordert, seine eindeutige Identifikationsnummer (UserID) einzugeben. Ist diese korrekt, d.h. existiert die Nummer in der Datenbank, so lautet die Antwort: "Das Passwort wurde an die hinterlegte E-Mail-Adresse verschickt". Wurde jedoch eine nicht existierende Identifikationsnummer eingegeben, so lautet die Antwort: "Dieser Benutzer existiert nicht, bitte korrigieren Sie Ihre Eingabe". Auf diese Weise lassen sich Benutzerkennungen durch Aufzählen (Enumeration) ermitteln. Richtig wäre folgende Antwort, die keine Information über das Vorhandensein einer UserID gibt: "Das Passwort wurde an die hinterlegte E-Mail-Adresse verschickt, falls die eingegebene UserID korrekt gewesen ist. Sollten Sie nicht in Kürze eine E-Mail von uns erhalten, so ist dies darauf zurückzuführen, dass Sie eine fehlerhafte UserID eingegeben haben".

Sichere Passwörter

Die Benutzung von sicheren Passwörtern ist dadurch zu erreichen, dass das System nicht jedes vom Anwender gewünschte Passwort akzeptiert und Regeln vorgibt sowie die Einhaltung dieser prüft. Bisher existieren für das Web keine allgemein anerkannten Verfahren und auch keine Standardbibliotheken zur Passwortprüfung. Auch wird häufig in der jeweiligen Anwendungssituation die Berücksichtigung anwendungsspezifischer Randbedingungen erforderlich sein. Generell sollten Passwörter aus einfachen Wörterbuchwörtern, persönlichen Angaben (Name, Geburtstag, etc.) sowie einfachen Zahlenkombinationen vermieden werden. Es empfiehlt sich eine Kombination aus (absichtlich falsch geschriebenen) Wörtern, Sonderzeichen, Groß- und Kleinschreibung sowie Zahlen.

Einsatz eines SSL/TLS/HTTPS-Protokolls

Daten, bei denen Ausspähen verhindert werden muss (z.B. Passwörter, Bankdaten, etc.) sind durch Einsatz des SSL-Protokolls zu schützen. Das SSL-Protokoll verschlüsselt die zwischen Browser und Server ausgetauschten Daten und sorgt dafür, dass vertrauliche Informationen vor dem Ausspähen auf dem Übertragungsweg geschützt sind. Diesen Schutz führen heutige Browser soweit, dass auch bei einem Wechsel von einer per SSL geschützten Seite (HTTPS) zu einer ungeschützten Seite (HTTP) – etwa dann, wenn der User auf der SSL-geschützten Seite auf einen HTTP-Link klickt – sensitive Protokollinformationen nicht weitergegeben werden. Das SSL Server-Zertifikat stellt außerdem sicher, dass der Hostname authentisch ist. D.h. es garantiert, dass der im Zertifikat angezeigte Hostname unverfälscht ist. Schließen wir den Fall aus, dass der DNS manipuliert worden ist, so garantiert das Zertifikat auch die Echtheit des Hosts (sofern die Seite keine Frames benutzt).

Sonstiges

Information Disclosure

Monitoring

Serverkonfiguration

Webserver

Datenbankserver

PHP-Umgebung

Web Application Isolation

Web Application Security Tools

Web Shields

Angriffe gegen eine Webanwendung können durch die Vermeidung von Sicherheitslücken während der Implementation oder durch den Einsatz von vorgeschalteten Web Application Firewalls abgewehrt werden.

Web Scanner

Strafrechtliche Aspekte

Dieser Artikel oder Absatz stellt die Situation in Deutschland dar. Bitte hilf uns dabei, die Situation in anderen Staaten zu schildern.

Jegliches rechtswidrige Verändern, Löschen, Unterdrücken oder Unbrauchbar-Machen fremder Daten erfüllt den Tatbestand nach § 303a StGB (Datenveränderung). In besonders schweren Fällen ist dies auch nach § 303b I Nr. 1 StGB („Computersabotage“) strafbar und wird mit Haftstrafe von bis zu fünf Jahren oder Geldstrafe bestraft. Die Durchführung von DDOS-Attacken stellt seit 2007 ebenfalls eine Computersabotage dar, gleiches gilt für jegliche Handlungen, die zur Beschädigung eines Informationssystems, das für einen anderen von wesentlicher Bedeutung ist, führen.

Das Ausspähen von Daten (§ 202a StGB), also die Erlangungs des Zugangs zu fremden Daten, die hiergegen besonders geschützt sind, wird mit Haftstrafe bis zu drei Jahren oder mit Geldstrafe bestraft. Das Abfangen fremder Daten in Netzen oder aus elektromagnetischen Abstrahlungen ist seit 2007 ebenfalls strafbar, anders als bei § 202a StGB kommt es hier nicht auf eine besondere Zugangssicherung an. Das sich Verschaffen, Erstellen, Verbreiten, Öffentlich-Zugänglichmachen etc. von sog. „Hackertools“ steht ebenfalls seit 2007 unter Strafe, wenn damit eine Straftat vorbereitet wird (§ 202c StGB).

Daten sind nach § 202a Abs. 2 in Verbindung mit Abs. 1 aber nur vor dem Ausspähen geschützt, wenn sie „besonders gesichert“ sind, um ein Ausufern des Tatbestandes zu vermeiden. Das heißt, erst wenn der Nutzer seine Daten technisch schützt genießt er auch den strafrechtlichen Schutz. Die frühere Debatte, ob das „Hacken“ ohne Abruf von Daten strafbar sei, ist hinfällig, seit der Wortlaut der Norm 2007 derart geändert wurde, dass Strafbarkeit bereits mit Erlangung des Zugangs zu Daten einsetzt. Weiter ist umstritten, ob die Verschlüsselung zur besonderen Sicherung zählt. Sie ist zwar sehr effektiv, aber es wird argumentiert, die Daten seien ja nicht gesichert sondern lägen nur in „unverständlicher“ bzw. schlicht „anderer“ Form vor.

Als Computerbetrug wird nach § 263 a StGB mit Geldstrafe oder Freiheitsstrafe bis zu fünf Jahren bestraft, wenn Datenverarbeitungsvorgänge zur Erlangung von Vermögensvorteilen manipuliert werden. Schon die Erstellung, Verschaffung, Anbietung, Verwahrung oder Überlassung dafür geeigneter Computerprogramme ist strafbar.

Siehe auch

Literatur

Einzelnachweise

  1. ↑ https://www.owasp.org/index.php/Category:OWASP_Guide_Project
  2. ↑ http://www.derkeiler.com/Mailing-Lists/securityfocus/secprog/2001-07/0001.html
  3. ↑ http://www.w3.org/2001/tag/doc/whenToUseGet.html
  4. ↑ http://www.technicalinfo.net/papers/WebBasedSessionManagement.html
  5. ↑ http://www.captcha.net/
Abgerufen von „https://de.wikipedia.org/w/index.php?title=Sicherheit_von_Webanwendungen&oldid=97659654“