You've been hacked!

Alles über Exploits gegen Webanwendungen
 
 
Rheinwerk (Verlag)
  • 1. Auflage
  • |
  • erschienen am 21. Dezember 2018
  • |
  • 578 Seiten
 
E-Book | ePUB mit Wasserzeichen-DRM | Systemvoraussetzungen
978-3-8362-4462-6 (ISBN)
 

Ihr Guide für sichere Webanwendungen

  • Sicherheitslücken in Webanwendungen aufspüren und schließen
  • Code analysieren, Praxisszenarien durchspielen, Hintergründe verstehen
  • Web-Hacking Für Penetration Tester und Entwickler
Sie müssen in der Webentwicklung zahlreiche Schwachstellen beachten, die sonst dafür sorgen, dass Ihr Code zum Einfallstor für Hacker und Schadsoftware wird. Welche Hacking-Gefahren auf Ihre Webanwendungen lauern, zeigt Ihnen dieser praxisorientierte Guide: von Authentifizierungsproblemen bis zum Cross Site Scripting, von Code Injections bis zu Architektur-Angriffen. Mit kommentierten Codebeispielen echter Schadsoftware und Beispielanwendung zum Ausprobieren.

Aus dem Inhalt:

  • Diese Schwachstellen müssen Sie kennen: Die OWASP Top 10
  • Testumgebung, Tools und Hilfsmittel
  • Ziele erkunden, Informationen sammeln
  • Zustandsbasierte Angriffe: Cookies, URLS, Sessions
  • Authentifizierung, Passwortsicherheit, Hashes
  • Cross Site Scripting: Reflektiertes, persistentes, DOM-basiertes XSS
  • SQL-Injections
  • Weitere Injections: OS-Code, XPATH, SOAP, SMTP, LDAP
  • Directory Traversal
  • Grundlagen: Pufferüberläufe, Formatstrings und mehr
  • Architektur-Probleme
  • Angriffe auf Webserver
1. Auflage
  • Deutsch
  • Bonn
  • |
  • Deutschland
  • Neue Ausgabe
  • 10,66 MB
978-3-8362-4462-6 (9783836244626)
weitere Ausgaben werden ermittelt
Carsten Eilers (Dipl.-Inf.) ist Pen-Tester und hat zahlreiche Projekte im Bereich der IT-Sicherheit und des Datenschutzes erfolgreich durchgeführt. Seit 2005 ist er als freier Berater und Coach für IT-Sicherheit und technischen Datenschutz selbständig tätig.


Materialien zum Buch ... 16


1. Über dieses Buch ... 17


1.1 ... Was dieses Buch ist ... 17

1.2 ... Welche Schwachstellen gibt es? ... 18

1.3 ... Wie findet man Schwachstellen? ... 23

1.4 ... Einige Tools im Überblick ... 24

1.5 ... Die Demo-Anwendung ... 32

1.6 ... OWASP Top 10 Platz 10: Insufficient Logging & Monitoring ... 53

1.7 ... Links ... 57



2. Das Ziel erkunden ... 59


2.1 ... Offensichtliche Informationen sammeln ... 59

2.2 ... Nicht offensichtliche Informationen sammeln ... 62

2.3 ... Die Untersuchung des Clients ... 63

2.4 ... Die Demo-Anwendung ... 69

2.5 ... Links ... 104



3. Zustandsbasierte Angriffe ... 105


3.1 ... Angriffe auf Zustandsinformationen ... 105

3.2 ... URL-Jumping ... 111

3.3 ... Session-Hijacking ... 114

3.4 ... Session-Fixation ... 117

3.5 ... Clickjacking ... 120

3.6 ... Cross-Site-Request-Forgery ... 126

3.7 ... Die Demo-Anwendung ... 129

3.8 ... Links ... 143



4. Angriffe auf die Authentifizierung ... 145


4.1 ... Einführung: Authentifizierung -- einfach, und doch so schwer ... ... 145

