Bedrohungen für Webanwendungen

Transkript

1 Bedrohungen für Webanwendungen 2 Wir beginnen damit den Kampf zu verlieren. Robert Thornton, Gründer von Fortify Software Zusammenfassung In diesem Kapitel werden zentrale Angriffe und Schwachstellen für Webanwendungen erläutert, deren Verständnis die Grundlage für die anschließende Diskussion von Maßnahmen darstellt. Der Einsatz von Webanwendungen ist mit einer Vielzahl von technischen Gefahren verbunden, die wiederum über eine noch größere Anzahl an Begriffen beschrieben werden. Das Web Application Security Consortium (WASC) hat mit der Threat Classification (WASC) (vergl. [23]) einen Versuch unternommen, diese Begriffswelt etwas zu strukturieren und unterscheidet drei Sichten: Die auf die Schwachstelle (Ursache), auf den Angriff (Ausnutzung) und den Impact (Auswirkung). In diesem Kapitel werden wir uns damit näher beschäftigen, bevor wir uns im nächsten Kapitel den entsprechenden Gegenmaßnahmen zuwenden. Diese Trennung ist auch deshalb von großer Bedeutung, da Sicherheitsmaßnahmen keinesfalls ausschließlich zur Korrektur einzelner Schwachstellen oder der Prävention bestimmter Angriffe dienen, sondern auch, um der Anwendung ein bestimmtes Sicherheitsniveau zu verleihen. 2.1 Begriffe und Konzepte In den folgenden Abschnitten werden einige zentrale Begriffe und Konzepte erläutert, die für die Diskussion in diesem Kapitel grundlegend sind. Springer Fachmedien Wiesbaden 2015 M. Rohr, Sicherheit von Webanwendungen in der Praxis, Edition <kes>, DOI / _2 43

2 44 2 Bedrohungen für Webanwendungen Bedrohung, Bedrohungsquelle und Gefährdung Im Rahmen der IT-Sicherheit ist häufig von Angriffen die Rede, denen etwa eine Webanwendung ausgesetzt sein kann. Angriffe stellen jedoch keinesfalls die einzige Gefahr für eine Webanwendung dar. Besser eignet sich daher der Begriff Bedrohungen. Bedrohung (engl. Threat) Eine Eigenschaft, ein Umstand oder ein Ereignis, durch die ein Schaden für ein Asset (z. B. Systeme, Anwendungen, Informationen) entstehen kann. Bedrohungen können dabei sowohl vorsätzlich als auch unbeabsichtigt sein. Gehen Bedrohungen wie Hackerangriffe noch eindeutig von Angreifern aus, ist ein solcher in vielen anderen Fällen keineswegs involviert. Es wird in diesem Zusammenhang daher häufig allgemein von Bedrohungsquellen gesprochen, um alle vorhandenen Ursachen für eine Bedrohung mit einzuschließen. Bedrohungsquelle (engl. Threat Source bzw. Threat Agent) Eine Person oder ein Prozess von der/dem eine Bedrohung vorsätzlich (z. B. im Fall eines Angreifers) oder unabsichtlich (z. B. im Fall eines Entwicklers, der einen Fehler macht) ausgeht. An dieser Stelle darf auch ein weiterer Begriff nicht unerwähnt bleiben, nämlich der einer Gefährdung. Eine Gefährdung ist eine Bedrohung, die aufgrund einer existierenden oder angenommenen Schwachstelle in einer Anwendung vorhanden ist. Sofern sich zwar (noch) keine Schwachstelle identifizieren lässt, jedoch relevante Systemeigenschaften hierfür vorhanden sind (z. B. eine Datenbankanbindung in Bezug auf eine SQL-Injection- Schwachstelle), so lässt sich von einer potentiellen Gefährdung sprechen. Gefährdung (engl. Applied Threat) Eine Gefährdung ist eine Bedrohung, die konkret auf ein Objekt über eine Schwachstelle einwirkt (BSI Glossar). Eine potentielle Gefährdung ist eine Bedrohung, zu der zwar bislang keine relevante Schwachstelle, jedoch die entsprechenden Systemeigenschaften identifiziert werden konnten. Eine Gefährdung ist als eine tatsächlich auftretende Bedrohung zu verstehen und in dem Zusammenhang gibt es auch einer Gefährdungsquelle sprechen, von der sie ausgeht. Entsprechend wird daher nicht von einem Bedrohungs- sondern einem Gefährdungspotential gesprochen. In Abschn wird ausführlich auf Bedrohungsanalysen eingegangen, mit welchen sich für eine Anwendung relevante Bedrohungen (= potentielle Gefährdungen) ermitteln lassen.

