Sicherheitsrelevante Aspekte bei der Nutzung von Content Management Systemen

Aus Winfwiki

Fallstudienarbeit
Hochschule:	Hochschule für Oekonomie & Management
Standort:	Essen
Studiengang:	Bachelor Wirtschaftsinformatik
Veranstaltung:	Fallstudie Wirtschaftsinformatik
Betreuer:	Prof._Dr._Uwe_Kern
Typ:	Fallstudienarbeit
Themengebiet:	Content Management Systeme
Autor(en):	Simon Hacks, Raphael Berger
Studienzeitmodell:	Tagesstudium
Semesterbezeichnung:
Studiensemester:	2
Bearbeitungsstatus:	Bearbeitung abgeschlossen
Prüfungstermin:
Abgabetermin:

Inhaltsverzeichnis 1 Abkürzungsverzeichnis 2 Abbildungsverzeichnis 3 Einführung 4 Grundlagen 4.1 CMS 4.1.1 Content 4.1.2 Management von Content 4.1.3 Systeme 4.2 Sicherheit 4.2.1 Definition 4.2.2 Grund für Sicherheit 4.2.2.1 Rechtliche Aspekte 4.2.2.2 Wirtschaftliche Aspekte 4.2.2.3 Potentielle Angreifer 5 Sicherheitsmaßnahmen 5.1 Software 5.1.1 Grundlagen 5.1.2 Secure Socket Layer/Transport Layer Security 5.1.3 Monitoring 5.1.4 Firewall 5.2 Hardware 6 Angriffe 6.1 php-spezifische Methoden 6.1.1 Cross Site Scripting 6.1.2 SQL Injection 6.1.3 Session Fixation 6.1.4 Session Hijacking 6.1.5 Cross Site Request Forgery 6.2 Allgemeine Methoden 6.2.1 Brute Force 6.2.2 Social Engineering 7 Vergleich gängiger Systeme 7.1 Vorgehensweise 7.2 Joomla! 7.2.1 Sicherheitseinstellungen 7.2.2 Ergebnis Penetration 7.3 Typo3 7.3.1 Sicherheitseinstellungen 7.3.2 Ergebnis Penetration 7.4 Drupal 7.4.1 Sicherheitseinstellungen 7.4.2 Ergebnis Penetration 8 Schlussbetrachtung 9 Fußnoten 10 Anhänge 10.1 Literatur- und Quellenverzeichnis 10.2 Rechtsquellenverzeichnis 10.3 Weitere Anhänge

1 Abkürzungsverzeichnis

Abkürzung	Bedeutung
CMS	Content Management System
HTML	Hypertext Markup Language
PDF	Portable Document Format
DBMS	Datenbank Management System
PC	Personal Computer
PHP	PHP: Hypertext Preprocessor
BDSG	Bundesdatenschutzgesetz
IT-Sicherheit	Informationssicherheit
EDV	Elektronische Datenverarbeitung
IT-System	Informationstechnisches System
OWASP	Open Web Application Security Project
TLS	Transport Layer Security
SSL	Secure Socket Layer
TCP/IP	Transmission Control Protocol/Internet Protocol
IETF	Internet Engineering Task Force
IPv6	Internet Protocol Version 6
HTTP	Hypertext Transfer Protocol
FTP	File Transfer Protocol
IDS	Intrusion Detection System
RAID	Redundant Array of Inexpensive Disks
DoS	Denial of Service
XSS	Cross-Site Scripting
XSRF	Cross-Site Request Forgery
CSRF	Cross-Site Request Forgery
URL	Uniform Resource Locator
SID	Session-ID
SQL	Structured Query Language
CSS	Cross-Site Scritping
TAN	Transaktionsnummer
WCMS	Web Content Management System

2 Abbildungsverzeichnis

Abb.-Nr.	Abbildung
1	Die drei Säulen des Content
2	Staging-CMS
3	Dynamisches-CMS
4	Funktionsweise SSL-V2 Protokoll
5	Ziel eines kombinierten Angriffs: PayPal
6	Ablauf einer Session Fixation
7	Screenshot Benutzerverwaltung(Joomla)
8	Screenshot "Site"-Einstellungen(Joomla)
9	Screenshot "System"-Einstellungen(Joomla)
10	Screenshot "Server"-Einstellungen(Joomla)
11	Screenshot Ergebnis(Joomla)
12	Screenshot TYPO3-Einstellungen(TYPO3)
13	Screenshot "SYS" (TYPO3)
14	Screenshot Ergebnis (TYPO3)
15	Screenshot Fehlermeldungen(Drupal)
16	Screenshot Benutzerverwaltung(Drupal)
17	Screenshot Zugriffsregeln(Drupal)
18	Screenshot Statusbericht(Drupal)
19	Screenshot Log(Drupal)
20	Screenshot Passworteingabe(Drupal)
21	Screenshot Ergebnis(Drupal)

3 Einführung

Mitte der 90er Jahre des letzten Jahrhunderts wurden eigene Internetpräsenzen für Unternehmen ein erforderlicher Imagefaktor. Vor Allem der immer schneller steigende Informationsfluss und damit einhergehende Anpassung der Internetseite erforderten einen immer größeren Aufwand, der zumeist nur von Leuten mit Expertenwissen, über den Aufbau der Internetseite und HTML (Hypertext Markup Language), ausgeführt werden konnte. Im Zuge dessen entwickelten die ersten Softwarehersteller CMS (Content Management Systeme), die es dem Benutzer ermöglichten unabhängig von HTML-Kenntnissen eigenen Inhalt online zu stellen. ^[1]

In den letzten Jahren hat sich gezeigt, dass das Internet immer häufiger der Ausgangspunkt für Attacken auf Systeme geworden ist. So stieg die Zahl der Straftaten, bei denen Daten ausgespäht oder abgefangen wurden von 2008 auf 2009 um 48,7%.^[2] Da CMS in der Regel direkten Zugriff durch das Internet bieten, liegt hier ein bedeutendes Gefährdungspotential vor, diesem kann man durch gewisse Einstellungen gegenüber treten, was das Thema dieser Abhandlung sein soll.^[3]

Zuerst erklären wir die Grundlagen zu unserer Hausarbeit, wobei wir vor allem darauf achten, dem Leser näher zu bringen, was ein CMS ist und was man in diesem Zusammenhang unter dem Begriff Sicherheit zu verstehen hat. Anschließend werden Aspekte abgehandelt, die man ergreifen kann, um sein CMS gegen unerwünschte Zugriffe abzusichern. Dies beinhaltet sowohl Möglichkeiten auf der Hard- sowie auf der Softwareseite. Darauf folgend werden einige Methoden erklärt, mit denen man gegen CMS vorgehen kann, da es in der Regel leichter ist sich gegen etwas zu schützen, das man kennt. Abschließend wollen wir die gewonnen Erkenntnisse einsetzen und testen drei gängige Open Source CMS auf die Sicherheitsmaßnahmen und stellen die Ergebnisse gegenüber.

4 Grundlagen

4.1 CMS

Ein CMS dient der Verwaltung von verschiedenen Information. CMS bieten die Möglichkeit sich verschiedene Inhalte unterschiedlich anzeigen zu lassen. So können Inhalte als Website, PDF (Portable Document Format) oder als Druckansicht angezeigt werden. Auch ermöglichen CMS die Zusammenarbeit an Dokumenten, da diese zentral verwaltet werden und so zum Beispiel häufiges versenden der selben Datei per E-Mail entfällt. Des Weiteren ermöglichen verschiedene Rollen eine klare Zuordnung zu bestimmten Aufgaben und erhöhen damit auch die Sicherheit, da jeder Nutzer im Idealfall nur die nötigen Rechte für sein Gebiet erhält.^[4]

CMS kann man in drei grundlegende Strukturen zerlegen. Den Content, das Management des Content und zu Grunde liegende Systeme.^[5]

4.1.1 Content

Im Allgemeinen versteht man unter Content eine optische Darstellung von Inhalten. Im Zusammenhang mit CMS reicht dies allerdings nicht, da sich für ein Programm, im Gegensatz zu einem Menschen, nicht allein durch eine Formatierung von Text in einer größeren Schriftgröße und fetter Schrift als Überschrift kund tut. Deswegen wurde die Dreiteilung in Struktur, Darstellungsform und Inhalt in CMS umgesetzt, um die automatische Weiterverarbeitung zu erleichtern.^[6]

Diese Teilung wird auch als die "Anatomie von Dokumenten"^[7] bezeichnet. Die Struktur beschreibt die inhaltliche Zuordnung und Abfolge der Einzelinformationen.^[8] So besteht dieser Artikel zum Beispiel aus unterschiedlich verschachtelten Überschriften, Bildern, Texten und Zitatverweisen. Die Darstellung enthält die Formatierungsgrundlagen zu den ihnen zugeordneten Strukturen, wobei die Darstellung für verschiedene Ausgabeformen hinterlegt sein kann, wie für eine HTML- oder eine PDF-Seite.^[8] So haben die einzelnen Überschriften in diesem Artikel verschiedene Schriftgrößen, ihrer Gliederungstiefe entsprechend. Außerdem sind verschiedene Formate hinterlegt, die zum Einen für die HTML- und zum Anderen für einen Offline-Ausdruck geeignet sind. Zu dem Inhalt wird ebenfalls, wie bei der Darstellung, die zugeordnete Struktur gespeichert^[8], wobei im Gegensatz zu der Darstellung, bei der mehrere Darstellungen einer Struktur zugeordnet werden, zu einer Struktur mehrere Inhalte gespeichert werden können.

4.1.2 Management von Content

Die zwei grundlegenden Hauptaufgaben eines CMS sind die Verlagerung des Einstellen des Contents von wenigen zentralen HTML-Fachleuten zu dezentralen Contentlieferanten und die Vereinfachung der Administrationsaufgaben durch ein einheitliches Grundmodell, dass mit wenigen Handgriffen angepasst werden kann. Durch die Dezentralisierung kann dafür gesorgt werden, dass der Informationsfluss erheblich beschleunigt wird und so die Aktualität einen höheren Grad erreicht. Ein wesentlicher Prozess im Content Management ist eine Benutzerverwaltung, die es ermöglicht den Nutzern genau die Rechte, Rollen und Gruppen zuzuweisen, die sie benötigen. So kann den Nutzern ermöglicht werden Texte zu erstellen, zu pflegen oder auch wieder zu löschen. Ebenso ermöglicht die Trennung von Benutzergruppen eine Qualitätssicherung, indem Texte nicht direkt veröffentlicht werden, sondern erst von einer Zwischeninstanz abgesegnet werden müssen. Ein weitere Funktion die CMS bieten ist die individuelle Einrichtung der Seitenstruktur, Navigationshilfen und Stylesheets, die durch das CMS den eingestellten Content wie gewünscht darstellen. Außerdem bieten CMS auch die Möglichkeit Teile der Steuerung der Systems zu automatisieren, wie das automatische archivieren oder Links auf ihre Konsistenz zu überprüfen.^[9]

