Einführung in die NetScaler Web App Firewall

Die NetScaler Web App Firewall verhindert Sicherheitsverletzungen, Datenverlust und mögliche unbefugte Änderungen an Websites, die auf vertrauliche Geschäfts- oder Kundeninformationen zugreifen. Dazu filtert es sowohl Anfragen als auch Antworten, untersucht sie auf Hinweise auf böswillige Aktivitäten und blockiert Anfragen, die solche Aktivitäten aufweisen. Ihre Website ist nicht nur vor gängigen Angriffsarten geschützt, sondern auch vor neuen, noch unbekannten Angriffen. Die Web App Firewall schützt nicht nur Webserver und Websites vor unbefugtem Zugriff, sondern schützt auch vor Sicherheitslücken in veraltetem CGI-Code oder -Skripten, Web-Frameworks, Webserver-Software und anderen zugrunde liegenden Betriebssystemen.

Die NetScaler Web App Firewall ist als eigenständige Appliance oder als Feature auf einer virtuellen NetScaler Appliance (VPX) verfügbar. In der Web App Firewall-Dokumentation bezieht sich der Begriff NetScaler auf die Plattform, auf der die Web App Firewall ausgeführt wird, unabhängig davon, ob es sich bei dieser Plattform um eine dedizierte Firewall-Appliance, ein NetScaler, auf dem auch andere Funktionen konfiguriert wurden, oder um eine NetScaler VPX handelt.

Um die Web App Firewall verwenden zu können, müssen Sie mindestens eine Sicherheitskonfiguration erstellen, um Verbindungen zu blockieren, die gegen die Regeln verstoßen, die Sie für Ihre geschützten Websites festgelegt haben. Die Anzahl der Sicherheitskonfigurationen, die Sie möglicherweise erstellen möchten, hängt von der Komplexität Ihrer Website ab. Manchmal ist eine einzige Konfiguration ausreichend. In anderen Fällen, insbesondere bei interaktiven Websites, Websites, die auf Datenbankserver zugreifen, und Onlineshops mit Einkaufswagen, benötigen Sie möglicherweise verschiedene Konfigurationen, um sensible Daten bestmöglich zu schützen, ohne großen Aufwand für Inhalte zu verschwenden, die für bestimmte Arten von Angriffen nicht anfällig sind. Oft können Sie die Standardeinstellungen für die globalen Einstellungen, die sich auf alle Sicherheitskonfigurationen auswirken, unverändert lassen. Sie können die globalen Einstellungen jedoch ändern, wenn sie mit anderen Teilen Ihrer Konfiguration in Konflikt stehen oder Sie sie lieber anpassen möchten.

Sicherheit von Webanwendungen

Webanwendungssicherheit ist Netzwerksicherheit für Computer und Programme, die mithilfe der HTTP- und HTTPS-Protokolle kommunizieren. Dies ist ein breiter Bereich, in dem es zahlreiche Sicherheitslücken und -schwächen gibt. Betriebssysteme auf Servern und Clients haben Sicherheitsprobleme und sind anfällig für Angriffe. Webserversoftware und Technologien, die Websites ermöglichen, wie CGI, Java, JavaScript, PERL und PHP, weisen grundlegende Sicherheitslücken auf. Browser und andere Client-Anwendungen, die mit webfähigen Anwendungen kommunizieren, weisen ebenfalls Sicherheitslücken auf. Websites, die jede Technologie außer der einfachsten HTML-Technologie verwenden, einschließlich Websites, die die Interaktion mit Besuchern ermöglichen, weisen häufig eigene Sicherheitslücken auf.

In der Vergangenheit war eine Sicherheitsverletzung oft nur ein Ärgernis, heute ist das selten der Fall. Beispielsweise waren Angriffe, bei denen sich ein Hacker Zugriff auf einen Webserver verschaffte und unbefugte Änderungen an (unkenntlich gemachten) Websites vornahm, früher üblich. Sie wurden in der Regel von Hackern ins Leben gerufen, die keine andere Motivation hatten, als ihre Fähigkeiten anderen Hackern unter Beweis zu stellen oder die Zielperson oder das Zielunternehmen in Verlegenheit zu bringen. Die meisten aktuellen Sicherheitsverletzungen sind jedoch auf den Wunsch nach Geld zurückzuführen. Die meisten versuchen, eines oder beide der folgenden Ziele zu erreichen: an sensible und potenziell wertvolle private Informationen zu gelangen oder unbefugten Zugriff auf und Kontrolle über eine Website oder einen Webserver zu erlangen.

Bestimmte Formen von Webangriffen konzentrieren sich auf die Erlangung privater Informationen. Diese Angriffe sind oft sogar gegen Websites möglich, die sicher genug sind, um zu verhindern, dass ein Angreifer die volle Kontrolle übernimmt. Zu den Informationen, die ein Angreifer von einer Website erhalten kann, können Kundennamen, Adressen, Telefonnummern, Sozialversicherungsnummern, Kreditkartennummern, Krankenakten und andere private Informationen gehören. Der Angreifer kann diese Informationen dann verwenden oder an andere verkaufen. Ein Großteil der Informationen, die durch solche Angriffe erlangt werden, ist gesetzlich geschützt, und zwar alle durch Gewohnheiten und Erwartungen. Ein solcher Verstoß kann schwerwiegende Folgen für Kunden haben, deren private Daten gefährdet sind. Bestenfalls müssen diese Kunden wachsam sein, um zu verhindern, dass andere ihre Kreditkarten missbrauchen, unbefugte Kreditkonten in ihrem Namen eröffnen oder sich ihre Identität direkt aneignen (Identitätsdiebstahl). Im schlimmsten Fall könnten die Kunden mit ruinierten Kreditratings konfrontiert werden oder sogar für kriminelle Aktivitäten verantwortlich gemacht werden, an denen sie nicht beteiligt waren.

