Citrix ADC

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 Kundendaten zugreifen. Dies geschieht, indem sowohl Anfragen als auch Antworten gefiltert werden, sie auf Hinweise auf bösartige Aktivitäten untersucht und diejenigen blockiert werden, die solche Aktivitäten aufweisen. Ihre Website ist nicht nur vor gängigen Arten von Angriffen geschützt, sondern auch vor neuen, noch unbekannten Angriffen. Zusätzlich zum Schutz von Webservern und Websites vor unbefugtem Zugriff und Missbrauch durch Hacker und bösartige Programme bietet die Web App Firewall Schutz vor Sicherheitslücken in Legacy-CGI-Code oder -Skripten, anderen Web-Frameworks, Webserver-Software und den 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, ein Citrix ADC, auf dem auch andere Funktionen konfiguriert wurden, oder um ein 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. In einigen Fällen reicht eine einzelne Konfiguration aus. In anderen Fällen, insbesondere in denen interaktive Websites, Websites, die auf Datenbankserver zugreifen, Onlineshops mit Einkaufswagen, benötigen Sie möglicherweise mehrere verschiedene Konfigurationen, um vertrauliche Daten am besten zu schützen, ohne großen Aufwand für Inhalte zu verschwenden, die für bestimmte Arten von Angriffe. Sie können die Standardeinstellungen für die globalen Einstellungen, die sich auf alle Sicherheitskonfigurationen auswirken, oft unverändert lassen. Sie können jedoch die globalen Einstellungen ändern, wenn sie mit anderen Teilen Ihrer Konfiguration in Konflikt stehen oder Sie sie lieber anpassen möchten.

Sicherheit für Webanwendungen

Webanwendungssicherheit ist Netzwerksicherheit für Computer und Programme, die mit der HTTP- und HTTPS-Protokolle kommunizieren. Dies ist ein äußerst breiter Bereich, in dem Sicherheitslücken und Schwächen im Überfluss vorhanden sind. Betriebssysteme auf Servern und Clients haben Sicherheitsprobleme und sind anfällig für Angriffe. Webserver-Software und Website-Technologien wie CGI, Java, JavaScript, PERL und PHP haben zugrunde liegende Schwachstellen. Browser und andere Clientanwendungen, die mit webfähigen Anwendungen kommunizieren, weisen ebenfalls Schwachstellen auf. Websites, die jede Technologie verwenden, aber die einfachste HTML, einschließlich jeder Website, die Interaktion mit Besuchern ermöglicht, haben oft eigene Schwachstellen.

In der Vergangenheit war eine Sicherheitsverletzung oft nur ein Ärger, aber heute ist das selten der Fall. Beispielsweise waren Angriffe, bei denen ein Hacker Zugriff auf einen Webserver verschafft und unautorisierte Änderungen an einer Website vorgenommen hat, häufig. Sie wurden in der Regel von Hackern gestartet, die keine Motivation hatten, außer anderen Hackern ihre Fähigkeiten zu demonstrieren oder die zielgerichtete Person oder Firma in Verlegenheit zu bringen. Die meisten aktuellen Sicherheitsverletzungen sind jedoch durch den Wunsch nach Geld motiviert. Die Mehrheit versucht, eines oder beide der folgenden Ziele zu erreichen: sensible und potenziell wertvolle private Informationen zu erhalten oder unbefugten Zugriff auf eine Website oder einen Webserver und deren Kontrolle zu erlangen.

Bestimmte Formen von Web-Attacken konzentrieren sich auf die Beschaffung privater Informationen. Diese Angriffe sind oft auch gegen Websites möglich, die sicher genug sind, um einen Angreifer daran zu hindern, die volle Kontrolle zu übernehmen. Die Informationen, die ein Angreifer von einer Website erhalten kann, können Kundennamen, Adressen, Telefonnummern, Sozialversicherungsnummern, Kreditkartennummern, Krankenakten und andere private Informationen umfassen. Der Angreifer kann diese Informationen dann verwenden oder an andere verkaufen. Ein Großteil der Informationen, die durch solche Angriffe erhalten werden, ist gesetzlich geschützt, und all dies durch Gewohnheit und Erwartung. Ein solcher Verstoß kann äußerst schwerwiegende Folgen für Kunden haben, deren private Informationen gefährdet sind. Diese Kunden müssen bestenfalls Wachsamkeit ausüben, um andere daran zu hindern, ihre Kreditkarten zu missbrauchen, unbefugte Kreditkonten in ihrem Namen zu eröffnen oder ihre Identität zu eigen (Identitätsdiebstahl). Im schlimmsten Fall können die Kunden ruinierte Kreditratings oder sogar für kriminelle Aktivitäten verantwortlich gemacht werden, an denen sie keine Rolle hatten.

