Support du Web App Firewall pour la boîte à outils Web de Google
Remarque : Cette fonctionnalité est disponible dans NetScaler version 10.5.e.
Les serveurs Web utilisant les mécanismes RPC (Remote Procedure Call) de Google Web Toolkit (GWT) peuvent être sécurisés par le NetScaler Web App Firewall sans nécessiter de configuration spécifique pour activer le support GWT.
Qu’est-ce que GWT
Le GWT est utilisé pour créer et optimiser des applications Web complexes à hautes performances par des personnes qui n’ont pas d’expertise en XMLHttpRequest et en JavaScript. Cette boîte à outils de développement libre et open source est largement utilisée pour développer des applications à petite et grande échelle et est assez fréquemment utilisée pour afficher des données basées sur des navigateurs, telles que les résultats de recherche pour les vols, les hôtels, etc. Le GWT fournit un ensemble de base d’API et de widgets Java pour écrire des scripts JavaScript optimisés pouvant être exécutés sur la plupart des navigateurs et appareils mobiles. Le framework GWT RPC permet aux composants client et serveur de l’application Web d’échanger facilement des objets Java via HTTP. Les services GWT RPC ne sont pas les mêmes que les services Web basés sur SOAP ou REST. Il s’agit simplement d’une méthode légère pour transférer des données entre le serveur et l’application GWT sur le client. GWT gère la sérialisation des objets Java en échangeant les arguments dans les appels de méthode et la valeur de retour.
Pour connaître les sites Web populaires qui utilisent GWT, voir
https://www.quora.com/What-web-applications-use-Google-Web-Toolkit-%28GWT%29
Comment fonctionne une demande GWT
La requête GWT RPC est délimitée par des canaux et possède un nombre variable d’arguments. Il est transporté en tant que charge utile de HTTP POST et possède les valeurs suivantes :
- Type de contenu = text/x-gwt-rpc. Le jeu de caractères peut prendre n’importe quelle valeur.
- Méthode = POST.
Les requêtes HTTP GET et POST sont considérées comme des requêtes GWT valides si le type de contenu est « text/x-gwt-rpc ». Les chaînes de requête sont désormais prises en charge dans le cadre des requêtes GWT. Configurez le paramètre « InspectQueryContentTypes » du profil App Firewall sur « OTHER » pour examiner la partie de requête pour le type de contenu « text/x-gwt-rpc ».
L’exemple suivant montre une charge utile valide pour une demande GWT :
5|0|8|http://localhost:8080/test/|16878339F02B83818D264AE430C20468| com.test.client.TestService|testMethod|java.lang.String|java.lang.Integer| myInput1|java.lang.Integer/3438268394|1|2|3|4|2|5|6|7|8|1|
<!--NeedCopy-->
La demande peut être divisée en trois parties :
a) Header: 5|0|8|
Les 3 premiers chiffres 5|0|8| de la requête ci-dessus représentent respectivement « la version, la subversion et la taille de la table ». Il doit s’agir de nombres entiers positifs.
b) Table à chaînes :
http://localhost:8080/test/|16878339F02B83818D264AE430C20468| com.test.client.TestService|testMethod|java.lang.String|java.lang.Integer|myInput1| java.lang.Integer/3438268394|
Les membres de la table de chaînes délimitées par des tuyaux ci-dessus contiennent les entrées fournies par l’utilisateur. Ces entrées sont analysées pour les vérifications du Web App Firewall et sont identifiées comme suit :
-
1er :
http://localhost:8080/test/Il s’agit de l’URL de la demande.
-
2e :
16878339F02B83818D264AE430C20468Identifiant HEX unique. Une requête est considérée comme mal formée si cette chaîne contient des caractères non hexadécimaux.
-
3ème :
com.test.client.TestServiceNom de la classe de service
-
4e :
testMethodNom de la méthode de service
-
À partir de la 5e année :
java.lang.String|java.lang.Integer|myInput1|java.lang.Integer/3438268394Types de données et données. Les types de données non primitifs sont spécifiés comme
<container>.<sub-cntnr>.name/<integer><identifier>
c) Payload: 1|2|3|4|2|5|6|7|8|1|
La charge utile se compose de références aux éléments de la table de chaînes. Ces valeurs entières ne peuvent pas être supérieures au nombre d’éléments de la table de chaînes.
Protection par le Web App Firewall pour les applications GWT
Le Web App Firewall comprend et interprète les requêtes GWT RPC, inspecte la charge utile pour détecter les violations des contrôles de sécurité et prend des mesures spécifiques.
Les en-têtes du Web App Firewall et les contrôles des cookies pour les requêtes GWT sont similaires à ceux des autres formats de demande. Après un décodage d’URL et une conversion du jeu de caractères appropriés, tous les paramètres de la table de chaînes sont inspectés. Le corps de la requête GWT ne contient pas de noms de champs, mais uniquement les valeurs des champs. Les valeurs d’entrée peuvent être validées par rapport au format spécifié à l’aide de la vérification du format du champ du Web App Firewall, qui peut également être utilisée pour contrôler la longueur de la saisie. Les attaques de script intersite et d’injection SQL présentes dans les entrées peuvent être facilement détectées et contrecarrées par le Web App Firewall.
Règles d’apprentissage et de relaxation : l’apprentissage et le déploiement des règles de relaxation sont pris en charge pour les requêtes GWT. Les règles du Web App Firewall se présentent sous la forme de mapping <actionURL> <fieldName>. Le format de requête GWT ne contient pas les noms de champs et nécessite donc un traitement spécial. Le Web App Firewall insère des noms de champs fictifs dans les règles apprises qui peuvent être déployées sous forme de règles de relaxation. L’indicateur -IsRegex fonctionne de la même manière que pour les règles non GWT.
-
URL de l’action :
Plusieurs services répondant à un RPC peuvent être configurés sur le même serveur Web. La requête HTTP contient l’URL du serveur Web, et non celle du service qui gère le RPC. Par conséquent, la relaxation n’est pas appliquée sur la base de l’URL de la requête HTTP, car cela assouplirait tous les services de cette URL pour le champ cible. Pour les requêtes GWT, le Web App Firewall utilise l’URL du service réel trouvé dans la charge utile GWT, dans le quatrième champ de la table de chaînes.
-
Nom du champ :
Étant donné que le corps de la requête GWT ne contient que des valeurs de champ, le Web App Firewall insère des noms de champs fictifs tels que 1, 2, etc. lorsqu’il recommande des règles apprises.
Exemple de règle apprise par GWT
POST /abcd/def/gh HTTP/1.1 Content-type: text/x-gwt-rpc Host: 10.217.222.75 Content-length: 157 5|0|8|http://localhost:8080/acdtest/|16878339F02Baf83818D264AE430C20468| com.test.client.TestService|testMethod|java.lang.String%3b|java.lang.Integer|onblur| The learn data will be as follows: > sh learningdata pr1 crossSiteScripting Profile: pr1 SecurityCheck: crossSiteScripting 1) Url: http://localhost:8080/acdtest/ >> From GWT Payload. Field: 10 Hits: 1 Done <!--NeedCopy-->Exemple de règle de relaxation GWT
bind appfw profile pr1 -crossSiteScripting 1 abcd -isregex NOTREGEX
Messages du journal : le Web App Firewall génère des messages de journal pour les violations des contrôles de sécurité détectées dans les demandes GWT. Un message de journal généré par une demande GWT mal formée contient la chaîne « GWT » pour faciliter l’identification.
Exemple de message de journal pour une demande GWT mal formée :
Dec 5 21:48:02 <local0.notice> 10.217.31.247 12/05/2014:21:48:02 GMT ns 0-PPE-0 : APPFW Message 696 0 : "GWT RPC request with malformed payload. <blocked>”
Différence entre le traitement des demandes GWT et celui des demandes non GWT :
La même charge utile peut déclencher différentes violations des contrôles de sécurité du Web App Firewall pour différents types de contenu. Prenons l’exemple suivant :
5|0|8|http://localhost:8080/acdtest/|16878339F02Baf83818D264AE430C20468|com.test.client.TestService|testMethod|java.lang.String%3b|java.lang.Integer|select|
Type de contenu : application/x-www-form-urlencoded :
Une requête envoyée avec ce type de contenu entraîne une violation SQL si le Type d’injection SQL est configuré pour utiliser l’une des quatre options disponibles : SQLSplCharANDKeyword, SQLSplCharORKeyword, SQLKeyword ou SQLSplChar. Le Web App Firewall considère « & » comme le séparateur de champs et « = » comme le séparateur nom-valeur lors du traitement de la charge utile ci-dessus. Comme aucun de ces caractères n’apparaît nulle part dans le corps du message, l’ensemble du contenu est traité comme un seul nom de champ. Le nom du champ de cette requête contient à la fois un caractère spécial SQL (;) et un mot clé SQL (select). Les violations sont donc détectées pour les quatre options de type d’injection SQL.
Type de contenu : text/x-gwt-rpc :
Une demande envoyée avec ce type de contenu déclenche une violation SQL uniquement si le type d’injection SQL est défini sur l’une des trois options suivantes : SQLSplCharorKeyword, SQLKeyWord ou SQLSplChar. Aucune violation n’est déclenchée si le type d’injection SQL est défini sur SQLSplCharANDKeyword, qui est l’option par défaut. Le Web App Firewall considère la barre | verticale comme le séparateur de champs pour la charge utile ci-dessus dans la requête GWT. Par conséquent, le corps du message est divisé en différentes valeurs de champs de formulaire et des noms de champs de formulaire sont ajoutés (conformément à la convention décrite précédemment). En raison de cette division, le caractère spécial SQL et le mot clé SQL font partie de champs de formulaire distincts.
Champ de formulaire 8 : java.lang.String%3b -\> %3b is the (;) char
Champ de formulaire 10 : select
Par conséquent, lorsque le type d’injection SQL est défini sur SQLSplChar, le champ 8 indique la violation SQL. Pour SQLKeyword, le champ 10 indique la violation. L’un de ces deux champs peut indiquer une violation si le type SQL Inject est configuré avec l’option SQLSplCharORKeyword, qui recherche la présence d’un mot-clé ou d’un caractère spécial. Aucune violation n’est détectée pour l’option SQLSplCharANDKeyword par défaut, car il n’y a pas de champ unique qui contient à la fois SQLSplChar et SQLKeyword ensemble.
Conseils :
- Aucune configuration spéciale du Web App Firewall n’est requise pour activer le support GWT.
- Le type de contenu doit être text/x-gwt-rpc.
- L’apprentissage et le déploiement des règles de relaxation pour tous les contrôles de sécurité pertinents du Web App Firewall appliqués à la charge utile GWT fonctionnent de la même manière que pour les autres types de contenu pris en charge.
- Seules les requêtes POST sont considérées comme valides pour GWT. Toutes les autres méthodes de requête sont bloquées si le type de contenu est text/x-gwt-rpc.
- Les requêtes GWT sont soumises à la limite de corps POST configurée pour le profil.
- Le paramètre sans session pour les contrôles de sécurité n’est pas applicable et sera ignoré.
- Le format de journal CEF est pris en charge pour les messages du journal GWT.