Andere Webangriffe zielen darauf ab, die Kontrolle über eine Website oder den Server, auf dem sie betrieben wird, zu erlangen (oder zu kompromittieren), oder beides. Ein Hacker, der die Kontrolle über eine Website oder einen Server erlangt, kann diese verwenden, um unautorisierte Inhalte zu hosten, als Proxy für Inhalte zu fungieren, die auf einem anderen Webserver gehostet werden, SMTP-Dienste für den Versand unaufgeforderter Massen-E-Mails bereitzustellen oder DNS-Dienste zur Unterstützung solcher Aktivitäten auf anderen kompromittierten Webservern bereitzustellen. Die meisten Websites, die auf kompromittierten Webservern gehostet werden, fördern fragwürdige oder offen betrügerische Unternehmen. Beispielsweise werden die meisten Phishing-Websites und Websites zur Ausbeutung von Kindern auf kompromittierten Webservern gehostet.

Um Ihre Websites und Webdienste vor diesen Angriffen zu schützen, ist eine mehrschichtige Abwehr erforderlich, die sowohl bekannte Angriffe mit identifizierbaren Merkmalen abwehren als auch vor unbekannten Angriffen schützen kann, die häufig erkannt werden können, weil sie sich vom normalen Traffic auf Ihren Websites und Webdiensten unterscheiden.

Bekannte Web-Angriffe

Die erste Verteidigungslinie für Ihre Websites ist der Schutz vor der großen Anzahl von Angriffen, von denen bekannt ist, dass sie existieren und von Websicherheitsexperten beobachtet und analysiert wurden. Zu den häufigsten Arten von Angriffen auf HTML-basierte Websites gehören:

• Buffer-Overflow-Angriffe. Das Senden einer langen URL, eines langen Cookie oder langer Informationen an einen Webserver führt dazu, dass das System hängt, abstürzt oder unbefugten Zugriff auf das zugrunde liegende Betriebssystem ermöglicht. Ein Pufferüberlaufangriff kann verwendet werden, um Zugriff auf unautorisierte Informationen zu erhalten, einen Webserver zu kompromittieren oder beides.
• Cookie-Sicherheitsangriffe. Senden eines modifizierten Cookie an einen Webserver, normalerweise in der Hoffnung, mithilfe gefälschter Anmeldeinformationen Zugriff auf unautorisierte Inhalte zu erhalten.
• Kräftiges Surfen. Direkter Zugriff auf URLs auf einer Website, ohne zu den URLs mit Hyperlinks auf der Startseite oder anderen gängigen Start-URLs auf der Website zu navigieren. Einzelne Fälle von erzwungenem Surfen können darauf hindeuten, dass ein Benutzer eine Seite auf Ihrer Website mit einem Lesezeichen versehen hat. Wiederholte Versuche, auf nicht existierende Inhalte oder Inhalte zuzugreifen, auf die Benutzer niemals direkt zugreifen dürfen, stellen jedoch häufig einen Angriff auf die Sicherheit der Website dar. Forceful Browsing wird normalerweise verwendet, um Zugriff auf unautorisierte Informationen zu erhalten, kann aber auch mit einem Pufferüberlaufangriff kombiniert werden, um Ihren Server zu kompromittieren.
• Sicherheitsangriffe auf Webformulare. Senden unangemessener Inhalte in einem Webformular an Ihre Website. Zu unangemessenen Inhalten können modifizierte versteckte Felder, HTML oder Code in einem Feld gehören, das nur für alphanumerische Daten bestimmt ist, eine zu lange Zeichenfolge in einem Feld, das nur eine kurze Zeichenfolge akzeptiert, eine alphanumerische Zeichenfolge in einem Feld, das nur eine Ganzzahl akzeptiert, und eine Vielzahl anderer Daten, die Ihre Website in diesem Webformular nicht erwartet. Ein Webformular-Sicherheitsangriff kann entweder verwendet werden, um unautorisierte Informationen von Ihrer Website zu erhalten oder um die Website direkt zu gefährden, normalerweise in Kombination mit einem Pufferüberlaufangriff.

Zwei spezielle Arten von Angriffen auf die Sicherheit von Webformularen verdienen besondere Erwähnung:

• SQL-Injection-Angriffe. Senden eines oder mehrerer aktiver SQL-Befehle in einem Webformular oder als Teil einer URL mit dem Ziel, eine SQL-Datenbank zur Ausführung des Befehls oder der Befehle zu veranlassen. SQL-Injection-Angriffe werden normalerweise verwendet, um unautorisierte Informationen zu erhalten.
• Cross-Site-Scripting-Angriffe. Die Verwendung einer URL oder eines Skripts auf einer Webseite, um gegen die Richtlinie zur gleichen Herkunft zu verstoßen, die es Skripten untersagt, Eigenschaften von einer anderen Website abzurufen oder Inhalte auf einer anderen Website zu ändern. Da Skripts Informationen auf Ihrer Website abrufen und Dateien ändern können, kann der Zugriff eines Skripts auf Inhalte auf einer anderen Website einem Angreifer die Möglichkeit geben, nicht autorisierte Informationen zu erhalten, einen Webserver oder beides zu gefährden.

Angriffe auf XML-basierte Webdienste lassen sich normalerweise in mindestens eine der beiden folgenden Kategorien einteilen: Versuche, unangemessene Inhalte an einen Webdienst zu senden, oder Versuche, die Sicherheit eines Webdienstes zu verletzen. Zu den häufigsten Arten von Angriffen auf XML-basierte Webdienste gehören:

• Bösartiger Code oder Objekte. XML-Anfragen, die Code oder Objekte enthalten, die entweder direkt vertrauliche Informationen abrufen oder einem Angreifer die Kontrolle über den Webdienst oder den zugrunde liegenden Server geben können.
• Schlecht formatierte XML-Anfragen. XML-Anfragen, die nicht der W3C-XML-Spezifikation entsprechen und daher die Sicherheit eines unsicheren Webdienstes beeinträchtigen können
• Denial-of-Service (DoS) -Angriffe. XML-Anfragen, die wiederholt und in großen Mengen gesendet werden, mit der Absicht, den anvisierten Webdienst zu überfordern und legitimen Benutzern den Zugriff auf den Webdienst zu verwehren.

