Hacking Im Web Denken Sie Wie Ein Hacker Und Schließen Sie Die Lücken in Ihren Webapplikationen

Völlig überarbeitete Tim Philipp Schäfers & aktualisierte Hacking 2. Au age im Web Denken Sie wie ein Hacker und schließen Sie die Lücken in Ihren Webapplikationen

• Angriffe verstehen: Session Hijacking, Cross-Site-Request-Forgery, Cross-Site-Scripting, File Inclusion, SQL-Injection, UI-Redressing und mehr • Eigene Testumgebung aufbauen und Kenntnisse direkt umsetzen • 35 Sicherheits-Tools kennenlernen und zum Aufspüren von Lücken nutzen

02.08.18 09:52 Tim Philipp Schäfers, Jahrgang 1995, ist seit seinem Abitur als Security-Consultant tätig und berät Firmen im Bereich Websicherheit/Webhacking. Schäfers deckte gravierende Sicherheitslücken bei Unternehmen wie PayPal, Facebook, Google, der deutschen Telekom und vielen weiteren Unternehmen verantwortlich auf. Er ist Mitgründer und Mitbetreiber des Webprojekts „Internetwache.org“, das sich ebenfalls mit der Sicherheit von Webapplikationen und Webhacking beschäftigt. Seit Ende 2015 schreibt Schäfers zudem auf dem Web-Portal golem.de über die Themen IT-Sicherheit und Privatsphäre.

60636-3_Titelei.indd 2 02.08.18 09:52 Tim Philipp Schäfers Hacking im Web Denken Sie wie ein Hacker und schließen Sie die Lücken in Ihren Webapplikationen

60636-3_Titelei.indd 3 02.08.18 09:52 Bibliografische Information der Deutschen Bibliothek

Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte Daten sind im Internet über http://dnb.ddb.de abrufbar.

Alle Angaben in diesem Buch wurden vom Autor mit größter Sorgfalt erarbeitet bzw. zusammengestellt und unter Einschaltung wirksamer Kontrollmaßnahmen reproduziert. Trotzdem sind Fehler nicht ganz auszuschließen. Der Verlag und der Autor sehen sich deshalb gezwungen, darauf hinzuweisen, dass sie weder eine Garantie noch die juristische Verantwortung oder irgendeine Haftung für Folgen, die auf feh- lerhafte Angaben zurückgehen, übernehmen können. Für die Mitteilung etwaiger Fehler sind Verlag und Autor jederzeit dankbar. Internetadressen oder Versionsnummern stellen den bei Redaktionsschluss ver- fügbaren Informationsstand dar. Verlag und Autor übernehmen keinerlei Verantwortung oder Haftung für Veränderungen, die sich aus nicht von ihnen zu vertretenden Umständen ergeben. Evtl. beigefügte oder zum Download angebotene Dateien und Informationen dienen ausschließlich der nicht gewerblichen Nutzung. Eine gewerbliche Nutzung ist nur mit Zustimmung des Lizenzinhabers möglich.

Alle Rechte vorbehalten, auch die der fotomechanischen Wiedergabe und der Speicherung in elektroni- schen Medien. Das Erstellen und Verbreiten von Kopien auf Papier, auf Datenträgern oder im Internet, insbesondere als PDF, ist nur mit ausdrücklicher Genehmigung des Verlags gestattet und wird widrigenfalls strafrechtlich verfolgt. Die meisten Produktbezeichnungen von Hard- und Software sowie Firmennamen und Firmenlogos, die in diesem Werk genannt werden, sind in der Regel gleichzeitig auch eingetragene Warenzeichen und sollten als solche betrachtet werden. Der Verlag folgt bei den Produktbezeichnungen im Wesentlichen den Schreibweisen der Hersteller.

Autor: Tim Philipp Schäfers Programmleitung: Dr. Markus Stäuble, Benjamin Hartlmaier Lektorat: Hans Hartings Satz: DTP-Satz A. Kugge, München art & design: www.ideehoch2.de Druck: M.P. Media-Print Informationstechnologie GmbH, 33100 Paderborn Printed in Germany

ISBN 978-3-645-60636-3

60636-3_Titelei.indd 4 02.08.18 09:52 Vorwort

Kaum ein Monat vergeht, in dem nicht bekannt wird, dass ein Unternehmen Opfer eines Hackerangriffs geworden ist. Oftmals wird die Webseite verunstaltet, Social- Media-Accounts geraten unter die Kontrolle von unbekannten Angreifern, oder es wird gar die gesamte Onlinedatenbank eines Unternehmens kopiert. Als Einstiegs- punkt für Angreifer dient oft das Web, genauer die Webapplikationen, die auf Servern im Internet betrieben werden. Im Handumdrehen kann die Webseite eines Unterneh- mens zum Einfallstor werden oder der Webshop zur Goldgrube für Onlinekriminelle. Solche Vorgänge schaden dem Geschäft meist erheblich. Die (Un-)Sicherheit Ihrer Webapplikationen entscheidet letztlich auch über den Erfolg oder Misserfolg Ihres Unternehmens, denn oftmals findet über diese Anwendungen die Abwicklung ganzer Geschäfts(teil)prozesse statt. Genau um diese Thematik soll es in diesem Buch gehen: die Sicherheit von Webanw endungen mithilfe eines sicheren Programmcodes und sicherer Konfiguration von Webservern zu gewährleisten. Längst wird für eine sichere Webapplikation mehr benötigt als Standardlösungen oder Firewalls, vielmehr ist ein hohes Maß an Wissen nötig, um überhaupt nachvoll ziehen zu können, was mögliche Angreifer auf Applikationsebene alles versuchen, um Systeme zu hacken. Da verschiedene Arten von Angriffen zur Verfügung stehen, geht dieses Fachbuch auf die gängigsten Angriffsvektoren beim Webhacking ein und versucht zu erklären, wie ihnen begegnet werden kann. Die Komplexität und das schnelle Wachstum des Webs und der damit verbundenen Technologien haben seit seiner Entstehung für einiges Durcheinander gesorgt. Dieser Wirrwarr wirkt sich auf die Sicherheit von Systemen und Webapplikationen negativ aus. Es gibt im Web Standards, die nicht eingehalten werden, gelebte Regeln (die eigentlich nur Vorschläge waren) und sicherlich auch eine Menge verzweifelter Ent- wickler, die sich fragen, wie sie da den Durchblick behalten können. »Hacking im Web« soll hier weiterhelfen: Es werden Angriffsmöglichkeit en aufge- zeigt, zahlreiche Tipps gegeben und Vorschläge zur Behebung von Lücken gemacht, damit Sie wissen, wie auf mögliche Gefahren reagiert werden kann. Dadurch kön- nen Angriffsflächen bereits während der Architektur- und Anwendungsentwicklung minimiert werden. Darüber hinaus soll Ihnen dieses Buch das notwendige Werkzeug an die Hand geben, um selbst Angriffe auf Ihre Webapplikationen zu Testzwecken durchführen zu kön- nen. Vorwort 6

In der zweiten, überarbeiteten Auflage von »Hacking im Web« wurden dazu ein Kapi- tel zur Einrichtung einer Testumgebung eingefügt und zudem die Nutzung von Tools stärker in den einzelnen Kapiteln berücksichtigt. Sofern Sie also selbst die vorgestellten Schwachstellen ausnutzen möchten, empfiehlt es sich, die Schritte aus Kapitel 3 zu befolgen und die in den Kapiteln vorgestellten Schwachstellen direkt selbst auszu- probieren. Neben inhaltlichen Anpassungen in den übrigen Kapiteln wurden mit Blick auf neue Technologien (Cloud-Speicher) damit verbundene Schwachstellen und sie auszunutzende Angriffsvektoren hinzugefügt. Das frühere Kapitel zum Basiswissen (Kapitel 3 der ersten Auflage) wurde aus dem Buch entfernt. Es lässt sich mittlerweile auf der Webseite zum Buch kostenfrei abru- fen: https://hacking-im-web.de/basiswissen.pdf Begleitend zum Buch wird es Kurz-Videos zum Thema Web- und IT-Sicherheit geben, die nach Veröffentlichung des Buches erscheinen. Um auf dem Laufenden zu bleiben, empfiehlt es sich, die Webseite zum Buch (https://hacking-im-web.de) periodisch abzurufen oder dem Autor auf Twitter zu folgen (https://twitter.com/TimPhSchaefers). Nun wünsche ich Ihnen erst einmal viel Freude bei der Lektüre und Erfolg bei der praktischen Umsetzung! Tim Philipp Schäfers, Detmold im Sommer 2018 Danksagung

Dieses Buch konnte nur in dieser Form erscheinen, weil zahlreiche Personen mich in meinem Vorhaben, einiges über die Sicherheit von Webapplikationen zu Papier zu bringen, unterstützt haben. Ein großes Dankeschön für geniale Ideen, geistreiche Einfälle und alle sonstigen For- men der Unterstützung geht an meine Freunde und meine gesamte Familie. Des Weiteren gilt mein ganz besonderer Dank Rico Walde und Sebastian Neef. Beide haben mit ihrem fundierten Fachwissen und durch hilfreiche Rückmeldungen zu einzelnen Kapiteln maßgeblich dazu beigetragen, dass dieses Fachbuch hoffentlich aus- geglichene Anteile an Theorie und Praxis aufweist und noch dazu angenehm zu lesen ist. Zudem möchte ich Dr. Markus Stäuble, dem ehemaligen Lektor und Programmleiter »Professional Series« beim Franzis Verlag, danken. Seine Ausdauer, seine Anregun- gen und Tipps und nicht zuletzt auch die Begeisterung für das Thema haben mich als recht jungen Erstautor 2016 motiviert, das Buchprojekt durchzuführen und mit dem Buch Teil der Serie zum Thema »Hacking« im Franzis Verlag zu werden. 2018 erscheint dieses Buch in zweiter Auflage. Daran haben weitere Personen mit- gearbeitet und mich unterstützt. Mein Dank gilt vor allem Benjamin Hartlmaier und dem Team vom Franzis Verlag, die immer ein offenes Ohr hatten und mich bei der Überarbeitung des Buches tatkräftig unterstützt haben. Außerdem möchte ich Hans Hartings ganz herzlich danken, der durch seine zahlrei- chen Hinweise im Rahmen des Lektorats maßgeblich zur Steigerung der sprachlichen Qualität dieses Buches beigetragen hat und insbesondere in der Endphase des Pro- jektes mir mit Rat und Tat zur Seite stand. Abschließend möchte ich Ihnen, liebe Leser, stellvertretend für eine ganze Reihe von Webnutzern danken! Das moderne Web existiert nicht ohne neugierige Entwickler, mutige Gestalter, gewiefte Blogger, clevere Hacker oder skeptische Mitleser. In der menschlichen Evolution gab es wohl kaum eine andere Kommunikations- und Ver- bindungsart, die so vielfältig, umfassend und allgegenwärtig war oder ist wie das Web — deshalb: Danke, dass Sie alle es täglich nutzen und es so zu dem machen, was es ist! Danksagung 8 Inhalt