Andere Web-Angriffe zielen darauf ab, die Kontrolle über eine Website oder den Server, auf dem sie arbeitet, oder beides zu erlangen (oder zu kompromittieren). Ein Hacker, der die Kontrolle über eine Website oder einen Server erhält, kann damit nicht autorisierte Inhalte hosten, als Proxy für Inhalte fungieren, die auf einem anderen Webserver gehostet werden, SMTP-Dienste zum Senden unerwünschter Massen-E-Mails bereitstellen oder DNS-Dienste bereitstellen, um solche Aktivitäten auf anderen kompromittierten Webservern zu unterstützen. Die meisten Websites, die auf kompromittierten Webservern gehostet werden, fördern fragwürdige oder betrügerische Unternehmen. Beispielsweise werden die meisten Phishing-Websites und Websites für untergeordnete Ausnutzung auf kompromittierten Webservern gehostet.

Der Schutz Ihrer Websites und Webdienste vor diesen Angriffen erfordert eine mehrschichtige Verteidigung, die sowohl bekannte Angriffe mit identifizierbaren Eigenschaften blockieren als auch vor unbekannten Angriffen schützt. Diese können oft erkannt werden, weil sie sich vom normalen Datenverkehr zu Ihren Websites unterscheiden und Web-Services.

Bekannte Webangriffe

Die erste Verteidigungslinie für Ihre Websites ist der Schutz vor der großen Anzahl von Angriffen, die bekanntermaßen existieren und von Web-Sicherheitsexperten beobachtet und analysiert wurden. Häufige Arten von Angriffen auf HTML-basierte Websites sind:

  • Pufferüberlaufangriffe. Senden einer extrem langen URL, extrem langen Cookie oder andere extrem lange Informationen an einen Webserver in der Hoffnung, dass sie oder das zugrunde liegende Betriebssystem hängen, abstürzen oder dem Angreifer Zugriff auf das zugrunde liegende Betriebssystem ermöglichen. Ein Pufferüberlaufangriff kann verwendet werden, um Zugriff auf nicht autorisierte Informationen zu erhalten, um einen Webserver oder beides zu gefährden.
  • Cookie-Sicherheitsangriffe. Senden eines modifizierten Cookies an einen Webserver, in der Regel in der Hoffnung, Zugriff auf nicht autorisierte Inhalte durch gefälschte Anmeldeinformationen zu erhalten.
  • Zwangsvolles Surfen. Direkter Zugriff auf URLs auf einer Website, ohne über Hyperlinks auf der Homepage oder andere allgemeine Start-URLs auf der Website zu den URLs zu navigieren. Einzelne Fälle von erzwungenem Surfen können einfach einen Benutzer anzeigen, der eine Seite auf Ihrer Website als Lesezeichen markiert hat, aber wiederholte Versuche, auf nicht vorhandene Inhalte oder Inhalte zuzugreifen, auf die Benutzer nie direkt zugreifen sollten, stellen oft einen Angriff auf die Sicherheit der Website dar. Erzwungenes Browsen wird normalerweise verwendet, um Zugriff auf nicht autorisierte Informationen zu erhalten, kann aber auch mit einem Pufferüberlaufangriff kombiniert werden, um Ihren Server zu gefährden.
  • Webformular-Sicherheitsangriffe. Senden unangemessener Inhalte in einem Webformular an Ihre Website. Unangemessene Inhalte können geänderte ausgeblendete Felder, HTML oder Code in einem Feld enthalten, das nur für alphanumerische Daten bestimmt ist, eine übermäßig lange Zeichenfolge in einem Feld, das nur eine kurze Zeichenfolge akzeptiert, eine alphanumerische Zeichenfolge in einem Feld, das nur eine ganze Zahl akzeptiert, und eine Vielzahl anderer Daten, die Ihre Website nicht erwarten, dass sie in diesem Webformular erhalten. Ein Webformular-Sicherheitsangriff kann entweder verwendet werden, um nicht autorisierte Informationen von Ihrer Website zu erhalten oder um die Website endlos zu gefährden, in der Regel 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 aktiven SQL-Befehls oder Befehls in einem Webformular oder als Teil einer URL, mit dem Ziel, die Ausführung des Befehls oder der Befehle durch eine SQL-Datenbank zu veranlassen. SQL-Injection-Angriffe werden normalerweise verwendet, um nicht autorisierte Informationen zu erhalten.
  • Cross-Site-Skripting-Angriffe. Verwenden einer URL oder eines Skripts auf einer Webseite, um gegen die Richtlinie der gleichen Herkunft zu verstoßen, die jedem Skript das Abrufen von Eigenschaften oder Ändern von Inhalten auf einer anderen Website verbietet. Da Skripte Informationen abrufen und Dateien auf Ihrer Website ändern können, kann es einem Angreifer ermöglichen, nicht autorisierte Informationen zu erhalten, einen Webserver oder beides zu gefährden.

