Web Application Security, 2. Auflage

Vorwort

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Willkommen bei Web Application Security: Exploitation and Countermeasures for Modern Web Applications. In diesem Vorwort gehen wir auf den Inhalt des Buches ein und erläutern, für wen dieses Buch gedacht ist und welche Fähigkeiten erforderlich sind, um die technischen Inhalte der folgenden Kapitel optimal nutzen zu können. Die Lektüre des Vorworts wird dir dabei helfen, herauszufinden, ob dieses Buch etwas für dich ist.

Änderungen gegenüber der ersten Ausgabe

Wenn du dieses Buch mit der ersten Auflage vergleichst, wirst du eine ganze Reihe von Änderungen feststellen. Es gibt über hundert neue Seiten, aber darüber hinaus gibt es Dutzende von überarbeiteten Seiten.

Die erste Ausgabe richtete sich in erster Linie an Einsteiger und Ingenieure der mittleren Ebene, aber in den Rückmeldungen wurde häufig der Wunsch nach fortgeschritteneren Inhalten geäußert, mit denen man für jedes Kapitel einen bestimmten Lernpfad einschlagen kann. In den meisten Kapiteln werden nun fortgeschrittene Inhalte angeboten, und so hoffe ich, dass auch erfahrene Sicherheitsexperten mehr von der Lektüre dieses Buches profitieren werden.

Außerdem wurde das Buch in erheblichem Umfang aktualisiert, um die neuesten Technologien einzubeziehen. Ich hielt es für unerlässlich, Beispielfälle und Code für die Sicherung und den Angriff auf neue, aber gängige Technologien in Webanwendungen hinzuzufügen, zum Beispiel GraphQL und NoSQL-Datenbanken.

Die zweite Ausgabe enthält zahlreiche neue Sicherheitsinhalte, darunter die neuesten und beliebtesten Webanwendungstechnologien. Außerdem wurde das Buch so überarbeitet, dass es mehr fortgeschrittene Inhalte pro Kapitel enthält und Dutzende, wenn nicht Hunderte von Vorschlägen und Wünschen von Lesern und Redakteuren berücksichtigt.

Ich hoffe, dass du dieses Buch gut organisiert findest und es dir Spaß macht, es zu lesen, und dass du nach der Lektüre mit neuem Wissen und neuen Perspektiven nach Hause gehst, die deine Fähigkeiten im Bereich Informationssicherheit verbessern.

Vorausgesetztes Wissen und Lernziele

In diesem Buch lernst du nicht nur, wie du deine Webanwendung gegen Hacker verteidigen kannst, sondern erfährst auch, welche Schritte Hacker unternehmen, um eine Webanwendung zu untersuchen und in sie einzubrechen.

In diesem Buch werden wir viele Techniken besprechen, mit denen Hacker heute in Webanwendungen einbrechen, die von Unternehmen, Regierungen und gelegentlich sogar von Hobbyisten betrieben werden. Nachdem wir die oben genannten Techniken ausreichend untersucht haben, diskutieren wir, wie man Webanwendungen gegen dieseHacker schützen kann.

Dabei wirst du ganz neue Denkansätze für die Anwendungsarchitektur entdecken. Außerdem lernst du, wie du bewährte Methoden für die Sicherheit in eine Entwicklungsorganisation integrieren kannst. Schließlich werden wir eine Reihe von Techniken zur Verteidigung gegen die häufigsten und gefährlichsten Arten von Angriffen auf Webanwendungen evaluieren, die heutzutage auftreten.

Nach Abschluss des Kurses Web Application Security verfügst du über das erforderliche Wissen, um Aufklärungsmaßnahmen gegen Anwendungen durchzuführen, auf die du keinen Zugriff auf Code-Ebene hast. Du wirst auch in der Lage sein, Bedrohungsvektoren und Schwachstellen in Webanwendungen zu identifizieren und Nutzdaten zu erstellen, die Anwendungsdaten kompromittieren, den Ausführungsfluss unterbrechen oder die beabsichtigte Funktion einer Webanwendung stören.

Mit diesen Kenntnissen und dem Wissen aus dem letzten Abschnitt über die Absicherung von Webanwendungen wirst du in der Lage sein, risikobehaftete Bereiche in der Codebasis einer Webanwendung zu erkennen und zu verstehen, wie du Code zur Abwehr von Angriffen schreibst, die deine Anwendung und ihre Nutzer/innen sonst gefährden würden.

Hinweis

Der Inhalt dieses Buches steigert sich nach und nach. Wenn du also etwas überspringst und feststellst, dass dir wichtige Informationen fehlen, kannst du einfach ein paar Kapitel zurückgehen und sie nachholen. Alle Themen, die in diesem Vorwort nicht als Voraussetzung definiert sind, sollten im Buch nicht ohne vorherige Erklärung behandelt werden.

Warum sind Beispiele in JavaScript?

Die meisten Codebeispiele in diesem Buch sind in JavaScript geschrieben, was untypisch für Bücher über Software-Sicherheit ist. Du fragst dich vielleicht, warum ich mich bei der Planung des Buches dafür entschieden habe.

Alle guten Sicherheitsingenieure müssen JavaScript verstehen, denn es ist die einzige Programmiersprache, die derzeit auf dem Client in einem Webbrowser ausgeführt werden kann. Deshalb habe ich beschlossen, dass es besser ist, die meisten serverseitigen Beispiele in JavaScript zu präsentieren, da die clientseitigen Beispiele in JavaScript sein müssen. Glücklicherweise sind Programmiersprachen größtenteils austauschbar. Wenn du also in der Lage bist, den Inhalt konzeptionell zu verstehen, solltest du in der Lage sein, jeden der serverseitigen Angriffe oder Abhilfemaßnahmen auf jede andere serverseitige Programmiersprache anzuwenden.

Warum Konzepte und nicht Werkzeuge unterrichten?

Dieses Buch erklärt offensive und defensive Cybersicherheitstechniken auf einem relativ niedrigen Niveau, um zu zeigen, was unter der Haube gängiger Tools passiert. In diesem Buch entwickelst du zum Beispiel Cross-Site Scripting (XSS)-Nutzlasten und findest XSS-Senken, anstatt ein automatisches XSS-Entdeckungstool wie XSS-Sniper zu verwenden.

Viele Sicherheitsingenieure und Pen-Tester verstehen heute nicht, was hinter den Tools steckt, die sie regelmäßig benutzen. Das hat den Nachteil, dass die Abhängigkeit von Tools dazu führt, dass diese Ingenieure und Pen-Tester nicht in der Lage sind, fortschrittliche Angriffe oder Abhilfemaßnahmen zu nutzen. Darüber hinaus sind die Tools in der Anwendungssicherheitsbranche sehr kurzlebig, d.h. sie werden regelmäßig ausgetauscht und veralten.