4.1.3 Systeme

Die CMS-Architektur besteht zu einem aus einem Systemkern, der den Content und seine drei Elemente verwaltet. Die Daten können mit allen verfügbaren DBMS (Datenbank Management System) verwaltet werden. Dabei empfiehlt sich vor Allem eine objektorientierte Datenbank, da in ihr die Daten direkt, verlustfrei und wiederherstellbar gesichert werden können. Eine weitere Komponente dient der Veröffentlichung des Contents. Diese Server laufen in der Regel auf UNIX oder Windows Umgebungen. Dabei werden UNIX-Systeme bevorzugt bei CMS eingesetzt, bei denen mit einer hohen Frequentierung gerechnet wird und hohe Ansprüche an eine gute Performance gestellt werden. Die auf den Servern installierten CMS sind in vielen verschiedenen Programmiersprachen implementiert, wobei sich JAVA dabei besonders hervor tut, da es sich bei ihr um eine plattformunabhängige Sprache handelt. Auf Seite des Client genügt häufig ein PC mit einer installierten Browseranwendung.^[10] Bei den Open Source-Lösungen, wie zum Beispiel Joomla!, findet die Skriptsprache PHP (PHP: Hypertext Preprocessor) häufig im Zusammenhang mit dem Open Source DBMS mySQL Anwendung.^[11]

Staging Server bieten sich vor Allem für CMS an, deren Inhalte statisch sind oder nur in zyklischen Abständen aktualisiert wird. Dabei wird das CMS auf einem Publishing-Server verwaltet, auf dem über einen auf einem PC (Personal Computer) installierten Browser Änderungen vorgenommen werden können. In bestimmten Zeitabständen werden auf dem Publishing-Server statische HTML Seiten aus den Daten und den Templates erzeugt, die dann auf einen Web-Server exportiert werden. Der Leser kann eine Anfrage über einen Browser an den Web-Browser stellen und erhält die HTML Seiten angezeigt. Dieses System zeichnet sich durch hohe Performance aus. Wenn Inhalte sich häufig ändern oder Informationen aus anderen Systemen angezeigt werden sollen bietet sich entweder ein reines Live-System an oder eine Mischung aus beiden Systemen, bei dem nur die Informationen, die sich nicht ändern, statisch vorgehalten werden.^[12]

Bei Seiten deren Inhalt einer hohen Aktualisierungsrate unterworfen ist oder zu großen Teilen aus anderen Systemen generiert wird, empfiehlt sich ein reiner Live-Server, da so die Seite zeit aktuell mit den erforderlichen Daten generiert werden kann. Wenn ein Leser eine Seite über einen Browser aufruft wird eine Anfrage an einen Web-Server gestellt. Dieser stellt selber eine Anfrage an einen Applikation-Server, der sich die aktuellen Daten von einem DBMS holt und diese in die Templates einsetzt. Diese zusammengestellte Seite wird zurück an den Web-Server gesendet, der sie dann an den Leser weiter leitet. Änderungen des Inhalts der Seite werden über den selben Weg geleitet und dabei auf dem Datenbank-Server gespeichert.^[14] Bei den Open Source-Lösungen fällt der Applikation-Server aus der Systemlandschaft, da die Skriptsprache PHP auf dem Webserver diese Aufgabe übernimmt und somit auf dem Webserver die Informationen zusammengeführt werden können.^[11]

4.2 Sicherheit

4.2.1 Definition

Der Duden definiert Sicherheit wie folgt: "Si|cher|heit, die; -, -en [mhd. sicherheit, ahd. sichurheit]: 1. <o. Pl.> Zustand des Sicherseins, Geschütztseins vor Gefahr od. Schaden; höchstmögliches Frei sein von Gefährdungen: soziale, wirtschaftliche S.; die öffentliche S. und Ordnung[...]"^[16] An dieser allgemeinen Definition kann man erkennen, dass Sicherheit als ein Zustand der Abwesenheit von Gefahr beschrieben wird. Jedoch wird dies dadurch eingeschränkt, dass nur ein höchstmöglicher Grad erreicht werden kann, es also nie zu einer völligen Abwesenheit von Gefahren kommen kann.

Diese allgemeine Definition genügt für diese Ausarbeitung nicht. Der Begriff der IT-Sicherheit (Informationssicherheit), der sich hierfür mehr eignet, erstreckt sich über die vier Punkte der Vertraulichkeit, Authentizität, Datenintegrität und Verfügbarkeit.^[17] Vertraulichkeit ist dann gegeben, wenn die Daten nur von Personen und Systemen eingesehen werden können, die dazu berechtigt sind. Authentizität wird dann sicher gestellt, wenn der Empfänger sich sicher sein kann, dass er auch die Daten empfangen hat, die der Sender abgeschickt hat. Datenintegrität wird dadurch erreicht, dass sicher gestellt wurde, dass an den Informationen während der Übertragung keine Veränderungen vorgenommen wurden. Verfügbarkeit beschreibt, die gesicherte Funktionalität von Soft- und Hardware.^[18] Eine weitere mögliche Unterteilung ist die in Systemsicherheit und Kommunikationssicherheit. Dabei kennzeichnet die Systemsicherheit den Schutz von Hard- und Software vor Fremdzugriffen. Die Kommunikationssicherheit hingegen betrifft die Übertragung der Daten.^[17]

4.2.2 Grund für Sicherheit

4.2.2.1 Rechtliche Aspekte

Es gibt mehrere verschiedene Gründe sich um die Sicherheit seiner Systeme Gedanken zu machen. Zum Einen muss jeder Betreiber einer Datenverarbeitungsanlage, in der personenbezogene Daten gespeichert oder mit deren Hilfe solche erhobene werden, das BDSG (Bundesdatenschutzgesetz) beachten, sofern diese dem Deutschen Gesetz unterworfen sind.^[19] Insofern personenbezogene Daten erhoben, verarbeitet oder genutzt werden, ist der Betreiber verpflichtet technische und organisatorische Maßnahmen zu treffen, um diese zu schützen, solange der Aufwand in einem angemessenen Verhältnis zum angestrebten Schutzzweck steht.^[20] Der Betreiber muss sicherstellen, dass unbefugte keinen Zutritt zu den Datenverarbeitungsanlagen bekommen. Das BDSG verlangt ebenso, dass nach gehalten werden muss ob und wer Daten erstellt, verändert oder gelöscht hat. Für den Fall, dass die Daten im Auftrag erhoben oder verarbeitet werden muss gewährleistet werden, dass auch nur die Funktionen auf den Daten ausgeführt werden, die den Weisungen des Auftraggebers entsprechen. Des Weiteren müssen die Daten vor zufälliger Zerstörung oder Veränderung gesichert und solche die zu unterschiedlichen Zwecken erhoben wurden, auch getrennt verarbeitet werden. Außerdem dürfen unbefugte keinen Zugriff auf Daten erhalten beziehungsweise dürfen Berechtigte nur Zugriff auf Daten bekommen, die sie auch einsehen dürfen. Auch muss gesichert sein, dass die Daten bei der Übertragung weder gelesen, geändert, kopiert oder entfernt werden können und ihren Bestimmungsort erreichen. Bei den letzten drei Punkten ist dabei zu beachten, dass Verschlüsselungsverfahren nach dem Stand der Technik genutzt werden.^[21] Wenn diese Anforderungen nicht erfüllt werden, können Betroffene gegen den Betreiber Schadensersatzforderungen geltend machen, wenn sie dadurch Schaden erlitten haben, es sei denn es wurde mit der entsprechenden Sorgfalt gehandelt.^[22]

4.2.2.2 Wirtschaftliche Aspekte

Auch aus betriebswirtschaftlicher Sicht lohnt sich die Investition in die IT-Sicherheit, da die Verfügbarkeit der Systeme, die Integrität der Programme und Daten und die Vertraulichkeit der Daten heraufgesetzt wird. Dies senkt mit hoher Wahrscheinlichkeit die anfallenden Kosten durch eventuelle Schäden. Ein weiterer Effekt ist die Entstehung eines positiven Images, das zur Werbung bei Kunden genutzt werden kann, da sensible Daten gut gesichert sind und sich somit auch ein größerer Kundenkreis erschließen lässt. Ein höherer Sicherheitsstandard bewirkt ebenso eine bessere Absicherung des Firmen Know-hows gegenüber Konkurrenten, da wichtige Informationen besser gesichert sind. Durch eine bessere Verfügbarkeit der Systeme steigt auch das Vertrauen der Mitarbeiter in die EDV (Elektronische Datenverarbeitung).^[23] IT-Sicherheit spielt auch volkswirtschaftlich eine wichtige Rolle. So führen Schäden in der öffentlichen Verwaltung zu einer geringeren Effektivität und Effizienz in dieser. Wenn in großen Teilen der Wirtschaft Probleme mit der IT-Sicherheit hat dies einen starken negative Einfluss auf die Leistungsfähigkeit der Volkswirtschaft. Bei punktuell auftretenden Problemen in Branchen kann dies zu einer erhöhten Anzahl von Insolvenzen und somit steigender Arbeitslosigkeit führen. Durch ein höheres Vertrauen in die IT-Sicherheit ist eine größere Akzeptanz von digitalen Märkten erreichbar, wodurch diese stärker wachsen können, was für eine Volkswirtschaft in einer globalisierten Welt von existenzieller Bedeutung ist. In den 90ern des letzten Jahrhunderts zeigte sich, dass die Budgets der Unternehmen für IT-Sicherheit überproportional stiegen, was ein Wachstum der Sicherheitsbranche impliziert.^[24]

4.2.2.3 Potentielle Angreifer

