Comment évoluent les directives de codage sécurisé

La semaine dernière, je faisais des recherches sur les vulnérabilités de Java Spring afin de mettre à jour nos directives de codage sécurisé. J'étais en train de passer en revue les défis existants sur notre plateforme et j'en ai remarqué quelques-uns sur XSS en affichant les paramètres d'URL dans les pages JSP. L'exemple de code incorrect ressemblerait à ce qui suit :

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

La bonne solution consistait à supprimer complètement le paramètre URL et la description indique qu'il est également sûr d'échapper au paramètre URL de la bonne manière.

Maintenant, mon travail consiste à formuler les directives de codage sécurisé de manière à ce qu'elles soient claires pour les développeurs et à les restreindre le moins possible tout en continuant à écrire du code sécurisé. Dans ce cas, je préférerais laisser les développeurs conserver les fonctionnalités prévues et leur recommander de le faire en toute sécurité en échappant au paramètre URL. De cette façon, le code ne contient plus de vulnérabilité XSS. L'exemple ci-dessus peut être sécurisé comme suit :

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

Et c'était notre directive de codage sécurisé pendant quelques jours, jusqu'à ce que je tombe sur un Page de l'OWASP sur l'injection de langage d'expression. Cette page décrit comment le Spring Expression Language (SPel) peut être utilisé de manière abusive pour l'injection avec de graves conséquences, notamment pour l'exécution de code à distance. C'était à moi de déterminer s'il pouvait y avoir des cas où le code respectant nos directives de codage sécurisé pouvait toujours être affecté par cette vulnérabilité. J'ai donc écrit une application de test rapide pour évaluer les expressions SPel, et j'ai testé les entrées avec et sans Xml s'échappant pour voir si je pouvais trouver des scénarios qui ne seraient pas détectés. Et je l'ai fait, il existe des expressions malveillantes qui ne contiennent aucun caractère détecté par XMLEscape. J'ai publié la démo de travail sur notre github, que vous pouvez trouver ici.

Et bien sûr, j'ai mis à jour notre directive de codage sécurisé qui se lit désormais comme suit : « Ne pas afficher ni évaluer les paramètres d'URL à l'aide du Spring Expression Language (SPel) ».

L'impact global de ce problème est élevé, pour les raisons suivantes : - Un attaquant pourrait modifier et invoquer des fonctionnalités sur le serveur d'applications. - Accès non autorisé aux données et aux fonctionnalités, ainsi que piratage de compte et exécution de code à distance. - Problèmes de confidentialité et d'intégrité liés à une attaque réussie.

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