Einführung in die Citrix Web Application Firewall

死Citrix Web应用防火墙verhindert Sicherheitsverletzungen, Datenverlust und mögliche unbefugte Änderungen an Websites, die auf sensible Geschäfts- oder Kundeninformationen zugreifen. Dies geschieht, indem sowohl Anfragen als auch Antworten gefiltert, sie auf Beweise für böswillige Aktivitäten untersucht und Anfragen 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. Neben dem Schutz von Webservern und Websites vor unbefugtem Zugriff schützt die Web App Firewall vor Schwachstellen in Legacy-CGI-Code oder -Skripten, Webframeworks, 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, 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. Manchmal reicht eine einzige Konfiguration aus. In anderen Fällen, insbesondere in solchen, in denen interaktive Websites, Websites, die auf Datenbankserver zugreifen, Online-Shops mit Einkaufswagen, benötigen Sie möglicherweise mehrere verschiedene Konfigurationen, um sensible 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 weites Gebiet, in dem es viele Sicherheitslücken und Schwächen gibt. Betriebssysteme auf Servern und Clients haben Sicherheitsprobleme und sind anfällig für Angriffe. Webserver-Software und Website-Endering-Technologien wie CGI, Java, JavaScript, PERL und PHP weisen zugrunde liegende Schwachstellen auf. Browser und andere Clientanwendungen, die mit webfähigen Anwendungen kommunizieren, weisen ebenfalls Schwachstellen auf. Websites, die eine beliebige Technologie verwenden, jedoch die einfachste HTML, einschließlich aller Websites, die die Interaktion mit Besuchern ermöglicht, weisen häufig eigene Schwachstellen auf.

In der Vergangenheit war eine Sicherheitsverletzung oft nur ein Ärger, aber heute ist das selten der Fall. Zum Beispiel waren Angriffe, bei denen ein Hacker Zugriff auf einen Webserver erhielt und unbefugte Änderungen an einer Website vorgenommen (unkennbar) machte, üblich. 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 und die Kontrolle über eine Website oder einen Webserver zu erhalten.