3 2.1 Begriffe und Konzepte Schwachstellen und Sicherheitslücken Derzeit werden im Deutschen die Begriffe Schwachstelle und Sicherheitslücke manchmal differenzierend, oftmals jedoch synonym verwendet. Ganz anders sieht es im Englischen aus, wo eine klare Unterscheidung zwischen beiden Begriffen existiert. Diese Unterscheidung ist nicht nur hilfreich, sondern auch ganz besonders wichtig, da wir über diese wesentlich deutlicher ein Sicherheitsproblem beschreiben können. Hierfür benötigen wir allerdings eine genaue Definition beider Begriffe. Beginnen wir mit dem einer Schwachstelle : Schwachstelle (engl. Weakness) 1 Eine Schwachstelle (auch: Schwäche ) stellt eine Eigenschaft in der Implementierung, Architektur, Konfiguration oder eines Prozesses dar, die unter bestimmten Bedingungen zu einer Sicherheitslücke führen kann. Eine Schwachstelle ist somit nicht auf den Quelltext einer Anwendung beschränkt, sondern lässt sich auch in der Architektur, der Konfiguration und sogar in organisatorischen Prozessen wiederfinden. Wichtig für diese Einordnung (also ob wir es mit einer architekturellen oder konfigurativen Schwachstelle zu tun haben) ist dabei immer die Bewertung der Natur einer Schwachstelle, nicht deren Behebung. Denn häufig lässt sich das Auftreten einer Implementierungs-Schwachstelle (z. B. eine fehlerhafte Enkodierung) auf architektureller Ebene verhindern oder deren Ausnutzung auf betrieblicher Ebene unterbinden, doch bleibt sie immer von ihrer Natur her ein Implementierungsfehler. Im nachfolgenden Kapitel werden einige konkrete Beispiele gezeigt. Neben Schwachstellen haben wir es in der Anwendungssicherheit häufig auch mit Sicherheitslücken zu tun. Dieser Begriff lässt sich wie folgt definieren: Sicherheitslücke (engl. Vulnerability) Eine Sicherheitslücke (auch Verwundbarkeit oder Angreifbarkeit ) bezeichnet das konkrete Auftreten einer oder mehrerer Schwachstellen, über welche die Sicherheit einer Anwendung nachweislich beeinträchtigt werden kann. Einer Sicherheitslücke liegt somit immer mindestens eine Schwachstelle zugrunde. Auch wenn beide Begriffe gerade im Deutschen leider oft vermengt werden, ist deren Abgrenzung sehr wichtig. Schauen wir uns zum besseren Verständnis das folgende Beispiel an: Beispiel Eine Gefängnismauer besitzt einen Riss, der zunächst einmal eine Schwachstelle darstellt. Nicht zwangsläufig ist durch diesen Riss jedoch gleich auch die Sicherheit des gesamten Gefängnisses akut gefährdet. Ist dies aber der Fall und können etwa Gefäng- 1 Der Begriff Schwachstelle wird häufig auch fälschlich mit Vulnerability übersetzt.