1 Einleitung...... 17 1.1 Der Ansatz...... 18 1.2 Das Ziel...... 18 1.3 Der Aufbau...... 19 1.4 Die Grenzen...... 21 1.5 Das (Kern-)Problem...... 22

2 Evolution des Webs...... 25 2.1 Die Anfänge des Webs...... 25 2.2 Die Boomphase des Webs...... 27 2.3 Webapplikationen heute...... 29 2.4 Webapplikationen in der Zukunft...... 30 2.5 Entwicklung der Websicherheit...... 31

3 Einrichtung der Testumgebung...... 35 3.1 Kali Linux herunterladen und installieren...... 35 3.2 Betriebssystem aktualisieren und Nutzer anlegen...... 37 3.3 Chromium installieren...... 38 3.4 DVWA installieren und konfigurieren...... 38

4 Session-Angriffe...... 47 4.1 Man-in-the-Middle-Angriff...... 49 4.1.1 Netzwerkverkehr mitschneiden...... 51 4.1.2 Netzwerkverkehr auswerten...... 52 4.2 Cookie-Replay-Angriff...... 53 4.3 Session-Hijacking...... 54 4.3.1 Session-Hijacking in der Praxis...... 58 4.4 Session-Fixation...... 60 4.5 Session-Riding bzw. CSRF (Cross Site Request Forgery)...... 62 4.6 Zusammenfassung: Abhilfe aus Entwicklersicht...... 65 4.6.1 Verschlüsselung...... 66 4.6.2 Sichere Generierung von Session-IDs...... 67 4.6.3 Sonstige Maßnahmen...... 67 4.6.4 Hinweise zu Session-Riding bzw. CSRF...... 70 10 Inhalt

5 Cross-Site-Scripting (XSS)...... 73 5.1 Reflexives XSS...... 74 5.2 Persistentes XSS...... 83 5.3 DOM-based XSS...... 87 5.4 self-XSS...... 88 5.5 Social-engineered XSS...... 89 5.6 uXSS...... 91 5.7 Flash-based XSS...... 92 5.8 Abhilfe aus Entwicklersicht...... 93 5.8.1 Sonstige Hinweise/Umgehen von Filtern...... 94 5.8.2 Schutz vor reflexivem und persistentem XSS...... 97 5.8.3 Schutz vor DOM-based XSS...... 109 5.8.4 Schutz vor self-XSS...... 110 5.8.5 Hinweise zu Social-engineered XSS...... 111 5.8.6 Hinweise zu uXSS...... 112 5.8.7 Schutz vor Flash-based XSS...... 113 5.9 Sonstige Maßnahmen gegen XSS...... 115 5.9.1 CSP (Content-Security-Policy)...... 116 5.9.2 XSS-Filter im Browser...... 120 5.9.3 http-only-Flags...... 121 5.10 Zusammenfassung der Maßnahmen...... 122 5.11 Wissenswertes über XSS...... 122 5.12 Scriptless Attacks...... 125

6 Angriffe auf nachgelagerte Datenbanksysteme...... 127 6.1 SQL-Injections...... 128 6.1.1 Login Bypass mit SQL-Injection...... 129 6.1.2 Basisangriffe durch SQL-Injection...... 132 6.1.3 Blind-SQL-Injection...... 151 6.1.4 Wesentliche Erkenntnisse: Angreifersicht...... 158 6.1.5 Sicherung von SQL-Datenbanken...... 159 6.1.6 Wesentliche Erkenntnisse: Entwicklersicht...... 166 6.1.7 Wissenswertes über SQL-Injections...... 166 6.2 Grundlagen von LDAP...... 168 6.2.1 Operatoren innerhalb von LDAP...... 172 6.2.2 Verknüpfung von Operatoren...... 173 6.2.3 LDAP-Injection...... 174 6.2.4 Blind-LDAP-Injection...... 175 6.2.5 Sicherung von LDAP-Systemen...... 176 6.3 XPath...... 177 6.3.1 XPath-Injection...... 178 6.3.2 Blind-XPath-Injection...... 180 Inhalt 11

6.3.3 Sicherung von XPath...... 181 6.3.4 Zusammenfassung: Sicherung nachgelagerter Dateisysteme...... 181

7 Sicherheit von Authentifizierungsmechanismen...... 183 7.1 Verschiedene Angriffsvektoren...... 183 7.1.1 Simple Angriffe gegen Authentifizierungsmechanismen...... 184 7.1.2 Wörterbuchangriff...... 184 7.1.3 Brute-Force-Methode...... 184 7.2 Grundlagen zum Passworthashing...... 186 7.3 Kryptografische Hashfunktionen...... 188 7.4 Passwortcracking...... 189 7.4.1 Lookup-Tabellen mittels Brute-Force-Methode oder Wörterbuchangriff...... 190 7.4.2 Rainbow Tables...... 190 7.4.3 Google-Suche...... 191 7.4.4 Tools...... 192 7.5 Typenunsicherer Vergleich...... 192 7.6 Abhilfe aus Entwicklersicht...... 196 7.6.1 Salt hinzufügen...... 196 7.6.2 Sicheres Passworthashing...... 198 7.6.3 Passwort-Policy...... 199 7.6.4 Passwortvalidierung...... 199 7.6.5 Sicherer Vergleich...... 201 7.6.6 Weitere Authentifizierungsarten...... 201 7.6.7 Hinweise zur Log-in-Änderung...... 203 7.6.8 Hinweise zur »Passwort vergessen?«-Funktion...... 204 7.6.9 Protokollierung (Logging)...... 204 7.6.10 Zusammenfassung...... 205

8 File Inclusion...... 209 8.1 Path Traversal...... 209 8.1.1 Abhilfe aus Entwicklersicht...... 212 8.2 Local File Inclusion (LFI)...... 213 8.2.1 Abhilfe aus Entwicklersicht...... 215 8.3 Nullbyte-Injection...... 216 8.3.1 Abhilfe zur Nullbyte-Injection...... 217 8.4 Uneingeschränkte Dateiuploads...... 217 8.4.1 Hinweis zum Upload von Dateien...... 221 8.5 Remote File Inclusion (RFI)...... 222 8.5.1 Abhilfe aus Entwicklersicht...... 223 8.6 XML-External-Entities-Injection (XXE)...... 223 8.6.1 Abhilfe aus Entwicklersicht...... 226 12 Inhalt

8.7 Code-Injection...... 227 8.7.1 Abhilfe aus Entwicklersicht...... 229 8.8 HTTP-Header-Injection...... 230 8.8.1 Cookie-Injection...... 231 8.8.2 SMTP-Header-Injection...... 232 8.8.3 Abhilfe aus Entwicklersicht...... 237 8.9 Zusammenfassung...... 238

9 Logische Fehler...... 239 9.1 Zugriffsrechte...... 239 9.1.1 Rechteausweitungen...... 240 9.1.2 Ungeschützte Funktionen...... 243 9.1.3 Kontextabhängige Zugriffe...... 245 9.1.4 Parametrisierte Zugriffskontrollen...... 245 9.1.5 Referrer-basierte Zugriffskontrolle...... 246 9.1.6 Schrittweise Zugriffskontrolle...... 247 9.2 Ungeprüfte Um- und Weiterleitungen...... 247 9.2.1 Abhilfe aus Entwicklersicht...... 248 9.3 Namenskonflikte...... 249 9.3.1 Namenskonflikte in URLs...... 249 9.3.2 Namenskonflikte in Nutzernamen...... 251 9.3.3 Namenskonflikte bei Uploads...... 251 9.4 Cookie-Manipulation...... 252 9.4.1 Abhilfe aus Entwicklersicht...... 252 9.5 Zusammenfassung...... 253

10 Informationspreisgabe...... 255 10.1 Fehlermeldungen...... 255 10.2 Directory Listing...... 258 10.3 Öffentlich zugängliche Informationen...... 260 10.3.1 Versteckte Subdomains...... 260 10.3.2 »Versteckte« Pfade/Standardpfade...... 261 10.3.3 Informationen aus dem Quelltext...... 262 10.3.4 Öffentliche Dateien...... 263 10.3.5 Öffentliche Logdateien...... 264 10.3.6 Repositories (git, svn, etc.)...... 265 10.3.7 DS_Store-Dateien...... 270 10.3.8 Sonstige Informationen...... 276 10.3.9 Unsichere direkte Objektreferenzen...... 276 10.3.10 Standardwerte...... 277 10.3.11 Suchmaschinen...... 278 10.3.12 Soziale Manipulation (Social Engineering)...... 289 Inhalt 13

10.4 Abhilfe: Informationspreisgabe...... 299 10.4.1 Abhilfe: Fehlermeldungen...... 299 10.4.2 Abhilfe: Directory Listing...... 300 10.4.3 Abhilfe: öffentlich zugängliche Informationen...... 301 10.4.4 Abhilfe: Standardwerte...... 303 10.4.5 Abhilfe: Suchmaschinen...... 303 10.4.6 Abhilfe: Phishing-Angriffe...... 306 10.4.7 Abhilfe: Social Hacking...... 307 10.4.8 Abhilfe: Social Hacking gegen Plattformbetreiber...... 307 10.4.9 Abhilfe: Social Hacking innerhalb von Plattformen...... 308

11 UI-Redressing...... 309 11.1 Die Methoden der Angreifer...... 309 11.1.1 Clickjacking...... 310 11.1.2 Cursorjacking...... 313 11.1.3 Fortgeschrittene UI-Redressing-Angriffe...... 316 11.2 Abhilfe aus Entwicklersicht...... 318 11.2.1 CSP (Content-Security-Policy)...... 318 11.2.2 X-Frame-Options (XFO)...... 319 11.2.3 Frame-Busting mittels JavaScript...... 321 11.2.4 Zusammenfassung...... 322

12 Weitere Angriffsarten...... 323 12.1 SQL-Injections zu XSS...... 323 12.2 XSS zu SQL-Injection...... 324 12.3 Domain- bzw. Typosquatting...... 325 12.4 Google-Bombing...... 329 12.5 Exploits...... 332 12.6 Rent a Hacker/Untergrundforen...... 333

13 Die 10 wichtigsten Regeln für Entwickler und Sicherheitsverantwortliche...... 337

