L'évolution des directives de développement sécurisé

La semaine dernière, j'ai étudié les vulnérabilités de Java Spring afin de mettre à jour nos directives de développement sécurisé. En passant en revue les défis existants sur notre plateforme, j'en ai remarqué quelques-uns concernant les failles XSS liées à l'affichage de paramètres d'URL dans des pages JSP. L'exemple de code incorrect ressemblerait à ceci :

   <input type="text" name="username" value="${param.username}">

La solution correcte consistait à supprimer complètement le paramètre d'URL, et la description précise qu'échapper correctement ce paramètre est également une méthode sûre.

Mon travail consiste désormais à formuler cette directive de manière claire pour les développeurs, en les limitant le moins possible tout en garantissant la sécurité du code. Dans ce cas, je préfère leur permettre de conserver la fonctionnalité souhaitée en leur recommandant de sécuriser le paramètre d'URL par échappement. Ainsi, le code n'est plus vulnérable aux failles XSS. L'exemple ci-dessus peut être sécurisé comme suit :

   <input type="text" name="username" value="${fn:escapeXml(param.username)}">

C'était notre directive de sécurité pendant quelques jours, jusqu'à ce que je tombe sur une page de l'OWASP concernant l'injection par langage d'expression. Cette page décrit comment le Spring Expression Language (SpEL) peut être détourné pour des injections aux conséquences graves, notamment l'exécution de code à distance. Il m'appartenait de déterminer si du code respectant nos directives pouvait encore être vulnérable. J'ai donc créé une application de test rapide pour évaluer les expressions SpEL, avec et sans échappement XML, afin d'identifier des scénarios non détectés. J'en ai trouvé : il existe des expressions malveillantes ne contenant aucun caractère filtré par XmlEscape. J'ai publié la démonstration sur notre GitHub, disponible ici.

J'ai évidemment mis à jour notre directive de sécurité, qui stipule désormais : « Ne pas afficher ni évaluer les paramètres d'URL à l'aide du Spring Expression Language (SpEL). »

L'impact global de cette vulnérabilité est élevé pour les raisons suivantes : - Un attaquant pourrait modifier et invoquer des fonctionnalités sur le serveur d'application. - Accès non autorisé aux données et fonctionnalités, détournement de compte et exécution de code à distance. - Risques pour la confidentialité et l'intégrité.

https://www.owasp.org/index.php/Expression_Language_Injection