Einführung in die Citrix Web Application Firewall

Die Citrix 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 -Skripts, Web-Frameworks, Webserver-Software und anderen zugrunde liegenden Betriebssystemen.

Die Citrix Web App Firewall ist als eigenständige Appliance oder als Funktion auf einer virtuellen Citrix ADC Appliance (VPX) verfügbar. In der Web App Firewall-Dokumentation bezieht sich der Begriff Citrix ADC 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, einen Citrix ADC, auf dem auch andere Funktionen konfiguriert wurden, oder um einen Citrix ADC 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 reicht eine einzige Konfiguration aus. In anderen Fällen, insbesondere bei interaktiven Websites, Websites, die auf Datenbankserver zugreifen, Onlineshops mit Einkaufswagen, benötigen Sie möglicherweise verschiedene Konfigurationen, um sensible Daten bestmöglich zu schützen, ohne viel Aufwand für Inhalte zu verschwenden, die nicht anfällig für bestimmte Arten von Angriffen sind. Sie können die Standardeinstellungen für die globalen Einstellungen, die sich auf alle Sicherheitskonfigurationen auswirken, häufig unverändert lassen. Sie können die globalen Einstellungen jedoch ändern, wenn sie mit anderen Teilen Ihrer Konfiguration in Konflikt stehen oder Sie es vorziehen, sie anzupassen.

Sicherheit von Webanwendungen

Webanwendungssicherheit ist Netzwerksicherheit für Computer und Programme, die über die Protokolle HTTP und HTTPS kommunizieren. Dies ist ein breiter Bereich, in dem es viele Sicherheitslücken und -schwächen gibt. Betriebssysteme auf Servern und Clients weisen Sicherheitsprobleme auf und sind anfällig für Angriffe. Webserver-Software 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, aber heute ist das selten der Fall. Beispielsweise waren Angriffe, bei denen sich ein Hacker Zugriff auf einen Webserver verschaffte und unbefugte Änderungen an einer Website vornahm (unkenntlich gemacht), früher weit verbreitet. Sie wurden in der Regel von Hackern ins Leben gerufen, die keine andere Motivation hatten, als anderen Hackern ihre Fähigkeiten zu demonstrieren oder die Zielperson oder das Unternehmen 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: sensible und potenziell wertvolle private Informationen zu erhalten oder unbefugten Zugriff auf und Kontrolle über eine Website oder einen Webserver zu erlangen.

Bestimmte Formen von Webangriffen konzentrieren sich darauf, an private Informationen zu gelangen. 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 abrufen 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 durch solche Angriffe erlangten Informationen ist gesetzlich geschützt, und alle sind durch Gewohnheiten und Erwartungen geschützt. 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 nicht autorisierte Inhalte zu hosten, als Proxy für Inhalte zu fungieren, die auf einem anderen Webserver gehostet werden, SMTP-Dienste für den Versand unerwünschter Massen-E-Mails bereitzustellen oder DNS-Dienste zur Unterstützung solcher Aktivitäten auf anderen gefährdeten Webservern bereitzustellen. Die meisten Websites, die auf kompromittierten Webservern gehostet werden, fördern fragwürdige oder schlichtweg betrügerische Unternehmen. Beispielsweise werden die meisten Phishing-Websites und Websites zur Ausbeutung von Kindern auf kompromittierten Webservern gehostet.

Der Schutz Ihrer Websites und Webdienste vor diesen Angriffen erfordert eine mehrschichtige Abwehr, 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 anders aussehen als der normale Traffic auf Ihre Websites und Webdienste.

Weitere Informationen zur Sicherheitsüberprüfung finden Sie unter Überblick über Sicherheitsüberprüfungen.