14 Tools...... 341 14.1 Toolübersicht...... 342 14.2 Mozilla Firefox-Erweiterungen...... 344 14.2.1 New Hackbar...... 344 14.2.2 HTTP Header Live...... 346 14.2.3 User-Agent Switcher...... 348 14.2.4 Wappalyser...... 350 14.2.5 Scrippy ...... 352 14.3 HTTP-Proxy-Tools...... 352 14.3.1 Burp Suite...... 353 14 Inhalt

14.3.2 OWASP Zed Attack Proxy (ZAP)...... 366 14.4 Tools zu Session-Angriffen...... 374 14.4.1 Wireshark...... 375 14.4.2 CSRFGenerator...... 378 14.5 Angriffstools zu XSS...... 379 14.5.1 XSSer...... 379 14.5.2 Xenotix XSS Exploit Framework...... 382 14.5.3 Adobe SWF Investigator...... 386 14.6 Tools zu nachgelagerten Datenbanksystemen...... 388 14.6.1 SQL-Ninja...... 388 14.6.2 sqlmap...... 391 14.6.3 Havij...... 393 14.6.4 LDAP Blind Explorer...... 397 14.6.5 XPath Blind Explorer...... 398 14.7 Angriffe gegen Authentifizierungsmechanismen...... 399 14.7.1 Brutus...... 400 14.7.2 Cintruder ...... 403 14.8 Passwortcracking...... 403 14.8.1 Hash Identifier...... 403 14.8.2 findmyhash ...... 405 14.8.3 John the Ripper...... 406 14.9 Tools zur Informationspreisgabe...... 407 14.9.1 Subbrute...... 408 14.9.2 Knock Subdomain Scan...... 409 14.9.3 WFuzz...... 410 14.9.4 DirBuster...... 413 14.9.5 WPScan...... 414 14.9.6 joomscan...... 417 14.9.7 GitTools (Finder, Dumper, Extractor)...... 419 14.9.8 .DS_Store Scanner...... 421 14.9.9 theHarvester...... 422 14.9.10 Social Engineering Toolkit (SET)...... 424 14.9.11 Snallygaster...... 429 14.10 Tools zu UI-Redressing...... 431 14.10.1 Clickjacking Tester...... 431 14.10.2 Jack (Clickjacking Tool)...... 432 14.11 Kommentar zu automatischen Schwachstellenscannern...... 433

15 Bug-Bounty-Programme...... 435 Inhalt 15

16 Legal Webhacking durchführen...... 439 16.1.1 HackITs...... 439 16.1.2 Capture the Flag...... 441 16.1.3 Responsible-Disclosure-Programme/Bug-Bounty-Programme.....441 16.1.4 Zusammenfassung...... 442

17 SCADA-Hacking...... 445 17.1.1 Ich sehe was, was du nicht siehst, und das bist … DU — öffentlich zugängliche Kameras...... 446 17.1.2 Zugriff auf elektronische Geräte...... 450 17.1.3 Öffentlich zugängliche Human Machine Interfaces (HMI)...... 454 17.1.4 Öffentlich zugängliche PLCs (Programmable Logic Controller)....465 17.1.5 Shodan — das dunkle Google...... 466 17.1.6 Fazit...... 468

Epilog...... 471

Abkürzungsverzeichnis...... 473

Literaturempfehlungen...... 477

Quellenverzeichnis...... 481

Index...... 489 Inhalt 16 1 Einleitung

Webapplikationen sind im Geschäftsalltag in nahezu jedem Unternehmen allgegen wärtig: Das fängt bei einem einfachen Ticketsystem für Supportleistungen an, führt über die Firmenwebsite zu einer komplexen Webanwendung für die Bestellung der Waren durch Kunden (E-Commerce) und reicht bis hin zu sensiblen Gehaltsabrech nungssystemen. Viele Anwendungen haben heutzutage Programmierschnittstellen (APIs) mit dem Web, und auch der Austausch von Unternehmensdaten mit Dritten wird immer mehr die Regel. Was wäre, wenn plötzlich der Webshop oder die Internetseite Ihres Unternehmens für mehrere Tage nicht erreichbar wäre, oder das Banner einer Hackergruppe darauf thronte? Wie gehen Sie damit um, wenn plötzlich Ihre Kundendatenbank in ominö- sen Onlineforen auftaucht oder vertrauliche E-Mails in sozialen Netzwerken für einen Sturm der Entrüstung (Shitstorm) sorgen? Eines der prominentesten Beispiele für die gravierenden Folgen eines Hackerangriffs ist der Hack von Yahoo im Jahr 2013. Bei diesem Hack gelang es Unbekannten die Daten von drei Milliarden Nutzern zu kopieren [1]. Der Angriff ist ausgerechnet kurz vor dem Verkauf des Unternehmens Yahoo an Verizon bekannt geworden und hat abschließend sogar die US-Börsenaufsicht auf den Plan gerufen [2]. Das Unterneh- men sollte ursprünglich für über 4,8 Milliarden US-Dollar verkauft werden – durch 18 1 Einleitung

das Bekanntwerden des Hacks wurde der Kaufpreis von Yahoo nachträglich auf 4,48 Milliarden US-Dollar (um circa 300 Millionen US Dollar) gesenkt, und in der Folge des Hacks ist die ehemalige Chefin von Yahoo (Marissa Mayer) zurückgetreten [3]. Wie sich an dem Beispiel zeigt, kann ein Hack auf ein Unternehmen immense Aus- wirkungen haben, nicht zuletzt haben neben dem Betreiber vor allem auch die Nutzer dieser Applikationen unter solchen Raubzügen im digitalen Raum zu leiden. Der australische Sicherheitsforscher Troy Hunt hat eine Webseite zu Datenleaks erstellt, auf der Sie durch Eingabe Ihrer E-Mail-Adresse prüfen können, ob Sie selbst schon einmal von einem »Data Breach« betroffen waren:

https://haveibeenpwned.com/ Trotz all dieser Hacks hat sich recht wenig getan, schließlich lesen wir Nachrichten zu solchen Hacks immer wieder. Umso wichtiger ist es, dass Sie sich mit Ihren Syste- men beschäftigen und solchen Angriffen präventiv begegnen, indem Sie sie stärker sichern.

1.1 Der Ansatz

In diesem Buch soll ganz pragmatisch gezeigt werden, wie die Programmierung einer sicheren Webapplikation möglich ist. Mittels realer Sicherheitslück en und durch Codebeispiele wird deutlich gemacht, wie schnell Hacker einer sicher geglaubten Webanwendung habhaft werden können. Um dies zu erreichen, wird immer wieder die Perspektive eines potenziellen Angreifers eingenommen und beispielsweise an Hand von Angriffen auf die Testumgebung gezeigt, welche Folgen Angriffe haben können. Dadurch soll die Bedrohung realistisch nachgeahmt und verdeutlicht werden, dass sie nicht nur durch IT-Profis realisiert werden kann, sondern durch jeden, der genug Zeit aufw endet und Interesse aufbringt. Letzteres ist auch der Grund, weshalb es solche Angriffe täglich tausendfach gibt.

1.2 Das Ziel

Für Entwickler oder IT-Sicherheitsverantwortliche ist es immer wieder sinnvoll, sich in die Lage eines Angreifers zu versetzen, um die eigene Anwendung besser gegen Angriffe zu schützen. Ziel des Buchs ist also die Schaffung eines Bewusstseins dafür, dass jeder geschriebene Code zum Einfallstor werden kann, wenn man ihn nicht so genau und korrekt implementiert wie notwendig. Das Buch zielt darauf ab, dass Sie um die Ecke zu denken lernen und noch nicht zufrieden sind, wenn eine Funktionali- 1.3 Der Aufbau 19

tät wie gewünscht implementiert wurde, sondern erst, wenn sie ausschließlich wie gewünscht verwendet werden kann und somit »sicher« ist.

1.3 Der Aufbau

Zu Anfang werden die gemeinsamen Grundlagen für das weitere Verständnis des Buchs gelegt. Es wird auf den historischen Entwicklungsprozess der Webanwendun gen und des Webs eingegangen (siehe Kapitel 2, »Evolution des Webs«) und anschließend darauf, wie sich der Aspekt der Websicherheit in den letzten Jahren verändert hat. Danach wechseln wir durch das Einrichten der Testumgebung direkt in die Praxis (siehe Kapitel 3, »Einrichtung der Testumgebung«). Die Testumgebung dient dazu, Angriffe zu beschriebenen Angriffsvektoren selbst durchzuführen und zu Test zwecken mit den über die in Kapitel 14 beschriebenen Angriffstools zu verfügen. Im anschließenden Kapitel beginnt die Auseinandersetzung mit verschiedenen Angriffsvektoren. Wir werden schauen, wie man sogenannten Sessions habhaft werden kann und welche Möglichkeiten zum Schutz bestehen (siehe Kapitel 4, »Session- Angriffe«). Das darauffolgende Kapitel widmet sich der Problematik des sogenannten Cross-Site- Scriptings. Wir werden verschiedene Techniken betrachten, um anschließend mögli- che Schutzmaßnahmen zu evaluieren (siehe Kapitel 5, »Cross-Site-Scripting (XSS)«). In Kapitel 6 wird es um nachgelagerte Datensysteme gehen. Wir werden feststellen, dass Angreifer bei unsicheren Applikationen mittels SQL-Injection Zugriff auf Datenban k en erlangen können und dass es weitere Speichermöglichkeiten gibt, bei denen Angreifer an Daten gelangen können. Natürlich betrachten wir auch, wie sich dieser unautorisierte Zugriff vermeiden lässt (siehe Kapitel 6, »Angriffe auf nachgelagerte Datenbanksysteme«). Authentifizierungssysteme gelten neben dem Session-Management als Kernstück vieler Webapplikationen, da darüber Zugriffe auf Funktionen und Accounts verwal- tet werden. Wir werden schauen, wie man ihrer habhaft werden kann und wie es möglich ist, diese Prozesse sicher zu gestalten. Dazu werden wir unter anderem auf die Möglichkeiten des Passworthashings eingehen (siehe Kapitel 7, »Sicherheit von Authentifizierungsmechanismen«). In Kapitel 8 werden wir schauen, inwieweit die Einbindung von Dateien durch den Nutzer problematisch werden kann. Viele Webapplikationen sind heutzutage inter aktiv und bieten neben Dateiuploads sogar die Möglichkeit, Dateien aus dem Inter- 20 1 Einleitung

