leer

Inhaltsverzeichnis:

Expertise und Angebote

Die Mitarbeiter von sic[!]sec haben die Entwicklung der "WAF-Technologie" schon sehr früh begleitet. Die ersten Erfahrungen wurden mit Produkten gemacht, als es den heute üblichen Begriff Web Application Firewall noch gar nicht gab (siehe auch: Definition und Historie). Wir haben nicht nur unterschiedliche Produkte evaluiert, installiert, konfiguriert und gewartet, sondern wir sind auch in direktem Kontakt mit Herstellern und geben unsere Erfahrungen weiter, was letztendlich in Produktverbesserungen einfließt.

Durch viele erfolgreiche Installationen von WAFs können wir heute sehr genau beurteilen, welche WAF am besten geeignet ist und wie diese konfigurieren werden muss.

Wir haben zu vielen WAF-Herstellern enge Kontakte, sowohl zum Vertrieb, Support als auch zu den Entwicklern selbst. Wenn Fragen auftreten oder Lösungen für neue Anforderungen zu finden sind, dann sind unsere Wege zum Hersteller kurz. Nutzen Sie diesen Vorteil!

Ein großer Teil dieser Erfahrungen ist auch in den OWASP-Artikel Best Practices: Einsatz von Web Application Firewalls eingeflossen. Achim Hoffmann ist nicht nur Mitautor sondern auch der Verantwortliche (Maintainer) des zugehörigen OWASP-Projekts.

Unsere Angebote

Das umfangreiche Wissen mit und über WAFs ist die Grundlage unserer Leistungen. Wir bieten Ihnen Hilfestellung über den gesamten Lebenszyklus einer WAF. Das beginnt bei der Beratung vor der Auswahl einer WAF, der gezielten Suche der für Ihre Anforderungen am Besten geeigneten WAF, der technischen Umsetzung (in Ihrem Netzwerk), der initialen Konfiguration, dem reibungslosen Betrieb, einem Support-Service rund um die WAF, bis zu speziellen Dienstleistungen wie einem Notfallservice.

Definition und Historie

Web Application Firewalls sind eine Schutzlösung, um Webseiten und Webanwendungen vor Angriffen zu schützen. WAFs sind in der Lage Angriffe abzuwehren, die von Intrusion-Detection-Systemen und Netzwerk-Firewalls nicht erkannt werden. Solche Schutzlösungen sind technisch unabhängig von der Anwendung. Es ist somit nicht notwendig, die Webanwendungen zu ändern, um Schwachstellen beseitigen zu können.

Der große Vorteil von WAFs gemäß dieser Definition liegt darin, dass sie nachträglich zur Absicherung von bereits fertiggestellten und produktiven Webanwendungen eingesetzt werden können. Dies erfolgt ohne Änderung der eigentlichen Webanwendungen.

Mit zunehmender Differenzierung moderner WAFs ist diese Definition aber nicht mehr ganz korrekt. Insbesondere die Systeme, die im Web- bzw. Applikationsserver oder direkt in der Anwendung implementiert sind – so genannte embedded WAFs –, sind technisch nicht mehr vollständig von der Anwendung unabhängig. Die Übergänge werden zunehmend fließender.

Eine kurze Historie

Der Begriff WAF als Abkürzung für Web Application Firewall ist noch recht jung. Trotz einer Vielzahl anderer, teilweise auch treffenderer Begriffe, ist er heute weitgehend etabliert, was wohl hauptsächlich an dem griffigen Akronym und der Verwendung von "Firewall", welches eine bewährte Sicherheit suggeriert, liegt.

Viele Hersteller geben ihren Produkten weitere Bezeichnungen, manchmal, um eine besondere Eigenschaft herauszustellen oder um das spezielle Einsatzgebiet besser zu skizzieren. Oder einfach nur als Ausschmückung.

Wenn man diese Begriffe alle verstehen will, kann es hilfreich sein, verschiedene Begriffe zu kennen. Solche die früher verwendet wurden oder solche, die bei anderen und/oder zusätzlichen Funktionen passender sind. Mit diesem Wissen lässt sich oft schon am Produktnamen oder den kurzen Werbeteasern ein Rückschluss auf Funktion oder Einsatz einer WAF schließen.

Eine Auswahl alternativer Bezeichnungen für WAFs finden Sie in unserem Glossar.