Angriffe auf XML-basierte Webdienste fallen normalerweise in mindestens eine der folgenden zwei Kategorien: Versuche, unangemessene Inhalte an einen Webdienst zu senden, oder Versuche, die Sicherheit eines Webdienstes zu verletzen. Häufige Arten von Angriffen gegen XML-basierte Webdienste sind:

  • Bösartiger Code oder Objekte. XML-Anforderungen, die Code oder Objekte enthalten, die entweder direkt sensible Informationen abrufen oder einem Angreifer die Kontrolle über den Webdienst oder den zugrunde liegenden Server geben können.
  • Schlecht geformte XML-Anforderungen. XML-Anforderungen, die nicht der W3C-XML-Spezifikation entsprechen und daher die Sicherheit eines unsicheren Webdienstes verletzen können
  • Denial-of-Service-Angriffe (DoS). XML-Anforderungen, die wiederholt und in hohem Umfang gesendet werden, mit der Absicht, den zielgerichteten Webdienst zu überwältigen und legitimen Benutzern den Zugriff auf den Webdienst zu verweigern.

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

  • SQL-Injection-Angriffe. Senden eines aktiven SQL-Befehls oder Befehls in einer XML-basierten Anforderung, mit dem Ziel, dass eine SQL-Datenbank diesen Befehl oder diese Befehle ausführen kann. Wie bei HTML-SQL-Injektionsangriffen werden XML-SQL-Injektionsangriffe normalerweise verwendet, um nicht autorisierte Informationen zu erhalten.
  • Cross-Site-Skripting-Angriffe. Verwenden eines Skripts, das in einer XML-basierten Anwendung enthalten ist, um gegen die Richtlinie des gleichen Ursprungs zu verstoßen, wodurch kein Skript Eigenschaften aus einer anderen Anwendung abrufen oder ändern kann. Da Skripts Informationen abrufen und Dateien mithilfe Ihrer XML-Anwendung ändern können, kann es einem Angreifer ermöglichen, nicht autorisierte Informationen zu erhalten, die Anwendung zu gefährden, oder beides zu gefährden.

Bekannte Webangriffe können in der Regel durch Filtern des Website-Datenverkehrs nach bestimmten Merkmalen (Signaturen) gestoppt werden, die immer für einen bestimmten Angriff erscheinen und niemals im legitimen Datenverkehr erscheinen sollten. Dieser Ansatz hat die Vorteile, dass relativ wenige Ressourcen benötigt werden und ein relativ geringes Risiko von False-Positives darstellt. Es ist daher ein wertvolles Werkzeug zur Bekämpfung von Angriffen auf Websites und Web-Services, und die Konfiguration grundlegender Signaturschutzmaßnahmen, die die meisten bekannten Web-Angriffe abfangen, ist einfach zu tun.

Unbekannte Webangriffe

Die größte Bedrohung für Websites und Anwendungen ist nicht von bekannten Angriffen, sondern von unbekannten Angriffen. Die meisten unbekannten Angriffe fallen in eine von zwei Kategorien: neu gestartete Angriffe, für die Sicherheitsfirmen noch keine wirksame Verteidigung entwickelt haben (Zero-Day-Angriffe), und sorgfältig gezielte Angriffe auf eine bestimmte Website oder einen Webdienst statt auf viele Websites oder Webdienste (Spear-Attacken). Diese Angriffe, wie bekannte Angriffe, sind in der Regel dazu gedacht, vertrauliche private Informationen zu erhalten, die Website oder den Webdienst zu gefährden und ermöglichen es, sie für weitere Angriffe oder beide Ziele verwendet werden.

Zero-Day-Angriffe stellen eine große Bedrohung für alle Benutzer dar. Diese Angriffe sind in der Regel von den gleichen Arten wie bekannte Angriffe; Zero-Day-Angriffe beinhalten oft injizierte SQL, ein siteübergreifendes Skript, eine siteübergreifende Anforderungsfälschung oder eine andere Art von Angriff ähnlich wie bekannte Angriffe. In den meisten Fällen zielen sie auf Schwachstellen ab, von denen die Entwickler der angestrebten Software, der Website oder des Webdienstes entweder nicht wissen oder von denen sie gerade erfahren haben. Sicherheitsfirmen haben daher normalerweise keine Abwehrmaßnahmen gegen diese Angriffe entwickelt, und selbst wenn sie dies getan haben, haben Benutzer die Patches normalerweise nicht erhalten und installiert oder die zum Schutz vor diesen Angriffen erforderlichen Problemumgehungen durchgeführt. Die Zeit zwischen der Entdeckung eines Zero-Day-Angriffs und der Verfügbarkeit einer Verteidigung (das Schwachstellenfenster) schrumpft, aber Täter können immer noch auf Stunden oder sogar Tage zählen, an denen viele Websites und Webdienste keinen spezifischen Schutz vor dem Angriff haben.

