Sicherheit von Webanwendungen

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 werden wir die notwendigen Grundlagen für das erfolgreiche Lesen und Verstehen der Inhalte dieses Buches besprechen. Wir werden auch die Lernziele erörtern und versuchen, ein archetypisches Leserprofil zu erstellen, damit du (der Leser) verstehen kannst, ob du von diesem Buch profitieren wirst oder nicht.

Wenn du nicht weißt, ob dieses Buch das Richtige für dich ist, oder wenn du dir nicht sicher bist, ob du die technischen Inhalte der folgenden Kapitel bewältigen kannst, solltest du dieses Vorwort lesen, bevor du mit Kapitel 1 weitermachst.

Vorausgesetztes Wissen und Lernziele

Dieses ist ein Buch, das dir nicht nur dabei hilft, zu lernen, wie du deine Webanwendung gegen Hacker verteidigen kannst, sondern das dich auch durch die Schritte führt, die Hacker unternehmen, um eine Webanwendung zu untersuchen und in sie einzubrechen.

In diesem Buch werden wir viele Techniken besprechen, die Hacker heute nutzen, um in Webanwendungen von Unternehmen, Regierungen und gelegentlich sogar von Hobbyisten einzubrechen.

Nachdem wir die oben genannten Techniken ausreichend untersucht haben, beginnen wir mit einer Diskussion darüber, wie man Webanwendungen gegen diese Hacker schützen kann.

Dabei wirst du ganz neue Denkweisen über 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 hast du das nötige 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 identifizieren 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ückblättern, um sie nachzuholen.

Alle Themen, die in diesem Kapitel nicht als Voraussetzung definiert sind, sollten im Buch nicht ohne vorherige Erklärung behandelt werden.

Vorgeschlagener Hintergrund

Das potenzielle Publikum für dieses Buch ist recht breit gefächert, aber der Stil, in dem das Buch geschrieben ist, und die Art und Weise, wie die Beispiele strukturiert sind, sollten es ideal für jeden machen, der ein mittleres Hintergrundwissen in Softwareentwicklung hat.

Du fragst dich vielleicht, was ein "mittlerer Hintergrund in der Softwareentwicklung" bedeutet? Die Antwort auf diese Frage wird von Person zu Person sehr unterschiedlich ausfallen. Für eine hochtechnische Person ist für dieses Buch eigentlich nur ein "Anfängerhintergrund in der Softwareentwicklung" erforderlich. Mit anderen Worten: Ein Systemadministrator mit Vorkenntnissen in der Webentwicklung und/oder Skripterstellung (wenn diese ausreichend sind) 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, um dieses Buch erfolgreich abzuschließen, als "fortgeschritten" und nicht als "Anfänger" zu bezeichnen, da dieses Buch nicht für diejenigen geeignet ist, 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 über diese Punkte hinausgeht, ist ein Pluspunkt und wird es dir erleichtern, 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 Voraussetzungen 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

Ich glaube, man kann mit Fug und Recht behaupten, dass dieses Buch sich in erster Linie an Softwareentwickler/innen und Webanwendungsentwickler/innen richtet, die sich am Anfang oder in der Mitte ihrer Laufbahn befinden. Idealerweise ist dieser Leser daran interessiert, ein tiefes Verständnis für die von Hackern genutzten Offensivtechniken oder für die von Sicherheitsingenieuren genutzten Defensivtechniken zur Abwehr von Hackern zu erlangen.

Oft werden die Bezeichnungen "Webanwendungsentwickler" und "Softwareentwickler" synonym verwendet, was zu einer gewissen Verwirrung führen könnte, da ich in den folgenden Kapiteln beide Begriffe verwende. 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 in diesem Buch enthaltenen Wissens mit minimalem Aufwand 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.

Außerdem nutzen mehrere in diesem Buch besprochene Exploits serverseitige Integrationen, die eine 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

Ein "Webanwendungsentwickler" hingegen ist nach meiner Definition jemand, der hochspezialisiert ist auf das Schreiben von Software, die im Web 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 einen Backend- oder Full-Stack-Entwickler sehr transparent und leicht verständlich ist.

Ich glaube, dass dieses Buch auch für andere Arten von Webanwendungsentwicklern wertvoll sein sollte, einschließlich derer, die keinen Code schreiben, der auf einem Server, sondern auf einem Webbrowser läuft (Frontend-/JavaScript-Entwickler).

Wie ich in den folgenden Kapiteln erkläre, gehen viele der Methoden, mit denen 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.