Bekannte Webangriffe

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 einer langen Information an einen Webserver führt dazu, dass das System hängen bleibt, abstürzt oder unbefugten Zugriff auf das zugrunde liegende Betriebssystem gewährt. Ein Angriff mit einem Pufferüberlauf kann verwendet werden, um Zugriff auf nicht autorisierte 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 nicht autorisierte 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 gewaltsamem Surfen können darauf hindeuten, dass ein Benutzer eine Seite auf Ihrer Website mit einem Lesezeichen versehen hat. Wiederholte Versuche, auf nicht existierende Inhalte zuzugreifen, oder auf Inhalte, 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 nicht autorisierte 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, von denen Ihre Website nicht erwartet, dass sie in diesem Webformular empfangen werden. Ein Sicherheitsangriff auf ein Webformular kann entweder dazu verwendet werden, unautorisierte Informationen von Ihrer Website zu erhalten oder 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, dass eine SQL-Datenbank den Befehl oder die Befehle ausführt. SQL-Injection-Angriffe werden normalerweise verwendet, um nicht autorisierte Informationen zu erhalten.
• Cross-Site-Scripting-Angriffe. Die Verwendung einer URL oder eines Skripts auf einer Webseite verstößt gegen die Same-Origin-Richtlinie, die es Skripten untersagt, Eigenschaften von einer anderen Website abzurufen oder Inhalte auf einer anderen Website zu ändern. Da Skripte Informationen abrufen und Dateien auf Ihrer Website ändern können, kann der Zugriff eines Skripts auf Inhalte auf einer anderen Website einem Angreifer die Möglichkeit bieten, an unbefugte Informationen zu gelangen, einen Webserver zu kompromittieren 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 verletzen können
• Denial-of-Service (DoS) -Angriffe. XML-Anfragen, die wiederholt und in großen Mengen gesendet werden, um den Ziel-Webdienst zu überfordern und legitimen Benutzern den Zugriff auf den Webservice zu verweigern.

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, dass eine SQL-Datenbank diesen Befehl oder diese Befehle ausführt. Wie bei HTML-SQL-Injection-Angriffen werden XML-SQL-Injection-Angriffe normalerweise verwendet, um nicht autorisierte Informationen zu erhalten.
• Cross-Site-Scripting-Angriffe. Die Verwendung eines Skripts, das in einer XML-basierten Anwendung enthalten ist, um gegen die Same-Origin-Richtlinie zu verstoßen, die es Skripten nicht 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 ein Angreifer, wenn Sie einem Skript Zugriff auf Inhalte gewähren, die zu einer anderen Anwendung gehören, die Möglichkeit bieten, an nicht autorisierte Informationen zu gelangen, die Anwendung zu kompromittieren oder beides.

Bekannte Webangriffe können in der Regel gestoppt werden, indem der Website-Verkehr nach bestimmten Merkmalen (Signaturen) gefiltert wird, die immer für einen bestimmten Angriff auftreten und niemals im legitimen Datenverkehr vorkommen dürfen. Dieser Ansatz hat den Vorteil, dass er relativ wenig Ressourcen erfordert und ein relativ geringes Risiko von Fehlalarmen birgt. Daher ist es ein wertvolles Tool zur Bekämpfung von Angriffen auf Websites und Webdienste und zur Konfiguration des grundlegenden Signaturschutzes.

Unbekannte Webangriffe

Die größte Bedrohung für Websites und Anwendungen geht nicht von bekannten Angriffen aus, sondern von unbekannten Angriffen. 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-Attacken), und gezielte Angriffe auf eine bestimmte Website oder einen Webdienst und nicht auf viele Websites oder Webdienste (Spear-Angriffe). Diese Angriffe zielen, wie auch bekannte Angriffe, darauf ab, vertrauliche private Informationen zu erhalten, die Website oder den Webdienst zu kompromittieren und es zu ermöglichen, sie für weitere Angriffe oder beide Ziele zu verwenden.

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. Zero-Day-Angriffe beinhalten häufig injiziertes SQL, ein Cross-Site-Script, eine Cross-Site-Request-Forgery 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 es getan haben, haben die Benutzer die Patches nicht erhalten und installiert oder die zum Schutz vor diesen Angriffen erforderlichen Abhilfemaßnahmen durchgeführt. Die Zeit zwischen der Entdeckung eines Zero-Day-Angriffs und der Verfügbarkeit einer Abwehr (das Sicherheitsfenster) wird immer kürzer, aber die Täter können immer noch mit Stunden oder sogar Tagen rechnen, in denen viele Websites und Webdienste keinen spezifischen Schutz vor dem Angriff haben.