Neben standardmäßigen XML-basierten Angriffen sind XML-Webdienste und Web 2.0-Sites auch anfällig für SQL-Injection- und Cross-Site-Scripting-Angriffe, wie unten beschrieben:

• SQL-Injection-Angriffe. Senden eines oder mehrerer aktiver SQL-Befehle in einer XML-basierten Anfrage mit dem Ziel, eine SQL-Datenbank zur Ausführung dieses Befehls oder dieser Befehle zu veranlassen. Wie bei HTML-SQL-Injection-Angriffen werden XML-SQL-Injection-Angriffe normalerweise verwendet, um unautorisierte Informationen zu erhalten.
• Cross-Site-Scripting-Angriffe. Verwendung eines Skripts, das in einer XML-basierten Anwendung enthalten ist, um gegen die Richtlinie für den gleichen Ursprung zu verstoßen, die es keinem Skript erlaubt, Eigenschaften von einer anderen Anwendung abzurufen oder Inhalte in einer anderen Anwendung zu ändern. Da Skripts mithilfe Ihrer XML-Anwendung Informationen abrufen und Dateien ändern können, kann der Zugriff eines Skripts auf Inhalte, die zu einer anderen Anwendung gehören, einem Angreifer die Möglichkeit geben, unautorisierte Informationen zu erhalten, die Anwendung zu kompromittieren oder beides.

Bekannte Webattacken können in der Regel gestoppt werden, indem der Website-Traffic nach bestimmten Merkmalen (Signaturen) gefiltert wird, die immer bei einem bestimmten Angriff vorkommen und niemals im legitimen Traffic vorkommen dürfen. Dieser Ansatz hat den Vorteil, dass relativ wenige Ressourcen benötigt werden und das Risiko falsch positiver Ergebnisse relativ gering ist. Daher ist es ein wertvolles Tool zur Bekämpfung von Angriffen auf Websites und Webdienste und zur Konfiguration des grundlegenden Signaturschutzes.

Unbekannte Web-Angriffe

Die größte Bedrohung für Websites und Anwendungen geht nicht von bekannten, sondern von unbekannten Angriffen aus. Die meisten unbekannten Angriffe lassen sich in eine von zwei Kategorien einteilen: neu gestartete Angriffe, gegen die Sicherheitsfirmen noch keine wirksame Abwehr entwickelt haben (Zero-Day-Angriffe), und sorgfältig gezielte Angriffe auf eine bestimmte Website oder einen Webdienst und nicht auf viele Websites oder Webdienste (Spear-Attacken). Diese Angriffe zielen, wie bekannte Angriffe, darauf ab, vertrauliche private Informationen zu erhalten, die Website oder den Webdienst zu kompromittieren und die Verwendung für weitere Angriffe oder beides zu ermöglichen.

Zero-Day-Angriffe stellen eine große Bedrohung für alle Benutzer dar. Bei diesen Angriffen handelt es sich in der Regel um dieselben Typen wie bekannte Angriffe. Bei Zero-Day-Angriffen handelt es sich häufig um injiziertes SQL, ein Cross-Site-Script, eine standortübergreifende Anforderungsfälschung oder eine andere Art von Angriff, die bekannten Angriffen ähnelt. In der Regel zielen sie auf Sicherheitslücken ab, von denen die Entwickler der Zielsoftware, Website oder des Webdienstes entweder nichts wissen oder von denen sie erfahren haben. Sicherheitsfirmen haben daher keine Abwehrmaßnahmen gegen diese Angriffe entwickelt, und selbst wenn sie dies getan haben, haben die Benutzer weder die Patches erhalten und installiert noch die zum Schutz vor diesen Angriffen erforderlichen Behelfslösungen durchgeführt. Die Zeit zwischen der Entdeckung eines Zero-Day-Angriffs und der Verfügbarkeit einer Abwehr (das Verwundbarkeitsfenster) wird immer kürzer, aber die Täter können immer noch mit Stunden oder sogar Tagen rechnen, an denen viele Websites und Webdienste keinen spezifischen Schutz vor dem Angriff haben.

Spearangriffe stellen eine große Bedrohung dar, allerdings für eine ausgesuchtere Benutzergruppe. Eine häufige Art von Spear-Attacke, ein Spear-Phishing, zielt auf Kunden einer bestimmten Bank oder eines bestimmten Finanzinstituts oder (seltener) auf Mitarbeiter eines bestimmten Unternehmens oder einer bestimmten Organisation ab. Im Gegensatz zu anderen Phishing-Methoden, bei denen es sich häufig um grob geschriebene Fälschungen handelt, die ein Benutzer, der mit der tatsächlichen Kommunikation der Bank oder des Finanzinstituts vertraut ist, erkennen kann, sind Spear-Phishing-E-Mails buchstabengetreu und überzeugend. Sie können individuelle Informationen enthalten, die auf den ersten Blick kein Fremder kennen oder erhalten kann. Der Spear-Phisher ist daher in der Lage, das Ziel davon zu überzeugen, die angeforderten Informationen bereitzustellen, die der Phisher dann verwenden kann, um Konten zu plündern, unrechtmäßig beschafftes Geld aus anderen Quellen zu verarbeiten oder Zugang zu anderen, noch sensibleren Informationen zu erhalten.