4 46 2 Bedrohungen für Webanwendungen nisinsassen durch den Riss die Mauer einreißen, so stellt dieser nicht nur eine Schwachstelle, sondern gleichzeitig auch eine Sicherheitslücke dar. In erster Linie arbeiten wir innerhalb der Webanwendungssicherheit mit Schwachstellen. Denn während wir Schwachstellen grundsätzlich in allen Entwicklungsphasen einer Anwendung identifizieren können (da es sich schließlich nur um sicherheitsrelevante Eigenschaften handelt), ist dies bei einer Sicherheitslücke erst dann möglich, wenn eine Anwendung bereits weitgehend fertiggestellt ist. Dann erst können wir die notwendige Bewertung anstellen, ob es sich tatsächlich um ein akutes Sicherheitsproblem handelt. Aus Gründen der Vereinfachung wird in diesem Buch hauptsächlich von Schwachstellen gesprochen, auch wenn diese in bestimmten Situationen eine Sicherheitslücke darstellen können. Weiterhin existieren noch einige weitere Begriffe mit denen wir es in diesem Zusammenhang häufiger zu tun haben. Exploits und Payloads Unter einem Exploit wird eine technische Beschreibung des Vorgehens zur Ausnutzung einer Schwachstelle verstanden. Häufig wird dieser in Form von Code oder eines URL- Aufrufes dargestellt. Mit einem Payload beschreiben wir die Schadfunktion, die in Verbindung mit einem Exploit zum Einsatz kommt. Im Rahmen von Tests werden in der Regel harmlose Payloads verwendet, die keinen Schaden anrichten, sondern nur für die Identifikation bzw. Demonstration einer Schwachstelle dienen. In letzterem Fall sprechen wir auch von sogenannten Proof-of-Concepts (PoCs). Bekannte Sicherheitslücken (Known Vulnerabilitys) Unter einer bekannten Sicherheitslücke wird eine ausnutzbare Schwachstelle außerhalb von Individualsoftware verstanden, also etwa in Standardsoftware oder Opensource (FOSS). Known Vulnerabilitys werden über das CVE-Verzeichnis ( Abschn. 1.4) über einen CVE-Identifier (z. B. CVE ) eindeutig referenziert. Über die letzten zehn Jahre betrachtet hat die Zahl bekannter Sicherheitslücken, auch in Webkomponenten, stetig zugenommen (vergl. [22]). Allerdings ist diese Zunahme nicht nur dadurch bedingt, dass Software laufend unsicherer wird, sondern es schlicht immer mehr Software gibt und das Wissen um Verfahren zur Identifikation von Schwachstellen laufend voranschreitet. In Bezug auf Webanwendungen können Known Vulnerabilitys in unterschiedlichen Bereichen auftreten: in Web-GUIs von Standardprodukten, in Browsern oder Browser-Plugins (z. B. Flash, Adobe PDF), in Web- und Anwendungs-Servern (z. B. IIS, Apache, WebSphere), in eingesetzten Anwendungskomponenten (z. B. Wordpress, Joomla!), in eingesetzten Bibliotheken und Frameworks (z. B. ASP.NET, jquery), in Laufzeitumgebungen (z. B. JRE,.NET oder PHP),

5 2.1 Begriffe und Konzepte 47 in Sicherheitskomponenten (z. B. Application Firewalls) sowie in Entwicklungstools. Grundsätzlich handelt es sich bei solchen bekannten Sicherheitslücken um dieselben Schwachstellen, mit denen wir es auch bei individuell entwickelten Webanwendungen zu tun haben, also Cross-Site Scripting, SQL Injection, Information Disclosure etc. Anders als Webanwendungen sind viele Standardkomponenten mit C und C++ programmiert, bei denen wir es auch mit Schwachstellen wie Pufferüberläufen (Abschn. 2.4) zu tun bekommen. Bekannte Sicherheitslücken müssen über das Einspielen entsprechender Patche behoben werden erfordern also ein Patch Management. Auch wenn ein Unternehmen ein Patch Management betreibt, so schließt dieses gewöhnlich Anwendungskomponten und APIs nicht mit ein. Für solche 3rd-Party-Komponenten muss daher ein seperates Patchmangement eingerichtet werden (Abschn ). Zero Days Viele Exploits werden dadurch erstellt, dass ein Patch von Angreifern reverse engineered und dadurch die Sicherheitslücke identifiziert wird, die der Patch behebt. Bei einem Zero Day Exploit ist dies anders. Ein solcher Exploit liegt bereits vor, noch bevor die zugehörige Sicherheitslücke dem Hersteller bekannt ist. Ein Zero Day ist dadurch besonders gefährlich, schließlich kann er selbst ein aktuell gepatchtes System kompromittieren. In manchen Fällen lässt sich die Ausnutzbarkeit einer Sicherheitslücke bereits dadurch unterbinden, dass der entsprechende Exploit einfach geblockt wird. Da diese Art von Maßnahme nicht die eigentliche Ursache behebt, wird sie auch als Virtual Patching bezeichnet. In anderen Fällen kann es unausweichlich sein, die betroffene Komponente zu deaktivieren, wenn das Risiko einer Kompromittierung als zu groß bewertet wird. Es ist kaum überraschend, dass für diese Art von Exploits ein florierender Schwarzmarkt existiert. Je nach betroffenem Produkt und Art des Exploits werden dort teilweise immense Summen für einen Zero Day bezahlt. Flaws, Bugs und Defects Im Verlauf dieses Buches werden häufiger verschiedene allgemeine Begriffe für Softwarefehler verwendet. Hierzu zählen vor allem Flaws, Bugs sowie Defects. Mit einem Bug ist ein Implementierungs- oder Coding-Fehler, mit einem Flaw dagegen ein Fehler in der Architektur bzw. dem Entwurf einer Anwendung gemeint. Ein Defect stellt einen Oberbegriff dar, der sowohl Bugs als auch Flaws einschließt. Auch eine Schwachstelle kann ein Defect sein. Allerdings nur dann, wenn sie unabsichtlich erzeugt wurde. Ansonsten ist gewöhnlich von Schadcode (Malware) die Rede. Abbildung 2.1 bringt mehr Klarheit hinter die einzelnen Begrifflichkeiten. Indikatoren ( Smells ) In der Anwendungssicherheit haben wir es keinesfalls nur mit konkreten Schwachstellen bzw. Sicherheitsmängeln zu tun. Häufig sind es sehr viel schwächere Symptome, die nicht gleich ein Sicherheitsproblem darstellen, jedoch auf ein solches hindeuten können.