Bestimmte Formen von Web-Attacken konzentrieren sich auf die Beschaffung privater Informationen. Diese Angriffe sind oft sogar gegen Websites möglich, die sicher genug sind, um einen Angreifer daran zu hindern, die volle Kontrolle zu übernehmen. Zu den 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 Verstoß dieser Art kann schwerwiegende Folgen für Kunden haben, deren private Informationen gefährdet sind. Im besten Fall müssen diese Kunden wachsam sein, um zu verhindern, dass andere ihre Kreditkarten missbrauchen, nicht autorisierte Kreditkonten in ihrem Namen eröffnen oder ihre Identität direkt aneignen (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 eineWebsite oderden Server, auf dem sie arbeitet, oder beides zu erlangen. Ein Hacker, der die Kontrolle über eine Website oder einen Server erlangt, kann damit nicht autorisierte Inhalte hosten, als Proxy für Inhalte fungieren, die auf einem anderen Webserver gehostet werden, SMTP-Dienste bereitstellen, um unerwünschte Massen-E-Mails zu senden, oder DNS-Dienste zur Unterstützung solcher Aktivitäten auf anderen kompromittierten Webservern bereitstellen. Die meisten Websites, die auf kompromittierten Webservern gehostet werden, fördern fragwürdige oder direkt 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 Verteidigung, die sowohl bekannte Angriffe mit identifizierbaren Merkmalen blockieren als auch vor unbekannten Angriffen schützen kann, die häufig erkannt werden können, da sie sich vom normalen Datenverkehr zu Ihren Websites und Ihrem Web unterscheiden -Dienstleistungen.

Bekannte Webangriffe

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

• Pufferüberlaufangriffe.Das Senden einer langen URL, eines langen Cookies oder langer Informationen an einen Webserver führt dazu, dass das System hängen bleibt, abstürzt oder unbefugten Zugriff auf das zugrunde liegende Betriebssystem bietet. 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 zu den URLs mit Hyperlinks auf der Startseite oder anderen allgemeinen Start-URLs auf der Website zu navigieren. Einzelne Fälle von kraftvollem Surfen können auf einen Benutzer hinweisen, der eine Seite auf Ihrer Website mit einem Lesezeichen versehen hat, aber wiederholte Versuche, auf nicht vorhandene Inhalte oder Inhalte zuzugreifen, auf die Benutzer niemals direkt zugreifen dürfen, stellen häufig einen Angriff auf die Website-Sicherheit 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 Sie unangemessene Inhalte in einem Webformular an Ihre Website. Unangemessene Inhalte können modifizierte ausgeblendete Felder, HTML oder Code in einem Feld enthalten, 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 ganze Zahl akzeptiert, und eine Vielzahl anderer Daten, die Ihre Website nicht akzeptiert erwarte, in diesem Webformular zu erhalten. Ein Sicherheitsangriff auf ein Web-Formular kann entweder verwendet werden, um nicht autorisierte 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 aktiven SQL-Befehls oder von Befehlen 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-Skripting-Angriffe.Verwenden einer URL oder eines Skripts auf einer Webseite, um gegen die Richtlinie für denselben Ursprung zu verstoßen, die es jedem Skript verbietet, Eigenschaften von einer anderen Website zu erhalten oder 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 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 von Befehlen in einer XML-basierten Anforderung, mit dem Ziel, dass eine SQL-Datenbank diesen Befehl oder diese Befehle ausführt. Wie bei HTML-SQL-Injectionsangriffen werden XML-SQL-Injectionsangriffe 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 normalerweise 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 erscheinen dürfen. Dieser Ansatz hat die Vorteile, dass relativ wenige Ressourcen benötigt werden und ein relativ geringes Risiko von False-Positives darstellt. Daher ist es ein wertvolles Werkzeug 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 ist nicht durch bekannte Angriffe, sondern durch unbekannte Angriffe. Die meisten unbekannten Angriffe fallen in eine von zwei Kategorien: neu eingeleitete Angriffe, für die Sicherheitsfirmen noch keine effektive Verteidigung entwickelt haben (Zero-Day-Angriffe), und sorgfältig gezielte Angriffe auf eine bestimmte Website oder einen Webdienst und nicht auf viele Websites oder Webdienste (Speerangriffe). Diese Angriffe, wie bekannte Angriffe, sollen sensible private Informationen erhalten, die Website oder den Webservice gefährden und die Verwendung für weitere Angriffe oder beide dieser Ziele ermöglichen.

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 der Regel zielen sie auf Schwachstellen ab, die den Entwicklern der Zielsoftware, der Website oder des Webdienstes entweder nicht bewusst sind oder von denen sie erfahren haben. Sicherheitsfirmen haben daher keine Abwehrmaßnahmen gegen diese Angriffe entwickelt, und selbst wenn dies der Fall ist, haben Benutzer die Patches 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 (dem Schwachstellenfenster) schrumpft, aber die Täter können immer noch auf Stunden oder sogar Tage zählen, in 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 Speerangriff, ein Spear-Phishes, richtet sich 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 grob geschriebene Fälschungen handelt, die ein Benutzer, der mit der tatsächlichen Kommunikation dieser Bank oder dieses Finanzinstituts vertraut ist, erkennen kann, sind Speerphishes perfekt und überzeugend. Sie können spezifische Informationen enthalten, die für den Einzelnen spezifisch sind, die auf den ersten Blick kein Fremder wissen oder erhalten darf. Der Speer-Phisher ist daher in der Lage, das Ziel davon zu überzeugen, die angeforderten Informationen bereitzustellen, die der Phisher dann verwenden kann, um 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 erfassen die normale Nutzung 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 nicht als primäre Verteidigungslinie verwendet, sondern als Backups von Signaturen oder anderen weniger ressourcenintensiven Ansätzen.

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.

明信片Signatur这Zeichenfolge奥得河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 Sicherheitsüberprüfung ist eine strengere, algorithmischere Prüfung einer Anfrage nach bestimmten Mustern oder Verhaltensweisen, 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 Funktion zum adaptiven Lernen verwenden, die die normale Nutzung Ihrer Website beobachtet und empfohlene Ausnahmen schafft.

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

Wie die Abbildung zeigt, prüft die Web App Firewall, wenn ein Benutzer eine URL auf einer geschützten Website anfordert, zuerst die Anfrage, 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 Anfrage 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 Anfrage 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 Reaktionssicherheitsprüfungen an. Die Reaktionssicherheitsprüfungen untersuchen die Reaktion auf Lecks sensibler privater Informationen, Anzeichen für eine Website-Verunstaltung oder andere Inhalte, 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 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 bereitstellen, wie unterBekannte Webangriffe,Unbekannte WebangriffeundFunktionsweise der Web App Firewallbeschrieben。感兴趣hervorzuheben是维ie 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 Funktionen für Protokolle, Statistiken und Berichte verwenden, um die Leistung der Web App Firewall zu bewerten und mögliche Anforderungen an mehr Schutz zu ermitteln.

Ändern des Anwendungsdatenverkehrs durch Citrix Web Application Firewall

死Citrix Web应用程序防火墙wirkt西奇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. Der Status der Sitzung verwaltet die Informationen der vom Kunden besuchten URLs und Formulare.

Das konfigurierbare Web App Firewall -Sitzungscookie lautetcitrix_ns_id.

Ab Citrix ADC Build 12.1 54 und 13.0 ist die Cookie-Konsistenz sitzungslos und erzwingt nicht das Hinzufügen von Sitzungscookie, das von der Appliancecitrix_ns_idgeneriert wird.

Citrix Web App Firewall Cookies

有Webanwendungen generieren饼干,嗯benutzer- oder sitzungsspezifische Informationen zu verfolgen. Diese Informationen können Benutzerpräferenzen oder Warenkorbelemente sein. 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.
• Sitzungs- 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, 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 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 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 einwlfCookie, um alle persistenten Anwendungscookies zu verfolgen, und einwatCookie, um alle Anwendungssitzungscookies zu verfolgen.

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:

Citrix Web应用防火墙ermoglicht Verschlusse死去lung 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 HTTPS-Anfragen als auch HTTPS-Antworten verwenden Header, um Informationen über eine oder mehrere Nachrichten von HPS 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: m.giftsix.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 Application Firewall 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.

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

Viele der Anforderungsheader, die sich auf das Caching beziehen, werden gelöscht, um jede Anfrage im Kontext einer Sitzung anzuzeigen. Wenn die Anforderung einen Codierungsheader enthält, der es dem Webserver ermöglicht, komprimierte Antworten zu senden, löscht die Application Firewall diesen Header, sodass der Inhalt der Antwort auf dem unkomprimierten Server von der Web App Firewall überprüft wird, um ein Auslaufen 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.
• 具有——Ermoglicht 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, dass die Verbindung während der Sitzung geöffnet bleibt. 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 zeigen alle Anfragen, die im Webserverprotokoll protokolliert wurden, an, 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 Application Firewall 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, führt die Application Firewall keine Änderung durch.
• Wenn die Clientanfrage HTTP 1.0 ist, fügt die 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, sodass sie 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 Credit Card oder URL Transform, führt Application Firewall die folgenden Aktionen durch:

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 dienen 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 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 durch das Einfügen des versteckten Formular-Tags al_fid in die Seite.

Beispiel:

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:

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 “” 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, um die Header und den Hauptteil der Antwort zu überprüfen und die Kreditkartennummern entweder zu entfernen oder zu entfernen, 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.

Siteübergreifendes Skripting transformiert Aktion

Wenn die Transformation für Cross-Site-Scripting aktiviert ist, ändert sich die Web App Firewall"<" into "%26lt;" and ">" into "%26gt;"in den Anfragen. Wenn die Einstellung “CheckRequestHeaders” in der Web App Firewall aktiviert ist, überprüft die Web App Firewall die Request-Header und transformiert diese Zeichen auch in Header und Cookies. 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 der verweigerten Cross-Site-Scripting-Muster wird ebenfalls bereitgestellt. Diese können angepasst werden, indem Sie das Signaturobjekt auswählen und auf denDialog SQL/Cross-Site Scripting Patterns verwaltenin der GUI klicken.

Transformieren von SQL-Sonderzeichen

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

要是死转换冯Sonderzeichen aktiviert ist und die checkRequestheAdern 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 Inspect Header beschädigt wird

1. Immer wenn NetScaler eine HTTP-Anfrage mit dem Expect-Header erhält, sendet NetScaler die Antwort expect: 100 -continue an den Client im Namen des Backend-Servers.
2. Dieses Verhalten liegt daran, dass der Schutz der Application Firewall 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 einer100 continueAntwort sendet der Kunde den verbleibenden Teil der Anfrage, der die Anfrage abschließt.
4. NetScaler führt dann alle Schutzmaßnahmen aus und leitet die Anforderung dann an den Server weiter.
5. Jetzt, da NetScaler die vollständige Anfrage weiterleitet, wird der expect -Header, der in der ersten Anfrage enthalten ist, 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.