Da die zugrunde liegenden Konzepte vermittelt werden, anstatt sich auf kostenpflichtige Tools zu stützen, sollte jeder, der dieses Buch liest, in der Lage sein, von einem Tool zum anderen zu wechseln oder benutzerdefinierte Tools, Angriffe oder Abhilfemaßnahmen einzusetzen. Das wäre nicht möglich, wenn sich das Buch auf bestimmte Tools konzentrieren würde.

Vorgeschlagener Hintergrund

Das Buch richtet sich an ein breites Publikum. Es ist für alle geschrieben und strukturiert, die über mittlere Kenntnisse in der Softwareentwicklung verfügen. Was ist ein "mittleres Niveau in der Softwareentwicklung"? Die Antwort wird von Person zu Person sehr unterschiedlich ausfallen.

Für eine hochtechnische Person könnte dieses Buch eigentlich nur ein Anfängerwissen in Softwareentwicklung erfordern. Mit anderen Worten: Ein Systemadministrator mit Vorkenntnissen in der Webentwicklung und/oder Skripterstellung (sofern diese ausreichen) kann dieses Buch lesen und alle Beispiele verstehen. Allerdings enthält dieses Buch Beispiele, die sowohl Kenntnisse in der Client- als auch in der Serverprogrammierung erfordern. Es reicht nicht aus, nur das eine oder das andere zu kennen, um diese Beispiele zu verstehen.

Dieses Buch enthält auch Diskussionen über grundlegende Client/Server-Netzwerke über HTTP. In späteren Kapiteln werden wir uns auch mit der Software-Architektur befassen und Wege finden, um eigene Software mit der Software von Drittanbietern zu integrieren und gleichzeitig die Sicherheitsrisiken zu minimieren.

Da in diesem Buch so viele Themen behandelt werden, habe ich mich dafür entschieden, das erforderliche Qualifikationsniveau für den erfolgreichen Abschluss dieses Buches als "fortgeschritten" und nicht als "Anfänger" zu definieren. Dieses Buch ist nicht für diejenigen geeignet, die keine Erfahrung oder Kenntnisse im Schreiben von Softwareanwendungen in Produktionsqualität haben.

Erforderliche Mindestfähigkeiten

Unter wird in diesem Buch ein "mittlerer Hintergrund in Softwareentwicklung" vorausgesetzt:

• Du kannst grundlegende CRUD-Programme (Erstellen, Lesen, Aktualisieren, Löschen) in mindestens einer Programmiersprache schreiben.

• Du kannst Code schreiben, der irgendwo auf einem Server läuft (z. B. Backend-Code).

• Du kannst zumindest etwas Code schreiben, der in einem Browser läuft (Frontend-Code, normalerweise JavaScript).

• Du weißt, was HTTP ist, und kannst GET/POST-Aufrufe über HTTP in einer Sprache oder einem Framework tätigen oder zumindest lesen.

• Du kannst Anwendungen schreiben oder zumindest lesen und verstehen, die sowohl serverseitigen als auch clientseitigen Code verwenden und zwischen beiden über HTTP kommunizieren.

• Du bist mit mindestens einer gängigen Datenbank vertraut (MySQL, MongoDB, etc.).

Diese Fähigkeiten sind die Mindestvoraussetzungen für die erfolgreiche Umsetzung der Beispiele in diesem Buch. Jede Erfahrung, die du über diese Punkte hinaus hast, ist ein Pluspunkt und macht es dir leichter, dieses Buch zu lesen und daraus einen pädagogischen Nutzen zu ziehen.

Hinweis

Obwohl die meisten Codebeispiele in diesem Buch der Einfachheit halber in JavaScript geschrieben sind (so dass der Client- und der Servercode in der gleichen Sprache sind), können die meisten Beispiele mit wenig Aufwand auf andere Sprachen übertragen werden.

Ich habe mein Bestes getan, um die Themen in diesem Buch so zu gliedern, dass sie in einem vertretbaren Tempo an Schwierigkeit zunehmen. Außerdem habe ich versucht, meine Erklärungen so ausführlich wie möglich zu halten. Das bedeutet, dass ich jedes Mal, wenn ich eine neue Technologie behandle, mit einem kurzen Hintergrund und einem Überblick darüber beginne, wie diese Technologie funktioniert.

Wer profitiert am meisten vom Lesen dieses Buches?

Abgesehen von den Vorkenntnissen halte ich es für wichtig, zu klären, wer am meisten von diesem Buch profitieren wird, deshalb möchte ich erklären, wer meine Zielgruppe ist. Zu diesem Zweck habe ich diesen Abschnitt nach Lernzielen und beruflichen Interessen gegliedert. Wenn du nicht in eine der folgenden Kategorien passt, kannst du trotzdem viele wertvolle oder zumindest interessante Konzepte aus diesem Buch lernen.

Dieses Buch wurde so geschrieben, dass es die Zeit überdauert. Wenn du dich also später für einen der Berufe entscheidest, die zur Zielgruppe gehören, sollte das gesamte Wissen aus diesem Buch immer noch relevant sein.

Softwareentwickler/innen und Webanwendungsentwickler/innen

Dieses Buch richtet sich in erster Linie an Softwareentwickler/innen, die am Anfang oder in der Mitte ihrer Karriere stehen, oder an Entwickler/innen von Webanwendungen. Idealerweise bist du daran interessiert, ein tiefes Verständnis entweder für die von Hackern genutzten Offensivtechniken oder für die von Sicherheitsingenieuren genutzten Defensivtechniken zur Abwehr von Hackern zu erlangen.

Oft sind die Bezeichnungen "Softwareentwickler" und "Webanwendungsentwickler" austauschbar, was zu einer gewissen Verwirrung führen kann. Ich verwende beide Bezeichnungen in diesem Buch. Fangen wir mit einer kleinen Klarstellung an.

Softwareentwickler

Wenn ich den Begriff Softwareentwicklung verwende, meine ich damit einen Generalisten, der in der Lage ist, Software zu schreiben, die auf einer Vielzahl von Plattformen läuft.

Softwareentwickler/innen werden in mehrfacher Hinsicht von diesem Buch profitieren. Zunächst einmal lässt sich ein Großteil des Wissens in diesem Buch leicht auf Software übertragen, die nicht im Internet läuft. Es ist auch auf andere Arten von vernetzten Anwendungen übertragbar, wobei native mobile Anwendungen als erstes in den Sinn kommen.

Mehrere in diesem Buch besprochene Exploits nutzen serverseitige Integrationen aus, die die Kommunikation mit einer Webanwendung und einer anderen Softwarekomponente beinhalten. Daher kann jede Software, die eine Schnittstelle zu einer Webanwendung hat, als potenzieller Bedrohungsvektor betrachtet werden (Datenbanken, CRM, Buchhaltung, Protokollierungstools usw.).

Entwickler von Webanwendungen

In diesem Buch ist ein Webanwendungsentwickler jemand, der sich auf das Schreiben von Software spezialisiert hat, die im Internet läuft. Sie werden oft weiter unterteilt in Frontend-, Backend- und Full-Stack-Entwickler.

