Importations
Plusieurs fonctionnalités du Web App Firewall utilisent des fichiers externes que vous chargez vers le Web App Firewall lors de sa configuration. À l’aide de l’interface graphique, vous gérez ces fichiers dans le volet Importations, qui comporte quatre onglets correspondant aux quatre types de fichiers que vous pouvez importer : objets d’erreur HTML, objets d’erreur XML, schémas XML et fichiers WSDL (Web Services Description Language). À l’aide de la ligne de commande NetScaler, vous pouvez importer ces types de fichiers, mais vous ne pouvez pas les exporter.
Objet d’erreur HTML
Lorsque la connexion d’un utilisateur à une page HTML ou Web 2.0 est bloquée, ou qu’un utilisateur demande une page HTML ou Web 2.0 inexistante, le Web App Firewall envoie une réponse d’erreur HTML au navigateur de l’utilisateur. Lorsque vous configurez la réponse d’erreur que le Web App Firewall doit utiliser, vous avez deux choix :
- Vous pouvez configurer une URL de redirection, qui peut être hébergée sur n’importe quel serveur Web auquel les utilisateurs ont également accès. Par exemple, si vous avez une page d’erreur personnalisée sur votre serveur Web, 404.html, vous pouvez configurer le Web App Firewall pour rediriger les utilisateurs vers cette page lorsqu’une connexion est bloquée.
- Vous pouvez configurer un objet d’erreur HTML, qui est une page Web HTML hébergée sur le Web App Firewall lui-même. Si vous choisissez cette option, vous devez charger l’objet d’erreur HTML vers le Web App Firewall. Vous pouvez le faire dans le volet Importations, dans l’onglet Objet d’erreur HTML.
L’objet d’erreur doit être un fichier HTML standard ne contenant aucune syntaxe autre que HTML, à l’exception des variables de personnalisation de l’objet d’erreur du Web App Firewall. Il ne peut pas contenir de scripts CGI, de code analysé par le serveur ou de code PHP. Les variables de personnalisation vous permettent d’intégrer des informations de dépannage dans l’objet d’erreur que l’utilisateur reçoit lorsqu’une demande est bloquée. Bien que la plupart des requêtes bloquées par le Web App Firewall soient illégitimes, même un Web App Firewall correctement configuré peut parfois bloquer des demandes légitimes, en particulier lorsque vous le déployez pour la première fois ou après avoir apporté des modifications importantes à vos sites Web protégés. En intégrant des informations dans la page d’erreur, vous fournissez à l’utilisateur les informations qu’il doit communiquer au support technique afin que les problèmes puissent être résolus.
Les variables de personnalisation de la page d’erreur du Web App Firewall sont les suivantes :
- $ {NS_TRANSACTION_ID}. L’ID de transaction que le Web App Firewall a attribué à cette transaction.
- $ {NS_APPFW_SESSION_ID}. L’ID de session du Web App Firewall.
- $ {NS_APPFW_VIOLATION_CATEGORY}. Le contrôle ou la règle de sécurité spécifique du Web App Firewall qui a été violée.
-
$ {NS_APPFW_VIOLATION_LOG}. Le message d’erreur détaillé associé à la violation.
- $ {COOKIE Le contenu du cookie spécifié. Remplacez par le nom du cookie spécifique que vous souhaitez afficher sur la page d’erreur.
<CookieName>Si vous souhaitez afficher le contenu de plusieurs cookies à des fins de résolution des problèmes, vous pouvez utiliser plusieurs instances de cette variable de personnalisation, chacune portant le nom de cookie approprié. Remarque : Si le blocage est activé pour le contrôle de cohérence des cookies, les cookies bloqués ne s’affichent pas sur la page d’erreur car le Web App Firewall les bloque.
Pour utiliser ces variables, vous les incorporez dans le code HTML ou XML de l’objet de la page d’erreur comme s’il s’agissait d’une chaîne de texte ordinaire. Lorsque l’objet d’erreur est affiché à l’utilisateur, pour chaque variable de personnalisation, le Web App Firewall remplace les informations auxquelles la variable fait référence. Un exemple de page d’erreur HTML qui utilise des variables personnalisées est illustré ci-dessous.
<!doctype html public "-//w3c//dtd html 4.0//en"> <html> <head> <title>Page Not Accessible</title> </head> <body> <h1>Page Not Accessible</h1> <p>The page that you accessed is not available. You can:</p> <ul> <li>return to the <b><a href="[homePage]">home page</a></b>, re-establish your session, and try again, or,</li> <li>report this incident to the help desk via <b><a href="mailto:[helpDeskEmailAddress]">email</a></b> or by calling [helpDeskPhoneNumber].</li> </ul> <p>If you contact the help desk, please provide the following information:</p> <table cellpadding=8 width=80%> <tr><th align="right" width=30%>Transaction ID:</th><td align="left" valign="top" width=70%>${NS_TRANSACTION_ID}</td></tr> <tr><th align="right" width=30%>Session ID:</th><td align="left" valign="top" width=70%>${NS_APPFW_SESSION_ID}</td></tr> <tr><th align="right" width=30%>Violation Category:</th><td align="left" valign="top" width=70%>${NS_APPFW_VIOLATION_CATEGORY}</td></tr> <tr><th align="right" width=30%>Violation Log:</th><td align="left" valign="top" width=70%>${NS_APPFW_VIOLATION_LOG}</td></tr> <tr><th align="right" width=30%>Cookie Name:</th><td align="left" valign="top" width=70%>${COOKIE("[cookieName]")}</td></tr> </table> <body> <html>
<!--NeedCopy-->
Pour utiliser cette page d’erreur, copiez-la dans un éditeur de texte ou HTML. Remplacez les variables suivantes par les informations locales appropriées, qui sont placées entre crochets pour les distinguer des variables NetScaler. (Laisser inchangés) :
-
[homePage]. L’URL de la page d’accueil de votre site Web. -
[helpDeskEmailAddress]. Adresse e-mail que vous souhaitez que les utilisateurs utilisent pour signaler les incidents de blocage. -
[helpDeskPhoneNumber]. Le numéro de téléphone que vous souhaitez que les utilisateurs appellent pour signaler les incidents de blocage. -
[cookieName]. Le nom du cookie dont vous souhaitez afficher le contenu sur la page d’erreur.
Objet d’erreur XML
Lorsque la connexion d’un utilisateur à une page XML est bloquée ou qu’un utilisateur demande une application XML inexistante, le Web App Firewall envoie une réponse d’erreur basée sur XML au navigateur de l’utilisateur. Vous configurez la réponse à l’erreur en téléchargeant une page d’erreur XML vers le Web App Firewall dans le volet Imports, sous l’onglet Objet d’erreur XML. Toutes les réponses d’erreur XML sont hébergées sur le Web App Firewall. Vous ne pouvez pas configurer d’URL de redirection pour les applications XML.
Remarque : Vous pouvez utiliser les mêmes variables de personnalisation dans un objet d’erreur XML que dans un objet d’erreur HTML.
Schéma XML
Lorsque le Web App Firewall effectue un contrôle de validation sur la demande d’un utilisateur pour une application XML ou Web 2.0, il peut valider la demande par rapport au schéma XML ou au document de type de conception (DTD) de cette application et rejeter toute demande qui ne suit pas le schéma ou la DTD. Un schéma XML et une DTD sont tous deux des fichiers de configuration XML standard qui décrivent la structure d’un type spécifique de document XML.
WSDL
Lorsque le Web App Firewall effectue un contrôle de validation sur la demande d’un utilisateur pour un service Web XML SOAP, il peut valider la demande par rapport au fichier de définition de type de services Web (WSDL) pour ce service Web. Un fichier WSDL est un fichier de configuration SOAP XML standard qui définit les éléments d’un service Web SOAP XML spécifique.
Objet d’importation de spécifications API
La spécification d’API définit la conception d’une API, y compris les points de terminaison, les méthodes, les paramètres et les formats de données. La fonctionnalité d’importation de spécifications d’API vous permet d’importer la spécification d’API ouverte, qui est généralement utilisée pour décrire l’API REST. Lorsque le Web App Firewall effectue un contrôle de validation sur la demande d’un utilisateur pour un service Web basé sur une API, il valide la demande par rapport au schéma spécifié dans le fichier de spécification de l’API pour ce service Web. NetScaler prend en charge les validations de schéma pour une API REST, la charge utile étant le JSON de l’application et ProtoBuf pour les requêtes d’API gRPC.
NetScaler prend en charge les formats de spécification suivants :
- API ouverte - Swagger 2.0, OAS 3.0, 3.1
- ProtoBuf - v3 et v2