Beide Angriffsarten weisen bestimmte Merkmale auf, die normalerweise erkannt werden können, allerdings nicht mithilfe statischer Muster, die nach bestimmten Merkmalen suchen, wie dies bei Standardsignaturen der Fall ist. Die Erkennung dieser Arten von Angriffen erfordert ausgefeiltere und ressourcenintensivere Ansätze wie heuristische Filterung und Systeme für positive Sicherheitsmodelle. Die heuristische Filterung sucht nicht nach bestimmten Mustern, sondern nach Verhaltensmustern. Systeme mit positivem Sicherheitsmodell modellieren das normale Verhalten der Website oder des Webdienstes, den sie schützen, und blockieren dann Verbindungen, die nicht in dieses normale Nutzungsmodell passen. URL-basierte und auf Webformularen basierende Sicherheitsprüfungen profilieren die normale Nutzung Ihrer Websites und kontrollieren dann, wie Benutzer mit Ihren Websites interagieren. Dabei verwenden sie sowohl Heuristiken als auch positive Sicherheitsfunktionen, um anomalen oder unerwarteten Traffic zu blockieren. Sowohl heuristische als auch positive Sicherheitslösungen können, wenn sie richtig konzipiert und eingesetzt werden, die meisten Angriffe abfangen, die von Signaturen übersehen werden. Sie benötigen jedoch erheblich mehr Ressourcen als Signaturen, und Sie müssen einige Zeit damit verbringen, sie richtig zu konfigurieren, um Fehlalarme zu vermeiden. Sie werden daher nicht als primäre Verteidigungslinie eingesetzt, sondern als Backups für Signaturen oder andere weniger ressourcenintensive Ansätze.

Indem Sie diese erweiterten Schutzmaßnahmen zusätzlich zu den Signaturen konfigurieren, erstellen Sie ein hybrides Sicherheitsmodell, das es der Web App Firewall ermöglicht, umfassenden Schutz vor bekannten und unbekannten Angriffen zu bieten.

So funktioniert die NetScaler Web App Firewall

Wenn Sie die Web App Firewall installieren, erstellen Sie eine erste Sicherheitskonfiguration, die aus einer Richtlinie, einem Profil und einem Signaturobjekt besteht. Die Richtlinie ist eine Regel, die den zu filternden Datenverkehr identifiziert, und das Profil identifiziert die Muster und Verhaltenstypen, die beim Filtern des Datenverkehrs zugelassen oder blockiert werden sollen. Die einfachsten Muster, die als Signaturen bezeichnet werden, werden nicht im Profil angegeben, sondern in einem Signaturobjekt, das dem Profil zugeordnet ist.

Eine Signatur ist eine Zeichenfolge oder ein Muster, das einem bekannten Angriffstyp entspricht. Die Web App Firewall enthält über tausend Signaturen in sieben Kategorien, die jeweils auf Angriffe auf bestimmte Arten von Webservern und Webinhalten gerichtet sind. NetScaler aktualisiert die Liste mit neuen Signaturen, sobald neue Bedrohungen identifiziert werden. Während der Konfiguration geben Sie die Signaturkategorien an, die für die Webserver und Inhalte geeignet sind, die Sie schützen müssen. Signaturen bieten einen guten Grundschutz bei geringem Verarbeitungsaufwand. Wenn Ihre Anwendungen spezielle Sicherheitslücken aufweisen oder Sie einen Angriff gegen sie feststellen, für den keine Signatur existiert, können Sie Ihre eigenen Signaturen hinzufügen.

Die fortschrittlicheren Schutzmaßnahmen werden als Sicherheitschecks bezeichnet. Eine Sicherheitsüberprüfung ist eine strengere, algorithmische Prüfung einer Anfrage auf bestimmte Muster oder Verhaltensweisen, die auf einen Angriff hinweisen oder eine Bedrohung für Ihre geschützten Websites und Webdienste darstellen könnten. Es kann beispielsweise eine Anfrage identifizieren, bei der versucht wird, einen bestimmten Vorgang auszuführen, der die Sicherheit verletzen könnte, oder eine Antwort, die vertrauliche private Informationen wie eine Sozialversicherungsnummer oder eine Kreditkartennummer enthält. Während der Konfiguration geben Sie die Sicherheitsprüfungen an, die für die zu schützenden Webserver und Inhalte geeignet sind. Die Sicherheitskontrollen sind restriktiv. Viele von ihnen können legitime Anfragen und Antworten blockieren, wenn Sie bei der Konfiguration nicht die entsprechenden Ausnahmen (Erleichterungen) hinzufügen. Die Identifizierung der erforderlichen Ausnahmen ist nicht schwierig, wenn Sie die adaptive Lernfunktion verwenden, die die normale Nutzung Ihrer Website beobachtet und empfohlene Ausnahmen erstellt.

Die Web App Firewall kann entweder als Layer-3-Netzwerkgerät oder als Layer-2-Netzwerkbrücke zwischen Ihren Servern und Ihren Benutzern installiert werden, normalerweise hinter dem Router oder der Firewall Ihres Unternehmens. Es muss an einem Ort installiert werden, an dem es den Datenverkehr zwischen den Webservern, die Sie schützen möchten, und dem Hub oder Switch, über den Benutzer auf diese Webserver zugreifen, abfangen kann. Anschließend konfigurieren Sie das Netzwerk so, dass Anfragen an die Web App Firewall statt direkt an Ihre Webserver und Antworten an die Web App Firewall statt direkt an Ihre Benutzer gesendet werden. Die Web App Firewall filtert diesen Datenverkehr, bevor sie ihn an sein endgültiges Ziel weiterleitet. Dabei werden sowohl ihr interner Regelsatz als auch Ihre Ergänzungen und Änderungen verwendet. Es blockiert oder macht harmlos alle Aktivitäten, die es als schädlich erkennt, und leitet dann den verbleibenden Datenverkehr an den Webserver weiter. Die folgende Abbildung gibt einen Überblick über den Filtervorgang.

Hinweis:

In der Abbildung wird die Anwendung einer Richtlinie auf eingehenden Verkehr weggelassen. Es zeigt eine Sicherheitskonfiguration, in der die Richtlinie alle Anforderungen verarbeiten soll. Außerdem wurde in dieser Konfiguration ein Signaturobjekt konfiguriert und dem Profil zugeordnet, und Sicherheitsprüfungen wurden im Profil konfiguriert.

Abbildung 1. Ein Flussdiagramm der Web App Firewall-Filterung