Spear-Angriffe sind eine große Bedrohung, aber für eine ausgewählte Gruppe von Benutzern. Eine übliche Art von Spear-Angriff, ein Spear Phish, richtet sich in der Regel an Kunden einer bestimmten Bank oder eines Finanzinstituts oder (seltener) an Mitarbeiter eines bestimmten Unternehmens oder einer bestimmten Organisation. Im Gegensatz zu anderen Phishes, bei denen es sich oft um grobe Fälschungen handelt, die ein Benutzer mit irgendeiner Vertrautheit mit der tatsächlichen Kommunikation dieser Bank oder Finanzinstitution erkennen kann, sind Spear Phishes buchstabenperfekt und überzeugend. Sie können spezifische Informationen für das Individuum enthalten, die auf den ersten Blick kein Fremder wissen oder in der Lage sein sollte. Der Speer-Phisher ist daher in der Lage, sein Ziel davon zu überzeugen, die angeforderten Informationen bereitzustellen, die der Phisher dann verwenden kann, um Konten zu plündern, unrechtmäßig erhaltenes Geld aus anderen Quellen zu verarbeiten oder Zugang zu anderen, noch sensibleren Informationen zu erhalten.

Beide Arten von Angriffen haben bestimmte Merkmale, die normalerweise erkannt werden können, wenn auch nicht mit statischen Mustern, die nach bestimmten Merkmalen suchen, wie Standardsignaturen. Die Erkennung dieser Arten von Angriffen erfordert anspruchsvollere und ressourcenintensivere Ansätze, wie heuristische Filterung und positive Sicherheitsmodellsysteme. Heuristische Filterung sieht nicht für bestimmte Muster, sondern für Verhaltensmuster aus. Positive Sicherheitsmodellsysteme modellieren das normale Verhalten der Website oder des Webdienstes, den sie schützen, und blockieren dann Verbindungen, die nicht in dieses Modell der normalen Verwendung passen. URL-basierte und webformularbasierte Sicherheitsprüfungen profilieren die normale Verwendung Ihrer Websites und steuern dann, wie Benutzer mit Ihren Websites interagieren, wobei sowohl Heuristik als auch positive Sicherheit verwendet werden, um anomalen oder unerwarteten Datenverkehr zu blockieren. Sowohl heuristische als auch positive Sicherheit, die ordnungsgemäß entworfen und bereitgestellt werden, können die meisten Angriffe erfassen, die Signaturen verpassen. Sie benötigen jedoch wesentlich mehr Ressourcen als Signaturen, und Sie müssen einige Zeit damit verbringen, sie richtig zu konfigurieren, um Fehlalarme zu vermeiden. Sie werden daher in der Regel nicht als primäre Verteidigungslinie verwendet, sondern als Backups für Signaturen oder andere weniger ressourcenintensive Ansätze.

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

Funktionsweise der Citrix Web Application 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 erlaubt oder blockiert werden sollen, wenn der Datenverkehr 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, die einer bekannten Art von Angriff 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. Citrix aktualisiert die Liste mit neuen Signaturen, wenn neue Bedrohungen erkannt werden. Während der Konfiguration geben Sie die Signaturkategorien an, die für die zu schützenden Webserver und Inhalte geeignet sind. Signaturen bieten einen guten Grundschutz bei geringem Verarbeitungsaufwand. Wenn Ihre Anwendungen spezielle Schwachstellen aufweisen oder Sie einen Angriff gegen sie erkennen, für den keine Signatur vorhanden ist, können Sie eigene Signaturen hinzufügen.