Spear-Angriffe stellen eine große Bedrohung dar, richten sich jedoch nur an eine bestimmte Benutzergruppe. Eine übliche Art von Spear-Attacke, ein Spear-Phishing, richtet sich gegen Kunden einer bestimmten Bank oder eines Finanzinstituts oder (seltener) gegen Mitarbeiter eines bestimmten Unternehmens oder einer bestimmten Organisation. Im Gegensatz zu anderen Phishing-Methoden, bei denen es sich oft um grob geschriebene Fälschungen handelt, die ein Benutzer, der mit der tatsächlichen Kommunikation dieser Bank oder dieses Finanzinstituts vertraut ist, erkennen kann, sind Spear-Phishes buchstabengenau und überzeugend. Sie können individuenspezifische Informationen enthalten, die auf den ersten Blick kein Fremder kennen oder erhalten können darf. Der Spear-Phisher ist somit in der Lage, die Zielperson davon zu überzeugen, die angeforderten Informationen bereitzustellen, die der Phisher dann verwenden kann, um Konten zu plündern, unrechtmäßig erlangtes Geld aus anderen Quellen zu verarbeiten oder sich Zugang zu anderen, noch sensibleren Informationen zu verschaffen.

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 positive Sicherheitsmodellsysteme. Heuristisches Filtern 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 webformularbasierte Sicherheitsprüfungen erfassen die normale Nutzung Ihrer Websites und kontrollieren dann, wie Benutzer mit Ihren Websites interagieren. Dabei werden sowohl heuristische als auch positive Sicherheitsvorkehrungen verwendet, um anomalen oder unerwarteten Traffic zu blockieren. Sowohl heuristische als auch positive Sicherheit können, wenn sie richtig konzipiert und eingesetzt werden, die meisten Angriffe abfangen, die Signaturen übersehen. 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 verwendet, sondern als Backups von Signaturen oder anderen weniger ressourcenintensiven Ansätzen.

Indem Sie diese erweiterten Schutzmaßnahmen zusätzlich zu den Signaturen konfigurieren, erstellen Sie ein hybrides Sicherheitsmodell, mit dem die Web App Firewall umfassenden Schutz vor bekannten und unbekannten Angriffen bietet.

So funktioniert die Citrix Web Application Firewall

Wenn Sie die Web App Firewall installieren, erstellen Sie eine anfängliche Sicherheitskonfiguration, die aus einer Richtlinie, einem Profil und einem Signaturobjekt besteht. Die Richtlinie ist eine Regel, die den zu filternden Verkehr identifiziert, und das Profil identifiziert die Muster und Verhaltenstypen, die zugelassen oder blockiert werden sollen, wenn der Verkehr gefiltert wird. Die einfachsten Muster, die als Signaturen bezeichnet werden, werden nicht innerhalb des Profils angegeben, sondern in einem Signaturobjekt, das dem Profil zugeordnet ist.