Was wollen Sie machen?

Auf dieser Seite haben wir einige häufige Fragestellungen, Problemanforderungen in Bezug auf die Sicherheit von Webanwendungen und die dazu passenden Antworten und Lösungen, die von den unterschiedlichen WAFs angeboten werden, zusammengetragen .

Sie haben eine Schwachstelle in Ihrer Webanwendung, für die bis zum nächsten Deployment des Gesamtsystems schnell ein Schutz bereitgestellt werden muss?
Die WAF leistet dies mit einem Virtual Patch.
Für mehrere (Web-)Anwendungen soll eine einheitliche und gemeinsame Authentisierung erfolgen?
Einige WAFs bieten ein Security Gateway oder Web Entry Gateway, das ein SSO ermöglicht. Dazu müssen die vorhandenen Authentisierungssysteme im Backend in der Regel nicht verändert werden.
Für eine Webanwendung erwarten Sie vielfach erhöhte Zugriffe; dazu sollen weitere (geklonte) Systeme über einen Loadbalancer zur Verfügung gestellt werden?
Eine WAF kann zusätzlich als Loadbalancer agieren oder die WAF befindet sich direkt auf dem geklonten System, womit sie ohne weitere Konfiguration sofort einsatzfähig ist.
Sie müssen eine Anwendung schützen, deren Schwachstellen nicht behoben werden können (z.B. 3rd-Party- und Legacy-Anwendung)?
Eine WAF ist unabhängig von der Art der Anwendung. Sie ist dadurch in der Lage auch Anwendungen zu schützen, von denen Sie nur die Zugriffe kennen.
Sie haben eine Appliance mit einer Webanwendung und wollen diese (zusätzlich) mit einer WAF schützen und ausliefern?
Es gibt WAFs, die eingebettet im Webserver oder Applikationsserver betrieben werden. Es gibt WAFs, die nur innerhalb der Webanwendung betrieben werden. Oder die WAF wird als minimaler vorgelagerter Webserver, der nur als Reverse Proxy arbeitet, installiert.
Ihre Anwendung ist permanenten Angriffsversuchen ausgesetzt. Sie kennen die Angriffsmuster nicht (z.B. Zero-Day-Exploits), wollen aber über alle ungewöhnlichen Zugriffe informiert werden?
Eine WAF kann so konfiguriert werden, dass sie nur protokolliert, aber den Zugriff nicht blockiert (Detection-only-Modus; vergleichbar einem IDS).
Mehrere Anwendungen werden über ein Portal betrieben, einige werden angegriffen. Welche sind das?
Da moderne WAFs umfassend protokollieren und entsprechende Suchfilter für die Protokolle bieten, kann jederzeit eine Übersicht über die erkannten Angriffsversuche erstellt werden. Dies ist auch pro konfigurierter Anwendung oder URL möglich.
Ihre Anwendung wird bei einem ISP gehostet, der aber keine WAF bietet?
Es gibt WAFs, die als minimaler vorgelagerter Webserver, der nur als Reverse Proxy arbeitet, installiert werden können. Es gibt WAFs, die eingebettet im Applikationsserver implementiert werden. Oder sogar WAFs, die innerhalb der Anwendung installiert und konfiguriert werden.
Viele Angriffsmuster sind den Entwicklern bekannt. Die WAF soll diese zusätzlich (oder explizit) blockieren?
Die WAF kann Konfigurationen, meist in Form von XML-Dateien, von anderen Quellen importieren. Einige WAFs erlauben dies sogar dynamisch und sind somit zugleich ein IPS.
Es wird eine WAF benötigt, aber weder ISP noch Betrieb können diese betreiben?
Hier empfiehlt sich eine WAF, die direkt mit der Anwendung installiert wird und somit von den Entwicklern fertig konfiguriert ist. Dies ist sowohl mit einem vorgelagerten Reverse Proxy als auch mit embedded WAFs möglich.
Ihre Webanwendung ist so komplex, dass Sie nicht alle Funktionen kennen. Die WAF soll auch unbekannte Funktionen sinnvoll schützen?
Einige WAFs haben intelligente Lernfunktionen. Sie protokollieren alle Zugriffe und erzeugen daraus automatisch Zugriffsregeln. Diese können dann interaktiv oder wiederum automatisch (z.B. nach 5 Tagen) aktiviert werden.
Ihre hochsensible Webanwendung muss möglichst effektiv gegen Session-Hijacking geschützt werden?
Moderne WAFs haben heuristische und/oder statistische Methoden implementiert, die aktiviert werden können, um z.B. Anomalien in den gesendeten Requests (Client Fingerprinting) oder den Requestabfolgen (Application Flow) zu erkennen.
Ausgezeichnete URLs in der Anwendung dürfen nur unter bestimmten Bedingungen aufgerufen werden, z.B. spezielle Authentisierungen oder Deep Links?
Eine WAF kann den Application Flow kontrollieren, d.h. sie kennt die genaue Reihenfolge, in der bestimmte Zugriffe erfolgen müssen. Diese Regeln können dann noch mit weiteren Bedingungen angereichert werden.
Brute-Force-Angriffe auf die Anwendung sollen verhindert werden?
Gezielte Brute-Force-Angriffe auf die Anwendung unterscheiden sich signifikant von den eher allgemeinen Brute-Force-Angriffen auf Netzwerkebene. Da die WAF das Ziel des Angriffs – die Anwendung – kennt, kann sie auch gezielt Gegenmaßnahmen einleiten. Dies kann ein einfaches Blockieren derartiger Zugriffe sein, eine zeitliche Verzögerung, ein Logout aus der angemeldeten Session oder gar die Aufforderung an die vorgelagerte Firewall, die entsprechende IP-Adresse zu sperren.