In der Vergangenheit haben viele Angriffe auf Webanwendungen auf serverseitige Schwachstellen abgezielt. Daher glaube ich, dass der Anwendungsfall dieses Buches für Backend- oder Full-Stack-Entwickler klar ist. Ich glaube aber auch, dass dieses Buch für andere Arten von Webanwendungsentwicklern wertvoll ist, einschließlich derer, die keinen Code schreiben, der auf einem Server, sondern auf einem Webbrowser läuft (Frontend-/JavaScript-Entwickler).

Wie ich noch erläutern werde, gehen viele der Möglichkeiten, wie Hacker die heutigen Webanwendungen ausnutzen, von bösartigem Code aus, der im Browser läuft. Einige Hacker machen sich sogar das DOM oder die CSS-Stylesheets des Browsers zunutze, um die Benutzer einer Anwendung anzugreifen. Für Frontend-Entwickler/innen, die keinen serverseitigen Code schreiben, ist es wichtig, sich der Sicherheitsrisiken bewusst zu sein, denen ihr Code ausgesetzt sein kann, und zu wissen, wie sie diese Risiken mindern können.

Allgemeine Lernziele

Dieses Buch ( ) ist eine fantastische Ressource für alle, auf die die oben genannten Beschreibungen zutreffen und die einen Karrierewechsel in eine sicherheitsorientierte Rolle anstreben. Es ist auch für diejenigen wertvoll, die lernen wollen, wie sie ihren eigenen Code oder den Code ihrer Organisation besser schützen können.

Wenn du deine Anwendung gegen sehr spezifische Exploits verteidigen willst, ist dieses Buch auch für dich geeignet. Die Struktur dieses Buches sollte es dir ermöglichen, es als Sicherheitsreferenz zu nutzen, ohne jemals eines der Kapitel lesen zu müssen, in denen es ums Hacken geht. Das heißt natürlich, wenn das dein einziges Ziel ist. Ich empfehle dir, das Buch von vorne bis hinten durchzulesen, damit du das Beste lernst. Wenn du aber nur ein Nachschlagewerk zum Schutz vor bestimmten Arten von Hacks suchst, kannst du das Buch nach der Hälfte durchblättern und loslegen.

Sicherheitsingenieure, Pen-Tester und Bug-Bounty-Jäger

Die Struktur des Buches eignet sich auch als Ressource für Penetrationstests, Bug Bounty Hunting oder jede andere Art von Sicherheitsarbeit auf Anwendungsebene. Wenn das für dich relevant oder interessant ist, könnte die erste Hälfte des Buches besser zu dir passen.

Wir werden uns eingehend damit beschäftigen, wie Exploits sowohl auf Code- als auch auf Architekturebene funktionieren, anstatt einfach nur bekannte Open-Source-Software (OSS)-Skripte auszuführen oder kostenpflichtige Sicherheitsautomatisierungssoftware zu verwenden. Aus diesem Grund richtet sich dieses Buch an eine zweite Zielgruppe: Softwareentwickler, IT-Sicherheitsingenieure, Netzwerksicherheitsingenieure, Penetrationstester und Bug Bounty Hunters. Dieses Buch ist für Sicherheitsexperten von Vorteil, die verstehen, wie viele Angriffe konzeptionell funktionieren, sich aber mit den Systemen und dem Code hinter einem Tool oder Skript befassen möchten.

Tipp

Willst du nebenbei ein bisschen Geld verdienen und gleichzeitig deine Hacking-Fähigkeiten weiterentwickeln? Lies dieses Buch und melde dich dann bei einem der in Teil III genannten Bug Bounty Programme an. Das ist eine großartige Möglichkeit, Unternehmen dabei zu helfen, die Sicherheit ihrer Produkte zu verbessern, während du deine Hacking-Fähigkeiten weiterentwickelst und etwas zusätzliches Geld verdienst.

Heutzutage ist es üblich, dass Penetrationstester mit einer breiten Palette von vorgefertigten Exploit-Skripten arbeiten. Dies hat zur Entwicklung zahlreicher kostenpflichtiger und Open-Source-Tools geführt, die klassische Angriffe automatisieren und Angriffe, die ohne tiefes Wissen über die Architektur einer Anwendung oder die Logik innerhalb eines bestimmten Codeblocks ausgeführt werden können.

Die in diesem Buch enthaltenen Exploits und Gegenmaßnahmen werden ohne den Einsatz spezieller Tools vorgestellt. Stattdessen verlassen wir uns auf unsere eigenen Skripte, Netzwerkanfragen und die Werkzeuge, die standardmäßig in Unix-basierten Betriebssystemen enthalten sind, sowie auf die Standardwerkzeuge der drei wichtigsten Webbrowser (Chrome,Firefox und Edge). Dies ist kein Urteil über den Wert spezialisierter Sicherheitstools - ich denke, dass viele von ihnen außergewöhnlich sind und die Durchführung professioneller, qualitativ hochwertiger Penetrationstests sehr viel einfacher machen!

In diesem Buch werden keine speziellen Sicherheitstools verwendet, damit wir uns auf die wichtigsten Aspekte konzentrieren können: das Auffinden einer Schwachstelle, die Entwicklung eines Exploits, die Priorisierung der Daten, die kompromittiert werden sollen, und die Sicherstellung, dass du dich gegen all diese Dinge verteidigen kannst. Deshalb glaube ich, dass du am Ende dieses Buches in der Lage sein wirst, neue Schwachstellen zu finden, Exploits für Systeme zu entwickeln, die noch nie zuvor ausgenutzt wurden, und die komplexesten Systeme gegen die hartnäckigsten Angreifer zu schützen.

Wie ist dieses Buch gegliedert?

Du wirst bald feststellen, dass dieses Buch ganz anders aufgebaut ist als die meisten anderen Technikbücher da draußen. Das ist gewollt. Dieses Buch ist absichtlich so aufgebaut, dass die Kapitel über Hacking (Angriff) und Sicherheit (Verteidigung) fast im Verhältnis 1:1 stehen.

Wir beginnen unser Abenteuer mit einer kleinen Geschichtsstunde und einer Erkundung der Technologien, Tools und Exploits der Vergangenheit. Dann wenden wir uns unserem Hauptthema zu: Ausnutzung und Gegenmaßnahmen für moderne Webanwendungen. (Daher auch der Untertitel dieses Buches.)

Der Hauptinhalt ist in drei große Teile gegliedert, die jeweils viele einzelne Kapitel zu einer Vielzahl von Themen enthalten. Idealerweise liest du dieses Buch linear von der ersten bis zur letzten Seite. Wie bereits erwähnt, lernst du am meisten, wenn du das Buch der Reihe nach liest. Du kannst es aber auch als Nachschlagewerk für Hacker oder Sicherheitstechniker nutzen, indem du dich auf die erste bzw. zweite Hälfte konzentrierst.