net einzubinden — dabei können viele Schwachstellen entstehen, die wir gemeinsam ausräumen wollen (siehe Kapitel 8, »File Inclusion«). Wir werden sehen, dass einige Fehler in Applikationen auf ganz simplen Missver ständnissen beim Geschäftsprozess beruhen. Diese logischen Fehler können mittler weile so umfassend sein, dass wir ihre Gefahren sowie Möglichkeiten zur Abhilfe in einem eigenen Kapitel behandeln werden (siehe Kapitel 9, »Logische Fehler«). Informationen können Angreifern sehr weiterhelfen, sowohl bei bereits aus den vor herigen Kapiteln bekannten Angriffsvektoren als auch bei Angriffen mittels Phishing oder Social Hacking. Was genau das ist, und ab welchem Grad Informationen als sicherheitskritisch zu betrachten sind, sehen wir uns in Kapitel 10, »Informations- preisgabe«, an. Vor einigen Jahren wurde Cross-Site-Scripting in Fachkreisen belächelt — mittlerweile hat sich dort allerdings herumgesprochen, welche erheblichen Gefahren davon ausgehen. Heutzutage wird UI-Redressing, vielen auch unter dem Begriff »Clickja- cking« bekannt, schlichtweg unterschätzt. Viele Entwickler denken, dass auf dem Zielsystem keine Veränderung en vorgenommen werden, insoweit bestünde auch keine große Gefahr. Das ist allerdings ein folgenschwerer Irrtum, denn Clickjacking und Co. bedrohen die Nutzer direkt, teilweise sogar so perfekt, dass man als Sei- tenbetreiber kaum etwas davon mitbekommt. Es gibt jedoch Abhilfe, die wir uns gemeinsam anschauen möchten (siehe Kapitel 11, »UI-Redressing«). Am Ende des Hauptteils möchten wir zwei Dinge genauer betrachten, zum einen die Kombination von bereits bekannten Angriffen und zum anderen sonstige Angriffs vektoren, die nicht direkt Webapplikationen betreffen, letztlich aber auch die Sicher heit von Webangeboten gefährden können (siehe Kapitel 12, »Weitere Angriffsar- ten«). Anschließend möchten wir einen zusammenfassenden Blick zurückwerfen und einige »goldene Regeln« aufstellen. Wenn sich jeder an diese halten würde, wäre schon viel in puncto Websicherheit gewonnen (siehe Kapitel 13, »Die 10 wichtigsten Regeln für Entwickler und Sicherheitsverantwortliche«). Es folgt eine langes Kapitel zu den Tools. Es gibt eine ganze Reihe von nützlichen Tools, die helfen können, Angriffe durchzuführen oder Lücken aufzuspüren. Wir wollen uns die bekanntesten Werkzeuge anschauen, um das zuvor erworbene Wis- sen anzuwenden und in unseren eigenen Systemen nach Lücken suchen zu können (siehe Kapitel 14, »Tools«). Bug-Bounty-Programme können eine organisatorische Maßnahme sein, um Sicher heitslücken in Webapplikationen zu schließen. Wie genau Bug-Bounty-Programme 1.4 Die Grenzen 21

funktionieren und was dabei zu beachten ist, möchten wir in Kapitel 15 näher beleuch- ten (siehe Kapitel 15, »Bug-Bounty-Programme«). An einigen Stellen in diesem Buch werden Sie Methoden kennenlernen, die sich in der realen Welt kaum für das Gute einsetzen lassen. Welche Möglichkeiten es gibt, diese Fertigkeiten dennoch sinnvoll einzusetzen, werden wir in Kapitel 16 behandeln (siehe Kapitel 16, »Legal Webhacking durchführen«). Das Internet der Dinge breitet sich rasant aus, und Kontrollsysteme von Industrie anlangen sind längst vernetzt und lassen sich auch über das Web steuern. Wir möch- ten in Kapitel 17 über sogenanntes SCADA-Hacking sprechen und sehen, welche Angriffsmöglichkeiten sich daraus ergeben (siehe Kapitel 17, »SCADA-Hacking«). Sie werden feststellen, dass die meisten Kapitel nach dem gleichen Schema aufge- baut sind. Zunächst soll die Problematik der Lücke deutlich werden, häufig anhand von Codebeispielen, konkreten Fällen und einfachen Erklärungen, damit im Anschluss eine mögliche Abhilfe betrachtet werden kann.

1.4 Die Grenzen

Es gibt keine absolute Sicherheit — aber immer Maßnahmen zur ihrer Erhöhung. Dieses Buch beschäftigt sich nicht oder kaum mit Lösungen im Rahmen der IT-Infra struktur (etwa Firewalls) oder des Sicherheitsdesigns (Risikomanagement), sondern handelt primär vom Schreiben eines sicheren Codes, also dem Programmieren und der sicheren Konfiguration von Webservern. Es soll dabei helfen, ein Verständnis der Anatomien von Sicherheitslück en in Webanwendungen zu erlangen. Sie sollen dafür sensibilisiert werden, Ihren Code aufmerksamer zu implementieren und Kon- figurationen bewusster vorzunehmen, um die Wahrscheinlichkeit einer angreifbaren Sicherheitslück e zu verringern. Einige Problematiken spezieller Programmiersprachen, wie C/C++, werden in diesem Buch nicht behandelt, da sie extrem komplex sind. Es ist unmöglich, sämtliche Angriffsvektoren und alle denkbaren Codevariationen in einem Buch abzubilden. Die Logik vieler Lücken ist jedoch ähnlich, und die Band- breite der in diesem Buch beschriebenen Lücken so groß, dass Sie nach der Lektüre in der Lage sein sollten, durch kreatives Testen und den Transfer des Wissens weitere Lücken selbst zu identifizieren. Der mittlerweile recht umfangreiche Komplex der Websicherheit entwickelt sich dynamisch weiter. Täglich gibt es neue Tricks aus der dunklen Ecke des Internets und Whitepapers mit neuen Erkenntnissen aus diesem Bereich. Insofern empfiehlt 22 1 Einleitung

es sich, dass Sie sich auch über das Buch hinaus informieren und sich auf dem aktuellen Stand halten.1 Ich werde an geeigneter Stelle Hinweise auf relevante Webprojekte oder weiter führende Literatur geben (siehe Kapitel »Literaturempfehlungen«). Weitere Quellen können Sie dem angehängten Quellenverzeichnis entnehmen. Eine letzte, in der Fachliteratur manchmal vernachlässigte Grenze möchte ich abschließend noch benennen: die der Akzeptanz seitens des Nutzers. Als Sicherheitsverantwortlicher oder Person mit Interesse an IT-Sicherheit neigt man zu Maßnahmen, die zwar unter dem Gesichtspunkt der Sicherheit hervorragend, für den Nutzer aber so lästig sind, dass dieser vom Einhalten dieser Regeln absieht oder die entsprechende Anwendung sogar nicht mehr nutzt. Letzteres wäre gerade im Bereich des Webs ein großes Übel, denn Webanwendungen sind dazu da, benutzt zu werden. Die Empfehlungen in diesem Buch sind fast immer auf größtmögliche Sicherheit angelegt. Deren Befolgung führt nicht zwangsläufig zu einer Optimierung im Sinne der Benutzbarkeit. Bei Veränderungen sollte somit (im Sinne eines ausgewogenen Change-Managements) dafür gesorgt werden, die Akzeptanz der Nutzer zu gewähr- leisten. Die sicherste Webapplikation der Welt bringt nichts, wenn sie nahezu »unbenutzbar« wird. Es besteht beispielsweise oft ein Zielkonflikt zwischen Sicherheit und Benutzer freundlichkeit/Bequemlichkeit (Usability). Es gibt eine Vielzahl weiterer Zielkonflikte, darunter an prominenter Stelle jener zwischen Sicherheit und Rentabilität. Generell gilt es, diese Zielkonflikte durch Kompromisse aufzulösen und abzuwäg en, ob fragliche Ziele in einem noch vertretbaren Maße erreicht und sonstige vitale Inte- ressen nicht erheblich missachtet werden.

1.5 Das (Kern-)Problem

Gleich zu Anfang möchte ich auf ein mögliches Kernproblem zu sprechen kommen, wenn es um die Sicherheit von Webapplikationen geht: Viele Menschen (auch erfahrene Entwickler) denken, dass Applikationen etwas »falsch machen« oder die Sicherheit aufgrund der Applikation selbst nicht gegeben

1 Grundsätzlich möchte ich bereits an dieser Stelle auf das »Open Web Application Security Project« (OWASP) aufmerksam machen, bei dem ich selbst Mitglied bin. Es ist eine Non-Profit-Organisation, die sich gezielt mit dem Thema Sicherheit von Anwendungen im WWW beschäftigt. Mehr dazu unter https://owasp.org/. 1.5 Das (Kern-)Problem 23

ist. Das ist jedoch weit gefehlt, denn Applikationen (und Computer generell) tun immer nur das, wozu sie angewiesen wurden. Sie folgen streng ihrem Ablauf und funktionieren, rein logisch betrachtet, wie sie es sollen. Nur wenn ein Fehler in der Verarbeitung einer Anweisung vorliegt, kommt es auch zu einem Fehler in der Applikation. Und Anweisungen kommen fast aus schließlich von dem Benutzer einer Anwendung. Wir werden in diesem Buch lernen, dass die meisten Fehler erst dann zu Sicherheits- risiken werden, wenn Applikationen von den Entwicklern (während des Program- miervorgangs) nicht klar angewiesen wurden, wie sie zu funktionieren haben.

Bild 1.1: Ein typischer »Fehler«, entstanden durch die doppelte Bedeutung des Worts »Essen«.

Die hier abgebildete Google-Suche (von 2015) zeigt mustergültig, wie schnell es zwischen dem Nutzer und einer Anwendung zu Missverständnissen kommen kann. Es 24 1 Einleitung

bleibt in der Suchformulierung unklar, ob wir »in Paderborn essen gehen« möchten oder von »Paderborn bis nach Essen gehen« möchten. Was in diesem Beispiel harm- los und ein Fehler ohne große Auswirkung ist, kann bei sensiblen Eingaben in komplexen Applikationen schnell zu einem Sicherheitsrisiko werden. Angreifer machen sich oftmals genau eine solche Systematik zunutze. Die Applika tion kann dafür nichts, vielmehr sind es Entwickler und Programmierer, die nicht alle möglichen Fälle bedacht oder aufgefangen haben. Welche Folgen das genau haben kann und wie es uns gelingt, bestmöglichsten Schutz vor solchen »Missverständnis sen« zu erhalten, wollen wir gemeinsam in diesem Buch genauer untersuchen. Mittlerweile (2018) hat Google seiner Suchmaschine die Doppelbedeutung des Wortes »Essen« beigebracht. Einen Hintergrundartikel zu dem Thema finden Sie auf dem Blog zum Buch: https://hacking-im-web.de/blog-semantik-websicherheit.html 2 Evolution des Webs