6 48 2 Bedrohungen für Webanwendungen Abb. 2.1 Defects vs. Schadcode Wir kennen hierfür aus der Softwarequalität den Begriff des Code-Smells. Laut Wikipedia handelt es sich dabei um ein Symptom im Code, welches auf ein tiefergehendes Problem hindeutet (vergl. [24]). Geläufige Beispiele dafür sind der sogenannte Spaghetticode 2 oder auch toter Code und prinzipiell alles was darauf hindeutet, dass ein Entwickler entweder nicht wirklich wusste, was er gemacht hat, unter Zeitdruck stand oder aus anderen Gründen unsauber gearbeitet hat. Häufig wurde Code zudem auch von so vielen Personen überarbeitet, dass er am Ende von keinem mehr so richtig durchdrungen werden kann. Natürlich lassen sich Code Smells auch in Bezug auf Sicherheitsprobleme recht häufig identifizieren. Hierzu einige Beispiele: Verwenden eigener Verschlüsselungsalgorithmen oder Validierungsroutinen Lösung von architekturellen Problemen auf programmtechnische Weise Blacklisting einzelner Angriffsmuster oder Exploits (meist mittels regulärer Ausdrücke) Ignorieren der Ausgabebehandlung, insbesondere bei sicherheitsrelevanten Funktionen Fehlende Trennung zwischen Code und Darstellung Hartkodierte Zugangsdaten (Credentials) Ebenso können wir sicherheitsrelevante Smells vorfinden: Anwendung versendet Passwörter in s Anwendung ist ausschließlich über HTTP aufrufbar Anwendung setzt verschiedene X-Header die auf den zugrundeliegenden Technologiestack offenlegen Anwendung verwendet Hidden Fields oder Cookies zum Transport von interner Parametrisierung (z. B. einer User-Id) Anwendungslayout reagiert bei der Eingabe bestimmter Sonderzeichen ungewöhnlich (zerstörtes Layout, andere Fehlermeldung als üblich) 2 siehe