Inzwischen solltest du wissen, wie du dich in dem Buch zurechtfindest, also lass uns die drei Hauptteile durchgehen, um die Bedeutung jedes einzelnen zu verstehen.

Aufklären

Der erste Teil dieses Buches ist "Aufklärung", in dem wir Möglichkeiten untersuchen, wie man Informationen über eine Webanwendung erhält, ohne sie unbedingt hacken zu wollen. In "Aufklären" besprechen wir eine Reihe wichtiger Technologien und Konzepte, die du unbedingt beherrschen musst, wenn du ein Hacker werden willst. Diese Themen sind auch für alle wichtig, die eine bestehende Anwendung absichern wollen, denn die Informationen, die durch viele dieser Techniken offengelegt werden, können mit der richtigen Planung entschärft werden.

Ich hatte die Gelegenheit, mit einigen der meiner Meinung nach besten Penetrationstester und Bug Bounty Hunters der Welt zusammenzuarbeiten. In meinen Gesprächen mit ihnen und bei der Analyse ihrer Arbeitsweise habe ich festgestellt, dass dieses Thema viel wichtiger ist, als viele andere Bücher es darstellen. Für viele der besten Bug Bounty Hunters der Welt ist die Fähigkeit zur Aufklärung auf Expertenebene das, was "großartige" Hacker von "guten" Hackern unterscheidet. Mit anderen Worten: Es ist eine Sache, ein schnelles Auto zu haben (in diesem Fall vielleicht, zu wissen, wie man Exploits baut), aber ohne die effizienteste Route zur Ziellinie zu kennen, wirst du das Rennen vielleicht nicht gewinnen. Ein langsameres Auto könnte es in kürzerer Zeit ins Ziel schaffen als ein schnelles, wenn es einen effizienteren Weg einschlägt.

Wenn dir Fantasy-Analogien näher liegen, könntest du dir die Aufklärungsfähigkeiten als so etwas wie einen Schurken in einem Rollenspiel vorstellen. In unserem Fall besteht die Aufgabe des Schurken nicht darin, viel Schaden anzurichten, sondern vor der Gruppe auszukundschaften und mit Informationen zurückzukehren. Er ist der Charakter, der dabei hilft, die Schüsse zu platzieren und herauszufinden, welche Kämpfe die größten Vorteile bringen.

Vor allem der letzte Teil ist äußerst wertvoll, denn es ist wahrscheinlich, dass viele Arten von Angriffen gegen gut verteidigte Ziele protokolliert werden können. Das bedeutet, dass du vielleicht nur eine Chance bekommst, eine bestimmte Software-Lücke auszunutzen, bevor sie gefunden und geschlossen wird. Daraus können wir schließen, dass der zweite Nutzen der Aufklärung darin besteht, Prioritäten für deine Angriffe zu setzen.

Wenn du dich für eine Karriere als Penetrationstester oder Bug Bounty Hunter interessierst, wird Teil I für dich von größter Bedeutung sein. Das liegt vor allem daran, dass in der Welt der Bug Bounty Hunters und in geringerem Maße auch bei Penetrationstests "Black Box"-Tests durchgeführt werden. "Black Box"-Tests sind Tests, bei denen der Tester keine Kenntnisse über die Struktur und den Code einer Anwendung hat und sich daher durch sorgfältige Analyse und Untersuchung ein eigenes Verständnis der Anwendung erarbeiten muss.

Offensive

Teil II ist "Offensive". Hier verschiebt sich der Schwerpunkt des Buches von der Aufklärung und Datenerfassung zur Analyse von Code und Netzwerkanfragen. Mit diesem Wissen werden wir dann versuchen, unsicher geschriebene oder unsachgemäß konfigurierte Webanwendungen auszunutzen.

Warnung

In einigen Kapiteln ( ) werden tatsächliche Hacking-Techniken erklärt, die von böswilligen Black Hat Hackern in der realen Welt eingesetzt werden.¹ Wenn du die in diesem Buch beschriebenen Techniken testest, darfst du das nur mit einer Anwendung tun, die dir gehört oder für die du eine ausdrückliche schriftliche Erlaubnis hast, Exploits zu testen.

Die unsachgemäße Anwendung der in diesem Buch vorgestellten Hacking-Techniken kann je nach den Gesetzen deines Landes zu Geld- oder Gefängnisstrafen führen.

In Teil II lernen wir, wie man Exploits erstellt und einsetzt. Diese Exploits sind darauf ausgelegt, Daten zu stehlen oder das Verhalten einer Anwendung zu verändern. Dieser Teil des Buches baut auf dem Wissen aus Teil I, "Recon", auf. Mit unseren zuvor erworbenen Aufklärungsfähigkeiten in Verbindung mit neu erworbenen Hacking-Fähigkeiten werden wir beginnen, Demo-Webanwendungen zu übernehmen und anzugreifen.

Teil II ist nach einzelnen Exploits gegliedert. In jedem Kapitel wird eine andere Art von Exploit im Detail erklärt. Diese Kapitel beginnen mit einer Erklärung des Exploits selbst, damit du verstehst, wie er mechanisch funktioniert. Dann besprechen wir, wie man nach Schwachstellen sucht, auf die dieser Exploit angewendet werden kann. Schließlich erstellen wir einen Payload, der speziell auf die Demo-Anwendung zugeschnitten ist, die wir ausnutzen wollen. Dann setzen wir die Nutzlast ein und beobachten die Ergebnisse.

XSS, einer der ersten Exploits, mit denen wir uns beschäftigen, ist eine Angriffsart, die sich gegen eine Vielzahl von Webanwendungen richtet, aber auch auf andere Anwendungen angewendet werden kann (z. B. mobile Apps, Flash/ActionScript-Spiele usw.). Bei diesem Angriff schreibst du einen bösartigen Code auf deinem eigenen Computer und nutzt dann schlechte Filtermechanismen in einer Anwendung aus, um dein Skript auf dem Computer eines anderen Benutzers auszuführen.

Wenn wir einen Exploit wie einen XSS-Angriff besprechen, beginnen wir mit einer verwundbaren App. Diese Demo-App ist einfach und übersichtlich und besteht idealerweise nur aus ein paar Absätzen Code. Auf dieser Grundlage schreiben wir einen Codeblock, der als Nutzlast in die Demo-App eingeschleust wird und dann einen hypothetischen Nutzer auf der anderen Seite ausnutzt.

Klingt einfach, nicht wahr? Und das sollte es auch sein. Ohne jegliche Schutzmaßnahmen sind die meisten Softwaresysteme leicht zu knacken. Deshalb werden wir bei einem Exploit wie XSS, bei dem es viele Verteidigungsmöglichkeiten gibt, immer tiefer in die Einzelheiten des Schreibens und des Einsatzes eines Angriffs einsteigen.