Bevor wir uns auf die Technik von Webapplikationen und deren Lücken konz entrieren, soll diese Einführung über den historischen Hintergrund erklären, wieso bis heute viele Webapplikationen unsicher sind und weshalb die (Un-)Sicherheit dieser Sys- teme von besonderer Bedeutung ist. Um das zu erreichen, werden die wichtigsten Entwicklungs stufen des Webs kurz umrissen.

2.1 Die Anfänge des Webs

1989 beschäftigte sich Tim Berners-Lee intensiv damit, Informationen und Ergeb- nisse von Forschungsprojekten zu »vernetzen«. Er entwickelte die Grundzüge des Webs, wie wir es heute kennen. In seinem Konzept baute er auf das bereits seit meh- reren Jahren existierende Internet auf und entwickelte die Idee von abrufbaren Web- seiten [4]. Wer sich mit Webseiten beschäftigt, weiß, dass es heute grundsätzlich zwei Typen von Webseiten gibt: zum einen die statischen und zum anderen die dynamischen Webseiten (meist Webapplikationen). 26 2 Evolution des Webs

Zu Beginn des Webs gab es ausschließlich statische Internetseiten, das sind jene, bei denen nur eine geringe Interaktion möglich ist. Einige von ihnen waren sogar reine Textdateien (.txt). Nach und nach wurden die meisten Webseiten allerdings mit einer abstrakten Auszeichnungssprache (HTML) strukturiert und enthalten oft ver schiedene Elemente, die auf Abruf angezeigt werden können. Das Suchen, Eingeben und Verarbeiten von Daten ist auf diesen Webseiten allerdings nicht möglich, sie sind statisch.

Bild 2.1: Die Webseite des CERN-Instituts [5], eine der ersten Webseiten überhaupt — sie war statisch und verwies auf weitere Informationen über das WWW-Projekt.

Der Aufruf solcher Webseiten2 funktioniert bis heute nach folgendem Prinzip: Ein Benut z er navigiert zu einer bestimmten Stelle im Web, lädt ein Dokument herunter, der Inhalt wird interpretiert und dann dem Benutzer angezeigt. Die Übertragung von Inhalten erfolgte also zunächst überwiegend von Server zu Client. Schauen Sie einmal selbst auf der ersten Webseite überhaupt vorbei: http://info.cern.ch/hypertext/WWW/TheProject.html Mit der Zeit versuchte man, Möglichkeiten zu entwickeln, die Benutzerinteraktion zu steigern: Der Benutzer sollte dazu in der Lage sein, durch Eingabe von Daten die Website zu verändern oder Aktionen durchzuführen. Erstrebenswert erschien unter anderem das Verwenden eines Formulars oder die Suche nach gewissen Inhalten

2 Das Internet selbst ist eine Plattform für Dienste, etwa das Web. Im Web gibt es Seiten, deshalb der Begriff »Webseiten«. »Internetseiten« ist streng genommen ein Wort der Umgangssprache und wird deshalb in diesem Fachbuch vermieden. 2.2 Die Boomphase des Webs 27

innerhalb einer Website. Was sich heute banal anhört, da wir es nahezu täglich nutzen, erschien damals bahnbrechend. Bereits 1991 wurde ein solches Vorgehen von einer Datenbankanwendung an der Stanford-Universität genutzt. Der erste Gebrauch dieser Applikation wurde auf deren Website umfassend dokumentiert [6]. Sie gilt bis heute als wohl erste Webappli- kation, da sie in der Lage war, eine Eingabe des Nutzers serverseitig zu verarbeiten, Dokumente zu bearbeiten und diese wieder an den Nutzer auszugeben. Im Laufe der Jahre (etwa um 1993) war es erstmals möglich, auch völlig pro grammiersprachenunabhängig eine Eingabe des Endnutzers serverseitig zu verarbei ten. Dies wurde zur Erstellung von dynamischen Inhalten genutzt. Wenig später folgten weitere Entwicklungen. So wurde PHP (Hypertext PreProces- sor) 1995 als Programmiersprache äußerst beliebt und zusammen mit dem neu ge schaff enen Betriebssystem »Apache HTTP Server« zu einer Art Standard im Web. Bis heute ist der »Apache Server« laut Netcraft Webserver-Survery der meist genutzte Webserver im Internet [7] und PHP eine der beliebtesten Programmier sprachen im Web3. Mit diesen Technologien und Möglichkeiten nahm die Evolution des Webs Fahrt auf, und der Grundstein für moderne Webanwendungen war gelegt. Es schien nur noch eine Frage der Zeit, bis neben Forschungseinrichtungen auch Unternehmen die Tech nologien nutzen wollten, um Vorteile für ihre Geschäftsprozesse zu erzielen.

2.2 Die Boomphase des Webs

Und genau so kam es: 1994 entwickelten zwei Studenten der Stanford-Universität die Idee, eine Art Übersicht über das Web zu schaffen, schließlich sah man sich einem gewaltigen Zuwachs an Webseiten und Informationen ausgesetzt. Wie sollte man den Überblick behalten und die Sachen finden, die man suchte? David Filo und Jerry Yang schufen mit Yahoo! eine der ersten bekannteren Web anwen dung en. Sie wurde zur zentralen Anlaufstelle für viele neue und neugierig e Nutzer, die das Web entdeckten. Ebenfalls 1994 gründeten die beiden Studenten ihr eigenes Unternehmen mit dem Namen »Jerry and David‘s guide to the World Wide Web«, später wurde es in »Yahoo!« umbenannt. Das war offenbar der Moment in der Geschichte des Webs, an dem erstmals klar war, dass es nicht länger eine Randerscheinung von einigen Akademikern oder

3 Das ist der Hauptgrund, weshalb unser Setup für die Testumgebung ebenfalls auf diesen Technologien basiert (dazu später mehr). 28 2 Evolution des Webs

Wissenschaf tlern bleiben würde, sondern dass immer mehr Innovationen in dem Bereich stattfinden würden. Viele große Unternehmen unterschätzten das Web jedoch zunächst und begannen erst recht spät, sich dafür zu interessieren. Dann wurden massenhaft Start-ups im Bereich der Informationsverarbeitung und Informa tionstechnologie in der Hoffnung gegründet, eine entscheidende Innovation im Bereich Web zu erzielen. Damit begann die Zeit der sogenannten »New Economy«, der Boomphase des Webs. Diese Ära endet mit einigen Erfolgsgeschichten, deren Ergebnis man heute noch sehen kann. Zu dieser Zeit entstanden Unternehmen wie Google, eBay, Amazon und Web.de, die heute erfolgreich am Markt etabliert sind (weitere siehe Tabelle unten). Neben den rein kommerziellen Erfolgen wurde auch technisch einiges Neues geschaffen. Viele der damaligen Technologien werden noch heute, allerdings in leicht abgewandelter Form, genutzt. Die wichtigsten Meilensteine sind in der nachfolgenden Tabelle dargestellt.

Jahr Spezifikation Server Client Dienst technologie technologie 1994 HTTP-Cookie Netscape Yahoo Navigator IMDb 0.9 1995 HTML 2.0 Apache HTTP Internet Amazon JavaScript Cold Fusion Explorer 1 eBay Java 1.0 PHP JavaScript Web.de 1996 HTTP/1.0 Active Server Macromedia HotMail Frames Pages (ASP) Flash Archive.org CSS 1997 HTML 4.0 Netscape GMX JavaScript Composer NETFLIX Standardisie- Internet rung Explorer 4 1998 DOM Zope Google

CSS 2 PayPal Diese Phase war für das Web von besonderer Bedeutung, denn durch die enormen Investitionen und die Weiterentwicklung der Lösungen wurde das Web alltäglicher, und viele Standards wurden schnell weiterentwickelt. Immer mehr Menschen in den Industrienationen hatten einen Internetanschluss, zeitgleich wuchs die Anzahl der 2.3 Webapplikationen heute 29

erreichbaren Applikationen im Web. Mitte der 1990er-Jahre bis zur Jahrtausend wende expandierte das Web sehr stark.

2.3 Webapplikationen heute

Die Expansion setzte sich auch nach der Jahrtausendwende fort, und das Angebot im Web ist inzwischen unfassbar groß. Durch die neuen Technologien und einige fin- dige Unternehmen erhielt auch der weniger technikversierte Nutzer die Möglichkeit, Inhalte im Web zu erstellen. Webapplikationen sind heute nicht mehr wegzudenken: Ob wir nur kurz online einen Blick auf das Wetter werfen, uns mit unseren Freunden über ein soziales Netzwerk schreiben, etwas zum Geburtstag unserer Freunde im Onlineshop kaufen, einem Onlinemeeting beitreten oder etwas in der Vertriebsdatenbank ändern — immer nutzen wir auch Webapplikationen. Durch das mobile Internet und Flatrates wurde die Nutzung des Webs im Consumer- bereich weiter intensiviert. Webapplikationen sind weit verbreitete Anwendungen im Businessbereich (sowohl Business-to-Business als auch Business-to-Consumer) und werden zunehmend auch von Behörden (E-Government) genutzt. Nachfolgend sind typische Anwendungen und entsprechende Dienste des heutigen Webs aufgelistet: ] Suche nach Informationen (Nachrichten, Lexika, Wetter etc.) ] Websuche (Suchmaschinen: google.com / yahoo.com / bing.com) ] Soziales Vernetzen (facebook.com / twitter.com / myspace.com) ] E-Mailing (yahoo.com / web.de / gmail.com) ] Einkaufen (E-Commerce: amazon.com / zalando.de) ] Auktionen und Marktplätze (ebay.com) ] Onlinebanking (paypal.com) ] Handel mit Wertpapieren/Kryptowährungen (Bitcoin) ] Onlinewetten/Gewinnspiele/Onlinespiele (Browserspiele) ] Blogs (wordpress.com, blogger.com) ] Medien (spiegel.de / zeit.de / youtube.com) 30 2 Evolution des Webs

Durch das Aufkommen von Smartphones wurde ein zusätzlicher Markt geschaffen. Viele Apps auf Smartphones sind mit Schnittstellen zum Web ausgestattet.4 Es gibt für sehr viele Systeme mittlerweile Schnittstellen im Web, so sind etwa ERP- Systeme über Webapplikationen erreichbar. Auch die Konfiguration von Hardware wird über Webanwendungen durchgeführt, und selbst im Bereich der Industrie maschinensteuerung (ICS) oder der Auswertung und Kontrolle (SCADA) gibt es die Tendenz, Steuerungssysteme über Webapplikationen bedienbar zu machen. Der Vorteil von Webapplikationen ist schlichtweg, dass diese auf nahezu jedem Endgerät lauffähig sind und kaum Ressourcen verbrauchen. Alles in allem ist in der ersten Dekade des 21. Jahrhunderts der Siegeszug des Webs und der von Webapplikationen unübersehbar, es ist der wohl wichtigste, zumindest aber der meistgenutzte, Dienst im Internet geworden. Das Web ist eine Technologie, die das Leben mehrerer Milliarden von Menschen täg lich stark beeinflusst und von ihnen vielfältig genutzt wird. Zudem bauen Unterneh men ihr komplettes Geschäftsmodell darauf auf, und nahezu jedes Unternehmen nutzt Webapplikationen zur Unterstützung des laufenden Betriebs oder der Reprä sentation im Web — aus diesem Grund ist die Sicherheit solcher Systeme sehr wich tig.

