Sécurité du serveur WL 6.0.0.1 - Le serveur est-il à l'abri des scripts intersites/de l'injection de code Javascript ?

Question

Cette question est revenue dans notre projet :

La sécurité fonctionne désormais sous HTTPS avec un test de sécurité mobile (XSRF, etc.) qui inclut l'authenticité des applications pour Android.Nos adaptateurs ne nécessitent aucune authentification utilisateur/pass, donc aucun autre domaine, module d'authentification ou de connexion n'est configuré.L'application peut appeler les procédures de l'adaptateur immédiatement après WL.Client.connect.

Que fait Worklight côté serveur pour empêcher les attaques par injection de code Javascript côté serveur ?

Détails sur ce type d'attaque : http://media.blackhat.com/bh-us-11/Sullivan/BH_US_11_Sullivan_Server_Side_WP.pdf

En d'autres termes, (bien que difficile) supposons que quelqu'un ait pu utiliser notre APK pour créer un nouvel APK capable de tromper le mécanisme d'authentification/sécurité de Worklight, sommes-nous alors vulnérables à une attaque par injection de code Javascript côté serveur ?

Cela se résume à la question de savoir si tous les paramètres de tous les appels du serveur WL sont évalués et analysés du texte vers des objets Javascript de manière extrêmement sûre et s'il n'y a jamais de chance que le texte du paramètre puisse être exécuté en tant que code Javascript sur le serveur. ?

Si tel est le cas, existe-t-il d'autres types d'attaques possibles contre lesquelles l'implémentation Javascript du serveur WL est sécurisée et dont nous ne sommes peut-être même pas conscients ?

Answer 1

Les paramètres sont reçus par les adaptateurs sous forme de chaîne/int/bool/array etc.Le framework d'adaptateur n'évaluera et n'exécutera jamais vos paramètres, donc à moins que vous n'utilisiez explicitement eval(param) quelque part dans votre code, tout va bien.

Un autre élément de protection du cadre d'adaptateur WL consiste à envelopper la réponse de l'adaptateur dans un commentaire.Par exemple.si votre adaptateur renvoie {val:1}, le corps de la réponse réelle contiendra

/* secure {val:1} */

Cela empêche JS d'être exécuté même s'il est automatiquement évalué par un client, par ex.lorsqu'il est chargé à partir d'un <script src="...">