Wir werden zunächst versuchen, routinemäßige Verteidigungsmechanismen zu durchbrechen und schließlich dazu übergehen, fortgeschrittenere Verteidigungsmechanismen zu umgehen. Erinnere dich: Nur weil jemand eine Mauer gebaut hat, um seine Codebasis zu schützen, heißt das nicht, dass du sie nicht überwinden oder unter ihr hindurchgehen kannst. Hier werden wir kreativ sein und einzigartige und interessante Lösungen finden.

Teil II ist wichtig, denn die Denkweise eines Hackers zu verstehen, ist oft entscheidend für die Entwicklung von sicheren Codebasen. Er ist besonders wichtig für alle, die sich für Hacking, Penetrationstests oder Bug Bounty Hunting interessieren.

Verteidigung

Im dritten und letzten Teil dieses Buches, "Verteidigung", geht es darum, deinen eigenen Code gegen Hacker zu sichern. In Teil III gehen wir noch einmal auf jede Art von Exploit ein, die wir in Teil II behandelt haben, und versuchen, sie noch einmal mit einem völlig anderen Blickwinkel zu betrachten. Hier werden wir uns nicht darauf konzentrieren, in Softwaresysteme einzubrechen, sondern versuchen, die Wahrscheinlichkeit, dass ein Hacker in unsere Systeme einbricht, zu verhindern oder zu mindern.

In Teil III lernst du, wie du dich gegen bestimmte Exploits aus Teil II schützen kannst. Außerdem lernst du allgemeine Schutzmaßnahmen, die deine Codebasis gegen eine Vielzahl von Angriffen absichern. Diese allgemeinen Schutzmaßnahmen reichen von "standardmäßig sicheren" Entwicklungsmethoden bis hin zu bewährten Methoden für die sichere Programmierung, die von einem Entwicklungsteam mithilfe von Tests und anderen einfachen automatisierten Werkzeugen (z. B. einem Linter) leicht umgesetzt werden können. Du lernst nicht nur, wie du sichereren Code schreibst, sondern auch eine Reihe wertvoller Tricks, um Hacker auf frischer Tat zu ertappen und die Einstellung deines Unternehmens zur Software-Sicherheit zu verbessern.

Die meisten Kapitel in Teil III sind ähnlich aufgebaut wie die Kapitel über Hackerangriffe in Teil II. Wir beginnen mit einem Überblick über die Technologie und die erforderlichen Fähigkeiten, um eine Verteidigung gegen eine bestimmte Art von Angriff vorzubereiten.

Zunächst werden wir eine Basisverteidigung vorbereiten, die Angriffe abschwächen sollte, aber die hartnäckigsten Hacker nicht immer abwehren kann. Schließlich werden wir unsere Verteidigung so weit verbessern, dass die meisten, wenn nicht sogar alle Hacking-Versuche gestoppt werden können.

An dieser Stelle unterscheidet sich die Struktur von Teil III von der von Teil II, da wir Kompromisse diskutieren, die sich aus der Verbesserung der Anwendungssicherheit ergeben. Generell sind alle Maßnahmen zur Verbesserung der Sicherheit mit Kompromissen verbunden, die nicht die Sicherheit betreffen. Es ist zwar nicht deine Aufgabe, Vorschläge zu machen, welches Risiko auf Kosten deines Produkts in Kauf genommen werden sollte, aber du solltest dir der Kompromisse bewusst sein, die eingegangen werden.

Oft gehen diese Kompromisse zu Lasten der Anwendungsleistung. Je mehr Aufwand du betreibst, um Daten zu lesen und zu bereinigen, desto mehr Vorgänge werden außerhalb der Standardfunktionalität deiner Anwendung ausgeführt. Daher erfordert eine sichere Funktion in der Regel mehr Rechenressourcen als eine unsichere Funktion.

Mit weiteren Operationen kommt auch mehr Code, was mehr Wartungs-, Test- und Entwicklungszeit bedeutet. Dieser Entwicklungsaufwand für die Sicherheit kommt oft auch in Form von Protokollierungs- oder Überwachungsaufwand hinzu. Schließlich gehen einige Sicherheitsvorkehrungen auf Kosten der Benutzerfreundlichkeit.

Ein sehr einfaches Beispiel für diesen Prozess des Abwägens von Sicherheitsvorteilen und ihren Kosten in Bezug auf Benutzerfreundlichkeit und Leistung ist ein Anmeldeformular. Wenn dem Nutzer beim Versuch, sich anzumelden, eine Fehlermeldung für einen ungültigen Benutzernamen angezeigt wird, ist es für einen Hacker wesentlich einfacher, Kombinationen aus Benutzernamen und Passwort zu erzwingen. Das liegt daran, dass der Hacker nicht mehr eine Liste aktiver Benutzernamen finden muss, da die Anwendung ein Benutzerkonto bestätigt. Der Hacker muss lediglich einige Benutzernamen erfolgreich erzwingen, die dann für spätere Einbruchsversuche bestätigt und protokolliert werden können.

Als Nächstes muss der Hacker nur noch Passwörter und keine Benutzernamen-Passwort-Kombinationen mehr erzwingen, was eine deutlich geringere mathematische Komplexität bedeutet und viel weniger Zeit und Ressourcen benötigt.

Wenn die Anwendung außerdem ein E-Mail- und Passwortschema für die Anmeldung verwendet und nicht ein Benutzernamen- und Passwortschema, dann haben wir ein weiteres Problem. Ein Hacker kann dieses Anmeldeformular nutzen, um gültige E-Mail-Adressen zu finden, die für Marketing- oder Spamzwecke verkauft werden können. Selbst wenn Vorkehrungen getroffen werden, um Brute-Force-Eingaben zu verhindern, kann ein Hacker mit sorgfältig ausgearbeiteten Eingaben (z. B. first. [e-mail], [e-mail], [e-mail]) das für die E-Mail-Konten des Unternehmens verwendete Schema zurückentwickeln und die gültigen Konten von Führungskräften für den Vertrieb oder von Personen mit wichtigen Zugangskriterien für Phishing ausfindig machen.

Daher wird es oft als bewährte Methode angesehen, dem Nutzer allgemeinere Fehlermeldungen zu geben. Natürlich steht diese Änderung im Konflikt mit der Benutzerfreundlichkeit, denn spezifischere Fehlermeldungen sind für die Benutzerfreundlichkeit deiner Anwendung definitiv ideal.

Dies ist ein gutes Beispiel für einen Kompromiss, der für eine verbesserte Anwendungssicherheit eingegangen werden kann, allerdings auf Kosten einer geringeren Benutzerfreundlichkeit. So bekommst du einen Eindruck von der Art der Kompromisse, die in Teil III dieses Buches behandelt werden.