2.4 Webapplikationen in der Zukunft

Da es weiterhin einen Zuwachs an Vernetzung zwischen verschiedenen Systemen geben wird, ist zu vermuten, dass das Web ebenfalls in diese Bereiche integriert wird. Mittlerweile wurde mit dem »Internet der Dinge« eine ähnliche Goldgräber- stimmung heraufbeschworen, wie sie einst zu den Boomzeiten des Webs herrschte — viele Hersteller wollen ihre Geräte »smart« machen, dazu nutzen sie meist auch Webapplikationen oder Apps. Es ist sehr wahrscheinlich, dass die Auswertung und vor allem die Darstellung von großen Datenmengen (»Big Data«) durch Webapplikationen erfolgen wird, da diese einfach zu bedienen und nahezu von jedem Endgerät aus zugänglich sind. Im Bereich des E-Government ist damit zu rechnen, dass langfristig eine vermehrte Authentifizierung über das Internet stattfinden wird, Webapplikationen würden eine benutzerfreundliche und plattformunabhängige Möglichkeit darstellen, diese Idee umzusetzen.

4 Die Sicherheit von mobilen Apps ist ein sehr wichtiges, jedoch eigenes Thema, das in diesem Buch nicht vertiefend behandelt wird. Viele der später aufgezeigten Lücken sind aber in ähnlicher Form auch im Bereich der App-Sicherheit möglich. 2.5 Entwicklung der Websicherheit 31

Die Relevanz des Webs wird also angesichts dieser kurz genannten Beispiele in kei- nem Fall abnehmen, es ist eher stark davon auszugehen, dass es mit anderen Tech- nologien zusammen seine Relevanz weiter ausbauen wird.

2.5 Entwicklung der Websicherheit

Websicherheit war fast immer ein eher beiläufiges, ja offenbar für viele unnötiges Thema. Zu Beginn des Webs spielte es gar keine Rolle, denn bei statischen Web- seiten gibt es kaum Möglichkeiten, auf Anwendungsebene Angriffe durchzuführ en. Es war schlicht nicht möglich, als Client komplexe Anweisungen an den Webserv er oder an Subsysteme zu schicken, wenn es sich um eine statische Seite (etwa HTML- Dokumente oder TXT-Dateien) handelte. Ein weiterer Faktor — und wohl ein bedeutender Grund dafür, dass man sich nicht besonders stark um die Sicherheit des Webs kümmerte — war, dass man sich ver- traute; die Nutzer der ersten Stunde waren allesamt Forscher und kannten sich sehr gut. Mehr als die »Vernetzung« von Wissen stellte das Web zunächst nicht dar; es war eine Art wissenschaftlicher Versuch, bei dem damals nicht abzusehen war, was dabei herauskommen würde. Nach dem Aufkommen der ersten größeren Webapplikationen und der Kommerziali sierung Mitte der 1990er-Jahre wurde dann allerdings nach und nach deutlich, dass Sicherheit doch ein extrem wichtiges Thema sein muss — lange Zeit hatte man sich eher darauf konzentriert, auf Netzwerk- bzw. Infrastrukturebene Sicherheit zu schaffen. Viele Unternehmen setzen bis heute teure Enterprise-Firewalls oder komplexe Netzwerk-Firewalls ein, führen die neuesten Softwarepatches durch, verschlüsseln ihre Kommunikation und führen immer wieder Penetration-Tests durch. Sie denken, dass sie sicher vor Angriffen seien, schließlich haben sie eine moderne Firewall, viele Schutzmechanismen und im besten Fall weitreichende Sicherheitsstandar ds. Grundsätzlich bietet diese Art von Maßnahmen auch einen gewissen Schutz, etwa vor sogenannten »Distributed Denial of Service«-Attacken (DDOS, massenhaf ten Anfragen, die eine Dienstüberforderung verursachen), unberechtigten Zugrif- fen und Man-in-the-Middle-Angriffen (MITM-Angriffen), trotzdem können diese Schutzwälle und Maßnahmen allein niemals die Sicherheit eines Systems mit Web applikationen garantieren, da sie auf der Transportebene, nicht aber auf der Applika tionsebene ansetzen. Meist fungieren zum Beispiel die Firewalls nur als eine Art »Türsteher«, durch den gewisse Zugriffe auf Netzwerkdienste zugelassen oder eben unterbunden werden. Diese konventionellen Schutzmaßnahmen stoßen aber bei der Sicherheit von Web anwendungen an ihre Grenzen, da sie oft ausschließlich auf Netzwerkprotokollebene 32 2 Evolution des Webs

analysieren, aber nicht beobachten, was nach dem Durchkommen tatsächlich pas- siert und welche möglicherweise schädlichen Zeichen ein Parameter beinhaltet. Da es immer wieder zu Zwischenfällen und Hacks größeren Ausmaßes kam, fand Anfang der 2000er ein Umdenken statt, das bis heute anhält. Man erkannte, dass gerade im Bereich des Webs eine erhebliche Gefahr bestand, denn: Die Hürde für Angreifer ist oft gering5 — der Schaden kann jedoch enorm sein.6 Es stellt sich also folgende Frage: Wie schafft man es, Webanwendungen sicher zu machen? Die Antwort fällt uns nicht leicht, denn das Web war in der Entwicklung schlicht schneller als seine Macher. Dass sich aus dieser Idee einmal so viel entwickeln würde, war nicht absehbar, deshalb gab es kaum verbindliche Sicherheitsstandards, sondern lediglich RFC (Requests For Comment) oder BCP (Best Current Practice). Nach und nach etablierten sich jedoch auch verbindlichere Internetstandards (STD). 2001 wurde vor allem durch die Gründung des »Open Web Application Security Pro- ject« (OWASP) erstmals vermehrt über das Thema Sicherheit von Webapplik ationen diskutiert. Bis heute stellt diese Organisation eine entscheidende Säule im Bereich der Websicherheit dar. So werden beispielsweise die sogenannten »OWASP Top 10« veröffentlicht, bei denen es sich um die Darstellung der zehn größten Bedrohungen bzw. Sicherheitslücken von Webapplikationen handelt. [8] Erstaunlich ist, dass es bis heute zu vielen Hacks von Webapplikationen über bereits bekannte Angriffsvektoren kommt, obwohl das Thema und entsprechende Problemati k en mittlerweile seit weit über zehn Jahren diskutiert werden. Daran wird jedoch noch einmal deutlich, dass es zum einen kein Allheilmittel gibt und zum anderen offenbar noch keine hinreichende Sensibilisierung aller Entwickler in dem Bereich statt gefunden hat. Oftmals scheint der Fokus beim Lehren einer Programmiersprache nicht in erster Linie auf Sicherheit, sondern auf Funktionsfähigkeit zu liegen. Eine weitere Entwicklung ist, dass Applikationen, die man noch vor fünf Jahren für sicher hielt, heute möglicherweise unsicher geworden sind, weil neue Angriffsvekto ren entdeckt wurden. Es bedarf also wachsamer und informierter Programmierer, um eine fortdauernde Sicherheit zu gewährleisten, da das technische Umfeld sehr dynamisch ist.

5 Oftmals ist nicht einmal das Umgehen einer komplexen Firewall oder die Kenntnis der im Hintergrund arbeitenden IT-Infrastruktur vonnöten, ein simpler Webbrowser mit einigen Erweiterungen genügt, um Schaden anzurichten, wie wir später sehen werden. 6 Überlegen Sie bitte einmal selbst, was der Diebstahl Ihrer Kundendaten oder die Verunstaltung der Webseite für Ihr Unternehmen bedeuten würde. 2.5 Entwicklung der Websicherheit 33

Zwischenzeitlich glaubte man, das Problem von Lücken in Webapplikationen weitge hend in den Griff zu bekommen, indem man sogenannte Web-Application-Firewalls (WAFs) entwickelte. Diese Systeme sollten ähnlich wie Firewalls arbeiten und zum Beispiel auffällige Anfragen blockieren, indem die Inhalte genauer betrachtet und nicht bloß Netzwerkpakete dahingehend kontrolliert wurden, ob der Dienst oder das Protokoll zulässig ist. Tatsächlich führte das aber nicht wirklich zum Erfolg, denn zum einen ist die Implementierung eines solchen Systems mit sehr viel Aufwand ver- bunden, weil es praktisch vor den Webserver geschaltet werden muss und dadurch die Komplexität des Systems erhöht. Und zum anderen gab es immer wieder Zwi schenfälle, bei denen die Filterregeln dieser Firewalls einfach umgangen werden konn ten. Diese WAFs dürften also nur als »Auffangnetz« infrage kommen und halten mög licherw eise unerfahrene Angreifer auf. Es ist allerdings mehr Verlass auf wirklich sicheren Code. Die neuesten Tendenzen im Bereich der Websicherheit bilden sogenannte Bug- Bounty-Programme, bei denen Sicherheitsexperten entlohnt werden, wenn sie Unternehmen eine Lücke in ihrer Applikation verantwortlich melden. Damit wollen Unternehmen dem florierenden Schwarzmarkt im Bereich der Lücken Einhalt gebie- ten und ihre Dienste sicherer machen, um einen Hack und einen damit verbundenen Imageschaden zu vermeiden. Unternehmen, die ein solches System im Einsatz haben, etwa Google [9] und Face- book [10], blieben bis jetzt sogar weitgehend unversehrt. Vielleicht ist diese Art der Websicherheit also auch ein Modell für die Zukunft. Insgesamt ist das Web besonders aufgrund der Durchdringung vieler Lebensbereiche ein bedeutender Teil des Alltags von Privatpersonen und Unternehmen geworden. Diesen vor potenziellen Angreifern zu schützen, erweist sich als zwingend notwen dig. Der Sicherheit von Webapplikationen sollte also eine sehr hohe Relevanz zukom- men, insbesondere in Unternehmen, in denen die eigentliche Wertschöpfung durch Produkte im Web erreicht oder entscheidend unterstützt wird. 34 2 Evolution des Webs Epilog

