Citrix ADC

Prise en charge Web App Firewall pour Google Web Toolkit

Remarque : Cette fonctionnalité est disponible dans Citrix ADC version 10.5.e.

Les serveurs Web suivant les mécanismes RPC (Remote Procedure Call) de Google Web Toolkit (GWT) peuvent être sécurisés par le pare-feu Citrix Web Web App sans avoir besoin de configuration spécifique pour activer la prise en charge de GWT.

Qu’est-ce que GWT

Le GWT est utilisé pour créer et optimiser des applications Web hautes performances complexes par des personnes qui n’ont pas d’expertise dans XMLHttpRequest et 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 le navigateur telles que les résultats de recherche pour les vols, les hôtels, etc. Le GWT fournit un ensemble de base d’API Java et de widgets pour écrire des scripts JavaScript optimisés qui peuvent s’exécuter sur la plupart des navigateurs et des appareils mobiles. Le framework RPC GWT facilite l’échange d’objets Java sur HTTP pour les composants client et serveur de l’application Web. Les services RPC GWT ne sont pas les mêmes que les services Web basés sur SOAP ou REST. Ils sont simplement 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

Fonctionnement d’une requête GWT

La requête RPC GWT est délimitée par un canal et a un nombre variable d’arguments. Il est porté comme une charge utile de HTTP POST et a les valeurs suivantes :

  1. Type de contenu = text/x-gwt-rpc. Charset peut être n’importe quelle valeur.
  2. Méthode = POST.

Les requêtes HTTP GET et POST sont toutes deux 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 du pare-feu de l’application sur « Other » pour examiner la partie requête pour le type conent-type « text/x-gwt-rpc ».

L’exemple suivant montre une charge utile valide pour une requête 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|

La demande peut être divisée en trois parties :

a)Header: 5|0|8|

Les 3 premiers chiffres5|0|8| de la requête ci-dessus représentent respectivement « version, subversion et taille de la table ». Ceux-ci doivent être des entiers positifs.

b) Table de 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îne délimitée par le tuyau 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 :16878339F02B83818D264AE430C20468

    Identifiant HEX unique. Une requête est considérée comme mal formée si cette chaîne a des caractères non hexadécimaux.

  • 3ème :com.test.client.TestService

    Nom de la classe de service

  • 4ème :testMethod

    Nom de la méthode de service

  • 5e à partir de :java.lang.String|java.lang.Integer|myInput1|java.lang.Integer/3438268394

    Types 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 consiste en des 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 dans la table de chaînes.

Protection Web App Firewall pour les applications GWT

Le Web App Firewall comprend et interprète les requêtes RPC GWT, inspecte la charge utile pour détecter les violations de contrôle de sécurité et prend les actions spécifiées.

Les en-têtes et les contrôles des cookies du Web App Firewall pour les requêtes GWT sont similaires à ceux des autres formats de requête. Après le décodage d’URL et la conversion de 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, seulement les valeurs de champs. Les valeurs d’entrée peuvent être validées par rapport au format spécifié à l’aide de la vérification Format de champ du Web App Firewall, qui peut également être utilisée pour contrôler la longueur de l’entrée. Les attaques de script inter-site et d’injection SQL 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 demandes GWT. Les règles du pare-feu des applications Web se présentent sous la forme de mappage <actionURL> <fieldName>. Le format de requête GWT n’a pas les noms de champs et nécessite donc un traitement spécial. Le Web App Firewall insère des noms de champs factices dans les règles apprises qui peuvent être déployés en tant que règles de relaxation. L’indicateur -isRegex fonctionne comme il le fait 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 a l’URL du serveur Web, et non du service qui gère le RPC. Par conséquent, la relaxation n’est pas appliquée sur la base de l’URL de requête HTTP, car cela relâcherait tous les services sur 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 requête GWT contient uniquement des valeurs de champ, le Web App Firewall insère des noms de champ factices tels que 1, 2, etc. lors de la recommandation de règles apprises.

    Exemple d’une règle d’apprentissage 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
    

    Exemple de règle de relaxation GWT

    bind appfw profile pr1 -crossSiteScripting 1 abcd -isregex NOTREGEX

Messages de journal : le Web App Firewall génère des messages de journal pour les violations de vérification de sécurité détectées dans les requêtes GWT. Un message de journal généré par une requête GWT mal formée contient la chaîne « GWT » pour une identification facile.

Exemple de message de journal pour une requête 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 dans le traitement des demandes GWT par rapport aux demandes non GWT :

La même charge utile peut déclencher différentes violations de vérification 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 champ 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 dans le corps de la publication, le contenu entier est traité comme un seul nom de champ. Le nom du champ dans cette requête contient à la fois un caractère spécial SQL ( ;) et un mot-clé SQL (select). Par conséquent, les violations sont interceptées pour les quatre options de type Injection SQL.

Type de contenu : text/x-gwt-rpc :

Une requête 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 que la barre| verticale est le séparateur de champ pour la charge utile ci-dessus dans la demande GWT. Par conséquent, le corps postérieur est divisé en différentes valeurs de champ de formulaire, et des noms de champ de formulaire sont ajoutés (conformément à la convention décrite plus haut). En raison de ce fractionnement, le caractère spécial SQL et le mot-clé SQL deviennent des parties de champs de formulaire distincts.

Champ de formulaire 8 :java.lang.String%3b -\> %3b is the (;) char

Champ 10 du formulaire :select

Par conséquent, lorsque 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 de Web App Firewall n’est nécessaire pour activer la prise en charge de GWT.
  • Le type de contenu doit être text/x-gwt-rpc.
  • L’apprentissage et le déploiement des règles de relaxation pour toutes les vérifications de sécurité pertinentes du Web App Firewall appliquées à la charge utile GWT fonctionnent de la même manière que pour les autres types de contenu pris en charge.
  • Seules les demandes 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 du profil.
  • Le paramètre sans session pour les vérifications de sécurité n’est pas applicable et sera ignoré.
  • Le format de journal CEF est pris en charge pour les messages de journal GWT.

Prise en charge Web App Firewall pour Google Web Toolkit