Die fortgeschrittenen Schutzmaßnahmen werden als Sicherheitsprüfungen bezeichnet. Eine Sicherheitsprüfung ist eine strengere, algorithmische Überprüfung einer Anfrage nach bestimmten Mustern oder Verhaltenstypen, die auf einen Angriff hinweisen oder eine Bedrohung für Ihre geschützten Websites und Webdienste darstellen könnten. Sie kann beispielsweise eine Anforderung identifizieren, die versucht, eine bestimmte Art von Vorgang auszuführen, die die Sicherheit verletzen könnte, oder eine Antwort, die vertrauliche private Informationen wie eine Sozialversicherungsnummer oder 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 Sicherheitsprüfungen sind restriktiv. Viele von ihnen können legitime Anfragen und Antworten blockieren, wenn Sie bei der Konfiguration keine entsprechenden Ausnahmen (Relaxationen) 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. Er muss an einem Ort installiert sein, an dem er den Datenverkehr zwischen den zu schützenden Webservern und dem Hub abfangen kann oder über den Benutzer auf diese Webserver zugreifen kann. Anschließend konfigurieren Sie das Netzwerk so, dass Anforderungen an die Web App Firewall anstatt direkt an Ihre Webserver gesendet werden, und Antworten auf die Web App Firewall statt direkt an Ihre Benutzer. Die Web App Firewall filtert diesen Datenverkehr, bevor er an das endgültige Ziel weiterleitet. Dabei wird sowohl der interne Regelsatz als auch die 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 Filterprozess.

Hinweis:

Die Abbildung lässt die Anwendung einer Richtlinie auf eingehenden Datenverkehr auslassen. 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

Flussdiagramm für Web App Firewall