Häufige Missverständnisse

Unsere Webserver sind sicher, weil sie nur über SSL-verschlüsselte Verbindungen erreichbar sind.
Diese Annahme (wir hoffen es ist keine Aussage) ist leider ein weit verbreiteter Trugschluss. SSL-Verschlüsselung ist in der Tat eine Technik, die sehr sicher ist. Nach heutigem Stand ist SSL nicht mit realistischem Aufwand kompromittierbar.

(Anmerkung: Bekannte erfolgreiche Angriffe sind immer auf weitere Schwachstellen angewiesen, wie z.B. DNS-Spoofing und -Poisoning, ARP-Spoofing, Seitenkanalangriffe, etc.)

SSL verschlüsselt die Daten auf dem Transportweg zwischen Client (Browser) und Server (Webserver). Damit ist lediglich der Datentransport sicher, z.B. vor MITM-Angriffen. Die Integrität und Vertraulichkeit ist somit gewährleistet. Angriffe auf der Protokollebene, in diesem Fall SSL, sind technisch sehr schwierig und daher ebenso selten. Die Angriffe auf Webanwendungen sind in den der Webanwendung eigenen Parametern zu finden, namentlich den Formparametern der Eingabeformulare. Diese Daten werden bei SSL alle verschlüsselt übertragen. Somit haben wir hier die paradoxe Situation, dass auch die Angriffe verschlüsselt sind. Ein Angreifer kann sich also (meist) sicher sein, dass seine Angriffsmuster auch sicher beim Webserver ankommen, ohne dass sie zuvor von einer Firewall blockiert bzw. von einem IDS/IPS erkannt werden. Eine WAF ist immer der Endpunkt einer SSL-Verbindung. Die WAF hat also alle Daten in unverschlüsselter Form vorliegen und kann sie entsprechend den zuvor definierten Regeln prüfen.
Die Sicherheit von Webanwendungen muss bereits bei der Entwicklung gewährleistet werden.
Dieser im Grundsatz richtigen Forderung ist nur zuzustimmen. Nur bleibt hierbei vollständig unbeachtet, dass die sichere Anwendung in einem komplexen IT-System betrieben wird, in dem andere Komponenten unter Umständen die Sicherheit der Anwendung kompromittieren, die Entwicklung darauf aber keinen Einfluss hat. Eine WAF kann hier eine Lücke bei der Durchsetzung von Sicherheitsanforderungen schließen.
Alle Sicherheitsprobleme können im Quellcode gelöst werden.
Auch diese Aussage ist im Grundsatz richtig. Wie zuvor müssten aber alle beteiligten Systeme in einer komplexen IT-Landschaft diesem Prinzip unterliegen. Das ist in der Praxis meist nicht der Fall. Beispiele für komplexe Angriffe sind: alle Varianten von HRS (HTTP-Response-Splitting bzw. HTTP-Request-Smuggling), HPP (HTTP-Parameter-Polution) oder HTTP-POST-DoS.
Eine WAF ist nur eine (traditionelle) Firewall mit mehr Funktionalität.
Im Gegensatz zu den traditionellen Firewalls beherrscht eine WAF den Umgang mit Daten auf den OSI-Layern 4 bis 7.
Es genügt eine Firewall mit zusätzlicher "WAF-Funktionalität" zu benutzen.
Es ist richtig, dass einige (traditionelle) Firewalls inzwischen auch Funktionen haben, die eher einer WAF zuzuordnen sind, diese sind aber meist unvollständig oder über Zusatzmodule realisiert. Hier sollte man z.B. die Frage stellen, ob eine solche "Next-Generation-Firewall" noch dasselbe leistet wie ohne WAF-Modul? Entscheidend ist hier die Anzahl der HTTP-Requests pro Zeiteinheit!
Eine WAF ersetzt die (traditionelle) Firewall.
Nein. Eine WAF bietet nicht die Funktionalität der bekannten Netzwerk-Firewalls. Eine WAF sollte daher immer zusammen mit einer Netzwerk-Firewall eingesetzt werden.
Ein IPS kann eine WAF ersetzen.
Hier gilt Ähnliches wie beim Vergleich einer WAF mit traditionellen Netzwerk-Firewalls: Es gibt durchaus Intrusion-Prevention-Systeme, die "WAF-Funktionalitäten" haben, sie bieten aber bei Weitem nicht die Funktionen und den Komfort einer modernen WAF.
Beim Einsatz einer WAF sinkt der Netzwerkdurchsatz signifikant.
Moderne WAFs werden die Performance kaum beeinflussen. Weiter sind WAFs auch mit oder "hinter" Loadbalancern einsetzbar. Wenn die WAF erfolgreich schädliche Anfragen abweist, dann ist sogar mit einer besseren Performance als ohne WAF zu rechnen.
Anwendungen sind beim Einsatz einer WAF nicht mehr funktionsfähig.
Auch wenn diese Aussage eher selten zutrifft, so sollte vor der Inbetriebnahme einer WAF ein erfahrener Berater abschätzen, ob solche Probleme zu erwarten sind und ob sie z.B. nur für die Kombination einer bestimmten WAF mit speziellen einzelnen Anwendungen zutreffen.
Unsere Systeme sind mit den aktuellsten Virenscannern ausgerüstet, eine WAF ist daher nicht nötig.
Diese Annahme stammt noch aus der Zeit als Viren und Trojaner die gängigen Angriffsmethoden auf Systeme und Daten darstellten. Viren und Trojaner brauchen aber eine weitere aktive Komponente, um wirksam zu werden – meist ein Programm, das gestartet werden muss. Im Umfeld von Webanwendungen werden i.d.R. keine neuen oder weiteren Programme gestartet, alle zum Betrieb der Webanwendung nötigen Programme sind schon aktiv, werden also allenfalls beim Neustart des Systems neu gestartet. Angriffe auf Webanwendungen erfolgen im Kontrollfluss der Webanwendung selbst und sind – bis auf wenige Ausnahmen – auch nicht mittels bekannter Signaturen, die auf Blacklists vermerkt werden könnten, erkennbar. Hier sind proaktive Systeme wie eine WAF notwendig, die hauptsächlich mit Whitelists arbeiten.
Unsere Webanwendung ist sicher, wir hatten noch nie Angriffe, es wurden noch keine Daten gestohlen.
Angriffe auf Webanwendungen hinterlassen meist keine Spuren. Im Gegensatz zu Viren oder Trojanern, die ihre Aktivität meist durch den Ausfall des Systems Kund tun, sind Angriffe auf Webanwendungen und Datendiebstahl "lautlos". Ohne detailliertes Expertenwissen und IT-Forensik lassen sie sich oft auch gar nicht feststellen. Eine proaktive WAF, die verdächtige Aktivitäten bzw. Daten erkennt und protokolliert, kann hier Hinweise geben und blockiert idealerweise die Zugriffe. Eine WAF kann z.B. auch den Transport der angeforderten Daten vom Server zum Browser unterbinden.