4.2 ... Designfehler ... 154

4.3 ... Ungeschützt übertragene Zugangsdaten ... 163

4.4 ... Funktion zum Ändern des Passworts ... 173

4.5 ... Passwort-Reset ... 178

4.6 ... »Remember me« ... 182

4.7 ... User Impersonation ... 184

4.8 ... »Halbe Passwörter« ... 186

4.9 ... Nicht eindeutige Benutzernamen und doppelte Benutzer ... 188

4.10 ... Vorhersagbare Benutzernamen ... 191

4.11 ... Vorhersagbare Passwörter ... 193

4.12 ... Übertragung der Zugangsdaten »out of band« ... 194

4.13 ... Fehler in mehrstufigen Systemen ... 196

4.14 ... Unsichere Speicherung von Zugangsdaten ... 198

4.15 ... Fail-Open-Mechanismen ... 206

4.16 ... Die Demo-Anwendung ... 206

4.17 ... Sichere Authentifizierung ... 212

4.18 ... Links ... 221



5. Cross-Site-Scripting ... 227


5.1 ... XSS-Schwachstellen im Überblick ... 227

5.2 ... Schutzmaßnahmen im Browser ... 232

5.3 ... Angriffe über XSS ... 238

5.4 ... Webwürmer ... 263

5.5 ... Reflektiertes XSS finden ... 282

5.6 ... Persistentes XSS finden ... 288

5.7 ... DOM-basiertes XSS finden ... 293

5.8 ... XSS verhindern ... 295

5.9 ... Die Demo-Anwendung ... 298

5.10 ... Links ... 340



6. SQL-Injection ... 345


6.1 ... Einführung ... 345

6.2 ... SQL-Injection im Überblick ... 348

6.3 ... SQL-Injection: Schwachstellen finden ... 351

6.4 ... Angriffe »in the wild« ... 371

6.5 ... SQL-Injection verhindern ... 378

6.6 ... Die Demo-Anwendung ... 382

6.7 ... Links ... 406



7. Injection jenseits von SQL ... 407


7.1 ... OS-Command-Injection ... 407

7.2 ... SMTP-Injection ... 413

7.3 ... LDAP-Injection ... 419

7.4 ... NoSQL-Injection ... 424

7.5 ... Scriptcode-Injection ... 425

7.6 ... SOAP-Injection ... 429

7.7 ... XPath-Injection ... 434

7.8 ... Injection-Angriffe abwehren ... 437

7.9 ... Die Demo-Anwendung ... 440

7.10 ... Links ... 451



8. Dateioperationen: von Directory-Traversal bis Datei-Uploads ... 453


8.1 ... Directory-Traversal ... 453

8.2 ... Sonderfall PHP: Local File Inclusion ... 461

8.3 ... Der Schadcode: Webshells ... 463

8.4 ... Suche nach Directory-Traversal-Schwachstellen ... 475

8.5 ... Abwehr von Directory-Traversal-Angriffen ... 479

8.6 ... Remote File Inclusion ... 481

8.7 ... Datei-Uploads ... 485

8.8 ... Die Demo-Anwendung ... 496

8.9 ... Links ... 506



9. Ein kleiner Exkurs: Pufferüberläufe, Integer-Schwachstellen und Format-Strings ... 509


9.1 ... Pufferüberlauf ... 510

9.2 ... Integer-Schwachstellen ... 519

9.3 ... Format-String-Schwachstellen ... 522

9.4 ... Die Demo-Anwendung ... 524

9.5 ... Links ... 525



10. Angriffe auf die Architektur ... 527


10.1 ... Schichtenarchitekturen ... 527

10.2 ... Shared Environments ... 531

10.3 ... Kurz zur Cloud ... 537

10.4 ... Die Demo-Anwendung ... 537

10.5 ... Links ... 537



11. Angriffe auf den Webserver ... 539


11.1 ... Webserver identifizieren ... 539