7 2.1 Begriffe und Konzepte 49 Schließlich können Symptome auf Sicherheitsprobleme hindeuten und bereits in der Architektur einer Anwendung identifiziert werden. Beispiele für solche architekturellen Smells die wir auch als Anti-Patterns bezeichnen können sind: Unnötiges Exponieren von Schnittstellen (zahlreiche Eingangspunkte, Admin-Schnittstellen) Keine zentrale Behandlung von Eingabewerten Fehlende Separierung von Model, View und Controller (MVC-Pattern) Hinweise auf fehlende Authentifizierung und Autorisierung (insb. im Backend) Security Smell Indikator für Sicherheitsproblem in Code (Code-Smell) oder Architektur (Architektur Smell) Angriffe Ein Angriff, der im Deutschen auch gelegentlich als Attacke bezeichnet wird, stellt oft nur eine andere Sicht auf eine Schwachstelle dar, nämlich aus der eines Angreifers. Dabei setzt die Durchführung eines solchen natürlich nicht zwangsläufig die Existenz einer Schwachstelle voraus. Vielfach führen Angreifer diese auf gut Glück durch, insbesondere wenn sie Tools einsetzen, die eine Webanwendung mit zahlreichen Exploits beschießt. Auch muss ein Angriff überhaupt nicht gegen eine Schwachstelle gerichtet sein. So wie im Fall von DDoS-Attacken, die schlicht die Ressourcen eines Systems verbrauchen. Angriff Ein Angriff stellt ein böswilliges Vorgehen (= Sequenz von Aktionen) dar, mit dem die Absicht verfolgt wird, eine Sicherheitslücke auszunutzen oder die Sicherheit einer Anwendung in anderer Weise zu beeinträchtigen. Nun ist es an dieser Stelle wichtig, den Begriff Angreifer genauer zu differenzieren. Allgemein lässt sich ein Angriff über die folgenden drei Eigenschaften kategorisieren: Extern oder intern (z. B. Internet oder Intranet) Anonym oder authentisiert Nicht-privilegiert oder privilegiert Einmalig oder dauerhaft Gezielt oder ungerichtet Ist eine Sicherheitslücke durch einen externen, anonymen Angreifer ausnutzbar, so kommt ihr zweifelsohne eine deutlich höhere Kritikalität zu, als dem Angriff durch einen internen und angemeldeten privilegierten Benutzer (also etwa einen Administrator). Der gerade von Medien häufig genannte Hacker ist dagegen mehr umgangssprachlicher Natur und

8 50 2 Bedrohungen für Webanwendungen Abb. 2.2 Bestandteile eines Angriffs (Quelle: OWASP) zur technischen Kategorisierung schlecht geeignet. Daher wird in diesem Buch in der Regel von Angreifern gesprochen. Bestandteile eines Angriffs Jeder Angriff besitzt verschiedeneeigenschaften, durch die wir ihn letztlich genau beschreiben und bewerten können. Ausgangspunkt ist dabei immer der Angreifer, der gewöhnlich eine konkrete Motivation, bestimmte Fertigkeiten und Ressourcen, sowie ein konkretes Ziel besitzt. Dieses Ziel lässt sich dabei gewöhnlich als technische Auswirkung (engl. Technical Impact) und/oder geschäftliche Auswirkung (engl. BusinessImpact) beschreiben. Die tatsächliche Vorgehensweise eines Angreifers wird als Angriffs-Vektor 3 bezeichnet. Die Ausnutzung einer Schwachstelle wird ggf. durch existierende Sicherheitsmechanismen (Security Controls) unterbunden oder zumindest erschwert. Etwa durch einen vorgeschalteten Filter oder eine sonstige Eingabevalidierungs-Funktion. Neben der eigentlichen Ausnutzung einer Schwachstelle sind Angreifer daher auch häufig mit der Aushebelung solcher (Gegen-)Mechanismen beschäftigt. Abbildung 2.2 veranschaulicht die einzelnen Bestandteile eines Angriffs. Die Darstellung in Abb. 2.2 ist deshalb so wertvoll, weil sie den technischen Aspekt eines Angriffs mit der Auswirkung auf die Geschäftstätigkeit in Verbindung setzt. Häufig wird dieser letzte Schritt nicht gegangen und Angriffe ausschließlich von der rein technischen Seite betrachtet. Nur durch Berücksichtigung des entsprechenden fachlichen Kontextes bekommt Sicherheit letztlich Relevanz! 3 Ein Angriffsvektor (oder einfach Vektor ) beschreibt einen konkreten technischen Weg, über den ein Angriff durchgeführt wird. Im Fall der Ermittlung einer Session-ID besteht ein Angriffsvektor etwa in der Ausnutzung einer Cross-Site-Scripting-Schwachstelle, ein anderer im Auslesen der ID aus einer Logdatei.