Wie die Abbildung zeigt, untersucht die Web App Firewall die Anfrage zunächst, um sicherzustellen, dass sie nicht mit einer Signatur übereinstimmt, wenn ein Benutzer eine URL auf einer geschützten Website anfordert. Wenn die Anforderung mit einer Signatur übereinstimmt, zeigt die NetScaler Web App Firewall entweder das Fehlerobjekt an (eine Webseite auf der Web App Firewall Appliance, die Sie mithilfe der Importfunktion konfigurieren können) oder leitet die Anforderung an die angegebene Fehler-URL (die Fehlerseite) weiter. Signaturen benötigen nicht so viele Ressourcen wie Sicherheitsprüfungen. Daher reduziert das Erkennen und Abwehren von Angriffen, die durch eine Signatur erkannt werden, bevor eine der Sicherheitsprüfungen ausgeführt wird, die Belastung des Servers.

Wenn eine Anforderung die Signaturprüfung besteht, wendet die Web App Firewall die aktivierten Sicherheitsprüfungen der Anforderung an. Die Sicherheitsüberprüfungen der Anfrage stellen sicher, dass die Anfrage für Ihre Website oder Ihren Webservice geeignet ist und kein Material enthält, das eine Bedrohung darstellen könnte. Beispielsweise untersuchen Sicherheitsprüfungen die Anforderung auf Zeichen, die darauf hindeuten, dass es sich um einen unerwarteten Typ handelt, unerwarteten Inhalt anfordern oder unerwartete und möglicherweise bösartige Webformulardaten, SQL-Befehle oder Skripts enthalten. Wenn die Anforderung eine Sicherheitsprüfung nicht besteht, bereinigt die Web App Firewall entweder die Anfrage und sendet sie dann zurück an die NetScaler Appliance (oder die virtuelle NetScaler Appliance) oder zeigt das Fehlerobjekt an. Wenn die Anforderung die Sicherheitsprüfungen bestanden hat, wird sie an die NetScaler Appliance zurückgesendet, die jede andere Verarbeitung abschließt und die Anforderung an den geschützten Webserver weiterleitet.

Wenn die Website oder der Webdienst eine Antwort an den Benutzer sendet, wendet die Web App Firewall die aktivierten Antwortsicherheitsprüfungen an. Bei den Response-Sicherheitschecks wird die Antwort auf undichte vertrauliche private Informationen, Anzeichen einer Verunstaltung der Website oder andere Inhalte untersucht, die nicht vorhanden sein dürfen. Wenn die Antwort eine Sicherheitsprüfung nicht besteht, entfernt die Web App Firewall entweder den Inhalt, der nicht vorhanden sein darf, oder blockiert die Antwort. Wenn die Antwort die Sicherheitsprüfungen bestanden hat, wird sie an die NetScaler Appliance zurückgesendet, die sie an den Benutzer weiterleitet.

Funktionen der NetScaler Web App Firewall

Die grundlegenden Funktionen der Web App Firewall sind Richtlinien, Profile und Signaturen, die ein hybrides Sicherheitsmodell bereitstellen, wie unter Bekannte Webangriffe, Unbekannte Webangriffeund Funktionsweise der Web App Firewallbeschrieben. Besonders hervorzuheben ist die Lernfunktion, die den Datenverkehr zu Ihren geschützten Anwendungen beobachtet und geeignete Konfigurationseinstellungen für bestimmte Sicherheitsprüfungen empfiehlt.

Die Importfunktion verwaltet Dateien, die Sie in die Web App Firewall hochladen. Diese Dateien werden dann von der Web App Firewall bei verschiedenen Sicherheitsprüfungen oder bei der Reaktion auf eine Verbindung verwendet, die einer Sicherheitsüberprüfung entspricht.

Sie können die Funktionen für Protokolle, Statistiken und Berichte verwenden, um die Leistung der Web App Firewall zu bewerten und mögliche Schutzmaßnahmen zu ermitteln.

So modifiziert NetScaler Web App Firewall den Anwendungsdatenverkehr

Die NetScaler Web App Firewall beeinflusst das Verhalten einer Webanwendung, die sie schützt, indem sie Folgendes ändert:

• Cookies
• HTTP-Header
• Formulare/Daten

Sitzungscookie für NetScaler Web App Firewall

Um den Status der Sitzung aufrechtzuerhalten, generiert die NetScaler Web App Firewall ein eigenes Sitzungscookie. Dieses Cookie wird nur zwischen dem Webbrowser und der NetScaler Web Application Firewall und nicht an den Webserver weitergegeben. Wenn ein Hacker versucht, das Sitzungscookie zu ändern, löscht die Application Firewall das Cookie, bevor sie die Anfrage an den Server weiterleitet, und behandelt die Anfrage als neue Benutzersitzung. Das Session-Cookie ist vorhanden, solange der Webbrowser geöffnet ist. Wenn der Webbrowser geschlossen wird, wird das Anwendungsfirewall-Sitzungscookie länger gültig. Der Status der Sitzung speichert die Informationen der vom Kunden besuchten URLs und Formulare.

Das konfigurierbare Web App Firewall-Sitzungscookie ist citrix_ns_id.

Ab NetScaler Build 12.1 54 und 13.0 ist die Cookiekonsistenz sitzungslos und erzwingt nicht das Hinzufügen des von der Appliance generierten Sitzungscookies citrix_ns_id.

NetScaler Web App Firewall-Cookies

Viele Webanwendungen generieren Cookies, um benutzer- oder sitzungsspezifische Informationen zu verfolgen. Diese Informationen können Benutzereinstellungen oder Warenkorbartikel sein. Ein Webanwendungs-Cookie kann einer der folgenden zwei Typen sein:

• Persistente Cookies — Diese Cookies werden lokal auf dem Computer gespeichert und beim nächsten Besuch der Website erneut verwendet. Diese Art von Cookie enthält normalerweise Informationen über den Benutzer, z. B. Anmeldung, Passwort oder Präferenzen.
• Sitzungscookies oder transiente Cookies — Diese Cookies werden nur während der Sitzung verwendet und nach Beendigung der Sitzung zerstört. Diese Art von Cookie enthält Informationen zum Anwendungsstatus, z. B. Warenkorbartikel oder Sitzungsdaten.