Der IT-Sicherheit müsste nicht eine solch große Bedeutung bei gemessen werden, wenn es nicht Menschen gäbe deren Antrieb es ist einem zu Schaden. Ohne diese Menschen müsste man sich nur gegen Naturbegebenheiten, wie Brände absichern. Am Besten dürften für Angriffe auf IT-Systeme (Informationstechnisches System) die Geheimdienste verschiedenster Länder ausgerüstet sein. Nach Ende des Kalten Krieges suchten sich diese als neues Beschäftigungsfeld unter anderem das ausspionieren fremder Volkswirtschaften und somit auch der dazugehörigen Unternehmen. Durch die gute finanzielle Unterstützung der Geheimdienste durch ihre Regierungen und der dadurch resultierenden guten materiellen Ausrüstung, ist damit zu rechnen, dass diese verschlüsselte Daten in kürzester Zeit entschlüsseln können. Neben der von Nationen geförderten Spionage, gibt es auch Unternehmen, die Einheiten zur Spionage unterhalten. Diese Einheiten sind nicht so gut ausgestattet, wie ihre nationalen Pendants, aber dessen ungeachtet lohnt sich der Einsatz für die Unternehmen, um etwas über gegnerische Konzernstrategien, Unternehmensdaten oder Forschungsergebnisse zu erfahren. Meist aus eigenem Antrieb handeln Hacker, wobei diese in der Regel nicht an den Informationen interessiert sind oder dem Opfer finanziell schaden wollen. Ihre Motivation liegt darin Ruhm in der Szene oder in der Öffentlichkeit zu erlangen, indem sie die gefundenen Sicherheitslücken veröffentlichen. Dies ermöglicht auch technisch nicht so beschlagenen Anwendern die Lücke zu nutzen und somit erheblichen Schaden anzurichten. Softwareentwickler richten in ihren Programmen häufig Hintertüren ein, mit deren Hilfe sie das Programm testen oder Updates einspielen wollen. Unter Umständen können diese Schnittstellen auch dafür genutzt werden Zugriff auf das Programm zu erlangen und so auch auf die Daten. Administratoren haben durch ihre umfangreichen Rechte häufig leicht Zugang zu Informationen. Diese Rechte erlauben es ihnen auch ihre Taten so gut zu verschleiern, dass diese lange Zeit oder gar nicht aufgedeckt werden können. Mitarbeiter können versuchen mit ihren eingeschränkten Rechten ihrem Arbeitgeber Schaden zuzufügen, wenn sie mit diesem unzufrieden sind. Aber auch aus Neugier, Spieltrieb, Überlastung oder Langeweile können Mitarbeiter ungewollt erheblichen Schaden anzurichten. Zu guter Letzt können Hilfskräfte im Unternehmen durch ihren logischen Zugang zu Systemen, wenn sie zum Beispiel die Räume reinigen oder Informationen ins System eingeben sollen, Angriffe gegen das System fahren.^[25]

5 Sicherheitsmaßnahmen

5.1 Software

5.1.1 Grundlagen

Bei der Arbeit mit einem CMS, das in der Skriptsprache PHP geschrieben ist sollten einige wichtige Grundlagen beachtet werden. Zum Einen sollte die register_globals Einstellung auf off gesetzt werden, da dies geringen Mehraufwand bei der Programmierung fordert, aber im Gegenzug mehr Sicherheit bringt. Bei der Einstellung auf on können Variablen direkt über die Übergabe mit GET, POST oder COOKIE gesetzt werden. Durch das Ausstellen wird der Entwickler dazu gezwungen sich mehr Gedanken über sicheres Programmieren zu machen. Im selben Zuge sollten auch alle Variablen zu Beginn initialisiert werden, da dies das Risiko ebenfalls senkt. Ein weiterer wichtiger Aspekt ist, das alle von außen eingehenden Daten gefiltert werden sollten. Die erste Möglichkeit dafür ist das Verwenden einer Dispatch-Datei. Diese ist die einzige von Außen zugängliche Datei und bindet alle anderen Dateien, nach Überprüfung der für den Seitenaufruf entscheidenden Daten, ein. Bei einer nicht-konformen Eingabe wird diese ignoriert und eine Standardanzeige generiert. Bei der Include-Methode wird der umgekehrte Weg gegangen. Dort bindet jede Skriptdatei die Include-Datei mit einer Whitelist, die alle korrekten Eingaben implementiert hat, ein. Diese beiden Möglichkeiten sollten nicht nur zur Überprüfung von Informationen zu Seitenaufrufen, sondern bei allen Übergaben gemacht werden, bei denen dies möglich ist. So sollte bei Zahleneingaben nur Zahlen zugelassen werden oder bei E-Mailadressen nur Kombinationen, die auch zu solchen passen. Dabei sollte man lieber in Kauf nehmen eine gültige Eingabe abzulehnen als eine ungültige zuzulassen. PHP bietet auch ein Error-Reporting an. Dies sollte man während der Entwicklung auf E_ALL einstellen, um jeglichen Fehler und jede Warnung mitgeteilt zu bekommen. Dies sollte man allerdings bei den Skripten ausstellen, die online gestellt werden, da potentiellen Angreifern Schwachstellen oder empfindliche Daten, wie die Zugangsdaten zu der Datenbank, mitgeteilt werden könnten. An dieser Stelle empfiehlt es sich hingegen eine Logdatei mitschreiben zu lassen, um über auftretende Probleme trotzdem unterrichtet werden zu können.^[26] Ein weiteres Kriterium was man beachten sollte, um die Sicherheit zu erhöhen, ist die Vorhaltung der Informationen für den Datenbankzugriff. Häufig werden die Daten in einer .inc im Dokumentpfad abgelegt. Problematisch ist dies daher, dass viele Server eine .inc als Klartext anzeigen. Um diesen Problem zu entgehen sollte die Datei außerhalb des Dokumentpfades abgespeichert werden mit einer .htaccess Datei, die Zugriff von außen völlig untersagt.^[27]

Im Allgemeinen sollte auch beachtet werden, dass relevante Daten regelmäßig nach dem 3-Generationen-Prinzip gesichert werden sollten. Dies hat den Vorteil, dass bei beschädigten Sohn-Daten die Vater-Daten eingespielt werden können und noch die Großvater-Daten als Sicherung bereitstehen, falls die Vater-Daten bereits inkonsistent sind. Ebenfalls sollten Passwörter verwendet werden, die nicht zu erraten sind und diese sollten ebenfalls häufig gewechselt werden.^[28]

5.1.2 Secure Socket Layer/Transport Layer Security

Das TLS-Protokoll (Transport Layer Security Protokoll) wurde ursprünglich als SSL-Protokoll (Secure Socket Layer), das auf TCP/IP (Transmission Control Protocol/Internet Protocol) aufsetzt, von der Firma Netscape bis 1996 entwickelt und betreut. Anschließend wurde das Protokoll in seinen heutigen Namen TLS umbenannt und von der IETF (Internet Engineering Task Force) übernommen. Seit 1999 gilt TLS als offener Internet-Standard und soll auch standardmäßig zum IPv6-Stack (Internet Protocol Version 6-Stack) gehören. TLS arbeitet in der Transportschicht von TCP/IP und ergänzt die Übertragung um die Sicherheitsaspekte von Integrität, Vertraulichkeit und Authentizität. Ein weiterer Vorteil, der sich dadurch ergibt, ist die Nutzung von mehreren verschiedenen Anwendungsprotokollen, wie HTTP (Hypertext Transfer Protocol) oder FTP (File Transfer Protocol), die Anwendung bei öffentlichen Netzen finden. TLS soll die zu übertragenden Daten sicher durch das öffentliche Netz bringen. Dazu verwendet es sowohl symmetrische wie auch asymmetrische Kryptographie-Verfahren. Netscape implementierte TLS mit der Absicht dem Nutzer einen Weg zu bieten, der eine weitgehend sichere Verbindung schafft, ohne dass er sich dabei um Details kümmern muss. Da TLS mittlerweile eine hohe Verbreitung bei Webbrowsern und Webservern erreicht hat stellt dies kein Problem dar. Folgend soll die Funktionsweise von TLS erläutert werden, wie sie in Abbildung 4 aufgezeigt wird. Dabei ist zu beachten, dass dies Version 2 darstellt. Die aktuelle Version 3 arbeitet nach dem selben Prinzip nur sind einige Schritte zusammengelegt worden, wodurch das Protokoll komplexer geworden ist. Zu Beginn sendet der Browser eine sogenannte "Client-Hello"-Nachricht, die einen Einmalwert und eine Liste mit allen möglichen Verschlüsselungsverfahren enthält. Der Server antwortet mit einer "Server-Hello"-Nachricht, die ein digitales Zertifikat des Servers, eine Connection-ID und eine Liste der Verschlüsselungsverfahren enthält, die er beherrscht. Der Browser überprüft die Echtheit des Zertifikats und entscheidet sich für ein Verschlüsselungsverfahren. Anschließend verschlüsselt er mit dem öffentlichen Schlüssel des Servers einen zufällig erzeugten Master-Key und übermittelt diesen mit der "Client-Master-Key"-Nachricht an den Server. Aus dem Master-Key, der Connection-ID, dem Einmalwert und anderen Daten, die aus der Verbindung hervor gehen, wird mithilfe einer Hash-Funktion ein Sitzungsschlüssel, ein Write-Key und ein Read-Key errechnet. Da der Server und der Klient die selben Informationen haben und die einzigen sind, die diese kennen, ist sichergestellt, dass nur diese Beiden miteinander über diesen Kanal kommunizieren können. Der Browser verschlüsselt die Connection-ID mit dem Write-Key und sendet diesen mit der "Client-Finish"-Nachricht an den Server. Dieser macht das selbe mit dem Einmalwert. Durch das entschlüsseln der Werte auf der anderen Seite kann überprüft werden, ob bei der Übertragung alles glatt gelaufen ist und auf der anderen Seite auch der Richtige steht. Zum Abschluss sendet der Server eine verschlüsselte Session-ID in der "Server-Finish"-Nachricht. Ab da können Server und Browser über einen gesicherten Kanal miteinander kommunizieren.^[29]

5.1.3 Monitoring