Wie die Abbildung zeigt, überprüft die Web App Firewall, wenn ein Benutzer eine URL auf einer geschützten Website anfordert, zuerst die Anforderung, um sicherzustellen, dass sie nicht mit einer Signatur übereinstimmt. Wenn die Anforderung mit einer Signatur übereinstimmt, zeigt die Citrix Web Application Firewall entweder das Fehlerobjekt an (eine Webseite, die sich auf der Web App Firewall Appliance befindet und 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. Das Erkennen und Beenden von Angriffen, die von einer Signatur erkannt werden, bevor eine der Sicherheitsprüfungen ausgeführt wird, verringert die Belastung des Servers.

Wenn eine Anforderung die Signaturprüfung bestanden hat, wendet die Web App Firewall die aktivierten Anforderungssicherheitsprüfungen an. Die Anforderungssicherheitsprüfungen stellen sicher, dass die Anforderung für Ihre Website oder Ihren Webdienst 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 fehlschlägt, bereinigt die Web App Firewall die Anforderung entweder und sendet sie dann an die Citrix ADC Appliance (oder die virtuelle Citrix ADC-Appliance) oder zeigt das Fehlerobjekt an. Wenn die Anforderung die Sicherheitsprüfungen bestanden hat, wird sie an die Citrix ADC 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 Überprüfungen der Antwortsicherheit wird die Reaktion auf Lecks vertraulicher Daten, Anzeichen einer Verflechtung von Websites oder andere Inhalte untersucht, die nicht vorhanden sein sollten. Wenn die Antwort eine Sicherheitsprüfung fehlschlägt, entfernt die Web App Firewall entweder den Inhalt, der nicht vorhanden sein sollte, oder blockiert die Antwort. Wenn die Antwort die Sicherheitsprüfungen bestanden hat, wird sie an die Citrix ADC Appliance zurückgesendet, die sie an den Benutzer weiterleitet.

Citrix Web Application Firewall-Funktionen

Die grundlegenden Funktionen der Web App Firewall sind Richtlinien, Profile und Signaturen, die ein hybrides Sicherheitsmodell bereitstellenBekannte Web-Angriffe/de-de/citrix-adc/13/application-firewall/introduction/web-application-security.html[()],Unbekannte Webangriffe[]wie unter, /de-de/citrix-adc/13/application-firewall/introduction/web-application-security.html()undFunktionsweise der Web App Firewall/de-de/citrix-adc/13/application-firewall/introduction/how-application-firewall-works.html[()]. 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 Sicherheitsprüfung entspricht.

Sie können die Protokolle, Statistiken und Berichte verwenden, um die Leistung der Web App Firewall auszuwerten und mögliche Anforderungen für zusätzlichen Schutz zu ermitteln.

Ändern des Anwendungsdatenverkehrs durch Citrix Web Application Firewall

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

  • Cookies
  • HTTP-Header
  • Formulare/Daten

Citrix Web Application Firewall-Sitzungscookie

Um den Status der Sitzung beizubehalten, 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 übergeben. Wenn ein Hacker versucht, das Sitzungscookie zu ändern, löscht die Application Firewall das Cookie, bevor die Anforderung an den Server weitergeleitet wird und behandelt die Anforderung als eine neue Benutzersitzung. Das Session-Cookie ist vorhanden, solange der Webbrowser geöffnet ist. Wenn der Webbrowser geschlossen wird, wird das Sitzungscookie der Application Firewall länger gültig.

Das konfigurierbare Web App Firewall -Sitzungscookie lautet citrix_ns_id.

Citrix Web App Firewall Cookies

Viele Webanwendungen generieren Cookies, um benutzer- oder sitzungsspezifische Informationen zu verfolgen. Bei diesen Informationen kann es sich um Benutzereinstellungen oder um Artikel im Warenkorb handeln. Ein Webanwendungs-Cookie kann einer der folgenden zwei Typen sein:

  • Permanente Cookies - Diese Cookies werden lokal auf dem Computer gespeichert und beim nächsten Besuch der Website wieder verwendet. Diese Art von Cookie enthält in der Regel Informationen über den Benutzer, wie Anmeldung, Kennwort oder Einstellungen.
  • Session oder Transient Cookies - Diese Cookies werden nur für die Dauer der Sitzung verwendet und werden nach Beendigung der Sitzung zerstört. Diese Art von Cookie enthält Informationen zum Anwendungsstatus, wie Einkaufswagenartikel oder Sitzungsdaten.

Hacker können versuchen, Anwendungscookies zu modifizieren oder zu stehlen, um eine Benutzersitzung zu entführen oder als Benutzer zu maskieren. Die Application Firewall verhindert solche Versuche, indem sie die Anwendungscookies hasht und anschließend zusätzliche 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 weder verändert noch gefährdet werden. Die Application Firewall ändert die Anwendungscookies nicht.

Die Citrix Web Application Firewall generiert die folgenden Standardcookies, um die Anwendungscookies zu verfolgen:

  • Permanente Cookies: citrix_ns_id_wlf. Hinweis: wlf steht für wird ewig leben.
  • Sitzungs- oder vorübergehende Cookies: citrix_ns_id_wat. Hinweis: wat steht für wird vorübergehend handeln. Um die Anwendungscookies zu verfolgen, gruppiert die Application Firewall die persistenten oder Session-Anwendungs-Cookies zusammen und hash und signiert dann alle Cookies zusammen. Daher generiert die Application Firewall ein wlf Cookie, um alle persistenten Anwendungscookies zu verfolgen, und ein wat Cookie, um alle Anwendungssitzungscookies zu verfolgen.

Die Web App Firewall generiert immer ein Application Firewall-Sitzungscookie, unabhängig davon, ob die Webanwendung Cookies generiert.

Die folgende Tabelle zeigt die Anzahl und Typen der Cookies, die von der Application Firewall basierend auf den von der Webanwendung generierten Cookies generiert werden:

Vor der Citrix ADC Web App Firewall Bis
Keine Cookies Sitzungscookie: citrix_ns_id
Ein persistenter Cookie Sitzungscookie: citrix_ns_id
Zwei persistente Cookies Zwei ursprüngliche persistente Cookie aus dem Application.Session-Cookie: citrix_ns_id, Persistentes Cookie: citrix_ns_id_wlf
Ein persistenter Cookie, ein vorübergehender Cookie Ein ursprüngliches persistentes Cookie aus der Anwendung. Ein Original-Session-Cookie aus der Anwendung. Sitzungscookie: citrix_ns_id, Persistentes Cookie: citrix_ns_id_wlf, Transientes Cookie: citix_ns_id_wat

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

Wie sich die Anwendungsfirewall auf HTTP-Header auswirkt

Sowohl HTTP (s) -Anfragen als auch HTTP (s) -Antworten verwenden Header, um Informationen über die HTTP (s) -Nachricht zu senden. Ein Header ist eine Reihe von Zeilen, wobei jede Zeile einen Namen enthält, gefolgt von einem Doppelpunkt, einem Leerzeichen und einem Wert. Beispielsweise hat der Host-Header das folgende Format:

Host: www.citrix.com

Einige Header-Felder werden sowohl in Anforderungs- als auch in Antwort-Headern verwendet, während andere nur für eine Anforderung oder eine Antwort geeignet sind. Die Anwendungsfirewall kann einige Header in der HTTP-Anforderung oder -Antwort hinzufügen, ändern oder löschen, um die Sicherheit der Anwendung aufrechtzuerhalten.

Anforderungsheader, die von der Citrix Web Application Firewall gelöscht wurden

Viele der Anforderungsheader im Zusammenhang mit dem Caching werden möglicherweise von der Application Firewall gelöscht, um jede Anforderung im Kontext einer Sitzung anzuzeigen. Wenn die Anforderung einen Codierungs-Header enthält, um dem Webserver das Senden komprimierter Antworten zu ermöglichen, löscht die Application Firewall diesen Header, sodass der Inhalt in der unkomprimierten Serverantwort von Application Firewall überprüft werden kann, um ein Austreten vertraulicher Daten an den Client zu verhindern.

Die Anwendungsfirewall löscht die folgenden Anforderungsheader:

  • Bereich — Wird zum Wiederherstellen von fehlgeschlagenen oder teilweisen Dateiübertragungen verwendet.
  • If-Range — Ermöglicht es einem Client, ein partielles Objekt abzurufen, wenn es bereits einen Teil dieses Objekts in seinem Cache enthält (bedingtes GET).
  • If-Modified-Since — Wenn das angeforderte Objekt seit der in diesem Feld angegebenen Zeit nicht geändert wird, wird keine Entität vom Server zurückgegeben. Sie erhalten einen HTTP 304 nicht modifizierten Fehler.
  • If-None-Match — Ermöglicht effiziente Aktualisierungen zwischengespeicherter Informationen mit einem minimalen Overhead.
  • Accept-Encoding — Welche Codierungsmethoden sind für ein bestimmtes Objekt erlaubt, wie gzip.

Anforderungsheader, geändert von der Citrix Web Application Firewall

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

Anforderungskopfzeilen, die von der Citrix Web Application Firewall hinzugefügt wurden

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 Anforderungen, die im Webserverprotokoll protokolliert werden, darauf hin, dass die Anforderungen von der Application Firewall gesendet werden.

Antwort-Header, der von der Citrix Web Application Firewall gelöscht wurde

Die Anwendungsfirewall blockiert oder ändert möglicherweise Inhalte wie das Entfernen von Kreditkartennummern oder das Entfernen von Kommentaren. Dies kann zu einer Abweichung in der Größe führen. Um ein solches Szenario zu verhindern, löscht die Anwendungsfirewall den folgenden Header:

Content-Length — Gibt die Größe der an den Empfänger gesendeten Nachricht an. Von der Anwendungsfirewall geänderte Antwort-Header

Viele der Antwort-Header, die von der Application Firewall geändert wurden, beziehen sich auf das Zwischenspeichern. Caching-Header in HTTP (S) -Antworten müssen geändert werden, um zu zwingen, dass der Webbrowser immer eine Anforderung an den Webserver für die neuesten Daten sendet und nicht den lokalen Cache verwendet. 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 temporäres Zwischenspeichern von Daten zu ermöglichen, wenn Advanced Security-Schutzmaßnahmen wie FFC, URL-Schließung oder CSRF-Prüfungen aktiviert sind, fügt Application Firewall die Cache-Control-Header in der Serverantwort hinzu oder ändert sie mithilfe der folgenden Logik:

  • Wenn Server Pragma:No-Cache sendet, nimmt die Application 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 Client Request HTTP 1.1 ist und Server Response Cache-Control-Header ohne Store oder keine Cache-Direktive hat, nimmt Application Firewall keine Änderungen vor.

  • Wenn Client Request HTTP 1.1 ist und Server Response entweder No Cache-Control-Header oder 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, privat.
  2. Fügt X-Cache-Control-orig = Ursprünglicher Wert von Cache-Control Header ein.
  3. Löscht zuletzt geänderte Kopfzeile.
  4. Ersetzt Etag.
  5. Fügt X-Expires-Orig=Ursprünglicher Wert des vom Server gesendeten Expire-Headers ein.
  6. Ändert den Expires Header und legt das Ablaufdatum der Webseite auf die Vergangenheit fest, so dass es immer wieder aufgenommen wird.
  7. Ändert Akzept-Bereiche und setzt sie auf keine.

Um vorübergehend zwischengespeicherte Daten im Clientbrowser zu ersetzen, wenn Application Firewall die Antwort ändert, z. B. für StripComments, X-out/Remove SafeObject, xout oder Entfernen von Kreditkarten- oder URL-Transformation, führt die Application Firewall die folgenden Aktionen aus:

  1. Löscht die letzte Änderung vom Server, bevor sie an den Client weitergeleitet wird.
  2. Ersetzt Etag durch einen Wert, der von der Application Firewall bestimmt wird.

Von der Citrix Web App Firewall hinzugefügte Antwortkopfzeilen

  • Transfer-Encoding: Chunked. Dieser Header streamt Informationen an einen Client zurück, ohne die Gesamtlänge der Antwort kennen zu müssen, bevor die Antwort gesendet wird. Dieser Header ist erforderlich, da der Content-length Header entfernt wird.
  • Set-Cookie: Die von der Application Firewall hinzugefügten Cookies.
  • Xet-Cookie: Wenn die Sitzung gültig ist und die Antwort nicht im Cache abgelaufen ist, können Sie aus dem Cache bedienen 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 ähnelt Xet-Cookie jedem anderen benutzerdefinierten Header.

Wie Formulardaten betroffen sind

Die Application Firewall schützt vor Angriffen, bei denen versucht wird, den Inhalt des ursprünglichen Formulars zu ändern, das vom Server gesendet wurde. Es kann auch vor Cross-Site-Request-Fälschungsangriffen schützen. Die Application Firewall erreicht dies, indem das ausgeblendete Formular-Tag as_fid in die Seite eingefügt wird.

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

Das ausgeblendete Feld as_fid wird für die Feldkonsistenz verwendet. Dieses Feld wird von Application Firewall verwendet, um alle Felder des Formulars einschließlich der verborgenen Feldname/Wert-Paare zu verfolgen und sicherzustellen, dass keines der Felder des Formulars, das vom Server gesendet wird, 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 entführen.

Sitzungslose Formularprüfung

Application Firewall bietet außerdem eine Option zum Schutz von Formulardaten mit sitzungsloser Feldkonsistenz. Dies ist nützlich für Anwendungen, bei denen Formulare eine große Anzahl dynamischer ausgeblendeter Felder aufweisen können, die zu einer hohen Speicherzuweisung pro Sitzung durch die Anwendungsfirewall führen. Die Sitzungslose Feldkonsistenzprüfung wird durchgeführt, indem ein anderes ausgeblendetes Feld as_ffc_field nur für POST-Anfragen oder für GET- und POST-Anforderungen basierend auf der konfigurierten Einstellung eingefügt wird. 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 gesendeten Formulars enthält. Im Folgenden finden Sie 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==" />

HTML-Kommentarentfernung

Die Application Firewall bietet außerdem 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 sucht und entfernt jeden Text, der zwischen “<!-“ und “->” Kommentar-Tags. Die Tags zeigen weiterhin an, dass an diesem Speicherort 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 korrekt, wenn JavaScript falsch in Kommentar-Tags eingebettet ist. Ein Vergleich des Seitenquellcodes vor und nachdem die Kommentare von Application Firewall entfernt wurden, kann bei der Identifizierung helfen, ob in einem der gestrippten Kommentare das erforderliche JavaScript eingebettet wurde.

Kreditkartenschutz

Die Application Firewall bietet eine Option, die Kopfzeilen sowie den Hauptteil der Antwort zu überprüfen und entweder die Kreditkartennummern zu entfernen oder zu x-out, 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 das Auslaufen anderer sensibler Daten verhindert werden, indem die Sicherheitsüberprüfung von Application Firewall für sicheres Objekt verwendet wird, um die sensiblen Inhalte in der Antwort zu entfernen oder zu löschen.

XSS-Transformationsaktion

Wenn die Transformation für XSS aktiviert ist, ändert sich die Anwendungsfirewall "<" into "%26lt;" and ">" into "%26gt;" in den Anforderungen. Wenn die Einstellung CheckRequestHeaders in Application Firewall aktiviert ist, überprüft die Application 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 XSS, die von der Application Firewall zugelassen sind. Eine Standardliste von verweigerten XSS-Mustern wird ebenfalls bereitgestellt. Diese können angepasst werden, indem Sie das Signaturenobjekt auswählen und auf den Dialog SQL/XSS-Muster verwalten in der grafischen Benutzeroberfläche klicken.

Transformieren von SQL-Sonderzeichen

Application Firewall verfügt über die folgenden Standard-Transformationsregeln für SQL-Sonderzeichen:

Unter Bis Transformation
‘(einfaches Anführungszeichen, das heißt, %27) Ein weiteres einfaches Zitat
\ (umgekehrter Schrägstrich, der ist%5C) |Ein weiterer umgekehrter Schrägstrich hinzugefügt  
; (Semikolon, das ist%3B)   - Abgefallen

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

Cirix Web Application Firewall Verhalten, bei dem es den Expect Header beschädigt

  1. Immer wenn NetScaler HTTP-Anforderung mit dem Expect Header empfängt, sendet NetScaler die Antwort “Expect: 100 -continue” an den Client im Auftrag des Back-End-Servers.
  2. Dieses Verhalten liegt daran, dass Application Firewall-Schutzmaßnahmen für die gesamte Anforderung ausgeführt werden müssen, bevor die Anforderung an den Server weitergeleitet wird. NetScaler muss die gesamte Anforderung vom Client abrufen.
  3. Beim Empfang der Antwort 100 -continue sendet der Client den verbleibenden Teil der Anforderung, der die Anforderung abschließt.
  4. NetScaler führt dann alle Schutzmaßnahmen aus und leitet die Anforderung dann an den Server weiter.
  5. Jetzt, da NetScaler den kompletten Request Expect Header weiterleitet, der in der ersten Anfrage kam, wird veraltet, da NetScaler diesen Header beschädigt und an den Server sendet.
  6. Server beim Empfang der Anforderung ignoriert alle Header, die beschädigt sind.

Einführung in die Citrix Web Application Firewall