Hacker können versuchen, Anwendungs-Cookies zu modifizieren oder zu stehlen, um eine Benutzersitzung zu kapern oder sich als Benutzer auszugeben. Die Application Firewall verhindert solche Versuche, indem sie die Anwendungs-Cookies hasht und dann weitere Cookies mit den digitalen Signaturen hinzufügt. Durch die Verfolgung der Cookies stellt die Application Firewall sicher, dass die Cookies zwischen dem Client-Browser und der Application Firewall nicht verändert oder kompromittiert werden. Die Anwendungsfirewall ändert die Anwendungs-Cookies nicht.

Die NetScaler Web App Firewall generiert die folgenden Standard-Cookies, um die Anwendungscookies zu verfolgen:

• Dauerhafte Cookies: citrix_ns_id_wlf. Hinweis: wlf steht für Will Live Forever.
• Sitzungs- oder Transiente Cookies: citrix_ns_id_wat. Hinweis: Was steht für will act transiently. Um die Anwendungscookies zu verfolgen, gruppiert die Application Firewall die permanenten oder Sitzungsanwendungscookies zusammen und hasht und signiert dann alle Cookies zusammen. Daher generiert die Application Firewall ein wlf-Cookie, um alle dauerhaften Anwendungscookies zu verfolgen, und ein wat-Cookie, um alle Anwendungssitzungscookies zu verfolgen.

Die folgende Tabelle zeigt die Anzahl und Art der Cookies, die von der Application Firewall auf der Grundlage der von der Webanwendung generierten Cookies generiert wurden:

Die NetScaler Web App Firewall ermöglicht die Verschlüsselung des Anwendungs-Cookies. Application Firewall bietet auch die Option, das von der Anwendung gesendete Sitzungscookie als Proxy zu verwenden, indem es zusammen mit den restlichen Sitzungsdaten der Application Firewall gespeichert und nicht an den Client gesendet wird. Wenn ein Client eine Anfrage an die Anwendung sendet, die ein Anwendungsfirewall-Sitzungscookie enthält, fügt Application Firewall das gesendete Anwendungs-Cookie wieder in die Anfrage ein, bevor die Anfrage an die ursprüngliche Anwendung gesendet wird. Die Anwendungsfirewall ermöglicht auch das Hinzufügen der Flags HttpOnly und/oder Secure zu Cookies.

Wie sich die Anwendungsfirewall auf HTTP-Header auswirkt

Sowohl HTTPS-Anfragen als auch HTTPS-Antworten verwenden Header, um Informationen über eine oder mehrere HTTPS-Nachrichten zu senden. Eine Kopfzeile besteht aus einer Reihe von Zeilen, wobei jede Zeile einen Namen enthält, gefolgt von einem Doppelpunkt und einem Leerzeichen sowie einem Wert. Der Host-Header hat beispielsweise das folgende Format:

Host: www.citrix.com

Einige Header-Felder werden sowohl in Anforderungs- als auch in Antwortheadern verwendet, während andere nur für eine Anfrage oder eine Antwort geeignet sind. Die Anwendungsfirewall kann einige Header in einer oder mehreren HTTPS-Anforderungen oder -Antworten hinzufügen, ändern oder löschen, um die Sicherheit der Anwendung zu gewährleisten.

Von der NetScaler Web App Firewall gelöschte Anforderungsheader

Viele der Anforderungsheader im Zusammenhang mit dem Caching werden gelöscht, um jede Anforderung im Kontext einer Sitzung anzuzeigen. In ähnlicher Weise löscht die Application Firewall diesen Header, wenn die Anforderung einen Codierungsheader enthält, der es dem Webserver ermöglicht, komprimierte Antworten zu senden, sodass der Inhalt der unkomprimierten Serverantwort von der Web App Firewall überprüft wird, um zu verhindern, dass vertrauliche Daten an den Client weitergegeben werden.

Die Application Firewall löscht die folgenden Anforderungsheader:

• Bereich — Wird zur Wiederherstellung nach einer fehlgeschlagenen oder teilweisen Dateiübertragung verwendet.
• If-Range — Ermöglicht einem Client, ein Teilobjekt abzurufen, wenn es bereits einen Teil dieses Objekts in seinem Cache enthält (bedingtes GET).
• If-Modified-Since — Wenn das angeforderte Objekt seit dem in diesem Feld angegebenen Zeitpunkt nicht geändert wurde, wird keine Entität vom Server zurückgegeben. Sie erhalten einen nicht modifizierten HTTP-304-Fehler.
• If-None-Match — Ermöglicht effiziente Aktualisierungen zwischengespeicherter Informationen mit minimalem Aufwand.
• Accept-Encoding — Welche Kodierungsmethoden sind für ein bestimmtes Objekt zulässig, z. B. Gzip.

Von der NetScaler Web App Firewall modifizierter Anforderungsheader

Wenn ein Webbrowser das HTTP/1.0-Protokoll oder frühere Protokolle verwendet, öffnet und schließt der Browser nach Erhalt jeder Antwort kontinuierlich die TCP-Socket-Verbindung. Dies erhöht den Aufwand für den Webserver und verhindert die Aufrechterhaltung des Sitzungsstatus. Das HTTP/1.1-Protokoll ermöglicht es, dass die Verbindung während der Sitzung geöffnet bleibt. Die Application Firewall ändert den folgenden Anforderungsheader, um HTTP/1.1 zwischen der Anwendungsfirewall und dem Webserver zu verwenden, unabhängig von dem vom Webbrowser verwendeten Protokoll: Verbindung: keep-alive

Von der NetScaler Web App Firewall hinzugefügte Anforderungsheader