Um zu bemerken, ob am eigenen System Veränderungen von Innen heraus vorgenommen wurden, kann man ein IDS (Intrusion Detection System) installieren. Diese Systeme überwachen bestimmt Bereiche und setzt eine Meldung ab, wenn es unerlaubte Aktionen bemerkt. IDS können zum Beispiel so eingestellt werden, dass dauerhaft den Netzwerkverkehr, die Protokolldateien oder Änderungen im Dateisystem überwacht. Dabei sucht das Programm nach Mustern, die typisch für spezielle Angriffe sind, so wie Virenprogramme nach bestimmten Mustern bei Viren suchen. Die Reaktionen des IDS können von einfacher E-Mail-Benachrichtigung des Administrators bis zu speziellen Gegenmaßnahmen, wie der Beendigung von Diensten oder Veränderungen an den Konfigurationen, reichen. IDS bieten, wie jedes andere Sicherheitssystem, allerdings keinen vollkommenen Schutz, da sie zum Einen selbst Ziel des Angriffes sein können oder die Angreifer ihre Angriffsmuster so anpassen, dass das IDS es nicht mehr erkennen kann. Dies kann durch eine zeitliche Streckung des Angriffes oder eine Verteilung der einzelnen Komponenten des Angriffes auf verschiedene Ausgangspunkte, sodass jede einzelne Aktion harmlos erscheint, erreicht werden.^[31]

Ein solches Tool ist zum Beispiel PHPIDS^[32]. Mit ihm kann man sich zum Beispiel gegen Cross-Site-Scripting oder SQL-Injections (Structured Query Language) schützen. Es empfiehlt sich zu Beginn des Einsatzes des Tools erst einmal mögliche Angriffe protokollieren zu lassen, um festzustellen ob man selber überhaupt in der Schusslinie steht. Falls dies der Fall ist lassen sich Routinen anlegen, die auf Angriffe so reagieren, dass zum Beispiel die Angreifer IP-Adresse für den Zugriff auf die Seite gesperrt wird. Das IDS lässt sich mit wenigen Handgriffen einbinden, wobei es sich empfiehlt die Anwendung selber nicht in das Wurzelverzeichnis des Webservers abzulegen, da so es so von außerhalb erreichbar wäre und unnötig Angriffsfläche bietet.^[33]

5.1.4 Firewall

Firewalls kontrollieren jedes ein- und ausgehende Paket an Netzwerkschnittpunkten, ob diese das Netzwerk betreten oder verlassen dürfen. Die verkehrenden Pakete enthalten die Adressen von Absender- und Zielrechner, Dienstnummern der beteiligten Programmen und welches Protokoll zum Transport genutzt wird. IP-Pakete mit den selben Adressinformationen, die als Identifikationsmerkmal dienen, gehören zu einer Session. Es kann zwischen zwei Arten von Firewalls unterschieden werden. Der Paketfilter zieht für die Entscheidung, ob ein Paket passieren darf, allein die Adressinformationen heran. So kann eingestellt werden, ob bestimmte Rechner, Subnetze oder Programme Zugriff erhalten oder verweigert bekommen. Ein Anwendungs-Gateway steht als Stellvertreter für einen Server oder Dienst eines Servers zwischen dem internen Netzwerk und dem Internet. Wird eine Anfrage an den Server gestellt. Wird eine Verbindung zum Gateway aufgebaut, der die übermittelten Daten analysiert und nur weiterleitet, wenn diese unbedenklich sind. Der Vorteil des Gateway gegenüber dem Paketfilter ist der, dass ein Paketfilter nicht das Konzept einer Sitzung betrachtet und somit nicht wie das Gateway logisch zusammenhängende Daten erkennt. Dies ist aber ebenso Nachteil des Gateway, da für jeden behandelten Dienst ein Stellvertreterdienst auf dem Firewall-Rechner aktiv sein muss und dieser noch eine Adressumwandlung durch die völlige Abtrennung des Netzwerks vollziehen muss. Dies führt zu Verzögerungen in der Bearbeitung und einem höheren Wartungsaufwand. Im Gegensatz dazu ist der Paketfilter relativ wartungsarm, wenn er einmal aufgesetzt ist.^[34]

5.2 Hardware

Bei der Hardware muss darauf geachtet werden, dass die Server in gesicherten Räumen untergebracht werden, sodass diese vor Wasser und Feuer geschützt sind. Außerdem muss sichergestellt werden, dass unbefugte Personen kein Zugang gewährt wird. Sicherungskopien sollten räumlich getrennt von den Originaldaten gelagert werden und dabei vor magnetischen und elektrischen Feldern geschützt sein.^[28]

Um die Ausfallsicherheit der Festplatten zu erhöhen empfiehlt sich die RAID-Technik (Redundant Array of Inexpensive Disks). Durch die Verwendung von vielen preiswerten kleineren Standardplatten werden die Kosten gesenkt, weil dort billige Standardware und nicht teure spezial Hardware verwendet werden kann, und gleichzeitig die Datentransferrate und die Ausfallsicherheit erhöht. Da RAID-Architekturen parallel aufgebaut sind können sie die Auftragslast untereinander besser aufteilen, was vor Allem die Antwortzeiten bei Datenbanken verkürzen kann. Zum Einsatz kommen von zwei bis mehreren Hundert Einzelfestplatten, die für den 24 Stunden Dauereinsatz ausgelegt sind und auf die anfragenden System wie eine große, schnelle Festplatte reagieren. Es gibt acht verschiedene RAID-Standards. Bei RAID-0 werden keine Daten redundant gehalten. Dort werden die Datenblöcke einfach nur auf mehrere Kanäle und Laufwerke verteilt. Kommt es zu einem Defekt sind alle Daten unwiederbringlich verloren, dafür ist die Konstellation am kostengünstigsten und am performantestens. RAID-1 ist im Gegensatz dazu relativ teuer, aber extrem sicher, da alle Informationen gespiegelt werden und auf einer zweiten Platte gesichert werden. Fällt eine Platte aus kann ohne Zeitverlust auf die andere Platte umgestellt werden und keine Informationen sind verloren gegangen. Bei RAID-3 werden die Daten parallel auf mehreren Laufwerken gespeichert und auf einem weiteren Laufwerk Paritätsinformationen. Durch die Paritätsinformationen, die entweder auf Bit- oder Byte-Basis die Summe aller anderen Laufwerke im gleichen Block darstellt, kann bei Verlust eines Laufwerks dieses mit den anderen Informationen wieder hergestellt werden. Dabei entstehen Ausfallzeiten, es sei denn bei dem ausgefallenen Laufwerk handelt es sich um das mit den Paritätsinformationen. RAID-3 eignet sich vor allem bei Anwendungen bei denen wenige große Daten gespeichert werden müssen, da beim Schreiben und Lesen sich alle Arme der Festplatten gleichzeitig bewegen müssen und dadurch eine hohe Datendurchsatzrate zustande kommt, aber ein paralleles Abrufen von verschiedenen Daten nicht möglich ist. Für große Datenbanken empfiehlt sich eine Architektur nach RAID-5 mit hohem Durchsatz bei Transaktionsverarbeitung, da sich die Arme unabhängig voneinander bewegen können. Dies wird dadurch erreicht, dass auf die Festplatte mit den Paritätsinformationen verzichtet wird und diese auf alle Platten aufgeteilt werden.^[35]

6 Angriffe

6.1 php-spezifische Methoden

6.1.1 Cross Site Scripting

XSS (Cross Site Scripting) und immer öfter auch CSS (nicht zu verwechseln mit Cascading Style Sheets), ist eine sehr gefährliche Angriffsmethode, die unabhängig von einer bestimmten Plattform oder eines bestimmten Browsers eingesetzt werden kann.^[36]Ziel eines Angriffs mittels XSS, ist nicht etwa ein Angriff auf einen bestimmten Server, um sich Zugang zu verschaffen, sondern vielmehr der Angriff auf einen einzelnen Web-Client, beziehungsweise Website-User. Bei diesem Angriffsverfahren möchte der Angreifer, meist mit Hilfe eines manipulierten Links, der vom Benutzer angeklickt wird, eine Sicherheitslücke einer Webanwendung einer dynamischen Seite ausnutzen und sensible Daten sammeln.^[37]

Bei den PHP-spezifischen Angriffsvarianten gibt es mittels Cross Site Scripting mehrere Methoden, die genutzt werden um einen Angriff auszuführen. Als Beispiel dient uns die "reflected injection" und die "persistent injection". Die erste Variante, die "reflected injection", ist die an sich simpelste Methode, um einen Angriff zu starten. Der Benutzer klickt dabei auf einen extra angefertigten Link und ruft somit aktiven Inhalt einer Website auf. Diese Links enthalten meist JavaScript Code, der nun genau wie der normale Link, mit an den Webserver gesendet und ausgeführt wird. Diese Links werden meistens verschlüsselt, da ansonsten der angehängte Script Code sehr leicht auffallen würde. Im Jahr 2006 kam es zu einer besonderen XSS Attacke, die Hand in Hand mit einer versuchten Phishing Attacke einher ging. Hacker schickten ausgewählten PayPal-Kunden eine typische Phishing Mail, mit einem Link, der tatsächlich auf eine original https-verschlüsselte PayPal-Seite führte. Da diese Seite aber XSS anfällig war, tauschten die Hacker kurzer Hand eine Variable, die für den Ausgabetext der Seite zuständig war mit dem Text "Your account is currently disabled because we think it has been accessed by a third party. You will now be redirected to Resolution Center.". Von dort wurden sie auf eine Seite weitergeleitet, die in der Gewalt der Angreifer lag. Dort gaben die Opfer nun ohne Bedenken ihren Usernamen und ihr Passwort ein. Schließlich kam man ja von einer per https-gesicherten original PayPal-Seite. Dies zählt zu einem der ausgeklügelsten und gefährlichsten Angriffe. Die Kombination aus Phishing-Mail und XSS-Attacke einer so großen Seite war ein tödliche Mischung.^[38]

Der Begriff "reflected" (oder zu Deutsch reflexiv) lässt sich darauf zurückführen, dass der Schadcode nur temporär ausgeführt wird, wenn der Nutzer beispielsweise einen gefälschten Link folgt. Er ist nicht beständig.

So aber die zweite Variante: die "persistent injection" (oder persistente Injektion). Dort versucht der Angreifer, seine schädlichen Inhalte direkt in die Datenbank oder das Filesystem der entsprechenden Präsenz ab zu speichern. So werden die vom Angreifer „eingepflegten“ Inhalte jedem Benutzer, der den infizierten Bereich besucht, angezeigt beziehungsweise zur Ausführung gebracht.