Dieser Teil des Buches ist extrem wichtig für alle Sicherheitsingenieure, die ihre Fähigkeiten aufbessern wollen, oder für alle Softwareentwickler, die sich mit dem Gedanken tragen, in eine Rolle als Sicherheitsingenieur zu wechseln. Die hier vorgestellten Informationen helfen dabei, sicherere Anwendungen zu entwickeln und zu schreiben.

Wie in Teil II beschrieben, ist das Wissen, wie die Sicherheit einer Anwendung verbessert werden kann, für jede Art von Hacker ein wertvolles Gut. Denn während Routineschutzmaßnahmen oft leicht umgangen werden können, erfordern komplexere Schutzmaßnahmen ein tieferes Verständnis und Wissen, um sie zu umgehen. Dies ist ein weiterer Grund, warum ich empfehle, das Buch von Anfang bis Ende zu lesen.

Auch wenn einige Teile dieses Buches dir je nach deinen Zielen eine wertvollere Ausbildung bieten als andere, bezweifle ich, dass irgendetwas davon verschwendet sein wird. Diese Art von Cross-Training ist besonders wertvoll, da jeder Teil des Buches nur eine andere Perspektive auf dasselbe Puzzle darstellt.

Sprache und Terminologie

Es ist wahrscheinlich inzwischen klar geworden, dass dieses Buch darauf abzielt, dir eine Reihe sehr nützlicher, aber auch sehr seltener und besonderer Fähigkeiten zu vermitteln. Diese Fähigkeiten werden zwar immer wertvoller und verbessern deine Chancen auf dem Arbeitsmarkt, aber sie sind auch ziemlich schwer zu erlernen. Sie erfordern Konzentration, Geschicklichkeit und die Fähigkeit, sich ein ganz neues Denkmodell anzueignen, das bestimmt, wie du Webanwendungen betrachtest.

Um diese neuen Fähigkeiten erfolgreich zu vermitteln, müssen wir eine gemeinsame Sprache finden. Das ist wichtig, um Verwirrung zu vermeiden und damit du deine neuen Ideen in einer Weise ausdrücken kannst, die in allen Sicherheits- und Entwicklungsorganisationen einheitlich ist.

Jedes Mal, wenn ich einen neuen Begriff oder eine neue Formulierung einführe, gebe ich mein Bestes, um sie zu erklären. Vor allem bei Akronymen buchstabiere ich zuerst das Akronym aus, bevor ich es selbst verwende. Du hast das vorhin gesehen, als ich XSS buchstabiert habe. Darüber hinaus habe ich mein Bestes getan, um herauszufinden, welche Begriffe und Phrasen erklärungsbedürftig sein könnten. Ich habe sie gesammelt und in den folgenden Tabellen (Tabellen P-1 bis P-3) zusammengestellt. Wenn du über einen Begriff oder eine Formulierung stolperst, die du nicht ganz verstehst, kannst du in diesem Vorwort nachsehen, ob er hier aufgeführt ist (Lesezeichen setzen!). Wenn nicht, kannst du meinem Redakteur eine E-Mail schreiben und wir können sie vielleicht in die nächste Ausgabe des Buches aufnehmen.

Tabelle P-1. Beruf

Beruf	Beschreibung
Hacker	Jemand, der in Systeme einbricht, um Daten zu exfiltrieren oder das System auf eine Art und Weise zu betreiben, die von den Entwicklern ursprünglich nicht beabsichtigt war.
Weißer Hut	Manchmal wird als "ethischer Hacker" bezeichnet - jemand, der Hacking-Techniken einsetzt, um Organisationen bei der Verbesserung der Sicherheit zu helfen.
Schwarzer Hut	Der archetypische Hacker - einer, der Hacking-Techniken einsetzt, um in Systeme einzubrechen, um Profit zu machen, Chaos zu verursachen oder um seine eigenen Ziele und Interessen zu verfolgen.
Grauer Hut	Ein Hacker liegt irgendwo zwischen White Hat und Black Hat. Gelegentlich verstoßen diese Hacker gegen Gesetze, z. B. wenn sie versuchen, ohne Erlaubnis in Anwendungen einzudringen, aber oft eher um der Entdeckung oder Anerkennung willen als um Profit zu machen oder um Chaos zu verursachen.
Penetrationstester	Jemand der dafür bezahlt wird, in Systeme einzubrechen, oft auf die gleiche Weise wie ein Hacker. Im Gegensatz zu Hackern werden Penetrationstester dafür bezahlt, Fehler und Versäumnisse in der Anwendungssoftware zu melden, damit das Unternehmen, dem die Software gehört, diese beheben kann, bevor ein Hacker mit böser Absicht in das System eindringt.
Käfer-Kopfgeldjäger	Ein freiberuflicher Penetrationstester. Oft legen große Unternehmen "Responsible Disclosure Programme" auf, die Geldpreise für das Melden von Sicherheitslücken vergeben. Einige Bug Bounty Hunters arbeiten hauptberuflich, aber oft handelt es sich dabei um Vollzeitbeschäftigte, die sich neben ihrer Arbeit für zusätzliches Geld engagieren.
Ingenieur für Anwendungssicherheit	Manchmal wird als "Product Security Engineer" bezeichnet - ein Softwareentwickler, dessen Aufgabe es ist, die Sicherheit der Codebasis und Anwendungsarchitektur eines Unternehmens zu bewerten und zu verbessern.
Softwareentwickler für Sicherheit	Ein Softwareentwickler, dessen Aufgabe es ist, sicherheitsrelevante Produkte zu entwickeln, der aber nicht unbedingt für die Bewertung der Sicherheit für das gesamte Unternehmen zuständig ist.
Admin	Manchmal wird auch als "Systemadministrator" oder "Systemadministrator" bezeichnet. Admins sind technische Mitarbeiter, die für die Wartung der Konfiguration und Betriebszeit eines Webservers oder einer Webanwendung zuständig sind.
Scrum Master	Eine Führungsposition in einer technischen Organisation, die für die Unterstützung eines technischen Teams bei der Planung und Durchführung von Entwicklungsarbeiten verantwortlich ist.
Meister der Sicherheit	Ein Software ingenieur, der weder einer Sicherheitsorganisation angehört noch für die Sicherheitsarbeit verantwortlich ist, aber daran interessiert ist, die Sicherheit des Codes eines Unternehmens zu verbessern.

Tabelle P-2. Begriffe