Die Anwendungsfirewall fungiert als Reverse-Proxy und ersetzt die ursprüngliche Quell-IP-Adresse der Sitzung durch die IP-Adresse der Anwendungsfirewall. Daher weisen alle im Webserver-Log protokollierten Anfragen darauf hin, dass die Anfragen von der Application Firewall gesendet werden.

Von der NetScaler Web App Firewall gelöschter Antwortheader

Die Application Firewall blockiert oder ändert möglicherweise Inhalte, z. B. indem sie Kreditkartennummern entfernt oder Kommentare entfernt, was zu einer Diskrepanz in der Größe führen kann. Um ein solches Szenario zu verhindern, löscht die Application Firewall den folgenden Header:

Inhaltslänge — Gibt die Größe der an den Empfänger gesendeten Nachricht an. Von der Application Firewall geänderte Antwortheader

Viele der von der Application Firewall modifizierten Antwortheader beziehen sich auf das Caching. Das Zwischenspeichern von Headern in HTTP (S) -Antworten muss geändert werden, um den Webbrowser zu zwingen, immer eine Anfrage an den Webserver nach den neuesten Daten zu senden und den lokalen Cache nicht zu verwenden. Einige ASP-Anwendungen verwenden jedoch separate Plug-ins, um dynamische Inhalte anzuzeigen, und erfordern möglicherweise die Möglichkeit, die Daten vorübergehend im Browser zwischenzuspeichern. Um das temporäre Zwischenspeichern von Daten zu ermöglichen, wenn Advanced Security-Schutzfunktionen wie FFC, URL-Schließung oder CSRF-Prüfungen aktiviert sind, fügt Application Firewall die Cache-Control-Header in der Serverantwort mithilfe der folgenden Logik hinzu oder ändert sie:

• Wenn der Server Pragma: no-cache sendet, nimmt die Application Firewall keine Änderungen vor.
• Wenn die Clientanfrage HTTP 1.0 ist, fügt Application Firewall Pragma: no-cache ein.
• Wenn die Clientanfrage HTTP 1.1 ist und Cache-Control: no-store hat, nimmt die Application Firewall keine Änderungen vor.

• Wenn die Clientanfrage HTTP 1.1 ist und die Serverantwort den Cache-Control-Header ohne Store- oder Cache-Direktive enthält, nimmt die Application Firewall keine Änderungen vor.

• Wenn die Clientanfrage HTTP 1.1 ist und die Serverantwort entweder keinen Cache-Control-Header hat oder der Cache-Control-Header keine Store- oder No-Cache-Direktive hat, führt die Application Firewall die folgenden Aufgaben aus:

1. Fügt Cache-Control ein: max-age=3, must revalidate, private.
2. Fügt X-Cache-Control-orig = Originalwert des Cache-Control-Headers ein.
3. Löscht den Header der letzten Änderung.
4. Ersetzt Etag.
5. Fügt X-Expires-Orig=Originalwert des vom Server gesendeten Expire Headers ein.
6. Ändert den Expires-Header und legt das Ablaufdatum der Webseite auf die Vergangenheit fest, sodass sie immer wieder abgerufen wird.
7. Ändert Accept-Ranges und setzt den Wert auf None.

Um temporär zwischengespeicherte Daten im Clientbrowser zu ersetzen, wenn Application Firewall die Antwort ändert, z. B. für StripComments, X-out/Remove SafeObject, xout oder remove Credit Card oder URL Transform, ergreift Application Firewall die folgenden Aktionen:

1. Löscht Last-Modified vom Server, bevor es an den Client weitergeleitet wird.
2. Ersetzt Etag durch einen Wert, der von Application Firewall bestimmt wird.

Von der NetScaler Web App Firewall hinzugefügte Antwortheader

• Transfer-Encoding: Aufgeschlüsselt. Dieser Header streamt Informationen zurück an einen Client, ohne die Gesamtlänge der Antwort kennen zu müssen, bevor die Antwort gesendet wird. Dieser Header ist erforderlich, da der Header mit Inhaltslänge entfernt wurde.
• Set-Cookie: Die von der Application Firewall hinzugefügten Cookies.
• Xet-Cookie: Wenn die Sitzung gültig ist und die Antwort im Cache nicht abgelaufen ist, können Sie aus dem Cache servieren und müssen kein neues Cookie senden, da die Sitzung noch gültig ist. In einem solchen Szenario wird das Set-Cookie in Xet-Cookie geändert. Für den Webbrowser.

Wie werden Formulardaten beeinflusst

Die Application Firewall schützt vor Angriffen, die versuchen, den Inhalt des vom Server gesendeten Originalformulars zu ändern. Es kann auch vor Cross-Site Request-Forgery-Angriffen schützen. Die Application Firewall fügt zu diesem Zweck das versteckte Formular-Tag as_fid in die Seite ein.

Beispiel:<input type="hidden" name="as_fid" value="VRgWq0I196Jmg/+LOY7C" />

Das versteckte Feld as_fid wird aus Gründen der Feldkonsistenz verwendet. Dieses Feld wird von Application Firewall verwendet, um alle Felder des Formulars zu verfolgen, einschließlich der versteckten Feldnamen/Wertepaare, und um sicherzustellen, dass keines der vom Server gesendeten Felder des Formulars auf der Clientseite geändert wird. Die CSRF-Prüfung verwendet auch dieses eindeutige Formular-Tag as_fid, um sicherzustellen, dass die vom Benutzer übermittelten Formulare dem Benutzer in dieser Sitzung zugestellt wurden und kein Hacker versucht, die Benutzersitzung zu kapern.

Sitzungsloser Formularcheck