Hier endet das Buch »Hacking im Web« — was wohl nie enden wird, ist das Hacking im Web selbst. Solange es das Web gibt, gibt es (vermutlich) immer wieder Angrei- fer und Angriffe — aber auch Verteidigungsmöglichkeiten. Bereits heute kann man sehen, welche Folgen es haben kann (Masshacking), wenn Schwachstellen oder Zero-Day-Exploits populärer Produkte oder Webapplikationen im Web auftauchen. Leider ist mit einer weiteren Professionalisierung im Bereich Cybercrime zu rechnen, also sollten Sie gewappnet sein, sich die Hinweise in diesem Buch zu Herzen nehmen und Ihre Webapplikationen entsprechend sichern oder anderen dabei helfen, das zu tun. Bislang geht es bei diesem Kampf meist »nur« um jede Menge Daten, Geld und Pixel — das ist bereits ärgerlich genug. Allerdings scheint in naher Zukunft ein noch viel bedrohlicheres Szenario möglich: Niemand kann genau sagen, was nach dem Einzug von Smart Home, Industrie 4.0 und dem Internet der Dinge für Gefahren entstehen könn(t)en. Die Folgen wären in jedem Fall verheerender, denn dann geht es nicht mehr um nur Einsen und Nullen in Computersystemen oder Pixel auf Bildschirmen, sondern um Auswirkungen in der realen Welt: die Sicherheit von Maschinen, Anlagen und allge mein kritischer Infrastruktur — also auch um unsere persönliche Sicherheit. Bleibt zu hoffen, dass es immer kluge Menschen geben wird, die im richtigen Moment auf der richtigen Seite stehen. Gleiches erbitte ich mir auch von Ihnen, den Lesern dieses Buchs: Seien Sie wach- sam, bleiben Sie kritisch und denken Sie mit. Sicherheit generell kann nie als stati- scher Faktor betrachtet werden, sondern ist ein Weg! Wir haben einen kleinen Teil des Wegs (im Bereich Web) gemeinsam beschritten. Ich hoffe sehr, dass Ihnen unsere gemeinsame Reise und der Besuch so mancher Sehenswürdigkeit (Schwachstelle) gefallen hat und Sie einiges Neues erfahren haben.

Ihre Kommentare Das Buch hat immer noch den Ruf eines Einweg-Kommunikationsmediums, schließ lich gibt es hier — anders als im Web — nicht die Möglichkeit, einen Kommentar zu schreiben oder Nachfragen zu stellen. 472 Epilog

E-Mail-Schlüssel für die Kommunikation Zur Verschlüsselung von E-Mails ist ein öffentlicher Schlüssel unter folgender URL zu finden (oder auf bekannten Schlüsselservern): http://hacking-im-web.de/0x3F8F7EB1.asc

Ich habe eine Webpräsenz erstellt, auf der ich immer wieder Artikel zu aktuellen The- men der Websicherheit veröffentlichen werde und auf der sich weitergehende Infor mationen zum Thema Webhacking, Websicherheit und Onlinekriminalität (auch nach Buchveröffentlichung) finden werden. Besuchen Sie mich doch einfach auf hacking-im-web.de. Ich würde mich sehr freuen, wenn Sie mir mitteilten, wie Sie dieses Buch fanden. Über Anfragen, Rückmeldungen, fachliche Diskurse und Kritik jeder Art freue ich mich und nehme diese gern über folgende E-Mail-Adresse entgegen: buch@tim- philipp-schaefers.de Sie werden von mir hören — mit Sicherheit. Tim Philipp Schäfers, Detmold im Juli 2018 Abkürzungsverzeichnis

AJAX = Asynchronous JavaScript and XML ANSI = American National Standards Institute API = Application Programming Interface ASCII = American Standard Code for Information Interchange ASP.NET = Active Server Pages .NET BCP = Best Current Practice CAPTCHA = Completely Automated Public Turing test to tell Computers and Humans Apart CGI = Common Gateway Interface CMS = Content-Management-System CORS = Cross-Origin Sharing Standard CSRF = Cross Site Request Forgery CSS = Cascading Style Sheets CSP = Content-Security-Policy CSV = Comma-separated Values CVE = Common Vulnerabilities and Exposures DB = Datenbank DBMS = Datenbank-Management-System DDOS = Distributed Denial of Service DIT = Directory Information Tree DOM = Document Object Model DOS = Denial of Service DTD = Document Type Definition DVWA = Damn Vulnerable Web Application ECMA-Script = European Computer Manufactures Association Script 474 Abkürzungsverzeichnis

ERP = Enterprise Resource Planning GUI = Graphical User Interface HSTS = HTTP Strict Transport Security HTML = Hypertext Markup Language HTTP(S) = Hypertext Transfer Protocol (Secure) HMI = Human Machine Interface IDOR = Insecure Direct Object References IDS = Intrusion Detection System IETF = Internet Engineering Task Force IP = Internet Protocol JSF = JavaServer Faces JSON = JavaScript Object Notation JSTL = JavaServer Pages Standard Tag Library LDAP = Lightweight Directory Access Protocol LFI = Local File Inclusion LSO = Local Shared Object MD5 = Message-Digest Algorithm 5 MITM = Man-in-the-Middle OCR = Optical Character Recognition OWASP = Open Web Application Security Project PHP = Hypertext Preprocessor PoC = Proof of Concept PLC = Programmable Logic Controller RCE = Remote Code Execution RFC = Request for Comment RFI = Remote File Inclusion RTU = Remote Terminal Units SGML = Standard Generalized Markup Language Abkürzungsverzeichnis 475

SHA1 = Secure Hash Algorithm SID = Session Identifier SIEM = Security Information and Event Management SMTP = Simple Mail Transfer Protocol SOP = Same-Origin-Policy SQL = Structured Query Language SSL/TLS = Secure Socket Layer SSO = Single Sign-On STD = Standard STS = Strict Transport Security SVG = Scalable Vector Graphics TCP = Transmission Control Protocol TLD = Top Level Domain TLS = Transport Layer Security UID = User Identifier URI = Uniform Resource Identifier URL = Uniform Resource Locator UTF-x = Unicode Transformation Format VBScript = Visual Basic Script VBA = Visual Basic for Applications VPN = Virtual Private Network W3C = World Wide Web Consortium WAF = Web Application Firewall WWW = World Wide Web XFO = X-Frame-Options XHR = XMLHttpRequest-Technologie XHTML = Extensible Hypertext Markup Language XML = Extensible Markup Language 476 Abkürzungsverzeichnis

XPath = XML Path Language XSS = Cross-Site-Scripting XXE = XML External Entity Index

Symbole Authentifizierung 19, 30, 48, 57, 62, %0a 237 186, 202, 205, 223, 239, 244, 261, %0a (New Line) 103, 230, 233 278, 301, 400, 403, 461, 463 2FA (Zwei-Faktor-Authentifizierung) 202, 206 B ´ (Apostroph) 99 Backdoor 218, 223, 227, 287, 334 in SQL-Systemen 133 base64 95 /etc/passwd 210 base64-Codierung 94, 214, 225, 345, .git 265 412, 449 .htaccess 222, 300, 302 bcrypt. Siehe Hashfunktionen # (Rautezeichen) Berners-Lee, Tim 25 in SQL-Systemen 150 Bit 67, 188, 216, 404 Bitcoin 29, 189, 334 A Bot 158, 206, 221, 278, 279, 303, 381, ActionScript 92, 387 427 Active Directory 169 Brute-Force 184, 190, 200, 206, 261, ActiveX 123 277, 303, 402, 406, 409, 410, 413 Adobe Acrobat PDF Reader 124, 426 Brutus 400 Adobe SWF Investigator 386 Bug-Bounty-Programme 20, 33, 223, Ajax 118, 324 435, 441 Alexa 261, 265, 270, 419 Bugcrowd 442 Amazon 28, 29, 63, 328 HackerOne 442 ANSI 137 Burp Suite 353 Apache 27, 28, 109, 215, 222, 300, 301 Extender 365 API 17, 242, 365 Intercept 356 Apple 185 Intruder 359 ASCII 146, 154, 177 Payload Processing 361 ASP.NET 48, 104, 227 Proxy 353 490 Index

Repeater 362 default-src 117, 319 Spider 358 font-ancestors 117 frame-ancestors 319 C frame-src 117 CAPTCHA 71, 201, 202, 206, 221, 288, img-src 116 403 media-src 117 Capture the Flag 441 object-src 116 Cintruder 403 style-src 116 Clickjacking. Siehe UI-Redressing unsafe-eval 117 Clickjacking Tester 431 unsafe-inline 117 Clickjacking Tool 432 X-Content-Security-Policy 116 Client 26, 31, 47, 49, 64, 123, 168, 197, CSRF 62, 64, 70, 81, 82, 246, 313, 316, 230, 309, 463 375, 378, 460 CMS 104, 113, 219, 261, 262, 287, 351, CSRF-Token 71 408, 414, 417 CSRFGenerator 378 Joomla 104, 261, 262, 417 CSS 73, 96, 104, 116, 125, 220, 259, 310, TYPO3 261, 262 314 WordPress 29, 55, 104, 219, 261, 262, Cursorjacking. Siehe UI-Redressing 277, 287, 414, 416 Code-Injection 227 D Content-Security-Policy. Siehe CSP Datenschutz 203, 205, 265, 331, 448 Cookie 28, 48, 54, 63, 66, 68, 75, 76, DDoS 158 92, 93, 120, 121, 213, 230, 231, 323, DDOS 31 360, 372, 374, 382, 385 Dictionary-Angriff 184 httponly 68, 372 DirBuster 413 Cookie-Manipulation 252 Directory Listing 258 Cookie-Replay-Angriff 53 Directory Traversal. Siehe Path Traver- Cookie-Replay-Attacke 377 sal CouchDB 181 Distributed Denial of Service. Siehe Crawler 235, 244, 278, 279, 329 DDOS Cross-Site-Scripting. Siehe XSS DNS 167, 261 CSP 116 DOM 28, 68, 87, 90, 109, 121, 321 connect-scr 117 DOM-Events 78 Content-Security-Policy 116 onclick 78 Index 491