11.2 ... Webserver angreifen ... ... 542

11.3 ... Abwehr der Angriffe ... 553

11.4 ... Sichere Konfiguration ... 558

11.5 ... Die Demo-Anwendung ... 559

11.6 ... Links ... 563



Index ... 569

1.2    Welche Schwachstellen gibt es?


Das Open Web Application Security Project (OWASP) veröffentlicht alle paar Jahre eine Liste mit den Top 10 der größten Bedrohungen für Webanwendungen [OWASP_Top10][ 1 ]. Aktuell ist derzeit die Version 2017, die im Herbst 2017 veröffentlicht wurde [OWASP_Top10-2017]. Aber wie es bei Top 10 üblich ist, gibt es noch viel mehr Bedrohungen, Schwachstellen, Angriffe ... Und ob die Top 10 wirklich so eine große Bedrohung sind, ist auch immer relativ. Auf Platz 4 stehen die XML External Entities (XXE). Für Webanwendungen, die XML gar nicht nutzen, ist das völlig harmlos. Was nicht da ist, kann auch nicht angegriffen werden.

Das ist aber auch nicht weiter schlimm, die OWASP Top 10 sollen ja gar nicht dazu dienen, z. B. Schwachstellentests zu planen oder die Sicherheit einer Webanwendung zu bewerten, sondern das Bewusstsein für diese Schwachstellen zu schärfen. Woraufhin diese hoffentlich seltener werden und dann irgendwann aus den Top 10 herausfallen.

Auch in dieser Version gab es einige Änderungen zur Vorgängerversion von 2013. So ist z. B. das Cross-Site-Scripting von Platz 3 auf Platz 7 gefallen, dafür ist der Punkt »Sensitive Data Exposure«/»Preisgabe sensibler Daten« von Platz 6 auf Platz 3 aufgestiegen. Die Cross-Site-Request-Forgery, die 2013 noch auf Platz 8 stand, ist inzwischen aus den Top 10 heraus und ungefähr auf Platz 13 gelandet [OWASP_Top10-2017-RC2]. Wenn Sie jetzt nur Bahnhof verstanden haben: Keine Angst, die ganzen Schwachstellen werde ich im Laufe des Buchs noch erklären.

Aber weil ich gerade von der Bewertung der Sicherheit von Webanwendungen geschrieben habe: Wieso muss ich da bloß immer an die Quartette aus meiner Kindheit denken? »Ich habe drei XSS und eine Sensitive Data Exposure« - »Und ich habe drei SQL-Injections und zwei OS-Command-Injections« - »OK, Du hast gewonnen, hier ist meine Karte. Du bist dran!«

Vermutlich, weil ich das für Spielerei halte. Jede Software und damit auch jede Webanwendung sollte möglichst gar keine Schwachstellen enthalten, egal, wie leicht oder schwer sie auszunutzen und wie gefährlich die Folgen eines Angriffs sind.

Natürlich ist es schlimm, wenn über z. B. eine SQL-Injection-Schwachstelle sämtliche Datenbanken ausgespäht werden. Aber was ist, wenn über eine persistente XSS-Schwachstelle Code zur Infektion der Rechner aller Besucher der Website eingeschleust wird - was ist dann schlimmer?

Im ersten Fall betrifft es einige Tausend registrierte Benutzer, deren Zugangsdaten und Kreditkartennummern von den Cyberkriminellen gehandelt werden. Im zweiten Szenario sind es einige zig Tausend arglose Besucher, deren Rechner nach dem Besuch mit einem Onlinebanking-Trojaner infiziert ist. Was ist schlimmer?

Oder vielleicht wurde die Webanwendung ja auch von einem Geheimdienst über einen Fehler in der Authentifizierung gezielt infiziert, um sie für den Angriff auf den Rechner eines Dissidenten zu präparieren? Sie wissen ja: Die Dissidenten und Terroristen der einen Seite sind für die andere unschuldig Verfolgte und Freiheitskämpfer. Wie soll man das bewerten?