Eine Signatur ist eine Zeichenfolge oder ein Muster, das einer bekannten Art von Angriff entspricht. Die Web App Firewall enthält über tausend Signaturen in sieben Kategorien, die sich jeweils gegen Angriffe auf bestimmte Arten von Webservern und Webinhalten richten. Citrix aktualisiert die Liste mit neuen Signaturen, sobald neue Bedrohungen erkannt 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 Basisschutz bei geringem Verarbeitungsaufwand. Wenn Ihre Anwendungen spezielle Sicherheitslücken aufweisen oder Sie einen Angriff gegen sie entdecken, 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 Verhaltensarten, 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, mit der versucht wird, eine bestimmte Art von Operation auszuführen, die möglicherweise die Sicherheit verletzt, oder eine Antwort, die vertrauliche private Informationen wie eine Sozialversicherungsnummer oder Kreditkartennummer enthält. Während der Konfiguration geben Sie die Sicherheitsüberprüfungen an, die für die Webserver und Inhalte, die Sie schützen müssen, geeignet sind. Die Sicherheitsüberprüfungen sind restriktiv. Viele von ihnen können legitime Anfragen und Antworten blockieren, wenn Sie bei der Konfiguration nicht die entsprechenden Ausnahmen (Lockerungen) hinzufügen. Es ist nicht schwierig, die benötigten Ausnahmen zu identifizieren, 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, und verwendet dabei sowohl ihren internen Regelsatz als auch Ihre Ergänzungen und Änderungen. Es blockiert oder macht alle Aktivitäten unschädlich, die es als schädlich erkennt, und leitet dann den verbleibenden Verkehr 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 nicht berücksichtigt. Es veranschaulicht eine Sicherheitskonfiguration, bei der die Richtlinie darin besteht, alle Anfragen zu verarbeiten. Außerdem wurde in dieser Konfiguration ein Signaturobjekt konfiguriert und dem Profil zugeordnet, und Sicherheitsüberprü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 Anfrage mit einer Signatur übereinstimmt, zeigt die Citrix Web Application Firewall entweder das Fehlerobjekt an (eine Webseite auf der Web App Firewall Appliance, die Sie mithilfe der Importfunktion konfigurieren können) oder leitet die Anfrage an die angegebene Fehler-URL (die Fehlerseite) weiter. Signaturen benötigen nicht so viele Ressourcen wie Sicherheitsüberprüfungen. Das Erkennen und Stoppen von Angriffen, die anhand einer Signatur erkannt werden, bevor eine der Sicherheitsüberprüfungen ausgeführt wird, reduziert also die Serverlast.

Wenn eine Anfrage die Signaturprüfung besteht, wendet die Web App Firewall die aktivierten Sicherheitsüberprüfungen für Anfragen 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. Bei Sicherheitsüberprüfungen wird die Anforderung beispielsweise auf Anzeichen untersucht, die darauf hinweisen, dass sie möglicherweise von einem unerwarteten Typ ist, unerwarteten Inhalt anfordert oder unerwartete und möglicherweise schädliche Webformulardaten, SQL-Befehle oder Skripts enthält. Wenn die Anfrage eine Sicherheitsprüfung nicht besteht, bereinigt die Web App Firewall die Anfrage entweder und sendet sie dann zurück an die Citrix ADC Appliance (oder die virtuelle Citrix ADC Appliance) oder zeigt das Fehlerobjekt an. Wenn die Anfrage die Sicherheitsprüfungen besteht, wird sie an die Citrix ADC Appliance zurückgesendet, die alle anderen Verarbeitungen abschließt und die Anfrage 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 Sicherheitschecks wird die Antwort auf undichte vertrauliche Informationen, Anzeichen einer Verunstaltung der Website oder andere Inhalte untersucht, die nicht vorhanden sein dürfen. Wenn die Antwort eine Sicherheitsüberprü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 besteht, wird sie an die Citrix ADC Appliance zurückgesendet, die sie an den Benutzer weiterleitet.

Funktionen der Citrix Web Application 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 Sicherheitsüberprüfungen empfiehlt.

Die Importfunktion verwaltet Dateien, die Sie auf 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 Schutzbedürfnisse zu ermitteln.

Wie die Citrix Web Application Firewall den Anwendungsverkehr verändert

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

• Cookies
• HTTP-Header
• Formulare/Daten

Sitzungscookie der Citrix Web Application Firewall

Um den Status der Sitzung aufrechtzuerhalten, generiert die Citrix ADC Web App Firewall ein eigenes Sitzungscookie. Dieses Cookie wird nur zwischen dem Webbrowser und der Citrix ADC Web Application Firewall und nicht an den Webserver weitergegeben. Wenn ein Hacker versucht, das Sitzungscookie zu ändern, löscht die Web App Firewall das Cookie, bevor die Anfrage an den Server weitergeleitet wird, und behandelt die Anfrage als neue Benutzersitzung. Das Sitzungscookie ist vorhanden, solange der Webbrowser geöffnet ist. Wenn der Webbrowser geschlossen wird, wird das Application Firewall-Sitzungscookie ungültig. Der Status der Sitzung enthält die Informationen der vom Client besuchten URLs und Formulare.

Das konfigurierbare Web App Firewall -Sitzungscookie lautet citrix_ns_id.