9 2.1 Begriffe und Konzepte 51 Abb. 2.3 Direkter Angriff Abb. 2.4 Indirekter Angriff ( Cross-Site-Angriff ) Bezogen auf eine Webanwendung lässt sich ein Angriff prinzipiell auf drei verschiedene Weisen durchführen: direkt, indirekt sowie unabhängig. Letzteres findet z. B. in Form eines -basierten Phishing-Angriffs statt, bei dem ein Angreifer sein Opfer auf eine gefälschte Webseite lockt. Da das Verständnis dieser drei Formen elementar wichtig ist, sollen sie genauer dargestellt werden: Direkte Angriffe Ein direkter Angriff (Abb. 2.3) ist dadurch gekennzeichnet, dass er nur einen Akteur besitzt, nämlich den Angreifer. Dieser versucht eine Schwachstelle innerhalb einer Anwendung auszunutzen, um darüber vertrauliche Daten zu stehlen (Schutzziel Vertraulichkeit), Inhalte zu manipulieren (Schutzziel Integrität) oder andere Schäden zu verursachen. Zu dieser Gruppe von Angriffen gehört etwa SQL Injection, Code Injection, Password Enumeration, Privilegienerweiterung (bzw. das Erlangen von Privilegien) und Information Disclosure. Die kritischsten Schwachstellen sind fast ausnahmslos durch direkte Angriffe ausnutzbar. Allerdings lassen sie sich dafür in der Regel sehr einfach beheben bzw. ihr Auftreten verhindern. Direkter Angriff Ein direkter Angriff hat die Kompromittierung der Anwendung selbst, der Plattform oder der verarbeiteten Daten zum Ziel. Indirekte Angriffe Für die Durchführung eines indirekten Angriffs (Abb. 2.4) kommt zusätzlich zum Angreifer nun auch noch ein weiterer Benutzer dieser Anwendung ins Spiel. In den meisten Fällen muss dieser Benutzer dort aktuell angemeldet sein. Über die Webanwendung (z. B. durch Ausnutzen einer vorhandenen Sicherheitslücke) greift der Angreifer den Benutzer an. Zu dieser Gruppe zählen grundsätzlich alle Angriffe, die ein Cross-Site im Namen tragen, wie zum Beispiel Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF) oder Cross-Site Redirection. Die konkrete Durchführung eines indirekten Angriffs erfolgt

10 52 2 Bedrohungen für Webanwendungen Abb. 2.5 Seitenkanalangriff etwa über einen manipulierten Link, den der Angreifer vom Benutzer aufrufen lassen muss. Mögliche Vektoren sind z. B. das Zusenden einer gefälschten oder das Posten eines Links in einem Forum. Die praktische Ausnutzungswahrscheinlichkeit ist deutlich eingeschränkter als im Fall eines direkten Angriffs. Darüber hinaus lassen sich direkte Angriffe vielfach auf Serverseite vollständig unterbinden. Da wir in der Regel nicht die Ausführungsumgebung des Benutzers (also den Browser) kontrollieren können, ist dies mit indirekten Angriffen meist eben nicht möglich. Bei indirekten Angriffen muss zusätzlich zum serverseitig ausgeführten Programmcode auch die Umgebung des Benutzers, also etwa dessen Webbrowser, mit in die Sicherheitsbetrachtung und die Definition von Maßnahmen einbezogen werden muss. Da dieser jedoch anwendungsextern und damit grundsätzlich nicht durch die Anwendung selbst kontrollierbar ist, lassen sich zahlreiche indirekte Angriffe oftmals nur sehr schwer ausschließen. Dieser Aspekt wurde bereits in Abschn ( Fehlende Kontrolle der Ausführungsumgebung ) als einer der zentralen Gründe für unsichere Webanwendungen angeführt. Wie wir später noch genauer sehen werden, können wir jedoch durch verschiedene Maßnahmen (insbesondere durch Setzen von bestimmten Security Headern) die Sicherheit der Clientseite sehr positiv beeinflussen. Indirekter Angriff Ein indirekter Angriff nutzt Schwachstellen (bzw. Eigenschaften) in einer Anwendung dazu aus, andere, meist dort angemeldete Benutzer, anzugreifen. Seitenkanalangriffe Eine dritte, wenn auch meist weniger im Fokus stehende Kategorie bilden die unabhängigen oder auch Seitenkanalangriffe (Abb. 2.5). Diese zeichnen sich durch die Eigenschaft aus, dass sie völlig unabhängig von einer bestimmten Anwendung durchgeführt werden. Involviert in einen solchen Angriff sind lediglich der Angreifer auf der einen und der Benutzer einer angegriffenen Anwendung auf der anderen Seite nicht jedoch die eigentliche Anwendung. Ein häufig vorkommendes Beispiel für diese Art von Angriffen bildet das klassische -basierte Phishing. Dabei sendet ein Angreifer seinem Opfer eine , die ihm vortäuscht, von dem Betreiber der Webseite zu stammen und den Empfänger z. B. dazu auffordert, einen bestimmtem Link aufzurufen, um dort sein Passwort einzugeben. Der

11