Diese Punkte legen nahe, dass es auch für Frontend-Entwickler, die keinen serverseitigen Code schreiben, wichtig ist, sich der Sicherheitsrisiken bewusst zu sein, denen ihr Code ausgesetzt sein kann, und zu wissen, wie diese Risiken gemindert werden können.

Allgemeine Lernziele

Dieses Buch ( ) ist eine fantastische Ressource für alle, die einen Karrierewechsel zu einer stärker sicherheitsorientierten 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. Dieses Buch folgt einer einzigartigen Struktur, die es dir ermöglichen sollte, es als Sicherheitsreferenz zu nutzen, ohne jemals eines der Kapitel lesen zu müssen, in denen es um Hacking geht. Das gilt natürlich nur, wenn das dein einziges Ziel beim Kauf dieses Buches ist.

Ich würde empfehlen, das Buch von vorne bis hinten durchzulesen, um die beste Lernerfahrung zu machen. Wenn du aber nur ein Nachschlagewerk für die Absicherung gegen bestimmte Arten von Hacks suchst, kannst du das Buch einfach zur Hälfte aufschlagen und mit dem Lesen beginnen.

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

Aufgrund der Struktur dieses Buches kann es auch als Ressource für Penetrationstests, Bug Bounty Hunting und jede andere Art von Sicherheitsarbeit auf Anwendungsebene verwendet werden. Wenn diese Art von Arbeit für dich relevant oder interessant ist, wird dir die erste Hälfte des Buches vielleicht mehr zusagen.

In diesem Buch wird tief in die Funktionsweise von Exploits sowohl auf Code- als auch auf Architekturebene eingetaucht, 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: Software-Sicherheitsingenieure, IT-Sicherheitsingenieure, Netzwerksicherheitsingenieure, Penetrationstester und Bug-Bounty-Jäger.

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 Bug-Bounty-Programme an, die in Teil III beschrieben sind. Das ist eine tolle Möglichkeit, anderen Unternehmen zu helfen, die Sicherheit ihrer Produkte zu verbessern, während du deine Hacking-Fähigkeiten weiterentwickelst und etwas Geld dazuverdienen kannst.

Dieses Buch ist sehr nützlich für Sicherheitsexperten, die verstehen, wie viele Angriffe konzeptionell funktionieren, aber gerne einen tieferen Einblick in die Systeme und den Code hinter einem Tool oder Skript hätten.

In heutigen Sicherheitswelt 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).

Das soll den Wert von spezialisierten Sicherheitstools nicht schmälern. Ich finde sogar, dass viele von ihnen außergewöhnlich sind und die Durchführung professioneller, hochwertiger Penetrationstests sehr viel einfacher machen!

Der Grund dafür, dass in diesem Buch keine speziellen Sicherheitstools verwendet werden, liegt darin, dass wir uns auf das Wichtigste konzentrieren können: das Auffinden einer Schwachstelle, die Entwicklung eines Exploits, die Priorisierung der zu kompromittierenden Daten und die Sicherstellung, dass du dich gegen all das verteidigen kannst. Ich bin überzeugt, dass du am Ende dieses Buches in der Lage sein wirst, neue Arten von 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.

Nachdem wir unser Abenteuer mit einer kleinen Geschichtsstunde und einer Erkundung der Technologien, Tools und Exploits der Vergangenheit begonnen haben, wenden wir uns unserem Hauptthema zu: Exploitation und Gegenmaßnahmen für moderne Webanwendungen. Daher auch der Untertitel dieses Buches.

Der Hauptinhalt dieses Buches ist in drei große Teile gegliedert, wobei jeder Teil viele einzelne Kapitel enthält, die eine breite Palette von Themen abdecken. Idealerweise gehst du dieses Buch linear durch, von der ersten bis zur letzten Seite. Wenn du das Buch in dieser Reihenfolge liest, wirst du den größtmöglichen Lernerfolg erzielen. Wie bereits erwähnt, kannst du dieses Buch auch als Nachschlagewerk für Hacker oder als Nachschlagewerk für Sicherheitstechniker verwenden, indem du dich auf die erste bzw. zweite Hälfte konzentrierst.

Inzwischen solltest du wissen, wie du dich in dem Buch zurechtfindest. Gehen wir also die drei Hauptteile des Buches durch, damit wir die Bedeutung jedes einzelnen Teils verstehen können.

Aufklären

Der erste Teil dieses Buches ist "Aufklärung", in dem wir Möglichkeiten untersuchen, um Informationen über eine Webanwendung zu erhalten, ohne sie unbedingt hacken zu wollen.