Ich denke, wir sind uns hier einig: Jede einzelne Schwachstelle in einer Webanwendung ist eine zu viel. Und Ranglisten haben immer etwas Subjektives, über das man sich streiten kann.

1.2.1    Die OWASP Top 10


In den OWASP Top 10 vom 2017 [OWASP_Top10-2017] sind folgende Bedrohungen enthalten:

  • A1:2017 - Injection

    Enthält Schwachstellen wie die SQL-Injection (siehe Kapitel 6), OS-Command- und SMTP-Injection (beide in Kapitel 7) und andere Schwachstellen, bei denen der Angreifer eigene Befehle in Interpreter und Ähnliches einschleusen kann

  • A2:2017 - Broken Authentication (gebrochene Authentifizierung)

    Wer Benutzer hat, muss sie identifizieren können. Das nennt man Authentifizierung, und jeder Fehler darin erlaubt es einem Angreifer, sich als anderer Benutzer auszugeben und/oder unbefugt auf die Webanwendung zuzugreifen (siehe Kapitel 4, »Angriffe auf die Authentifizierung«).

  • A3:2017 - Sensitive Data Exposure (Preisgabe sensibler Daten)

    Das ist ein weites Feld. Dazu gehören unverschlüsselt übertragene Zugangsdaten, die dann unterwegs belauscht werden können, oder offen zugängliche Dateien mit vertraulichen Daten (siehe z. B. Kapitel 6, »SQL-Injection«).

  • A4:2017 - XML External Entities (XXE)

    Wird XML verwendet, kann es über XML External Entities manipuliert werden. XML und damit XXE kommen hier im Buch nicht vor.

  • A5:2017 - Broken Access Control (gebrochene Zugriffskontrolle)

    Die Authentifizierung stellt sicher, dass Sie wissen, wer der Benutzer ist. Genauso wichtig ist aber die Zugriffskontrolle oder Autorisierung: Darf der Benutzer das, was er gerade machen will, überhaupt? Hier im Buch kommt das z. B. in Kapitel 3, »Zustandsbasierte Angriffe«, vor.

  • A6:2017 - Security Misconfiguration (sicherheitsrelevante Fehlkonfiguration)

    Alles, was sich konfigurieren lässt, lässt sich auch unsicher konfigurieren, z. B. wenn für die TLS-Verschlüsselung unsichere Kryptoverfahren verwendet werden oder wenn ein eigentlich nötiger Passwortschutz vergessen wird, so dass Teile der Webanwendung frei zugänglich sind, statt wie geplant nur bestimmten Benutzern offenzustehen. Das kommt im Buch an verschiedenen Stellen vor.

  • A7:2017 - Cross-Site-Scripting (XSS)

    Das Einschleusen von bösartigem JavaScript-Code in die Webanwendung erlaubt alle möglichen Angriffe, beispielsweise kann darüber der Benutzer ausgespäht oder sein Rechner mit Schadsoftware infiziert werden.

  • A8:2017 - Insecure Deserialization (unsichere Deserialisierung)

    Werden Daten serialisiert gespeichert (vereinfacht werden dabei komplizierte Strukturen einfach hintereinander weg in eine Variable geschrieben), müssen sie später wieder deserialisiert, d. h. in die Ausgangsdaten zurückverwandelt werden. Ein Angreifer kann eine Schwachstelle dabei ausnutzen, um Daten zu manipulieren. Dies kommt im Buch nicht vor.

  • A9:2017 - Using Components with known Vulnerabilities (Nutzung von Komponenten mit bekannten Schwachstellen)

    Wenn Sie die Demo-Anwendung als Blog in Ihre Webanwendung integrieren, haben Sie dieses Problem. Spaß beiseite: Hier geht es wirklich darum, dass z. B. Bibliotheken mit bekannten Schwachstellen verwendet werden. Das Problem sind dabei weniger die direkt genutzten Komponenten, die kennen Sie hoffentlich und können sie aktuell halten. Aber wie sieht es mit den Dritthersteller-Komponenten aus, die diese von Ihnen genutzten Komponenten verwenden? Wer sorgt dafür, dass diese immer in einer sicheren Version verwendet werden? Sie können das kaum, dazu müssten Sie nämlich wissen, welche Komponenten das sind, und wenn es ein Update gibt, prüfen, ob Sie das einfach so installieren können oder ob danach irgendetwas mit der Komponente nicht mehr funktioniert. Das wird nie was. Im Buch kommt dies Thema aber nicht vor.

  • A10:2017 - Insufficient Logging & Monitoring (unzureichende Protokollierung und Überwachung)

    Das ist wie die XXE auf Platz 4 ein Neuzugang in den Top 10 2017. Da es sich weder um eine Schwachstelle in der Webanwendung noch um einen Angriff darauf handelt, passt es eigentlich nicht richtig in die Liste. Dabei ist es doch sehr wichtig, denn wenn Sie nicht merken, dass jemand versucht, Ihre Webanwendung anzugreifen, können Sie den Angriff auch nicht abwehren. Dieses Thema werde ich in Abschnitt 1.6 kurz behandeln.