Bei den Cross Site Angriffen nutzt der Angreifer es also aus, dass bestimmte Eingaben nicht ausreichend geprüft werden, bevor sie als dynamische Seite an den Benutzer zurückgegeben werden. Um sich vor solchen Angriffen mittels XSS zu schützen gibt es einige grundlegenden Punkte, die beachtet werden sollten: Alle Daten, die von externen Quellen übermittelt werden, (das heißt, im Internet jede einzelne Seite die aufgerufen wird) sollte vor einer weiteren Verwendung abgeglichen und überprüft werden. Außerdem sollten Inhalte stets mit einer so genannten „Whitelist“ abgeglichen werden. Nur die Inhalte, die auf so einer Liste erfasst wurden, sollten als vertrauenswürdig eingestuft werden. Alles andere sollte bis zu einer genauen Überprüfung geblockt werden.^[40]

6.1.2 SQL Injection

SQL-Injection bedeutet so viel wie das Einschleusen von SQL-Code. Es geht aber hier nicht wie beim XSS um den Angriff auf einen einzelnen Webseitenbenutzer, sondern diese Art von Angriff wird verwendet, um die Datenbank eines Webservers anzugreifen und SQL-Code einzuschleusen. Falls es dem Angreifer gelingt seinen Code zu übertragen, hat er danach mehrere Möglichkeiten. Im besten Fall kann er mit seinem Code einfach nur Schaden in der Datenbank anrichten. Das Worst-Case-Szenario sehe so aus, dass der Angreifer durch seinen Code nun Zugriff auf private und geschützte Daten hätte.

Obwohl die Angriffsabsichten sich vom XSS unterscheiden, ähneln sich die Angriffe aber dennoch. Bei beidem besteht das Problem, dass Daten unverändert an den Webserver weitergeleitet werden, ohne sie vorher zu verschlüsseln oder zu überprüfen. „Werden die dort eingegebenen Daten einfach ungefiltert an die Datenbank weitergegeben, dann ist die Datenbank per SQL-Injection angreifbar.“^[41] Dies kann zum Beispiel durch einfache Eingaben in ein Loginformular auf einer Internetseite passieren. Das heißt, durch gezielte Eingaben per SQL in ein einfaches Formular, kann es geschehen, dass eine Datenbank per SQL-Injection angegriffen und infiziert wird. Hat ein Angreifer eine Seite gefunden, die SQL-Injection zulässt bestehen sehr große Gefahren, die darauf hinauslaufen können, dass mit wenigen Befehlen ganze Datenbanktabellen gelöscht werden können. Die Auswirkungen wären für große Firmen verheerend. Deshalb sollte besonders darauf geachtet werden diese Angriffsfläche erst gar nicht zu zulassen. Setzt sich eine Website beispielsweise aus PHP zusammen, lässt sich dieses Problem mit einer einzigen Funktion lösen. Der Befehl lautet „mysql_escape_string“.^[40] Werden „alle Parameter, die aus Anwendereingaben stammen und in den Querystring eingehen, mit dieser Funktion escapet“^[41], ist die Internetseite (auf PHP-Basis) gegen SQL-Injections geschützt.

6.1.3 Session Fixation

Frei übersetzt heißt Session Fixation so viel wie fixierte Sitzung. Dabei ist es wichtig zu wissen, dass eine Session, eine aufgebaute Verbindung zwischen Client und Server darstellt. Normalerweise gibt es bei Protokollen, wie beispielsweise HTTP keine stehenden Verbindungen, so wie sie das Wort Session beschreiben würde. Ein Client fordert eine Seite an und die Seite wird vom Webserver geliefert. Der Client lässt sich so aber nicht eindeutig identifizieren. Da es aber immer öfter vorkommt, dass Client und Server sich während einer Sitzung (Session) kennen müssen (zum Beispiel beim Online Banking), um zu interagieren, wurden Sessions eingeführt. Sessions ermöglichen die Speicherung einer Webanwendung während der aktuellen Sitzung. Die Idee der Sessions hat zwar große Vorteile mit sich gebracht, ist aber auch sehr angreifbar. Das Problem liegt wieder einmal im PHP-Bereich. Leider akzeptiert PHP jede beliebig übermittelte Session-ID. Das heißt, dass eine Session-ID von einem Angreifer benutzt werden kann, um diese zu fixieren. Einfacher gesagt: Der Angreifer denkt sich eine beliebige Session-ID aus und versucht nun diese seinem Opfer irgendwie zukommen zu lassen, damit dieser die übermittelte SID benutzt und sich anmeldet. Danach kann der Angreifer eine Adresse mit der gleichen SID aufrufen und hat somit vollen Zugriff auf alle Funktionen einer Webanwendung des Nutzers, der seine Anmeldung mit der fixierten SID vorgenommen hat. Ein kleines Beispiel an Hand eines Online Banking Logins soll dies noch einmal verdeutlichen: Der Angreifer schickt einen präparierten Link (zum Beispiel per Mail) mit der fixierten SID an sein Opfer. Nun ruft das Opfer den präparierten Link auf, ohne zu wissen, dass die SID vom Angreifer fixiert wurde. Als nächstes loggt sich das Opfer mit seinen privaten Anmeldedaten ein. Nun kann der Angreifer mit der von ihm selbst präparierten Session-ID auf die Session des Opfers zugreifen und hat somit vollen Zugriff auf das Konto und den Kundenbereich im Online Banking System, des jeweiligen Institutes. Da heutzutage zum Online Banking TAN (Transaktionsnummer) Nummern verwendet werden, könnte es sein, dass der Angreifer vorher schon das leichtfertige Opfer mit einer Phishing-Mail einige TAN‘s entlocken konnte. Somit wäre der Hack eines Online Banking Systems eines beliebigen Kunden perfekt.^[42]

6.1.4 Session Hijacking

Session Hijacking beschreibt eine, wie das Wort Hijacking schon sagt, Entführung einer Session-ID. Warum eine gültige Session-ID für einen Angreifer nützlich sein kann, wurde in dem oberen Beitrag zu Session Fixation schon erläutert. Es gibt nun mehrere Möglichkeiten, um eine Session-ID zu entführen. Hier werden zwei Methoden vorgestellt. Die erste ist das sogenannte Session Sniffing. Dabei nutzt der Angreifer ein Werkzeug, dass Sniffer genannt wird. Ein Sniffer (engl. für riechen, schnüffeln) ist ein Netzwerkanalysetool, um Datenverkehr eines Netzwerkes zu empfangen und aufzuzeichnen. Mit Hilfe eines Sniffers hat der Angreifer also die Möglichkeit, sich zwischen dem Opfer und dem Webserver zu platzieren, um so den Netzwerkverkehr aufzuzeichnen und die übermittelte Session-ID zu entführen. Wurde die SID mittels Sniffer protokolliert, kann der Angreifer die SID nutzen, um den Webserver mit der entführten SID zu täuschen. Der Server geht davon aus, dass die SID noch immer vom autorisierten Nutzer kommt. Eine weitere Möglichkeit eine SID zu entführen wäre eine Cross-site Script Attacke. Diese Art von PHP-spezifischer Attacke wurde bereits auch in einem oberen Beitrag erläutert. Nun ist es also möglich mit Hilfe einer Cross-site script Attacke auf dem Client mit einem einfachen Befehl, die SID zu entführen. Ein Beispiel für eine solche clientseitige Attacke wäre: „alert(document.cookie);“. Dieser einfache Code gibt dem Angreifer auf schnelle Art und Weise durch das Auslesen des Cookie die Session-ID zurück.^[44]

6.1.5 Cross Site Request Forgery

Das CSRF (Cross Site Request Forgery) unterscheidet sich in einem Punkt komplett vom XSS. Beim XSS vertraut der Benutzer dem Webbrowser und geht davon aus, dass die dargestellten Inhalte sicher sind. XSS nutzt also das Vertrauen der Benutzer aus, um Angriffe zu starten. Beim CSRF ist es im Prinzip genau umgekehrt. Der Webbrowser vertraut darauf, dass der Benutzer weiß was er tut und nimmt die Anfragen an, so wie sie kommen.^[45]

Wir versuchen CSRF an Hand eines einfachen Beispiels zu erklären. Jeder Internetnutzer kennt mittlerweile das Tab-Browsing. Das heißt, das Surfen im Browser auf mehreren Seiten gleichzeitig, obwohl nur ein Programm geöffnet ist. Die Seiten werden dabei, in so genannten Tabs dargestellt. Nehmen wir nun einmal an, dass ein beliebiger Internetnutzer ein Tab öffnet, um sich bei einem der vielen Dienste, wie zum Beispiel Ebay, Facebook, Xing oder ins VZ Netzwerk einzuloggen. Bei der Anmeldung werden nun Cookies gespeichert, die Sitzungsdaten und Anmeldedaten enthalten. Daran ist bisher nichts auszusetzen, so lange der Nutzer sich nicht auf einer XSS oder CSRF anfälligen Seite befindet. Als nächstes surft der Nutzer aber eine CSRF "verseuchte" Seite an. Das heißt konkret, dass auf dieser Seite beispielsweise ein Bild eingebettet ist, dass folgenden Code beinhaltet: "<img src=”http://www.xing.com/app/message?op=sendmessage&recipient=MaxMustermann&body=Viagra+For+Free”>". Dies wäre ein Beispiel dafür, dass falls der Nutzer sich vorher bei XING angemeldet hat und nun die CSRF Seite besucht, eine Nachricht an Max Mustermann schickt mit dem Titel "Viagra for free". Dies passiert alles vollautomatisch und ohne, dass der Nutzer es merkt, da das Bild mit dem eingebetteten Code vom Browser einfach mit geladen wird und somit der Code ausgeführt wird. Das Problem besteht, da alle Tabs trotzdem auf die gleichen Cookies zugreifen. Wenn ein neuer Tab geöffnet wird, und XING aufgerufen wird, ist der Benutzer immer noch eingeloggt. Man erkennt sofort, die Gefahr des CSRF. Mit dieser Methode lassen sich sehr viele Operationen ausführen, ohne das der Benutzer auch nur etwas mit bekommt. Natürlich ist so etwas auch bei Banken möglich, die nicht gegen CSRF ab geschützt sind. Das heißt, es lassen sich per CSRF Überweisungen tätigen und der Nutzer merkt es erst, wenn der Kontostand auf einmal sehr viel kleiner ist, als noch vor 2 Minuten. Zuletzt soll noch gesagt werden, dass XING natürlich auch vor CSRF geschützt ist.^[46]