In "Recon" 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 sperren 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. Durch meine Gespräche mit ihnen und meine Analyse ihrer Arbeit ist mir klar geworden, dass dieses Thema viel wichtiger ist, als es in vielen anderen Büchern dargestellt wird.

Warum ist Aufklärung wichtig?

Ich würde sogar so weit gehen zu sagen, dass für viele der besten Bug Bounty Hunters der Welt die Fähigkeit zur Aufklärung auf Expertenebene das ist, was diese "großartigen" Hacker von einfach "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 derjenige, der dabei hilft, die Schüsse zu platzieren und herauszufinden, welche Kämpfe die größten Gewinne versprechen.

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.

Wir können sicher sein, dass der zweite Nutzen der Aufklärung darin besteht, herauszufinden, wie du deine Exploits priorisieren kannst.

Wenn du dich für eine Karriere als Penetrationstester oder Bug Bounty Hunter interessierst, wird dieser Teil des Buches für dich von größter Bedeutung sein. Das liegt vor allem daran, dass in der Welt der Bug Bounty Hunts 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 Bild von der Anwendung machen muss.

Offensive

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

Warnung

In einigen Kapiteln dieses Buches ( ) werden tatsächliche Hacktechniken 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 Hacktechniken kann je nach den Gesetzen deines Landes zu Geldstrafen, Gefängnisaufenthalten usw. 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, "Aufklärung", 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. Jedes Kapitel erklärt im Detail eine andere Art von Exploit.

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.

Eingehend betrachtete Schwachstellen

Cross-Site Scripting (XSS), eines der ersten Exploits, mit dem wir uns befassen, 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 Leser, 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 zurück und betrachten jede Art von Exploit, die wir in Teil II behandelt haben, noch einmal aus einem völlig anderen Blickwinkel. Diesmal konzentrieren wir uns nicht darauf, in Softwaresysteme einzubrechen, sondern versuchen stattdessen, 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 von immer wertvolleren Tricks, um Hacker auf frischer Tat zu ertappen und die Einstellung deines Unternehmens zur Softwaresicherheit zu verbessern.

Die meisten Kapitel in Teil III sind ähnlich aufgebaut wie die Hacking-Kapitel in Teil II. Wir beginnen mit einem Überblick über die Technologie und die Fähigkeiten, die erforderlich sind, 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.

Unter beginnt die Struktur von Teil III sich von der von Teil II zu unterscheiden, da wir Kompromisse diskutieren, die sich aus der Verbesserung der Anwendungssicherheit ergeben. Im Allgemeinen sind alle Maßnahmen zur Verbesserung der Sicherheit mit Kompromissen verbunden, die nicht die Sicherheit betreffen. Es steht dir zwar nicht zu, Vorschläge zu machen, welches Risiko du auf Kosten deines Produkts in Kauf nehmen solltest, aber du solltest dir der Kompromisse bewusst sein, die dabei 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 werden einige Sicherheitsvorkehrungen auf Kosten der Benutzerfreundlichkeit gehen.

Bewertung des Kompromisses

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 Benutzername 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 ein paar Benutzernamen erfolgreich erzwingen, die dann bestätigt und für spätere Einbruchsversuche protokolliert werden können.

Als Nächstes muss der Hacker nur noch Passwörter erzwingen und nicht mehr Kombinationen aus Benutzername und Passwort, 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 verbessern 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 darüber, wie die Sicherheit einer Anwendung verbessert werden kann, ein wertvolles Kapital für jede Art von Hacker. 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 du in einigen Teilen dieses Buches je nach deinen Zielen mehr lernst als in anderen, wird nichts davon verschwendet sein. 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 beizubringen. Diese Fähigkeiten werden zwar immer wertvoller und verbessern deine Chancen auf dem Arbeitsmarkt, aber sie sind auch ziemlich schwer zu erlernen, denn sie erfordern Konzentration, Geschick und die Fähigkeit, sich ein ganz neues Denkmodell anzueignen, das bestimmt, wie du Webanwendungen betrachtest.

Um diese neuen Fähigkeiten richtig vermitteln zu können, müssen wir eine gemeinsame Sprache finden. Das ist wichtig, damit ich dich ohne Verwirrung durch das Buch führen kann und damit du deine neuen Ideen auf eine 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. Das hast du schon gesehen, als ich Cross-Site Scripting (XSS) erklärt habe.

Darüber hinaus habe ich mein Bestes getan, um herauszufinden, welche Begriffe und Ausdrücke erklärungsbedürftig sein könnten. Ich habe sie gesammelt und in den folgenden Tabellen (Tabellen P-1 bis P-3) zusammengestellt.