Begriff	Beschreibung
Schwachstelle	Ein Fehler in einem Softwaresystem, der oft durch ein technisches Versehen oder eine unerwartete Funktionalität bei der Verbindung mehrerer Module entsteht. Diese besondere Art von Fehler ermöglicht es einem Hacker, unbeabsichtigte Aktionen gegen das Softwaresystem durchzuführen.
Bedrohungsvektor oder Angriffsvektor	Ein Teilbereich der Anwendungsfunktionalität, den ein Hacker für unsicher geschrieben hält und der daher wahrscheinlich Schwachstellen enthält und ein gutes Ziel für Hacker ist.
Angriffsfläche	Eine Liste von Schwachstellen in einer Anwendung, die ein Hacker erstellt, wenn er überlegt, wie er ein Softwaresystem am besten angreifen kann.
Ausnutzen	In der Regel ein Codeblock oder eine Liste von Befehlen, die verwendet werden können, um eine Schwachstelle auszunutzen.
Nutzlast	Ein Exploit, der so formatiert wurde, dass er an einen Server gesendet werden kann, um eine Sicherheitslücke auszunutzen. Oft bedeutet dies nur, dass ein Exploit in das richtige Format verpackt wird, um über ein Netzwerk gesendet zu werden.
Rote Mannschaft	Ein Team, das sich oft aus Penetrationstestern, Netzwerksicherheitsingenieuren und Software-Sicherheitsingenieuren zusammensetzt. Dieses Team versucht, sich in die Software eines Unternehmens zu hacken, um zu prüfen, ob das Unternehmen in der Lage ist, sich gegen echte Hacker zu wehren.
Blaues Team	Ein Team, das sich häufig aus Software-Sicherheitsingenieuren und Netzwerksicherheitsingenieuren zusammensetzt. Dieses Team versucht, die Softwaresicherheit eines Unternehmens zu verbessern und nutzt dabei oft das Feedback eines roten Teams, um Prioritäten zu setzen.
Lila Team	Ein Team, das eine Kombination aus den Aufgaben des roten und des blauen Teams übernimmt. Ein allgemeines Sicherheitsteam anstelle eines spezialisierten Teams; oft schwieriger richtig zu besetzen, da die Anforderungen an die Fähigkeiten sehr hoch sind.
Website	Eine Reihe von Informationsdokumenten, die über das Internet zugänglich sind, normalerweise über das HTTP-Protokoll.
Webanwendung	Eine desktopähnliche Anwendung, die über das Internet bereitgestellt wird und in einem Browser und nicht in einem Host-Betriebssystem läuft. Sie unterscheiden sich von herkömmlichen Websites dadurch, dass sie viele Berechtigungsstufen haben, Benutzereingaben in Datenbanken speichern und es den Benutzern oft ermöglichen, Inhalte miteinander zu teilen.
Hybride Anwendung	Eine mobile Anwendung, die auf einer webbasierten Technologie aufbaut. In der Regel verwenden sie eine andere Bibliothek, wie z. B. Cordova von Apache, um native Funktionen mit der darüber liegenden Webanwendung zu teilen.

Tabelle P-3. Akronyme

Akronym	Beschreibung
API	Anwendung Programmierschnittstelle - eine Reihe von Funktionen, die von einem Codemodul zur Verfügung gestellt werden, damit andere Codes sie nutzen und verwenden können. Wird in diesem Buch normalerweise für Funktionen verwendet, die über HTTP bereitgestellt werden und die ein Browser auf einem Server aufrufen kann. Er kann auch verwendet werden, wenn er sich auf Module bezieht, die lokal miteinander kommunizieren, einschließlich separater Module im selben Softwarepaket.
CSRF	Cross-Site Request Forgery - ein Angriff bei dem ein Hacker die Berechtigungen eines privilegierten Benutzers ausnutzt, um Anfragen an einen Server zu stellen.
CSS	Cascading Style Sheets - eine Styling-Sprache, die normalerweise in Kombination mit HTML verwendet wird, um eine optisch ansprechende und korrekt ausgerichtete Benutzeroberfläche zu erstellen.
DDoS	Distributed Denial of Service - ein DoS-Angriff ( ), der von mehreren Computern gleichzeitig durchgeführt wird und einen Server mit seiner schieren Anzahl überwältigt; ein einzelner Computer wäre wahrscheinlich nicht in der Lage, ein solches Chaos anzurichten.
DOM	Document Object Model - eine API, die mit jedem Webbrowser ausgeliefert wird. Es enthält alle notwendigen Funktionen zum Organisieren und Verwalten des HTML in der Seite sowie APIs für die Verwaltung von Verlauf, Cookies, URLs und anderen gängigen Browserfunktionen.
DoS	Denial of Service - ein Angriff, bei dem es nicht um den Diebstahl von Daten geht, sondern darum, so viele Server- oder Client-Ressourcen anzufordern, dass sich die Benutzerfreundlichkeit der Anwendung verschlechtert oder die Anwendung nicht mehr funktioniert.
HTML	HyperText Markup Language - eine Templating-Sprache, die im Web neben CSS und JavaScript verwendet wird.
HTTP	HyperText Transfer Protocol-das am häufigsten verwendete Netzwerkprotokoll für die Kommunikation zwischen Clients und Servern in einer Webanwendung oder Website.
HTTPS	HyperText Transfer Protocol Secure-HTTP-Verkehr, der entweder mit HTTP over TLS oder HTTP over SSL verschlüsselt ist.
JSON	JavaScript Object Notation - eine Spezifikation für die Speicherung von hierarchischen Daten in einer Art und Weise, die leichtgewichtig, für Menschen und für Maschinen einfach zu lesen ist. Sie wird häufig bei der Kommunikation zwischen dem Browser und einem Webserver in modernen Webanwendungen verwendet.
OOP	Objektorientierte Programmierung - ein Programmiermodell, das den Code um Objekte und Datenstrukturen herum organisiert und nicht um Funktionalität oder Logik.
OSS	Open-Source-Software - Software, die sowohl zum Konsum als auch zur Veränderung frei verfügbar ist. Sie wird oft unter Lizenzen wie MIT, Apache, GNU oder BSD veröffentlicht.
REST	Representational State Transfer - eine spezielle Architektur zum Aufbau zustandsloser APIs, die API-Endpunkte als Ressourcen und nicht als funktionale Einheiten definieren. In REST sind viele Datenformate zulässig, aber normalerweise wird JSON verwendet.
RTC	Echtzeitkommunikation - ein neueres Netzwerkprotokoll, das es Browsern ermöglicht, miteinander und mit Webservern zu kommunizieren.
SOAP	Simple Object Access Protocol - ein Protokoll für funktionsgesteuerte APIs, die streng geschriebene Schemata erfordern. Unterstützt nur XML als Datenformat.
SOP	Same Origin Policy - eine vom Browser erzwungene Richtlinie, die verhindert, dass Inhalte von einem Ursprung in einem anderen Ursprung geladen werden.
SPA	Single-Page-Anwendung - auch "Single-Page-Webanwendung" (SPWA) genannt. Bezieht sich auf eine Website im Internet, die ähnlich wie eine Desktop-Anwendung funktioniert und ihre eigene Benutzeroberfläche und ihren eigenen Status verwaltet, anstatt die Standardeinstellungen des Browsers zu verwenden.
SSDL	Secure Software Development Life Cycle - auch SDLC/SDL genannt. Ein gemeinsamer Rahmen, der es Softwareentwicklern und Sicherheitsingenieuren ermöglicht, zusammenzuarbeiten, um einen sichereren Code zu schreiben.
SSL	Secure Sockets Layer - ein kryptografisches Protokoll, das für die Sicherung von Informationen bei der Übertragung (über das Netzwerk) entwickelt wurde, insbesondere für die Verwendung in HTTP.
TLS	Transport Layer Security - ein kryptografisches Protokoll, das für die Sicherung von Informationen bei der Übertragung (über das Netzwerk) entwickelt wurde und normalerweise in HTTP verwendet wird. Dieses Protokoll hat SSL ersetzt, das inzwischen veraltet ist.
VCS	Versionskontrollsystem - ein spezieller Typ von Software zur Verwaltung historischer Ergänzungen und Änderungen in einer Codebasis. Manchmal beinhaltet sie auch Funktionen zur Verwaltung von Abhängigkeiten und zur Zusammenarbeit.
XML	Extensible Markup Language - eine Spezifikation für die Speicherung hierarchischer Daten, die sich an strenge Regeln hält. Sie ist schwerer als JSON, aber besser konfigurierbar.
XSS	Cross-Site Scripting - eine Angriffsart bei der ein anderer Client (oft ein Browser) gezwungen wird, von einem Hacker geschriebenen Code auszuführen.
XXE	XML External Entity - ein Angriff, der sich auf einen falsch konfigurierten XML-Parser stützt, um lokale Dateien auf dem Webserver zu stehlen oder bösartige Dateien von einem anderen Webserver einzubinden.