1.2.2    Weitere Schwachstellen


Außerdem stelle ich im Buch Schwachstellen vor, die nicht in den Top 10 enthalten oder gerade hinausgerutscht sind, z. B. Clickjacking, das es nie in die Top 10 geschafft hat und unter dessen Variante »Likejacking« - Angriffe auf den »Like«-Button - Facebook sehr gelitten hat. Ich würde wetten, dass Mark Zuckerberg Clickjacking ziemlich weit oben in den Top 10 sehen würde. Auch die schon erwähnte CSRF, die 2017 aus den Top 10 ausschied, kommt im Buch vor.

1.2.3    Gliederung des Buchs


Die Gliederung richtet sich nach einem möglichen Vorgehen bei der Suche nach Schwachstellen: Zunächst erkunden Sie die Webanwendung, dann suchen Sie entweder systematisch schrittweise nach den verschiedenen Schwachstellen (wenn Sie alle finden möchten) oder gezielt...

Dateiformat: ePUB
Kopierschutz: Wasserzeichen-DRM (Digital Rights Management)

Systemvoraussetzungen:

Computer (Windows; MacOS X; Linux): Verwenden Sie eine Lese-Software, die das Dateiformat EPUB verarbeiten kann: z.B. Adobe Digital Editions oder FBReader - beide kostenlos (siehe E-Book Hilfe).

Tablet/Smartphone (Android; iOS): Installieren Sie bereits vor dem Download die kostenlose App Adobe Digital Editions (siehe E-Book Hilfe).

E-Book-Reader: Bookeen, Kobo, Pocketbook, Sony, Tolino u.v.a.m. (nicht Kindle)

Das Dateiformat ePUB ist sehr gut für Romane und Sachbücher geeignet - also für "fließenden" Text ohne komplexes Layout. Bei E-Readern oder Smartphones passt sich der Zeilen- und Seitenumbruch automatisch den kleinen Displays an. Mit Wasserzeichen-DRM wird hier ein "weicher" Kopierschutz verwendet. Daher ist technisch zwar alles möglich - sogar eine unzulässige Weitergabe. Aber an sichtbaren und unsichtbaren Stellen wird der Käufer des E-Books als Wasserzeichen hinterlegt, sodass im Falle eines Missbrauchs die Spur zurückverfolgt werden kann.

Weitere Informationen finden Sie in unserer E-Book Hilfe.


Download (sofort verfügbar)

35,90 €
inkl. 7% MwSt.
Download / Einzel-Lizenz
ePUB mit Wasserzeichen-DRM
siehe Systemvoraussetzungen
E-Book bestellen