Wenn du jemals über einen Begriff oder eine Formulierung stolperst, die du nicht ganz verstehst, kannst du gerne zu diesem Kapitel zurückgehen (Lesezeichen setzen!) und nachsehen, ob es hier aufgeführt ist. Wenn nicht, kannst du meinem Redakteur eine E-Mail schicken, und vielleicht können wir es in die nächste Ausgabe des Buches aufnehmen - falls ich das Glück habe, genug Exemplare zu verkaufen, um eine Fortsetzung zu rechtfertigen!

Tabelle P-1. Beruf

Beruf	Beschreibung
Hacker	Jemand der in Systeme einbricht, in der Regel 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, der irgendwo zwischen White Hat und Black Hat angesiedelt ist. 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 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öswilligen Absichten 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 auch "Product Security Engineer" genannt - ein Software ingenieur, 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	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 Softwareentwickler, 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 Versehen der Entwickler oder unerwartete Funktionen 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	Typischerweise ein Codeblock oder eine Liste von Befehlen, mit denen eine Sicherheitslücke ausgenutzt werden kann.
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 oft aus Penetrationstestern, Netzwerksicherheitsingenieuren und Software-Sicherheitsingenieuren besteht. 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 oft aus Software-Sicherheitsingenieuren und Netzwerksicherheitsingenieuren besteht. Dieses Team versucht, die Softwaresicherheit eines Unternehmens zu verbessern und nutzt dabei oft das Feedback des roten Teams, um die 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, das aufgrund der hohen Qualifikationsanforderungen oft schwieriger richtig zu besetzen ist.
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 auf 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 Benutzer/innen oft ermöglichen, Inhalte mit anderen zu teilen.
Hybride Anwendung	Eine mobile Anwendung, die auf einer webbasierten Technologie aufbaut. In der Regel nutzen sie eine andere Bibliothek, wie Apache Cordova, um native Funktionen mit der Webanwendung zu teilen.

Tabelle P-3. Akronyme

Acryonym	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 Rechte eines privilegierten Benutzers ausnutzen kann, um Anfragen an einen Server zu stellen.
CSS	Cascading Style Sheets - eine Formatierungssprache, 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 (Dienstverweigerung) - 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 Internet 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 wird.
JSON	JavaScript Object Notation - eine Spezifikation für die Speicherung von hierarchischen Daten in einer Art und Weise, die leichtgewichtig, für Menschen leicht lesbar und für Maschinen leicht lesbar 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, anstatt um Funktionalität oder Logik.
OSS	Offene Quellensoftware - 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	Kommunikation in Echtzeit - 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 festgelegte Schemata erfordern. Unterstützt nur XML als Datenformat.
SOP	Same Origin Policy - eine vom Browser durchgesetzte 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	Sicher 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	Version Versionskontrolle - eine spezielle Art 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 Art von Angriff, bei dem 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 von Nutzen ist. Es ist außerdem so geschrieben, dass es für jede Art von Entwickler oder Administrator mit ausreichenden Kenntnissen in der Webprogrammierung (Client + Server) leicht zu verstehen und anzuwenden ist.

Web Application Security führt dich durch eine Reihe von Techniken, die von talentierten Hackern und Bug Bounty Hunters eingesetzt werden, um in Anwendungen einzubrechen. Anschließend lernst du die Techniken und Prozesse kennen, die du in deiner eigenen Software implementieren kannst, um dich vor solchen Hackern zu schützen.

Dieses Buch ist so konzipiert, dass es von der ersten bis zur letzten Seite gelesen werden kann, kann aber auch als Nachschlagewerk für bestimmte Arten von Aufklärungsmethoden, Angriffen und Verteidigungsmaßnahmen gegen Angriffe verwendet werden. Letztlich soll dieses Buch dem Leser dabei helfen, die Sicherheit von Webanwendungen zu verbessern, und zwar auf praktische Art und Weise und 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 (den Leser) 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 schicken.

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 über 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, Konferenzen 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 findest du unter http://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-998-9938 (in den Vereinigten Staaten oder Kanada)
• 707-829-0515 (international oder lokal)
• 707-829-0104 (Fax)

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-app-security aufrufen .

Schreib eine E-Mail an [e-mail], um Kommentare oder technische Fragen zu diesem Buch zu stellen.

Weitere Informationen zu unseren Büchern, Kursen, Konferenzen und Neuigkeiten findest du auf unserer Website unter http://www.oreilly.com.

Finde uns auf Facebook: http://facebook.com/oreilly

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

Schau uns auf YouTube: http://www.youtube.com/oreillymedia