6.2 Allgemeine Methoden

6.2.1 Brute Force

Hat ein Angreifer keine Sicherheitslücke gefunden, um in ein System einzudringen, bleibt immer noch die Methode roher Gewalt. Dieser Angriff nennt sich Brute Force Attacke. Bei dieser Art von Angriff werden mit roher Gewalt alle Schlüsselkombinationen durchprobiert, bis die richtige Kombination gefunden wurde. Die einzige Möglichkeit sich gegen solch einen Angriff zu schützen besteht darin, ein Passwort zu wählen, was lang genug ist und aus verschiedenen Zahlen, Buchstaben und Zeichen besteht. Je sicherer das Passwort, desto größer ist der Aufwand. Ist das Passwort stark genug wird sich der Aufwand zum knacken via Brute Force (gemessen in Zeit und Geld) nicht lohnen. Viele Brute Force Knacker arbeiten, bevor sie die tatsächlich rohe Gewalt anwenden, mit sorgfältig zusammengestellten Passwortlisten. Das Programm geht die gesamte Liste durch und prüft, ob womöglich eines der Passwörter mit dem richtigen Passwort übereinstimmt.^[47]

6.2.2 Social Engineering

Social Engineering (engl. für angewandte Sozialwissenschaft) ist eine sehr gefährliche und meistens erfolgreiche Methode, um Informationen zu beschaffen, ohne auf technische Hilfsmittel zurückgreifen zu müssen. Der Angreifer nutzt dabei die Gutmütigkeit, beziehungsweise „den Glaube an das Gute im Menschen“ aus. Es gibt viele Wege und Möglichkeiten, um durch Social Engineering an private Informationen zu kommen. Oft wurde schon davon berichtet, das so genannte „Kundenbetreuer“, besonders bei älteren Menschen per Telefon angerufen haben und den Gesprächspartner zunächst freundlich begrüßten. Haben die Opfer erst einmal Vertrauen gefasst und kaufen dem Angreifer ab seriös zu sein, können fast alle Arten von Informationen gesammelt werden. Oft wird den Opfern erzählt, es ginge um Aktualisierungen im System und dazu benötige man die aktuellen Anmeldedaten der Kunden. Unwissende Kunden geben so, ohne die geringsten Befürchtungen, ihre sensiblen Daten per Telefon weiter. Je öfter so ein Betrugsversuchs an die Oberfläche gekommen ist, desto intensiver warnten die Institute (vor allem Banken) davor, sensible Daten am Telefon weiterzugeben. Ein sehr beliebter Satz der großen Unternehmungen, die ihre Kunden in E-Mails warnen klingt in etwa so: „Unsere Mitarbeiter werden sie nie telefonisch nach Ihrem Passwort oder anderen sensiblen Daten fragen!“. Doch Social Engineering spielt sich nicht nur am Telefon ab. Genauso gut ist es möglich, das Menschen sensible Informationen in der Kneipe oder Ähnlichem ausplaudern. So wurden sie noch nicht einmal nach Informationen gefragt; sie geben sie ganz alleine preis. Um erfolgreich einen Angriff durch Social Engineering durchzuführen, ist eine sehr gründliche und detaillierte Vorarbeit notwendig. Der Angreifer muss wissen, welche fragen er stellen muss, damit er die gewünschten Informationen so schnell und so genau wie nur möglich bekommt. Ist so ein Angriff gut geplant und weiß der Angreifer, wie er sich verhalten muss, ist ein Erfolg vorprogrammiert. Je höher die sozialen Kompetenzen des Angreifers, desto größer ist die Wahrscheinlichkeit auf Erfolg.^[48]

7 Vergleich gängiger Systeme

7.1 Vorgehensweise

Bei der Durchführung von Tests an IT-Systemen sollte man von allen an diesem IT-System Beteiligten deren Zustimmung einholen, da das Ausspähen^[49], Abfangen^[50] von Daten und selbst nur die Vorbereitung^[51] unter Strafe gestellt wird. Sollten Daten im System verändert oder das System selber außer Betrieb gesetzt werden kann dies auch als Computersabotage geahndet werden.^[52] Aus diesen Gründen haben wir uns dafür entschieden diese Tests nur auf eigenen Servern durchzuführen, da so nur wir selber betroffen sind und die vorangegangenen Punkte nur auf Antrag verfolgt werden, es sei denn es besteht ein besonderes öffentliches Interesse an der Verfolgung.^[53] Zu Beginn wollen wir erst die Sicherheitseinstellungen darstellen, die die CMS von sich aus anbieten. Anschließend wollen wir die CMS mit eine Penetrationstool auf weitere Sicherheitsvorkehrungen testen. Als Tool zur Penetration haben wir uns für die Live CD^[54] des OWASP (Open Web Application Security Project) entschieden. Als Tool für den Penetrationstest entschieden wir uns für w3af, da dieses ein stark automatisiertes Verfahren anbietet und über eine große Bandbreite verschiedenster Tests verfügt. Auf Grund dieser Vielfalt verschiedenster Möglichkeiten wollten wir die verschiedenen Systeme auf die zehn gefährlichsten Sicherheitslücken testen. Als Nummer eins Sicherheitsrisiko wurde 2010 in Injections definiert. Dies sind Anweisungen, die in Befehlen oder Querys versteckt sind und den Interpreter dazu veranlassen ungewollte Befehle auszuführen oder Informationen frei zu geben. An zweiter Stelle rangiert XSS bei dem eine ungesicherte Verbindung ausgenutzt wird und beim Browser des Client unerwünschte Befehle ausgeführt werden, um ein Session hijacking zu Betreiben, Veränderungen an der Website vorzunehmen oder den Nutzer auf eine andere Website weiterzuleiten. Mit Hilfe von fehlerhaft implementierten Funktionen, die mit der Authentifizierung oder dem Session Management zu tun haben, können Angreifer Informationen erlangen, die dazu genutzt werden können die Identität des Nutzers zu übernehmen. Wenn der Programmierer direkte Verweise auf Objekte, wie Dateien oder Ordner, genutzt hat und diese nicht vor Aufruf auf deren Konsistenz überprüft, kann ein Angreifer dies Nutzen und den Verweis so umschreiben, dass dieser auf unautorisierte Daten zeigt. Beim XSRF (Cross-Site Request Forgery) wird der Browser eines eingeloggten Nutzers dazu gezwungen eine HTTP-Anfrage zu stellen, die alle notwendigen Informationen enthält, um sich am System anmelden zu können. Ein weiteres Problem sind schlecht konfigurierte Sicherheitseinstellungen an Server, Datenbank, CMS und so weiter. Dazu gehört auch alles auf dem neuesten Stand zu halten. Häufig sind sensitive Daten vom System auch nur unzureichend geschützt, sodass diese für kriminelle Aktionen missbraucht werden können. An achter Stelle wird aufgelistet, dass Seiten in geschützten Bereichen jedes Mal überprüfen müssen, ob der Zugriff erlaubt ist, da sonst möglicherweise die URL (Uniform Resource Locator) erraten sein könnte. Nicht selten ist auch die Transportschicht unzureichend gesichert, was an fehlerhafter Authentifizierung oder Verschlüsselung liegen kann, weil die Anwendungen schwache Algorithmen oder falsche oder abgelaufene Zertifikate akzeptieren. Der letzte erwähnte Punkt ist der, dass auf Seiten Anwender häufig auf andere Seiten weitergeleitet werden auf Grund von Daten, die nicht ausreichend oder gar nicht validiert wurden.^[55]

Ein positiver Test, also das Aufdecken von Sicherheitslücken, ist nicht unbedingt eine schlechte Nachricht, da so eine Sicherheitslücke bekannt wurde, die dann auch geschlossen werden kann. Dies gilt im umgekehrten Sinne auch für ein negatives Testergebnis, da durch einen technischen Test nicht alle Fälle abgedeckt werden können. So können Änderungen an der Konfiguration nicht berücksichtigt werden, genauso wenig wie die Missachtung von Sicherheitsrichtlinien oder unzureichende Wartung des Systems durch den Administrator.^[56]

7.2 Joomla!

7.2.1 Sicherheitseinstellungen

Das WCMS (Web Content Management System) Joomla hat den Vorteil, dass es sehr übersichtlich gehalten ist und die Benutzer sich sehr schnell einarbeiten können. Dies merkt man auch bei den Einstellungen beziehungsweise Sicherheitseinstellungen, auf die wir einen Blick werfen möchten. Die wichtigsten Einstellungen, so zum Beispiel die User-Verwaltung und das Einstellen von wichtigen Sicherheitseinstellungen kann nur der Administrator vornehmen. In Joomla gibt es verschiedene Kategorien von Nutzern. Diese Kategorien sind hierarchisch aufgebaut und beginnen mit dem "Super Administrator", weiter geht es mit dem "Administrator", dann folgt der "Manager". Diese User haben Zugriff auf das Backend. Zugriff auf das Frontend haben die "Publisher", die "Editor" und die "Autoren".

Über das sogenannte Kontrollzentrum gelangt man über Konfiguration > und dann entweder auf System, Site oder Server auf die verschiedenen Einstellungen des CMS. Über das Einstellungsfenster "Site" werden allgemeine Einstellungen vorgenommen. So zum Beispiel, ob die Webseite online oder offline geschaltet werden soll. Hier lässt sich ein kleiner Kurztext eingeben, falls die Seite sich im Offline Modus befindet. Außerdem lassen sich hier weitere Einstellungen vornehmen, wie den verwendeten Editor, zum Bearbeiten von Beiträgen, und die globale Seitenbeschreibung.

Das nächste Einstellungsfenster nennt sich "System". Hier lassen sich sehr umfangreiche Einstellungen vornehmen. Es geht über die Einstellungen des Logverzeichnisses, das Erlauben der Benutzerregistrierung und die erlaubten Medienerweiterungen, über weitere allgemeine Einstellungen zu Medien, die eingebunden werden sollen. Das Debuggen des Systems und die Zwischenspeichereinstellungen können hier ebenfalls gesetzt werden.

Das letzte Einstellungsfenster nennt sich "Server". Hier wird der Pfad zum tmp-Verzeichnis des Server eingestellt. Weiter lassen sich hier einige Servereinstellungen vornehmen, so zum Beispiel die Serverzeit, die FTP Einstellungen, die Datenbank Daten und die Mailingeinstellungen.