Application Firewall bietet auch eine Option zum Schutz von Formulardaten mithilfe sitzungsloser Feldkonsistenz. Dies ist nützlich für Anwendungen, bei denen die Formulare möglicherweise eine große Anzahl dynamischer versteckter Felder enthalten, was zu einer hohen Speicherzuweisung pro Sitzung durch die Anwendungsfirewall führt. Die sessionlose Feldkonsistenzprüfung wird durchgeführt, indem ein weiteres verstecktes Feld as_ffc_field nur für POST-Anfragen oder je nach konfigurierter Einstellung sowohl für GET- als auch für POST-Anfragen eingefügt wird. Die Application Firewall ändert die Methode GET in POST, wenn sie das Formular an den Client weiterleitet. Die Appliance setzt dann die Methode auf GET zurück, wenn sie an den Server zurückgesendet wird. Der Wert as_ffc_field kann groß sein, da er die verschlüsselte Zusammenfassung des ausgegebenen Formulars enthält. Im Folgenden finden Sie ein Beispiel für die sitzungslose Formularüberprüfung:

<input type="hidden" name="as_ffc_field" value="CwAAAAVIGLD/luRRi1Wu1rbYrFYargEDcO5xVAxsEnMP1megXuQfiDTGbwk0fpgndMHqfMbzfAFdjwR+TOm1oT
+u+Svo9+NuloPhtnbkxGtNe7gB/o8GlxEcK9ZkIIVv3oIL/nIPSRWJljgpWgafzVx7wtugNwnn8/GdnhneLCJTaYU7ScnC6LexJDLisI1xsEeONWt8Zm
+vJTa3mTebDY6LVyhDpDQfBgI1XLgfLTexAUzSNWHYyloqPruGYfnRPw+DIGf6gGwn1BYLEsRHKNbjJBrKpOJo9JzhEqdtZ1g3bMzEF9PocPvM1Hpvi5T6VB
/YFunUFM4f+bD7EAVcugdhovzb71CsSQX5+qcC1B8WjQ==" />
<!--NeedCopy-->

Entfernen von HTML-Kommentaren

Die Application Firewall bietet auch die Option, alle HTML-Kommentare in den Antworten zu entfernen, bevor sie an den Client gesendet werden. Dies betrifft nicht nur Formulare, sondern alle Antwortseiten. Die Application Firewall findet und entfernt jeglichen Text, der zwischen den Kommentar-Tags “<!-“ und “->”. Die Tags zeigen weiterhin an, dass an dieser Stelle des HTML-Quellcodes ein Kommentar vorhanden war. Jeder Text, der in andere HTML- oder JavaScript-Tags eingebettet ist, wird ignoriert. Einige Anwendungen funktionieren möglicherweise nicht richtig, wenn JavaScript falsch in Kommentar-Tags eingebettet ist. Ein Vergleich des Seitenquellcodes vor und nach dem Stricken der Kommentare durch die Application Firewall kann dabei helfen, festzustellen, ob in den gelöschten Kommentaren das erforderliche JavaScript eingebettet war.

Kreditkartenschutz

Die Application Firewall bietet die Möglichkeit, die Header und den Text der Antwort zu überprüfen und die Kreditkartennummern entweder zu entfernen oder zu löschen, bevor die Antwort an den Client weitergeleitet wird. Derzeit bietet Application Firewall Schutz für die folgenden gängigen Kreditkarten: American Express, Diners Club, Discover, JCB, MasterCard und Visa. Die X-Out-Aktion funktioniert unabhängig von der Block-Aktion.

Sicherer Objektschutz

Ähnlich wie bei Kreditkartennummern kann auch der Verlust anderer vertraulicher Daten verhindert werden, indem die Application Firewall Safe Object-Sicherheitsprüfung verwendet wird, um den vertraulichen Inhalt in der Antwort entweder zu entfernen oder zu löschen.

Cross-Site-Scripting transformiert das Handeln

Wenn die Transformation für Cross-Site Scripting aktiviert ist, ändert die Web App Firewall "<" into "%26lt;" and ">" into "%26gt;" in den Anforderungen. Wenn die Einstellung checkRequestHeaders in der Web App Firewall aktiviert ist, überprüft die Web App Firewall die Request-Header und wandelt diese Zeichen ebenfalls in Header und Cookies um. Die Transformationsaktion blockiert oder transformiert keine Werte, die ursprünglich vom Server gesendet wurden. Es gibt eine Reihe von Standardattributen und -Tags für Cross-Site Scripting, die die Web App Firewall zulässt. Eine Standardliste verweigerter Cross-Site-Scripting-Muster wird ebenfalls bereitgestellt. Diese können angepasst werden, indem Sie das Signaturobjekt auswählen und in der GUI auf den Dialog SQL/Cross-Site-Scripting-Muster verwalten klicken.

Transformation von SQL-Sonderzeichen

Application Firewall hat die folgenden Standard-Transformationsregeln für SQL-Sonderzeichen:

Wenn die Transformation von Sonderzeichen aktiviert ist und CheckRequestHeaders auf ON gesetzt ist, erfolgt die Transformation von Sonderzeichen auch in Headern und Cookies. Hinweis: Einige Anforderungsheader wie User-Agent, Accept-Encoding enthalten normalerweise Semikolons und können von der SQL-Transformation beeinflusst werden.

Verhalten der NetScaler Web App Firewall, bei dem der EXPECT-Header beschädigt wird

1. Immer wenn NetScaler eine HTTP-Anfrage mit dem EXPECT-Header empfängt, sendet NetScaler im Namen des Backend-Servers die Antwort EXPECT: 100 -continue an den Client.
2. Dieses Verhalten ist darauf zurückzuführen, dass der Application Firewall-Schutz für die gesamte Anfrage ausgeführt werden muss, bevor die Anforderung an den Server weitergeleitet wird. NetScaler muss die gesamte Anfrage vom Client abrufen.
3. Nach Erhalt einer 100 continue-Antwort sendet der Client den verbleibenden Teil der Anfrage, der die Anfrage vervollständigt.
4. NetScaler führt dann alle Schutzmaßnahmen aus und leitet die Anfrage dann an den Server weiter.
5. Da NetScaler nun die vollständige Anfrage weiterleitet, wird der EXPECT-Header, der in der ursprünglichen Anfrage enthalten war, veraltet, wodurch NetScaler diesen Header beschädigt und an den Server sendet.
6. Server beim Empfang der Anforderung ignoriert alle Header, die beschädigt sind.