Vérification d’URL de démarrage
Le contrôle de l’URL de départ examine les URL des demandes entrantes et bloque la tentative de connexion si l’URL ne répond pas aux critères spécifiés. Pour répondre aux critères, l’URL doit correspondre à une entrée de la liste des URL de départ, sauf si le paramètre Appliquer la fermeture de l’URL est activé. Si vous activez ce paramètre, l’utilisateur qui clique sur un lien de votre site Web est connecté à la cible de ce lien.
L’objectif principal de la vérification de l’URL de départ est d’empêcher les tentatives répétées d’accéder à des URL aléatoires sur un site Web (navigation forcée) par le biais de signets, de liens externes ou de sauter à des pages en saisissant manuellement les URL pour ignorer les pages requises pour accéder à cette partie du site Web. La navigation forcée peut être utilisée pour déclencher un débordement de la mémoire tampon, trouver du contenu auquel les utilisateurs n’étaient pas censés accéder directement ou trouver une porte dérobée menant à des zones sécurisées de votre serveur Web. Le Web App Firewall applique le chemin de traversée ou le chemin logique donné à un site Web en n’autorisant l’accès qu’aux URL configurées comme URL de départ.
Si vous utilisez l’assistant ou l’interface graphique, dans la boîte de dialogue Modifier la vérification de l’URL de démarrage, sous l’onglet Général, vous pouvez activer ou désactiver les actions Bloquer, Journaliser, Statistiques, Learn et les paramètres suivants :
- Imposer la fermeture de l’URL. Autorisez les utilisateurs à accéder à n’importe quelle page Web de votre site Web en cliquant sur un lien hypertexte situé sur n’importe quelle autre page de votre site Web. Les utilisateurs peuvent accéder à n’importe quelle page de votre site Web accessible à partir de la page d’accueil ou de toute page d’accueil désignée en cliquant sur des hyperliens. Remarque : La fonction de fermeture d’URL permet d’ajouter et d’envoyer n’importe quelle chaîne de requête avec l’URL d’action d’un formulaire Web soumis à l’aide de la méthode HTTP GET. Si vos sites Web protégés utilisent des formulaires pour accéder à une base de données SQL, assurez-vous que le contrôle d’injection SQL est activé et correctement configuré.
- Fermeture d’URL sans session. Du point de vue du client, ce type de fermeture d’URL fonctionne exactement de la même manière que la fermeture d’URL standard adaptée à la session, mais utilise un jeton intégré dans l’URL au lieu d’un cookie pour suivre l’activité de l’utilisateur, ce qui consomme beaucoup moins de ressources. Lorsque la fermeture d’URL sans session est activée, le Web App Firewall ajoute une balise « as_url_id » à toutes les URL en cours de fermeture d’URL. Remarque : Lorsque vous activez le mode sans session (fermeture d’URL sans session), vous devez également activer la fermeture normale d’URL ( Appliquer la fermeture d’URL), sinon la fermeture d’URL sans session ne fonctionnera pas.
-
Valider l’en-tête du référent. Vérifiez que l’en-tête Referer d’une demande contenant des données de formulaire Web provenant de votre site Web protégé plutôt que d’un autre site Web. Cette action permet de vérifier que c’est votre site Web, et non un attaquant extérieur, qui est à l’origine du formulaire Web. Cela permet de se prémunir contre les contrefaçons de requêtes intersites (CSRF) sans nécessiter le balisage des formulaires, qui nécessite davantage de ressources processeur que les vérifications d’en-tête. Le Web App Firewall peut gérer l’en-tête HTTP Referer de l’une des quatre manières suivantes, selon l’option que vous sélectionnez dans la liste déroulante :
- Désactivé—Ne validez pas l’en-tête Referer.
- If-Present—Validez l’en-tête Referer s’il existe un en-tête Referer. Si un en-tête de référence non valide est trouvé, la demande génère une violation de l’en-tête de référence. S’il n’existe aucun en-tête de référence, la demande ne génère pas de violation de l’en-tête de référence. Cette option permet au Web App Firewall d’effectuer une validation de l’en-tête Referer sur les requêtes contenant un en-tête Referer, mais de ne pas bloquer les demandes provenant d’utilisateurs dont les navigateurs ne définissent pas l’en-tête Referer ou qui utilisent des proxys Web ou des filtres qui suppriment cet en-tête.
- Toujours sauf les URL de départ : validez toujours l’en-tête du référent. S’il n’existe aucun en-tête de référence et que l’URL demandée n’est pas exemptée par la règle de relaxation startURL, la demande génère une violation de l’en-tête de référence. Si l’en-tête Referer est présent mais qu’il n’est pas valide, la demande génère une violation de l’en-tête de référence.
- Toujours sauf la première demande : validez toujours l’en-tête du référent. S’il n’y a pas d’en-tête de référence, seule l’URL à laquelle vous avez accédé en premier est autorisée. Toutes les autres URL sont bloquées sans en-tête de référence valide. Si l’en-tête Referer est présent mais qu’il n’est pas valide, la demande génère une violation de l’en-tête de référence.
Un paramètre d’URL de départ, Exempter les URL de fermeture des contrôles de sécurité, n’est pas configuré dans la boîte de dialogue Modifier la vérification de l’URL de début, mais est configuré dans l’onglet Paramètres du profil. S’il est activé, ce paramètre indique au Web App Firewall de ne pas effectuer d’autres vérifications basées sur des formulaires (telles que l’inspection par script intersite et injection SQL) sur les URL qui répondent aux critères de fermeture d’URL.
Remarque
Bien que le contrôle de l’en-tête du référent et le contrôle de sécurité de l’URL de démarrage partagent les mêmes paramètres d’action, il est possible de ne pas respecter le contrôle de l’en-tête du référent sans enfreindre le contrôle de l’URL de départ. La différence est visible dans les journaux, qui vérifient les violations de l’en-tête du référent séparément des violations du contrôle de l’URL de démarrage.
Les paramètres de l’en-tête Referer (OFF, IF-Present, AlwaysExceptStartUrls et AlwaysExceptFirstRequest) sont organisés du moins restrictif au plus restrictif et fonctionnent comme suit :
OFF :
- En-tête de référence Non coché.
If-Present :
- La demande n’a pas d’en-tête de référence -> La demande est autorisée.
- La demande a un en-tête de référence et l’URL du référent est en fermeture d’URL -> La demande est autorisée.
- La demande possède un en-tête de référence et l’URL du référent n’est pas en fermeture d’URL -> La demande est bloquée.
AlwaysExceptStartURLs :
- La demande n’a pas d’en-tête de référence et l’URL de la demande est une URL de départ -> La demande est autorisée.
- La demande n’a pas d’en-tête de référence et l’URL de la demande n’est pas une URL de départ -> La demande est bloquée.
- La demande a un en-tête de référence et l’URL du référent est en fermeture d’URL -> La demande est autorisée.
- La demande possède un en-tête de référence et l’URL du référent n’est pas en fermeture d’URL -> La demande est bloquée.
AlwaysExceptFirstRequest :
- La demande n’a pas d’en-tête de référence et est la première URL de requête de la session -> La demande est autorisée.
- La demande n’a pas d’en-tête de référence et n’est pas la première URL de requête de la session -> La demande est bloquée.
- La demande possède un en-tête de référence et est soit la première URL de requête de la session, soit elle est en cours de fermeture d’URL -> La demande est autorisée.
- La demande possède un en-tête de référence et n’est pas la première URL de requête de la session et n’est pas en cours de fermeture d’URL -> La demande est bloquée.
Si vous utilisez l’interface de ligne de commande, vous pouvez entrer les commandes suivantes pour configurer la vérification de l’URL de démarrage :
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])
Pour spécifier des assouplissements pour la vérification de l’URL de démarrage, vous devez utiliser l’interface graphique. Sous l’onglet Vérifications de la boîte de dialogue Modifier la vérification de l’URL de début, cliquez sur Ajouter pour ouvrir la boîte de dialogue Ajouter la relaxation de la vérification de l’URL de début ou sélectionnez une relaxation existante et cliquez sur Ouvrir pour ouvrir la boîte de dialogue Modifier la relaxation de la vérification de l’URL de début. L’une ou l’autre des boîtes de dialogue fournit les mêmes options pour configurer une relaxation.
Voici des exemples d’assouplissements liés à la vérification de l’URL de démarrage :
-
Autorisez les utilisateurs à accéder à la page d’accueil sur www.example.com :
^http://www[.]example[.]com$ <!--NeedCopy--> -
Autorisez les utilisateurs à accéder à toutes les pages Web au format HTML statique (.htm et .html), HTML analysé par le serveur (.htp et .shtml), PHP (.php) et Microsoft ASP (.asp) sur 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--> -
Autoriser les utilisateurs à accéder aux pages Web avec des noms de chemin d’accès ou des noms de fichiers contenant des caractères non ASCII sur 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-->Remarque : Dans l’expression ci-dessus, chaque classe de caractères a été regroupée avec la chaîne x[0-9a-fa-F][0-9A-Fa-f], qui correspond à toutes les chaînes de codage de caractères correctement construites, mais n’autorise pas les barres obliques inverse errantes qui ne sont pas associées à une chaîne de codage de caractères UTF-8. La double barre oblique inverse () est une barre oblique inverse échappée, qui indique au Web App Firewall de l’interpréter comme une barre oblique inverse littérale. Si vous n’incluiez qu’une seule barre oblique inverse, le Web App Firewall interpréterait le crochet gauche suivant ([) comme un caractère littéral au lieu de l’ouverture d’une classe de caractères, ce qui briserait l’expression.
-
Autorisez les utilisateurs à accéder à tous les graphiques au format GIF (.gif), JPEG (.jpg et .jpeg) et PNG (.png) sur 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--> -
Autorisez les utilisateurs à accéder aux scripts CGI (.cgi) et PERL (.pl), mais uniquement dans le répertoire CGI-BIN :
^http://www[.]example[.]com/CGI-BIN/[0-9A-Za-z][0-9A-Za-z_.-]*[.](cgi|pl)$ <!--NeedCopy--> -
Autorisez les utilisateurs à accéder à Microsoft Office et aux autres fichiers de documents du répertoire docsarchive :
^http://www[.]example[.]com/docsarchive/[0-9A-Za-z][0-9A-Za-z_-.]*[.](doc|xls|pdf|ppt)$ <!--NeedCopy-->
Remarque
Par défaut, toutes les URL du Web App Firewall sont considérées comme des expressions régulières.
Attention : Les expressions régulières sont puissantes. Surtout si vous n’êtes pas très familier avec les expressions régulières au format PCRE, vérifiez toutes les expressions régulières que vous écrivez. Assurez-vous qu’ils définissent exactement l’URL que vous souhaitez ajouter en tant qu’exception, et rien d’autre. L’utilisation négligente des caractères génériques, et en particulier de la combinaison de métacaractères/caractères génériques ( .*), peut avoir des résultats que vous ne voulez pas, comme bloquer l’accès au contenu Web que vous n’aviez pas l’intention de bloquer ou autoriser une attaque que la vérification de l’URL de démarrage aurait autrement bloquée.
Conseil
Vous pouvez ajouter le -and- à la liste autorisée de mots-clés SQL pour le schéma d’attribution de noms d’URL. Par exemple, https://FQDN/bread-and-butter.