Vergleich: WAF vs. Firewall

Einige Anforderungen, für die eine WAF Lösungen bietet oder für die eine WAF empfohlen wird, können auch von (traditionellen) Firewalls oder Intrusion-Detection-Systemen (IDS) erfüllt werden. Wir wollen hier aufzeigen, wo die Grenzen der jeweiligen Systeme liegen und erklären, warum ein anderes System besser geeignet ist.

Angriffe mit manipulierten Daten (XSS, SQL Injection, usw.).
Die Angriffsmuster werden hier meist (Ausnahmen siehe unten) nicht im Protokoll, sondern in einer anwendungsspezifischen Syntax auf den OSI-Layern 4 bis 7 transportiert. Da Firewalls auf die Kontrolle, d.h. die Einhaltung, des Protokolls implementiert und optimiert sind, sind für die Daten in der Anwendungsschicht zusätzliche Module erforderlich. Ferner sind die Daten in der Anwendungsschicht nur wenig normiert und können zudem in weitere "Protokollschichten" (HTML, XML, JSON, usw.) verpackt sein. Der einfache und strenge Ansatz, das Protokoll zu prüfen, stößt hier an seine Grenzen. Um solche anwendungsspezifischen Daten effektiv und sinnvoll zu prüfen, sind Kontrollmechanismen erforderlich, die die Daten für die Anwendung "verstehen"; dies geht erheblich über die profane Einhaltung von Normen hinaus.