onfocus 78 Google-Bombing 329 oninput 78 Googlebot 381 onkeydown 78 Google-Dorking 280, 305, 334, 445, onkeypress 78 446 onkeyup 78 Google-Hacking. Siehe Google-Dor- onmouseleave 78 king onmouseover 78 Google Hacking Database (GHDB) onmouseup 78 446 onpageshow 78 Google-Safe-Browsing 326 onscroll 78 Google-Suche 191, 326, 423 onsearch 78 onunload 78 H Hackbar 345 E HackIT 439 E-Commerce 17, 29 Hashfunktionen 186, 188 E-Government 29, 316 MD5 188 Exploit 292, 332, 334, 386, 414, 417, RIPEMD-160 189 426, 452 SHA-1 188 Zero-Day-Exploit 332, 335, 471 SHA-2 188 SHA-3 189 F Hash Identifier 403 Facebook 29, 33, 111, 120, 223, 225, Hashing 165 295, 328, 436 Hashkollision 189 Framebreaking. Siehe Frame-Busting Havij 393 Frame-Busting 321 Heiderich, Mario 125, 314 Framekilling. Siehe Frame-Busting HMI 454 (F)PD 258 Honeypot 134, 288 HSTS 66 G HTML 26, 28, 31 GitTools (Finder, Dumper, Extractor) Formular 26 419 HTTP Google 23, 28, 29, 33, 68, 118, 226, 236, GET 360 278, 280, 288, 289, 304, 318, 326, POST 360, 453 328, 329, 331, 368, 409, 423, 436, X-XSS-Protection 120 445, 446, 450, 452, 464, 466 HTTP-Header-Injection 230 492 Index

HTTP Header Live 346 Gleichheit 172 HTTP Strict Transport Security. Siehe Größer-Vergleich 172 HSTS Kleiner-Vergleich 172 Human Machine Interface. Siehe HMI LDAP-Injection 174 LDIF 171 I Master-Slave-Konfiguration 169 ICS 30, 465 Nichtvorhandensein 172 Industry Control System. Siehe ICS o 171 INFORMATION_SCHEMA 137 Operatoren in LDAP 172 COLUMNS 139 ou 171 TABLE_NAME 139 uid 171 Inline-Scripting 117 Ungefähr-Vergleich 172 Internetwache 249, 261, 291 Ungleichheit 172 Vorhandensein 172 J Wildcards 173 JavaScript 70, 77, 90, 93 LDAP Blind Explorer 397 Frame-Busting 321 LDAP-Injection. Siehe LDAP JDBC 164 LDIF. Siehe LDAP John the Ripper 406 LFI 213 joomscan 417 Likejacking. Siehe UI-Redressing Live HTTP headers 346 K Local File Inclusion. Siehe LFI Kali Linux 342 Logdateien 264 Kamkar, Samy 85 Logische Fehler 239 Klein, Amit 88 Long, Johnny 280, 446 Knock Subdomain Scan 409 Lookup-Tabellen 190 Kotowicz, Krzysztof 314 M L Man-in-the-Middle-Angriff 31, 49, 66 LDAP 168 MD5 221, 302, 345, 412. Siehe Hash- Blind-LDAP-Injection 175 funktionen cn 171 Metasploit 427 dc 171 Index 493

Microsoft 48, 105, 169, 294, 319, 388, PHP 391, 423, 436 base64 214 MitM-Angriff. Siehe Man-in-the-Midd- Typsicherer Vergleich 192 le-Angriff Piwik 68, 262 MongoDB 181 PLC 465 Myspace 29, 85, 122 Port 354, 467 MySQL 161 Prepared Statements. Siehe SQL Prezi 436 N Programmable Logic Controller. Siehe Namenskonflikte 249 PLC Neef, Sebastian 7 New Hackbar 344 R NoSQL 181 Rainbow Tables 190 Nullbyte 216 RCE. Siehe Code-Injection Nullbyte-Injection 216 Rechteausweitung 240 Nullbyte Poisoning. Siehe Nullbyte- horizontale Rechteausweitung 240 Injection vertikale Rechteausweitung 241 Referer 71, 372 O Referrer 246 OpenID 223 Remote Code Execution. Siehe Code- OWASP 32, 366, 373, 413, 417, 440 Injection OWASP Zed Attack Proxy (ZAP) 366 Remote File Inclusion. Siehe RFI Requests for Comment. Siehe RFC P Responsible-Disclosure-Programme (F)PD 258 441, 442 Passwort RFC 32, 304 Hashing 165 RFC 821 232, 235 Passwortcracking 189 RFC 1779 171 Passwort-Policy 199 RFC 2254 177 Path Traversal 209 RFC 2849 171 PayPal 28, 29, 212, 290, 436 RFC 4510 171 PDO 161 RFC 5322 232 Pfadpreisgabe. Siehe (F)PD RFC 7034 319 494 Index

RFI 222 SQL RIPEMD-160. Siehe Hashfunktionen ASCII 146 Blind-SQL-Injection 151 S Boolean-based Blind-SQL-Injection Salt 196 152 SCADA 30, 446 CONCAT 147 Schreiber, Thomas 62 concat_ws 139 Scriptless Attacks 125 DELETE 144 SEO 304, 329 Heavy Queries 158 Session INSERT 142 Angriffe 47 limit 146 Session-Fixation 60 Master-Slave-Konfiguration 169 Session-Hijacking 54 MySQL 133, 141, 149, 156, 391, 440 Session-ID 67 MySQL-Error 133 Session-Riding 62, 70 ORDER BY 134 SET. Siehe Social Engineering Toolkit Out-of-Band-SQL-Injection 167 SHA-1 188, 267, 346. Siehe Hashfunk- PostgreSQL 134, 137 tionen Prepared Statements 160 SHA-2. Siehe Hashfunktionen Second-Order-SQL-Injection 147 SHA-3. Siehe Hashfunktionen SLEEP 156 Sharejacking. Siehe UI-Redressing SQL-Injection 128, 129, 132, 391 Shodan 466 SQL-Version 149 SMTP 232 SUBSTRING 146 Hauptteil (Body) 232 Time-based Blind-SQL-Injection 156 Header-Injection 232 UNION 135 Kopfbereich (Header) 232 UPDATE 143 Social Engineering 289. Siehe Social WHERE 143 Hacking SQL-Injection. Siehe SQL Phishing-Angriffe 290 sqlmap 391 Social Hacking 293 SQL-Ninja 388 Social Engineering Toolkit (SET) 424 Stuxnet 466 Social Hacking 293 Subbrute 408 SOP 82, 90, 91, 93, 115 Subdomain 260 Index 495

Suchmaschinenoptimierung. Siehe SEO Safari 120, 326 Supervisory Control and Data WFuzz 410 Acquisition. Siehe SCADA Whirlpool. Siehe Hashfunktionen Wireshark 375 T Wörterbuchangriff 184, 190 Telekom 436 WPScan 414 theHarvester 422 Twitter 29, 85, 122, 249, 292, 423, 436 X Typenunsicherer Vergleich 192 Xenotix XSS Exploit Framework 382 XFO 431 U X-Frame-Options. Siehe XFO UI-Redressing 309, 431 XML 104, 115, 127, 223, 226, 399 Clickjacking 310, 317, 346, 431, 432 XPath 177 Cursorjacking 313 XML-External-Entities-Injection. Siehe Likejacking 312 XXE Sharejacking 312 XPath 177 Uneingeschränkte Dateiuploads 217 Blind-XPath-Injection 180 Unicode 94, 102, 360 XPath-Injection 178 User-Agent 56, 112, 241, 346 XPath Blind Explorer 398 Manipulation 278, 303 XSP, X-WebKit-CSP 116 User Agent Switcher 348 XSS 71, 73, 316, 453 DOM-based XSS 87, 93 V Flash-based XSS 92 Verschlüsselung 66 mXSS 124 persistentes XSS 83, 97 W reflexives XSS 97 Wappalyser 351 self-XSS 88 Webbrowser 80, 104, 112, 116, 159, 215, Social-engineered XSS 89 231, 317, 319, 353, 367, 382, 436, 454 uXSS 91 Chrome 116, 120, 326, 382 XSS-Filter 120 Internet Explorer 91, 116, 120, 123, 319 XSS-Wurm 71, 85, 122 Mozilla Firefox 80, 96, 116, 118, 320, XSSer 379 326, 349, 382, 436 XXE 223 496 Index

Y Z Yahoo 29 Zalando 29, 327 Yahoo! 27, 329 ZAP. Siehe OWASP Zed Attack Proxy YouTube 29, 248 (ZAP) Zeichenkettenkonkatenation 128 Zugriffsrechte 239 Tim Philipp Schäfers AUS DEM INHALT

• Aufbau einer Testumgebung

• Session-Angriffe

• Cross-Site-Scripting

• Injections: Code, Cookie, http- Header, LDAP, SMTP-Header, SQL Hacking und XPath • Grundlagen von LDAP & XPath

• Sicherheit von Authenti zierungs- im Web mechanismen • Kryptogra sche Hashfunktionen

Der Erfolg des E-Commerce hat auch seine Schatten- • Passwortcracking seiten: Hackerangriffe im Web gehören inzwischen • File Inclusion zum Alltag. Es geht dabei nicht nur um unsichere • Zugriffsrechte Firewalls oder Fehler in Betriebssystemen, häu- g stellt die selbst programmierte Webapplikation • Cookie-Manipulation das größte Einfallstor dar. Um sich vor Hackern zu • Informationspreisgabe schützen, ist es wichtig, wie ein Hacker zu denken. • UI-Redressing In diesem Buch lernen Sie die häu gsten Angriffs- methoden kennen und erhalten Tipps, wie Sie sich • Google-Bombing und -Dorking dagegen schützen können. Analysieren Sie Ihren • Exploits Programmcode auf Schwachstellen und schließen • Hackertools Sie die Lücken gleich in der Implementierungsphase.

Die wichtigsten Angriffsvektoren Durch die Kombination verschiedenster Technologien wie Browser, HTML, JavaScript, PHP, Java und SQL in Webanwendungen sind die potenziellen Schwachstellen quasi unzähl- bar. Ob SQL-Injection, Cross-Site-Scripting oder Session-Hijacking: Lernen Sie die Funktionsweise dieser Angriffe kennen, stellen Sie Ihr Können beim Angreifen der Testumgebung unter Beweis Übersichtliche Diagramme erläutern und schützen Sie sich mit den aufgeführten Tipps das Vorgehen bei einem Angriff. erfolgreich vor Angriffen.

Werkzeuge kennen und nutzen Entwickler sind keine Sicherheitsexperten und können nicht jede Schwachstelle der eingesetzten Programmiersprache und Bibliotheken kennen. Umso wichtiger ist es, die entstandene Web- anwendung auf ihre Schwachpunkte zu testen. Schäfers stellt in einem ausführlichen Anhang zahlreiche Werkzeuge vor, mit denen Sie effektiv nach Schwachstellen suchen können. Anfällige Webanwendungen gefährden auch Industrie-4.0-Betriebe wie Biogasanlagen.

Besuchen Sie 40,– EUR [D] unsere Website ISBN 978-3-645-60636-3 www.franzis.de

60636-3.indd 1