Zusammenfassung

Dies ist ein vielseitiges Buch, das sowohl für diejenigen mit offensiven als auch defensiven Sicherheitsinteressen geeignet ist. Es ist für jede Art von Entwickler oder Administrator mit ausreichenden Kenntnissen in der Webprogrammierung (Client und Server) leicht zu verstehen und anzuwenden.

Web Application Security führt dich durch eine Reihe von Techniken, die talentierte Hacker und Bug Bounty Hunters nutzen, um in Anwendungen einzubrechen. Anschließend lernst du Techniken und Prozesse kennen, die du in deine eigene Software implementieren kannst, um dich vor solchen Hackern zu schützen.

Dieses Buch kann von der ersten bis zur letzten Seite gelesen werden oder als Nachschlagewerk für bestimmte Arten von Aufklärungsmethoden, Angriffen und Abwehrmaßnahmen dienen. Letztendlich soll es dir dabei helfen, die Sicherheit von Webanwendungen auf praktische Weise zu verbessern, und zwar in einer logischen Abfolge, so dass keine besonderen Vorkenntnisse erforderlich sind.

Ich hoffe aufrichtig, dass die Hunderte von Stunden, die in das Schreiben dieses Buches geflossen sind, für dich von Nutzen sind und dass du etwas Interessantes aus dem Inhalt lernen kannst. Du bist herzlich eingeladen, mir Feedback oder Vorschläge für zukünftige Ausgaben zu geben.

In diesem Buch verwendete Konventionen

In diesem Buch werden die folgenden typografischen Konventionen verwendet:

Kursiv

Weist auf neue Begriffe, URLs, E-Mail-Adressen, Dateinamen und Dateierweiterungen hin.

Constant width

Wird für Programmlistings sowie innerhalb von Absätzen verwendet, um auf Programmelemente wie Variablen- oder Funktionsnamen, Datenbanken, Datentypen, Umgebungsvariablen, Anweisungen und Schlüsselwörter hinzuweisen.

Constant width bold

Zeigt Befehle oder anderen Text an, der vom Benutzer wortwörtlich eingetippt werden sollte.

Constant width italic

Zeigt Text an, der durch vom Benutzer eingegebene Werte oder durch kontextabhängige Werte ersetzt werden soll.

Tipp

Dieses Element steht für einen Tipp oder eine Anregung.

Hinweis

Dieses Element steht für einen allgemeinen Hinweis.

Warnung

Dieses Element weist auf eine Warnung oder einen Warnhinweis hin.

O'Reilly Online Learning

Hinweis

Seit mehr als 40 Jahren bietet O'Reilly Media Schulungen, Wissen und Einblicke in Technologie und Wirtschaft, um Unternehmen zum Erfolg zu verhelfen.

Unser einzigartiges Netzwerk von Experten und Innovatoren teilt sein Wissen und seine Erfahrung durch Bücher, Artikel und unsere Online-Lernplattform. Die Online-Lernplattform von O'Reilly bietet dir On-Demand-Zugang zu Live-Trainingskursen, ausführlichen Lernpfaden, interaktiven Programmierumgebungen und einer umfangreichen Text- und Videosammlung von O'Reilly und über 200 anderen Verlagen. Weitere Informationen erhältst du unter https://oreilly.com.

Wie du uns kontaktierst

Bitte wende dich mit Kommentaren und Fragen zu diesem Buch an den Verlag:

• O'Reilly Media, Inc.
• 1005 Gravenstein Highway Nord
• Sebastopol, CA 95472
• 800-889-8969 (in den Vereinigten Staaten oder Kanada)
• 707-829-7019 (international oder lokal)
• 707-829-0104 (Fax)
• [e-mail]
• https://www.oreilly.com/about/contact.html

Wir haben eine Webseite für dieses Buch, auf der wir Errata, Beispiele und zusätzliche Informationen auflisten. Du kannst diese Seite unter https://oreil.ly/web-application-security-2e aufrufen .

Neuigkeiten und Informationen über unsere Bücher und Kurse findest du unter https://oreilly.com.

Du findest uns auf LinkedIn: https://linkedin.com/company/oreilly-media.

Folge uns auf Twitter: https://twitter.com/oreillymedia.

Sieh uns auf YouTube: https://youtube.com/oreillymedia.

Danksagungen

Besonderer Dank gilt den folgenden Personen:

• Herausgeber der 1. Auflage: Angela Rufino und Jennifer Pollock

• Technische Überprüfung der 1. Auflage: August Detlefsen, Ryan Flood, Chetan Karande, Allan Liska, und Tim Gallo

• Herausgeber der 2. Auflage: Angela Rufino, Katherine Tozer, und Tonya Trybula

• Technische Überprüfung der 2. Auflage: Nishil Shah, Dustin Kinsey, Caroline Wong, Jon Lamendola, Ming Chow und Chetan Karande

Ich möchte auch meiner Frau Amy ein großes Lob aussprechen, die mich über ein Jahrzehnt lang bei einer Reihe schwieriger Projekte unterstützt hat, darunter beide Ausgaben dieses Buches.

¹ O'Reilly ist bestrebt, eine bildhafte Sprache zu vermeiden, die positive oder negative Eigenschaften mit Farben assoziiert, die auch problematisch mit Menschen in Verbindung gebracht werden. In diesem Buch verwenden wir die Begriffe "schwarzer Hut" und "weißer Hut", wenn eine Alternative in der Informationssicherheit noch nicht weit genug verbreitet ist, um eindeutig zu sein.