WAFs sind genau auf die Daten in dieser Anwendungsschicht hin ausgerichtet und optimiert. Einige Intrustion-Detection- und -Prevention-Systeme haben inzwischen solche Funktionalitäten ebenfalls implementiert. Im Gegensatz dazu bieten die Firewalls hier eher rudimentäre Ansätze, die meist mit einem inakzeptablen Mehraufwand und/oder Performanceverlust erkauft werden müssen.

Ob für eine erwartete Schutzfunktion eine "aufgebohrte" Firewall ausreicht oder ob dafür eine WAF vorzuziehen ist, muss im Einzelfall beurteilt werden.
Angriffe mit kodierten Daten.
HTTP hat für den Transport beliebiger Daten unterschiedliche (En-)Kodierungen definiert. Diese sind teilweise in unterschiedlichen Kontexten erlaubt (z.B. URL-Encoding im URL und HTML der Seite) oder streng an einen bestimmten Kontext gebunden (z.B. Kodierung via "\hex" in CSS-Daten) oder sind zwar an bestimmte Kontexte gebunden, die Anwendungen oder Browser sind aber in Bezug auf die Verwendung tolerant (z.B. HTML-Entity in der URL, obwohl nur im HTML-Text erlaubt). Weitere kontextabhängige Kodierungen sind Base64 und UTF-7 – heute zwar eher selten verwendet, aber vielfach noch akzeptiert!

Wie leicht zu verstehen ist, muss ein System, das Angriffsmuster in solchen Daten erkennen soll, die anwendungsspezifischen – besser: anwendungsschichtspezifischen – Daten "verstehen". Ohne eine passende Dekodierung ist das nicht möglich. Das Beispiel Base64 erfordert sogar, dass Anfang und Ende der Daten präzise erkannt werden, was etwa bei URL-Encoding weniger entscheidend ist.

Moderne WAFs beherrschen diese Disziplin nahezu perfekt, teilweise sogar beliebig verschachtelt. Wenn eine Firewall oder ein IDS/IPS hier vorgibt, Angriffe sicher zu erkennen, dann sollte das zunächst kritisch hinterfragt und auch konkret überprüft werden.
Brute-Force-Angriffe
Typische Brute-Force-Angriffe erfolgen auf unterschiedliche Ziele und nutzen dabei unterschiedliche Techniken. Sie können sowohl auf Netzwerkebene als auch Protokollebene – hier vor allem HTTP – erfolgen. Sie können auf die Anwendung selbst abzielen – speziell auf die Business-Logik. Die Auswirkungen können sehr unterschiedlich sein.

Es ist daher naheliegend, solche Angriffe so früh wie möglich zu erkennen und zu blockieren. Wie bereits zuvor erklärt, stößt eine Firewall hier an ihre Grenzen, es sei denn das Angriffsmuster ist direkt im Protokoll erkennbar. Eine WAF kann hier viel feingranularer erkennen und reagieren.
Denial of Service (DoS)
Genau wie Brute-Force-Angriffe sind DoS-Angriffe auf Netzwerk-, Protokoll- oder Anwendungsebene durchführbar.