Ab Citrix ADC Build 12.1, 54 und 13.0 ist die Cookie-Konsistenz sitzungslos und das Hinzufügen des von der Appliance citrix_ns_id generierten Sitzungscookies wird nicht erzwungen. Weitere Informationen zur Konfiguration von Cookies finden Sie unter Engine-Einstellungen.

Cookies der Citrix Web App Firewall

Viele Webanwendungen generieren Cookies, um benutzer- oder sitzungsspezifische Informationen zu verfolgen. Bei diesen Informationen kann es sich um Benutzerpräferenzen oder Einkaufswagenartikel handeln. 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, wie z. B. Anmeldung, Passwort oder Einstellungen.
• 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. Artikel im Einkaufswagen oder Anmeldeinformationen für die Sitzung.

Hacker können versuchen, Anwendungscookies zu modifizieren oder zu stehlen, um eine Benutzersitzung zu kapern oder sich als Benutzer auszugeben. Die Anwendungsfirewall verhindert solche Versuche, indem sie die Anwendungs-Cookies hasht und dann weitere Cookies mit den digitalen Signaturen hinzufügt. Durch die Nachverfolgung 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 Citrix Web Application 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 für steht, wird vorübergehend wirken. 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 die Arten von Cookies, die von der Application Firewall auf der Grundlage der von der Webanwendung generierten Cookies generiert werden:

Die Citrix Web App Firewall ermöglicht die Verschlüsselung des Anwendungs-Cookies. Die Application Firewall bietet auch die Möglichkeit, 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 Application Firewall-Sitzungscookie enthält, fügt Application Firewall das von der Anwendung gesendete Cookie wieder in die Anfrage ein, bevor die Anfrage an die ursprüngliche Anwendung weitergeleitet 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, gefolgt von einem Doppelpunkt und einem Leerzeichen sowie einem Wert enthält. Der Host-Header hat beispielsweise das folgende Format:

Host: www.citrix.com

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

Von der Citrix Web Application Firewall verworfene Anforderungsheader

Viele der Anforderungsheader im Zusammenhang mit dem Caching werden gelöscht, um jede Anfrage im Kontext einer Sitzung anzuzeigen. Wenn die Anfrage einen Codierungs-Header enthält, damit der Webserver komprimierte Antworten senden kann, löscht die Application Firewall diesen Header, sodass der Inhalt der unkomprimierten Serverantwort von der Web App Firewall überprüft wird, um zu verhindern, dass sensible Daten an den Client gelangen.

Die Application Firewall löscht die folgenden Anforderungsheader:

• Bereich — Wird für die Wiederherstellung nach fehlgeschlagenen oder teilweisen Dateiübertragungen verwendet.
• If-Range — Ermöglicht einem Client, ein Teilobjekt abzurufen, wenn er einen Teil dieses Objekts bereits 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 HTTP 304-Fehler, der nicht geändert wurde.
• If-None-Match — Ermöglicht effiziente Aktualisierungen zwischengespeicherter Informationen mit minimalem Overhead.
• Accept-Encoding — Welche Kodierungsmethoden sind für ein bestimmtes Objekt zulässig, z. B. gzip.

Von der Citrix Web Application Firewall geänderter Anforderungsheader

Wenn ein Webbrowser die Protokolle HTTP/1.0 oder früher verwendet, öffnet und schließt der Browser nach Erhalt jeder Antwort kontinuierlich die TCP-Socket-Verbindung. Dies erhöht den Overhead des Webservers 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 Citrix Web Application Firewall hinzugefügte Anforderungsheader

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

Von der Citrix Web Application Firewall gelöschter Antwortheader

Die Anwendungsfirewall blockiert oder ändert möglicherweise Inhalte wie das Entfernen von Kreditkartennummern oder das Entfernen von Kommentaren, was zu einer Größenabweichung 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 für die neuesten Daten zu senden und nicht den lokalen Cache 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 erweiterte Sicherheitsvorkehrungen 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 Anwendungs-Firewall keine Änderungen vor.
• Wenn Client Request HTTP 1.0 ist, fügt Application Firewall Pragma: no-cache ein.
• Wenn Client Request HTTP 1.1 ist und Cache-Control: no-store hat, nimmt die Application Firewall keine Änderungen vor.