7.2.2 Ergebnis Penetration

Bei der Penetration von Joomla wurde eine Sicherheitslücke gefunden. Der Fehler nennt sich "pathDisclosure". Dies ist eine Sicherheitslücke, die einen Angreifer es ermöglicht, das Root-Verzeichnis zu sehen und leichter anzugreifen. Der Fehler tritt auf, wenn das System bei Fehlermeldungen zulässt, ganze Verzeichnispfade in der Fehlermeldung auszugeben. Die Sicherheitslücke lässt sich schließen, in dem der Administrator einstellt, dass bei Fehlermeldungen nicht der ganze Verzeichnispfad genannt wird, sondern nur ein Auszug daraus, ohne eine verschlüsselte Angabe. Leider gibt es das Problem, dass theoretisch jede einzelne Erweiterung oder jedes Modul Fehlermeldungen ausgeben kann. Das bedeutet, dass der Administrator nicht immer Einfluss darauf hat und die Einstellung nicht selbst vornehmen kann.

7.3 Typo3

7.3.1 Sicherheitseinstellungen

TYPO3 bietet im Backend ein Menü mit Namen "Admin-Werkzeuge". Dort sind einige Tools, mit denen sich verschiedene Einstellungen vornehmen lassen. Die wirklich wichtigen Einstellungen, die sich auf das System auswirken und für die Sicherheit und alles andere zuständig sind, finden sich in dem Menüpunkt "Konfiguration". Leider ist das Einstellungsmenü von TYPO3 nicht so intuitiv und übersichtlich, wie beispielsweise bei Joomla. Dafür lassen sich hier viel mehr und detailliertere Einstellungen vornehmen. Die Einstellungen sind unter dem Begriff "$TYPO3_CONF_VARS" gesammelt. Die ist ein Array, in dem alle grundlegenden TYPO3-Einstellungen gespeichert werden. Dazu zählen auch Installationsoptionen und Extensions Parameter. Als nächstes werden wir näher auf die wichtigsten Unterbereiche des Arrays eingehen.

Unter dem Bereich "GFX" werden alle Einstellungen für die grafischen Benutzereinstellungen gespeichert. In dem Bereich "SYS" werden die grundlegenden Systemeinstellungen vorgenommen. Diese betreffen sowohl das Backend, als auch das Frontend. "EXT", hier stellt der Administrator den Umgang mit Extensions ein. "BE", sind die Backend Einstellungen. "FE", beschreiben die Frontend Einstellungen. Die Einstellungsmöglichkeiten, die in Joomla möglich sind, sind ebenfalls alle in TYPO3 möglich, unter dem Bereich "SYS". Darüber hinaus lassen sich aber die Einstellungen mehr aufspalten und der Administrator hat mehr Möglichkeiten Einstellungen nach seinem Sicherheitsempfinden zu setzen.

TYPO3 bietet natürlich auch eine umfassende Benutzerverwaltung. Diese findet man ebenfalls unter den "Admin-Werkzeugen" > Verwaltung. Dort lassen sich neue User erstellen, verschiedene Rollen zuweisen und Rechte vergeben. Außerdem können hier Benutzer vorübergehend gesperrt werden. Über diese Funktion der Benutzerverwaltung hat nur der Administrator Zugriff. Für andere User im Backend kann das Menü angezeigt oder ausgeblendet werden. Diese Einstellungen kann im Bereich "BE" vorgenommen werden.

7.3.2 Ergebnis Penetration

Bei der Penetration von TYPO3 wurde bei dem ausführlichen Scan keine Sicherheitslücke gefunden. Dies spricht für eine gute Grundeinstellung des Systems und sehr gut gesetzte Sicherheitseinstellungen des Administrators.

7.4 Drupal

7.4.1 Sicherheitseinstellungen

Drupal bietet verschiedene Sicherheitseinstellungen an. So kann man unter dem Menüpunkt Verwalten > Einstellungen > Fehlermeldungen im Administratorenmenü einstellen, ob diese nur geloggt oder auch angezeigt werden sollen. Dies sollte ausgestellt werden, da so potentiellen Angreifern mögliche Schwachstellen mitgeteilt werden könnten. Die standardmäßige Einstellung hierbei ist, dass Fehlermeldungen angezeigt werden. Jedoch wird auch von Drupal empfohlen dies nur bei Testsystemen so zu belassen.

Die Benutzerverwaltung von Drupal lässt dem Administrator viele Wahlmöglichkeiten, sodass er für jede Rolle das genau Nötige einstellen kann, was ein erheblicher Vorteil aus sicherheitstechnischer Sicht ist, aber mit Mehraufwand verbunden ist. Es ist möglich für jedes Modul einzeln festzulegen welche Aufgaben die Rolle dort erledigen kann. So lässt sich beim node-Modul zum Beispiel einstellen, ob die Rolle nur eigene Beiträge erstellen, verändern oder löschen kann oder sich dies auch auf alle Beiträge erschließen soll.

Über die Zugriffsregeln kann festgelegt werden, ob bestimmte Benutzer, E-Mail-Adressen, Computernamen oder IP-Adressen der Zugriff auf die Internetseite verweigert werden soll. Dafür werden auch Wildcards angeboten, wodurch zum Beispiel auch ganze IP-Räume leicht gesperrt werden können. Mit dieser Einstellung lässt sich zum Beispiel einem DoS-Angriff (Denial of Service) entgegentreten oder Bots die Anmeldung verweigern, deren E-Mail-Adresse häufig bestimmte wiederkehrende Teile enthält.

Drupal bietet unter dem Menüpunkt Verwalten > Berichte > Statusbericht eine Zusammenfassung über den technischen Hintergrund zu Drupal und weist dort auch auf mögliche Probleme hin. Dort erhält man einen schnellen Überblick, ob Drupal, die Datenbank und PHP noch in der aktuellsten Version auf dem Server laufen, wichtige Pfade von außen unzugänglich sind und ob register_globals abgeschaltet ist. Im selben Menü nur unter "Neue Log-Einträge" ist auch eine Auflistung aller Meldungen zu finden, die nach Grad und Erscheinungsort gefiltert werden können.

Abb. 18 Screenshot Statusbericht(Drupal)

Abb. 19 Screenshot Log(Drupal)

Bei der Passworteingabe unterstützt Drupal den Anwender mit Tipps, wie ein sicheres Passwort aussieht und welchen Sicherheitsstatus das bisher eingegebene Passwort erreicht hat.

7.4.2 Ergebnis Penetration

Bei der Penetration von Drupal wurden mehrere Sicherheitslücken gefunden. Die erste gefundene Lücke ist eine Anfälligkeit des CMS auf allen Pfaden für XSRF. Die Sicherheitslücke, die auf eine miss-konfigurierte Authentifizierung bei .htaccess deutet, kann nicht auf Drupal zurückgeführt werden, da nur Pfade betroffen sind, die nicht zu dem Drupalverzeichnis gehören. Bei der zuletzt gefundenen Lücke werden laut dem Tool verschiedenste Kreditkartennummern offen gelegt. Dies scheint ebenso eine Fehlinterpretation des Tools zu sein, da im System keine Kreditkartennummern hinterlegt sind. Vom Tool wird nur die Sicherheitslücke, die die Authentifizierung betrifft, als kritisch eingestuft. Die anderen Beiden als nicht so kritisch.^[57]

Um die erste Lücke zu schließen wird sollte in den HTML-Body oder in die URL ein Token eingesetzt werden, das mindestens einzigartig für eine bestimmte Session ist oder am Besten für jede Anfrage. Mögliche Tools um dies zu automatisieren wären CSRF Guard oder ESAPI.^[58] Um die Lücke zu schließen durch die das Tool die Kreditnummern gefunden haben will, wird empfohlen sich erst der Bedrohung klar zu machen, der man ausgeliefert ist. Alle Back-Ups sollten stark verschlüsselt sein und die zugehörigen Schlüssel separat gelagert werden und stark genug sein. Passwörter sollten mit einem guten Hash-Algorithmus verschlüsselt sein und genau wie die Schlüssel vor unautorisiertem Zugriff geschützt sein.^[59]

8 Schlussbetrachtung

Abschließend kann gesagt werden, dass wir durch die Untersuchung der verschiedenen CMS in Bezug auf die sicherheitsrelevanten Aspekte tiefere Einblicke gewonnen haben und insgesamt kann die Untersuchung als erfolgreich bezeichnet werden. Durch die kleine Einführung in allgemeine Grundlagen wurde ein guter Einstieg geschaffen. Der kleine Crash-Kurs in die Begrifflichkeiten der "Sicherheit" kristallisierte die wirkliche Bedeutung und Priorität des heutigen Begriffs der "Sicherheit" heraus. Die Sicherheitsmaßnahmen gaben einen guten Überblick über die verschiedenen Methoden, die durchgeführt und geprüft werden sollten, damit für die Sicherheit eines CMS gesorgt ist. Angesprochen wurden sowohl software- als auch hardwarespezifische Methoden. Direkt danach folgte eine Auflistung einiger Angriffe, die in letzter Zeit einen besonderen Stellenwert eingenommen haben. Hier wurde jedem von uns bewusst, wie angreifbar Systeme durch das Internet tatsächlich sind. Zu guter Letzt folgten die Angriffe auf tatsächliche Systeme. Hier haben wir uns für drei unterschiedliche CMS entschieden. TYPO3 war das CMS, dass am meisten in Puncto Sicherheit überzeugte. Leider fiel aber auf, dass es nicht so einfach und intuitiv zu bedienen war, wie Drupal oder Joomla. Durch die Penetration der einzelnen System konnten wir einige interessante Eindrücke gewinnen und Sicherheitslücken aufdecken, mit denen man nicht gerechnet hätte. Alles in allem war die Untersuchung der Systeme eine interessante Angelegenheit und hat das Bewusstsein in Bezug auf die Sicherheit solcher Systeme, aber auch anderer IT-Systeme, geschärft. Mit "Sicherheit" wird man als Administrator eines solchen CMS nach Durchführung dieser wissenschaftlichen Arbeit, besonders vorsichtig und umsichtig sein, um sich vor Gefahren aus dem Netz abzusichern.

9 Fußnoten

