URL-Prüfung starten
Die Start-URL-Prüfung untersucht die URLs in eingehenden Anfragen und blockiert den Verbindungsversuch, wenn die URL die angegebenen Kriterien nicht erfüllt. Um die Kriterien zu erfüllen, muss die URL mit einem Eintrag in der Liste Start-URL übereinstimmen, es sei denn, der Parameter URL-Schließung erzwingen ist aktiviert. Wenn Sie diesen Parameter aktivieren, wird ein Benutzer, der auf einen Link auf Ihrer Website klickt, mit dem Ziel dieses Links verbunden.
Der Hauptzweck der Start-URL-Überprüfung besteht darin, wiederholte Versuche zu verhindern, auf zufällige URLs auf einer Website zuzugreifen (erzwungenes Surfen) durch Lesezeichen, externe Links oder das Springen zu Seiten, indem die URLs manuell eingegeben werden, um die Seiten zu überspringen, die für den Zugriff auf diesen Teil der Website erforderlich sind. Forceful Browsing kann verwendet werden, um einen Pufferüberlauf auszulösen, Inhalte zu finden, auf die Benutzer nicht direkt zugreifen sollten, oder eine Hintertür zu sicheren Bereichen Ihres Webservers zu finden. Die Web App Firewall erzwingt den angegebenen Traversal- oder Logikpfad einer Website, indem sie nur den Zugriff auf die URLs zulässt, die als Start-URLs konfiguriert sind.
Wenn Sie den Assistenten oder die GUI verwenden, können Sie im Dialogfeld Start URL Check ändern auf der Registerkarte Allgemein Sperren, Protokollieren, Statistiken, Lernaktionen und die folgenden Parameter aktivieren oder deaktivieren:
- URL-Schließung erzwingen. Ermöglichen Sie Benutzern den Zugriff auf jede Webseite Ihrer Website, indem Sie auf einer beliebigen anderen Seite Ihrer Website auf einen Hyperlink klicken. Benutzer können zu jeder Seite Ihrer Website navigieren, die von der Startseite oder einer bestimmten Startseite aus erreicht werden kann, indem sie auf Hyperlinks klicken. Hinweis: Die URL-Schließfunktion ermöglicht das Anhängen und Senden einer beliebigen Abfragezeichenfolge an die Aktions-URL eines Webformulars, das mithilfe der HTTP GET-Methode eingereicht wurde. Wenn Ihre geschützten Websites Formulare für den Zugriff auf eine SQL-Datenbank verwenden, stellen Sie sicher, dass die SQL-Injection-Überprüfung aktiviert und ordnungsgemäß konfiguriert ist.
- Sitzungsloser URL-Abschluss. Aus Sicht des Kunden funktioniert diese Art der URL-Schließung genauso wie die standardmäßige, sitzungsabhängige URL-Schließung, verwendet jedoch ein in die URL eingebettetes Token anstelle eines Cookie, um die Aktivitäten des Benutzers zu verfolgen, was erheblich weniger Ressourcen verbraucht. Wenn sitzungslose URL-Schließung aktiviert ist, hängt die Web App Firewall ein as_url_id -Tag an alle URLs, die sich im URL-Abschluss befinden. Hinweis: Wenn Sie die Sitzungslose (Sitzungslose URL-Schließung) aktivieren, müssen Sie auch die reguläre URL-Schließung aktivieren (URL-Schließung erzwingen), da sonst die sitzungslose URL-Schließung nicht funktioniert.
-
Referer-Header validieren. Stellen Sie sicher, dass der Referer-Header in einer Anfrage enthalten ist, die Webformulardaten von Ihrer geschützten Website und nicht von einer anderen Website enthält. Diese Aktion stellt sicher, dass Ihre Website und kein Angreifer von außen die Quelle des Webformulars ist. Dies schützt vor Cross-Site Request Forgeries (CSRF), ohne dass Formular-Tagging erforderlich ist, was CPU-intensiver ist als Headerprüfungen. Die Web App Firewall kann den HTTP-Referer-Header auf eine der folgenden vier Arten verarbeiten, je nachdem, welche Option Sie in der Dropdownliste auswählen:
- Off— Der Referer-Header wird nicht validiert.
- If-Present— Validiert den Referer-Header, falls ein Referer-Header vorhanden ist. Wenn ein ungültiger Referer-Header gefunden wird, generiert die Anfrage eine Referer-Header-Verletzung. Wenn kein Referer-Header vorhanden ist, generiert die Anfrage keine Referer-Header-Verletzung. Diese Option ermöglicht es der Web App Firewall, eine Referer-Header-Validierung für Anfragen durchzuführen, die einen Referer-Header enthalten, aber keine Anfragen von Benutzern zu blockieren, deren Browser den Referer-Header nicht festlegen oder die Web-Proxys oder Filter verwenden, die diesen Header entfernen.
- Immer außer Start-URLs— Überprüfen Sie immer den Referer-Header. Wenn kein Referer-Header vorhanden ist und die angeforderte URL nicht von der StartURL-Relaxationsregel ausgenommen ist, generiert die Anfrage eine Referer-Header-Verletzung. Wenn der Referer-Header vorhanden, aber ungültig ist, generiert die Anfrage eine Referer-Header-Verletzung.
- Immer mit Ausnahme der ersten Anfrage— Überprüfen Sie immer den Referer-Header. Wenn kein Referer-Header vorhanden ist, ist nur die URL zulässig, auf die zuerst zugegriffen wird. Alle anderen URLs werden ohne gültigen Referer-Header blockiert. Wenn der Referer-Header vorhanden, aber ungültig ist, generiert die Anfrage eine Referer-Header-Verletzung.
Eine Start-URL-Einstellung, Closure URLs von Sicherheitsprüfungenausschließen, wird nicht im Dialogfeld Start URL Check ändern konfiguriert, sondern auf der Registerkarte Einstellungen des Profils konfiguriert. Wenn diese Einstellung aktiviert ist, weist die Web App Firewall darauf hin, keine weiteren formularbasierten Prüfungen (wie Cross-Site Scripting und SQL Injection-Prüfung) für URLs durchzuführen, die die URL-Schließungskriterien erfüllen.
Hinweis
Obwohl die Referer-Header-Überprüfung und die Start-URL-Sicherheitsprüfung dieselben Aktionseinstellungen verwenden, ist es möglich, die Referer-Header-Prüfung zu verletzen, ohne die Start-URL-Prüfung zu verletzen. Der Unterschied ist in den Protokollen sichtbar, in denen Verstöße gegen die Referer-Header-Prüfung getrennt von den Verstößen gegen die Start-URL-Prüfung protokolliert werden.
Die Referer-Header-Einstellungen (OFF, IF-Present, AlwaysExceptStartUrls und AlwaysExceptFirstRequest) sind in der Reihenfolge von am wenigsten restriktiv bis am restriktivsten angeordnet und funktionieren wie folgt:
OFF:
- Referer-Header Nicht geprüft.
Wenn vorhanden:
- Anfrage hat keinen Referer-Header -> Anfrage ist erlaubt.
- Die Anfrage hat einen Referer-Header und die Referer-URL befindet sich in der URL-Schließung -> Anfrage ist zulässig.
- Die Anfrage hat einen Referer-Header und die Referer-URL befindet sich nicht in der URL-Schließung -> Die Anfrage ist blockiert.
AlwaysExceptStartURLs:
- Die Anfrage hat keinen Referer-Header und die Anforderungs-URL ist eine Start-URL -> Anfrage ist zulässig.
- Die Anfrage hat keinen Referer-Header und die Anforderungs-URL ist keine Start-URL ->Die Anfrage ist blockiert.
- Die Anfrage hat einen Referer-Header und die Referer-URL befindet sich in der URL-Schließung -> Anfrage ist zulässig.
- Die Anfrage hat einen Referer-Header und die Referer-URL befindet sich nicht in der URL-Schließung -> Die Anfrage ist blockiert.
AlwaysExceptFirstRequest:
- Die Anfrage hat keinen Referer-Header und ist die erste Anforderungs-URL der Sitzung -> Anfrage ist zulässig.
- Die Anfrage hat keinen Referer-Header und ist nicht die erste Anforderungs-URL der Sitzung -> Die Anfrage ist blockiert.
- Die Anfrage hat einen Referer-Header und ist entweder die erste Anforderungs-URL der Sitzung oder befindet sich in der URL-Schließung -> Anfrage ist zulässig.
- Die Anfrage hat einen Referer-Header und ist weder die erste Anforderungs-URL der Sitzung noch befindet sich in der URL-Schließung -> Die Anfrage ist blockiert.
Wenn Sie die Befehlszeilenschnittstelle verwenden, können Sie die folgenden Befehle eingeben, um die Start-URL-Überprüfung zu konfigurieren:
set appfw profile <name> -startURLAction [block] [learn] [log] [stats] [none]set appfw profile <name> -startURLClosure ([ON] | [OFF])set appfw profile <name> -sessionlessURLClosure ([ON] | [OFF])set appfw profile <name> -exemptClosureURLsFromSecurityChecks ([ON] | [OFF)set appfw profile <name> -RefererHeaderCheck ([OFF] | [if-present] | [AlwaysExceptStartURLs] | [AlwaysExceptFirstRequest])
Um Relaxationen für die Start-URL-Überprüfung anzugeben, müssen Sie die GUI verwenden. Klicken Sie auf der Registerkarte Prüfungen des Dialogfelds Start URL Check ändern auf Hinzufügen, um das Dialogfeld Start URL Check Relaxation hinzufügen zu öffnen, oder wählen Sie eine vorhandene Entspannung aus, und klicken Sie auf Öffnen, um das Dialogfeld URL Check Relaxation ändern zu öffnen. Beide Dialogfelder bieten dieselben Optionen für die Konfiguration einer Entspannung.
Im Folgenden finden Sie Beispiele für Relaxationen bei der Start-URL-Überprüfung:
-
Erlauben Sie Benutzern den Zugriff auf die Startseite unter www.example.com:
^http://www[.]example[.]com$ <!--NeedCopy--> -
Erlauben Sie Benutzern den Zugriff auf alle Webseiten im statischen HTML- (.htm und .html), servergeparsten HTML (.htp und .shtml), PHP (.php) und Microsoft ASP (.asp) -Format unter www.example.com:
^http://www[.]example[.]com/([0-9A-Za-z][0-9A-Za-z_-]\*/)\* [0-9A-Za-z][0-9A-Za-z_.-]*[.](asp|htp|php|s?html?)$ <!--NeedCopy--> -
Benutzer können auf Webseiten mit Pfadnamen oder Dateinamen zugreifen, die Nicht-ASCII-Zeichen enthalten, unter www.example-español.com:
^http://www[.]example-espaxC3xB1ol[.]com/(([0-9A-Za-z]|x[0-9A-Fa-f][0-9A-Fa-f])([0-9A-Za-z_-]|x[0-9A-Fa-f][0-9A-Fa-f])\*/)\* ([0-9A-Za-z]|x[0-9A-Fa-f][0-9A-Fa-f])([0-9A-Za-z_-]|x[0-9A-Fa-f][0-9A-Fa-f])*[.](asp|htp|php|s?html?)$ <!--NeedCopy-->Hinweis: Im obigen Ausdruck wurde jede Zeichenklasse mit der Zeichenfolge x[0-9a-Fa-F][0-9A-Fa-f]gruppiert, die allen ordnungsgemäß konstruierten Zeichencodierungszeichenfolgen entspricht, aber keine streunenden Backslash-Zeichen zulässt, die nicht mit einer UTF-8-Zeichencodierungszeichenfolge verknüpft sind. Der doppelte umgekehrte Schrägstrich () ist ein maskierter umgekehrter Schrägstrich, der die Web App Firewall anweist, ihn als wörtlichen umgekehrten Schrägstrich zu interpretieren. Wenn Sie nur einen Backslash verwenden, würde die Web App Firewall stattdessen die folgende linke eckige Klammer ([) als Literalzeichen interpretieren, anstatt eine Zeichenklasse zu öffnen, wodurch der Ausdruck beschädigt würde.
-
Ermöglichen Sie Benutzern den Zugriff auf alle Grafiken im GIF- (.gif), JPEG- (.jpg und .jpeg) und PNG-Format (.png) auf www.example.com:
^http://www[.]example[.]com/([0-9A-Za-z][0-9A-Za-z_-]\*/)\* [0-9A-Za-z][0-9A-Za-z_.-]*[.](gif|jpe?g|png)$ <!--NeedCopy--> -
Erlauben Sie Benutzern den Zugriff auf CGI- (.cgi) und PERL-Skripts (.pl), jedoch nur im CGI-BIN-Verzeichnis:
^http://www[.]example[.]com/CGI-BIN/[0-9A-Za-z][0-9A-Za-z_.-]*[.](cgi|pl)$ <!--NeedCopy--> -
Erlauben Sie Benutzern den Zugriff auf Microsoft Office und andere Dokumentdateien im Verzeichnis docsarchive:
^http://www[.]example[.]com/docsarchive/[0-9A-Za-z][0-9A-Za-z_-.]*[.](doc|xls|pdf|ppt)$ <!--NeedCopy-->
Hinweis
Standardmäßig gelten alle Web App Firewall URLs als reguläre Ausdrücke.
Achtung: Reguläre Ausdrücke sind leistungsstark. Vor allem, wenn Sie mit regulären Ausdrücken im PCRE-Format nicht genau vertraut sind, überprüfen Sie alle regulären Ausdrücke, die Sie schreiben. Stellen Sie sicher, dass sie genau die URL definieren, die Sie als Ausnahme hinzufügen möchten, und sonst nichts. Die unachtsame Verwendung von Platzhaltern und insbesondere der Kombination aus Metazeichen und Platzhaltern ( .*) kann zu unerwünschten Ergebnissen führen, z. B. zum Blockieren des Zugriffs auf Webinhalte, die Sie nicht blockieren wollten, oder zum Zulassen eines Angriffs, den die Start-URL-Überprüfung sonst blockiert hätte.
Tipp
Sie können das -und- zur zulässigen Liste von SQL-Schlüsselwörtern für das URL-Benennungsschema hinzufügen. Zum Beispiel https://FQDN/bread-and-butter.