• Wenn die Client-Anfrage HTTP 1.1 ist und die Serverantwort einen Cache-Control-Header ohne Store- oder Cache-Direktive hat, nimmt die Application Firewall keine Änderungen vor.

• Wenn die Client-Anfrage HTTP 1.1 ist und die Serverantwort entweder No 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 „Zuletzt geändert“.
4. Ersetzt Etag.
5. Fügt X-Expires-Orig=Originalwert des vom Server gesendeten Expire-Headers ein.
6. Ändert den Expires-Header und setzt das Ablaufdatum der Webseite auf die Vergangenheit, sodass sie immer wieder abgerufen wird.
7. Ändert Accept-Ranges und setzt ihn auf None.

Um vorübergehend zwischengespeicherte Daten im Client-Browser 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 Citrix Web App Firewall hinzugefügte Antwortheader

• Transfer-Encoding: Aufgeschlüsselt. Dieser Header streamt Informationen zurück an einen Client, ohne dass Sie die Gesamtlänge der Antwort kennen müssen, bevor Sie die Antwort senden. Dieser Header ist erforderlich, da der Content-Length-Header 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 Formulardaten betroffen sind

Die Application Firewall schützt vor Angriffen, bei denen versucht wird, den Inhalt des vom Server gesendeten Originalformulars zu ändern. Es kann auch vor Cross-Site Request-Forgery-Angriffen schützen. Die Application Firewall erreicht dies, indem sie das versteckte Formular-Tag as_fid in die Seite einfügt.

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

Das versteckte Feld as_fid wird für die Feldkonsistenz verwendet. Dieses Feld wird von Application Firewall verwendet, um alle Felder des Formulars zu verfolgen, einschließlich der versteckten Feldname/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.

Formularprüfung ohne Sitzung

Application Firewall bietet auch eine Option zum Schutz von Formulardaten mithilfe von sitzungsloser Feldkonsistenz. Dies ist nützlich für Anwendungen, bei denen die Formulare möglicherweise eine große Anzahl dynamischer versteckter Felder enthalten, die zu einer hohen Speicherzuweisung pro Sitzung durch die Anwendungsfirewall führen. Die Konsistenzprüfung von Feldern ohne Sitzung wird durchgeführt, indem ein weiteres ausgeblendetes Feld as_ffc_field nur für POST-Anfragen oder sowohl für GET- als auch für POST-Anfragen eingefügt wird, basierend auf der konfigurierten Einstellung. Die Application Firewall ändert die Methode GET in POST, wenn sie das Formular an den Client weiterleitet. Die Appliance setzt die Methode dann auf GET zurück, wenn sie an den Server zurückgesendet wird. Der Wert as_ffc_field kann groß sein, da er den verschlüsselten Digest des Formulars enthält, das zugestellt wird. Das Folgende ist ein Beispiel für die sitzungslose Formularprü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 Möglichkeit, 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 zwischen den Kommentar-Tags “<!-“ und “->”. Die Tags weisen weiterhin darauf hin, 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 Entfernen der Kommentare durch die Application Firewall kann dabei helfen, festzustellen, ob in einem der gelöschten Kommentare das erforderliche JavaScript eingebettet war.

Schutz Ihrer Kreditkarte

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 sensibler Daten verhindert werden, indem die Sicherheitsüberprüfung Application Firewall Safe Object verwendet wird, um die vertraulichen Inhalte in der Antwort entweder zu entfernen oder zu löschen.

Siteübergreifendes Scripting transformiert Aktionen

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 Anforderungsheader und wandelt diese Zeichen auch 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.

Transformieren 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 Citrix Web Application 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 EXPECT: 100 -continue-Antwort 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 Anfrage 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. Jetzt, da NetScaler die komplette Anfrage weiterleitet, wird der EXPECT-Header, der in der ursprünglichen Anfrage kam, veraltet, sodass NetScaler diesen Header beschädigt und an den Server sendet.
6. Der Server ignoriert beim Empfang der Anfrage jeden beschädigten Header.