Angriffe auf Netzwerkebene werden idealerweise von der Firewall erkannt und verhindert. Bei solchen auf Protokollebene ist wiederum entscheidend, ob die eingesetzte Firewall die Angriffsmuster zuverlässig erkennen kann oder ob dafür eine WAF besser geeignet ist. DoS-Angriffe auf Anwendungsebene können nur noch von einer WAF erkannt werden, da alle Zugriffe vollständig protokollkonform erfolgen und keinerlei Anomalien erkennbar sind. Das heißt konkret: Um den Angriff zu erkennen, muss die WAF ein bestimmtes "Wissen" über die Anwendung (meist die Business-Logik) oder den verwendeten Web- und/oder Applikationsserver haben.

Neben dem bereits erwähnten Application Flow werden in diesem Fall auch heuristische und statistische Methoden eingesetzt.

Technische Grenzen

Es soll nicht verschwiegen werden, dass eine WAF nicht gegen alle Angriffe schützen kann. Weiter ist zu beachten, dass es Funktionalitäten in der Webtechnologie gibt, die beim Einsatz einer WAF eingeschränkt oder gar nicht mehr nutzbar sind. Hier ist im Einzelfall zu entscheiden, ob der verbesserte Schutz durch die WAF oder die Funktionalität die höhere Priorität hat.

Angriffe auf die Business-Logik.
Business-Logik ist, wie der Name schon andeutet, nicht im Protokoll oder Format der Daten implementiert, sondern in der Programmlogik der Anwendung, die die Daten verarbeitet. Es liegt also in der Natur der Sache, dass die Prüfung hier nicht gegen definierte Standards, z.B. ein Protokoll oder das Format der Daten, erfolgen kann. Vielmehr muss die zu prüfende Logik meist in einer der Anwendung eigenen Art und Weise "nachgebildet" werden.

WAFs bieten hier unterschiedliche Ansätze, wie dies erfolgen kann. Meist wird dazu ein Application Flow (auch als Site Usage Enforcement bezeichnet) verwendet.
Persistent/Stored XSS.
Diese Ausprägung von Cross-Site Scripting kann von einer WAF zumeist nicht erkannt und somit auch nicht blockiert werden. Die Daten, die das XSS enthalten, kommen schließlich direkt von der Anwendung und sind syntaktisch korrekt ins HTML eingebettet. Der Request, der diesen Response veranlasst, enthält keine Hinweise auf die manipulierten Daten.
Browser-generierte URLs (AJAX).
Insbesondere bei "Web 2.0"-Anwendungen, die vielfach mit browserseitigem Skripting (JavaScript) arbeiten, werden URLs dynamisch im Browser erzeugt. Dabei können auch Formparameter generiert werden, die diesen URLs dann als GET- oder POST-Parameter mitgegeben werden. Je nach Art und Weise, wie eine WAF die Schutzfunktionen implementiert hat, kann es hier zu Einschränkungen der Schutzfunktion oder zu erhöhtem Konfigurationsaufwand kommen. Zum Beispiel ist eine URL-Verschlüsselung für solche URLs nicht mehr möglich und auch einige Formen von Tokens, etwa als CSRF-Schutz, funktionieren nicht mehr richtig.
Bookmarks.
Wenn die Anwendung Bookmarks erlaubt, dann müssen solche URLs ebenfalls von der URL-Verschlüsselung aufgenommen werden. Bei der Konfiguration von Application Flows sind Bookmarks ebenfalls besonders zu betrachten. In beiden Fällen führt dies nicht zu einer Beeinträchtigung der Funktionalität der Anwendung, aber zu einem niedrigeren Schutzniveau.
Deep Links.
Mit Deep Links können unterschiedliche – ja sogar gegensätzliche – Anforderungen verbunden sein. Zum Einen kann die Anforderung bestehen, Deep Links zu verhindern, zum Anderen, sie explizit zu erlauben.

Um Deep Links zu verhindern, kann die URL-Verschlüsselung oder der Application Flow verwendet werden. Um sie zu erlauben, darf genau das nicht konfiguriert sein. Mit den Folgen, die weiter oben bei Bookmarks und Browser-generierten URLs (AJAX) bereits beschrieben wurden.
Grundlagen
  • Glossar
  • Web Application Firewalls