1. ↑ Vgl. Fraunhofer (2001) S. 4f
2. ↑ Vgl. BMI (2010) S. 7
3. ↑ Vgl. Gora (2003) S. 82f
4. ↑ Vgl. Lotze (2005) S. 2-5
5. ↑ Vgl. Fraunhofer (2001) S. 5
6. ↑ Vgl. Fraunhofer (2001) S. 6
7. ↑ Fraunhofer (2001) S. 7
8. ↑ ^{8,0 8,1 8,2} Vgl. Fraunhofer (2001) S. 7
9. ↑ Vgl. Fraunhofer (2001) S. 8f
10. ↑ Vgl. Fraunhofer (2001) S. 11
11. ↑ ^{11,0 11,1} Vgl. Ebersbach (2009) http://openbook.galileocomputing.de/joomla15/joomla_01_einleitung_006.htm 25.05.2010 10:36
12. ↑ Vgl. Fraunhofer (2001) S. 11f
13. ↑ In Anlehnung an: Fraunhofer (2001) Abb. 4 S. 12
14. ↑ Vgl. Fraunhofer (2001) S. 12f
15. ↑ In Anlehnung an: Fraunhofer (2001) Abb. 5 S. 13
16. ↑ Duden (2007) Sicherheit
17. ↑ ^{17,0 17,1} Vgl. Hansen (2005) S. 706
18. ↑ Vgl. Gora (2003) S. 20f
19. ↑ S. §1 BDSG (1990)
20. ↑ S. §9 BDSG (1990)
21. ↑ S. Anlage (zu §9 Satz 1) BDSG (1990)
22. ↑ S. §7 BDSG (1990)
23. ↑ Vgl. BSI (2000) S. 118f
24. ↑ Vgl. BSI (2000) S. 119-122
25. ↑ Vgl. Gora (2003) S. 83-85
26. ↑ Vgl. PHPSEC (2007) http://phpsec.org/projects/guide/1.html 31.05.2010 14:26
27. ↑ Vgl. PHPSEC (2007) http://phpsec.org/projects/guide/3.html 31.05.2010 17:21
28. ↑ ^{28,0 28,1} Vgl. IT-Handbuch (2009) S. 387
29. ↑ Vgl. Hansen (2005) S. 716-719
30. ↑ In Anlehnung an: Hansen (2005) S. 718 Abb. 6.8.5/1
31. ↑ Vgl. Hansen (2005) S. 713f
32. ↑ Vgl. PHPIDS (2010)
33. ↑ Vgl. heise (2009)
34. ↑ Vgl. Hansen (2005) S. 712f
35. ↑ Vgl. Hansen (2005) S. 127-130
36. ↑ Vgl. CMS Sicherheit 2010
37. ↑ Vgl. XSS (2010)
38. ↑ Vgl. heise.de (2006)
39. ↑ PayPal.de (2010) 09.06.2010 15:03
40. ↑ ^{40,0 40,1} Vgl. TECCHANNEL (2004)
41. ↑ ^{41,0 41,1} TECCHANNEL (2004)
42. ↑ Vgl. Web Tuts (2010)
43. ↑ Web Tuts (2010) 09.06.2010 15:23
44. ↑ Vgl. OWASP (2010a) http://www.owasp.org/index.php/Session_hijacking_attack 06.06.2010 18:34
45. ↑ Vgl. CMS Sicherheit (2010) http://www.cms-sicherheit.de/module-blog-viewpub-tid-1-pid-24.html 13.06.2010 15:54
46. ↑ Vgl. PHP Gangsta (2009) http://www.phpgangsta.de/was-ist-cross-site-request-forgery-csrf 13.06.2010 15:52
47. ↑ Vgl. Hansen (2005) S. 709
48. ↑ Sicherheitskultur (2009)
49. ↑ S. §202a StGB (1871)
50. ↑ S. §202b StGB (1871)
51. ↑ S. §202c StGB (1871)
52. ↑ S. §303b StGB (1871)
53. ↑ S. §303c StGB (1871)
54. ↑ Vgl. OWASP (2010a) http://www.owasp.org/index.php/LiveCD 04.06.2010 12:56
55. ↑ Vgl. OWASP (2010b) S. 6
56. ↑ Vgl. BSI (2001) S. 76f
57. ↑ Vgl. Log Drupal (2010)
58. ↑ Vgl. OWASP (2010b) S. 11
59. ↑ Vgl. OWASP (2010b) S. 13

10 Anhänge

10.1 Literatur- und Quellenverzeichnis

BSI (2000)	UIMC Dr. Vossbein GmbH & CO KG (Hrsg.): Kosten und Nutzen der IT-Sicherheit: Studie des BSI zur Technikfolgen-Abschätzung, 1. Auflage, SecuMedia Verlag, Ingelheim 2000
BSI (2001)	7. Deutscher IT-Sicherheitskongress des BSI 2001: 2001 - Odyssee im Cyberspace? Sicherheit im Internet: Tagungsband, 1. Auflage, SecuMedia Verlag, Ingelheim 2001
Gora (2003)	Gora, Walter (Hrsg.); Krampert, Thomas (Hrsg.): Handbuch IT-Sicherheit: Strategien, Grundlagen und Projekte, 1. Auflage, Addison-Wesley Verlag, München 2003
Hansen (2005)	Hansen, Hans Robert; Neumann, Gustaf: Wirtschaftsinformatik 2: Informationstechnik, 9. Auflage, Lucius & Lucius Verlagsgesellschaft mbH, Stuttgart 2005
Fraunhofer (2001)	Bullinger, Hans-Jörg (Hrsg.): Content Management Systeme: Auswahlstrategien, Architekturen und Produkte, 6. Auflage, Verlagsgruppe Handelsblatt GmbH, Düsseldorf 2001
IT-Handbuch (2009)	Hübscher, Heinrich; Petersen, Hans-Joachim; Rathgeber, Carsten; Richter, Klaus; Scharf, Dirk: IT-Handbuch: IT-Systemelektroniker/-in, Fachinformatiker/-in, 6. Auflage, Westermann, Braunschweig 2009
Lotze (2005)	Lotze, Thomas; Theune, Christian: Content Management mit Plone: Handbuch für Autoren und Redakteure, 1. Auflage, gocept GmbH und Co. KG , Köthen 2005
BMI (2010)	Bundesministerium des Innern: Die Kriminalität in der Bundesrepublik Deutschland: Polizeiliche Kriminalstatistik für das Jahr 2009, Berlin 2010, http://www.bka.de/pks/pks2009/download/pks2009_imk_kurzbericht.pdf 19.05.2010 15:53
Ebersbach (2009)	Ebersbach, Anja; Glaser, Markus; Kubani, Radovan: Joomla! 1.5: http://openbook.galileocomputing.de/joomla15/ 25.05.2010 10:30
Duden (2007)	o.V.: Duden - Deutsches Universalwörterbuch, 6. Auflage, Dudenverlag, Mannheim, Leipzig, Wien, Zürich 2007
PHPSEC (2007)	Shiflett, Chris: PHP Security Consortium, http://phpsec.org/ 27.05.2010 16:26
heise (2009)	Bachfeld, Daniel: Artikel: Einbruchmelder, Erste Schritte mit der Einbruchserkennung PHPIDS, 24.04.2009, http://www.heise.de/security/artikel/Erste-Schritte-mit-der-Einbruchserkennung-PHPIDS-270122.html 27.05.2010 20:05
PHPIDS (2010)	Heiderich, Mario; Matthies, Christian; Strojny, Lars: PHPIDS, Webapplication Security 2.0, http://php-ids.org/ 04.06.2010 12:52
OWASP (2010a)	o.V.: OWASP, http://www.owasp.org/ 04.06.2010 12:54
OWASP (2010b)	o.V.: OWASP Top 10 - 2010, The Ten Most Critical Web Application Security Risks, http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202010.pdf 06.06.2010 11:37
TECCHANNEL (2004)	Woelfer, Thomas: Cross-site Scripting und SQL Injection, http://www.tecchannel.de/sicherheit/spam/402351/cross_site_scripting_und_sql_injection/ 06.06.2010 14:08
CMS Sicherheit (2010)	Krapohl, Andreas: Cross-site Scripting, http://www.cms-sicherheit.de/module-blog-viewpub-tid-1-pid-3.html 06.06.2010 14:16
Web Tuts (2010)	Strohhäcker, Maik: PHP Session Sicherheit - Session Fixation, http://www.web-tuts.de/php-session-sicherheit-session-fixation.html 06.06.2010 17:49
Sicherheitskultur (2009)	Schaumann, Philipp: Schutz gegen Social Engineering - neue psychologische Ansätze, http://sicherheitskultur.at/social_engineering.htm, 06.06.2010 19:55
heise.de (2006)	o.V.: Paypal-Phishing via Cross-Site-Scripting, http://www.heise.de/newsticker/meldung/Paypal-Phishing-via-Cross-Site-Scripting-133382.html 09.06.2010 15:11
XSS (2010)	Stephan Uhlmann: Konstruktion sicherer Anwendungssoftware - "Cross Site Scripting (XSS)", http://su2.info/uni/sosi/xss_paper.pdf 09.06.2010 15:19
PHP Gangsta (2009)	Michael Kliewe: Was ist “Cross Site Request Forgery” (CSRF)?, http://www.phpgangsta.de/was-ist-cross-site-request-forgery-csrf 13.06.2010 15:54

10.2 Rechtsquellenverzeichnis

BDSG (1990)	Bundesdatenschutzgesetz in der Fassung der Bekanntmachung vom 14. Januar 2003 (BGBl. I S. 66), das zuletzt durch Artikel 1 des Gesetzes vom 14. August 2009 (BGBl. I S. 2814) geändert worden ist
StGB (1871)	Strafgesetzbuch in der Fassung der Bekanntmachung vom 13. November 1998 (BGBl. I S. 3322), das zuletzt durch Artikel 3 des Gesetzes vom 2. Oktober 2009 (BGBl. I S. 3214) geändert worden ist

10.3 Weitere Anhänge

Log Drupal (2010)	http://docs.google.com/leaf?id=0B7ItPZM5aelMMTMwNjgyNDUtNDg5Ny00M2VhLWI1MjktYTU3YmMwOTNhNDMx&hl=de
Log Joomla (2010)	Textdatei: Log_Joomla.txt
Log TYPO3 (2010)	Textdatei: Log_Typo3.txt