Comment évoluent les lignes directrices en matière de codage sécurisé ?
La semaine dernière, j'ai fait des recherches sur les vulnérabilités de Java Spring afin de mettre à jour nos lignes directrices en matière de codage sécurisé. J'ai passé en revue les défis existants sur notre plateforme et j'en ai remarqué quelques-uns concernant les XSS par l'affichage de 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 solution correcte consistait à supprimer complètement le paramètre URL et la description mentionne qu'il est également possible d'échapper le paramètre URL de la bonne manière.
Maintenant, mon travail consiste à formuler la ligne directrice sur le codage sécurisé d'une manière qui soit claire pour les développeurs et qui les restreigne le moins possible tout en continuant à écrire du code sécurisé. Dans ce cas, je préférerais laisser les développeurs conserver la fonctionnalité prévue et leur recommander de le faire de manière sécurisée en échappant le paramètre URL. De cette manière, 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)}">
C'était notre ligne de conduite en matière de codage sécurisé pendant quelques jours, jusqu'à ce que je tombe sur une page de l'OWASP sur l'injection de langage d'expression. Cette page décrit comment le langage d'expression Spring (SpEL) peut être utilisé de manière abusive à des fins d'injection avec un impact sérieux, y compris l'exécution de code à distance. Il m'incombait de déterminer s'il pouvait y avoir des cas où un code adhérant à notre directive de codage sécurisé pouvait encore ê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 échappement Xml pour voir si je pouvais trouver des scénarios qui ne seraient pas pris en compte. Et c'est ce que j'ai fait, il y a des expressions malveillantes qui ne contiennent aucun caractère pris en compte 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 ligne directrice sur le codage sécurisé, qui se lit désormais comme suit : "N'affichez pas et n'évaluez pas les paramètres d'URL en utilisant le langage d'expression Spring (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'application. - Accès non autorisé aux données et aux fonctionnalités, ainsi que détournement de compte et exécution de code à distance. - Problèmes de confidentialité et d'intégrité en cas d'attaque réussie.
https://www.owasp.org/index.php/Expression_Language_Injection
La semaine dernière, j'ai recherché des vulnérabilités dans Java Spring afin de mettre à jour nos lignes directrices en matière de codage sécurisé.
Chercheur en sécurité applicative - Ingénieur R&D - Doctorant
Secure Code Warrior est là pour vous aider à sécuriser le code tout au long du cycle de vie du développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Réservez une démonstration
Chercheur en sécurité applicative - Ingénieur R&D - Doctorant
La semaine dernière, j'ai fait des recherches sur les vulnérabilités de Java Spring afin de mettre à jour nos lignes directrices en matière de codage sécurisé. J'ai passé en revue les défis existants sur notre plateforme et j'en ai remarqué quelques-uns concernant les XSS par l'affichage de 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 solution correcte consistait à supprimer complètement le paramètre URL et la description mentionne qu'il est également possible d'échapper le paramètre URL de la bonne manière.
Maintenant, mon travail consiste à formuler la ligne directrice sur le codage sécurisé d'une manière qui soit claire pour les développeurs et qui les restreigne le moins possible tout en continuant à écrire du code sécurisé. Dans ce cas, je préférerais laisser les développeurs conserver la fonctionnalité prévue et leur recommander de le faire de manière sécurisée en échappant le paramètre URL. De cette manière, 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)}">
C'était notre ligne de conduite en matière de codage sécurisé pendant quelques jours, jusqu'à ce que je tombe sur une page de l'OWASP sur l'injection de langage d'expression. Cette page décrit comment le langage d'expression Spring (SpEL) peut être utilisé de manière abusive à des fins d'injection avec un impact sérieux, y compris l'exécution de code à distance. Il m'incombait de déterminer s'il pouvait y avoir des cas où un code adhérant à notre directive de codage sécurisé pouvait encore ê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 échappement Xml pour voir si je pouvais trouver des scénarios qui ne seraient pas pris en compte. Et c'est ce que j'ai fait, il y a des expressions malveillantes qui ne contiennent aucun caractère pris en compte 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 ligne directrice sur le codage sécurisé, qui se lit désormais comme suit : "N'affichez pas et n'évaluez pas les paramètres d'URL en utilisant le langage d'expression Spring (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'application. - Accès non autorisé aux données et aux fonctionnalités, ainsi que détournement de compte et exécution de code à distance. - Problèmes de confidentialité et d'intégrité en cas d'attaque réussie.
https://www.owasp.org/index.php/Expression_Language_Injection
La semaine dernière, j'ai fait des recherches sur les vulnérabilités de Java Spring afin de mettre à jour nos lignes directrices en matière de codage sécurisé. J'ai passé en revue les défis existants sur notre plateforme et j'en ai remarqué quelques-uns concernant les XSS par l'affichage de 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 solution correcte consistait à supprimer complètement le paramètre URL et la description mentionne qu'il est également possible d'échapper le paramètre URL de la bonne manière.
Maintenant, mon travail consiste à formuler la ligne directrice sur le codage sécurisé d'une manière qui soit claire pour les développeurs et qui les restreigne le moins possible tout en continuant à écrire du code sécurisé. Dans ce cas, je préférerais laisser les développeurs conserver la fonctionnalité prévue et leur recommander de le faire de manière sécurisée en échappant le paramètre URL. De cette manière, 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)}">
C'était notre ligne de conduite en matière de codage sécurisé pendant quelques jours, jusqu'à ce que je tombe sur une page de l'OWASP sur l'injection de langage d'expression. Cette page décrit comment le langage d'expression Spring (SpEL) peut être utilisé de manière abusive à des fins d'injection avec un impact sérieux, y compris l'exécution de code à distance. Il m'incombait de déterminer s'il pouvait y avoir des cas où un code adhérant à notre directive de codage sécurisé pouvait encore ê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 échappement Xml pour voir si je pouvais trouver des scénarios qui ne seraient pas pris en compte. Et c'est ce que j'ai fait, il y a des expressions malveillantes qui ne contiennent aucun caractère pris en compte 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 ligne directrice sur le codage sécurisé, qui se lit désormais comme suit : "N'affichez pas et n'évaluez pas les paramètres d'URL en utilisant le langage d'expression Spring (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'application. - Accès non autorisé aux données et aux fonctionnalités, ainsi que détournement de compte et exécution de code à distance. - Problèmes de confidentialité et d'intégrité en cas d'attaque réussie.
https://www.owasp.org/index.php/Expression_Language_Injection
Cliquez sur le lien ci-dessous et téléchargez le PDF de cette ressource.
Secure Code Warrior est là pour vous aider à sécuriser le code tout au long du cycle de vie du développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Voir le rapportRéservez une démonstration
Chercheur en sécurité applicative - Ingénieur R&D - Doctorant
La semaine dernière, j'ai fait des recherches sur les vulnérabilités de Java Spring afin de mettre à jour nos lignes directrices en matière de codage sécurisé. J'ai passé en revue les défis existants sur notre plateforme et j'en ai remarqué quelques-uns concernant les XSS par l'affichage de 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 solution correcte consistait à supprimer complètement le paramètre URL et la description mentionne qu'il est également possible d'échapper le paramètre URL de la bonne manière.
Maintenant, mon travail consiste à formuler la ligne directrice sur le codage sécurisé d'une manière qui soit claire pour les développeurs et qui les restreigne le moins possible tout en continuant à écrire du code sécurisé. Dans ce cas, je préférerais laisser les développeurs conserver la fonctionnalité prévue et leur recommander de le faire de manière sécurisée en échappant le paramètre URL. De cette manière, 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)}">
C'était notre ligne de conduite en matière de codage sécurisé pendant quelques jours, jusqu'à ce que je tombe sur une page de l'OWASP sur l'injection de langage d'expression. Cette page décrit comment le langage d'expression Spring (SpEL) peut être utilisé de manière abusive à des fins d'injection avec un impact sérieux, y compris l'exécution de code à distance. Il m'incombait de déterminer s'il pouvait y avoir des cas où un code adhérant à notre directive de codage sécurisé pouvait encore ê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 échappement Xml pour voir si je pouvais trouver des scénarios qui ne seraient pas pris en compte. Et c'est ce que j'ai fait, il y a des expressions malveillantes qui ne contiennent aucun caractère pris en compte 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 ligne directrice sur le codage sécurisé, qui se lit désormais comme suit : "N'affichez pas et n'évaluez pas les paramètres d'URL en utilisant le langage d'expression Spring (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'application. - Accès non autorisé aux données et aux fonctionnalités, ainsi que détournement de compte et exécution de code à distance. - Problèmes de confidentialité et d'intégrité en cas d'attaque réussie.
https://www.owasp.org/index.php/Expression_Language_Injection
Table des matières
Chercheur en sécurité applicative - Ingénieur R&D - Doctorant
Secure Code Warrior est là pour vous aider à sécuriser le code tout au long du cycle de vie du développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Réservez une démonstrationTéléchargerRessources pour vous aider à démarrer
Secure Code Warrior corporate overview
Secure Code Warrior is an AI Software Governance platform designed to enable organizations to safely adopt AI-driven development by bridging the gap between development velocity and enterprise security. The platform addresses the "Visibility Gap," where security teams often lack insights into shadow AI coding tools and the origins of production code.
Thèmes et contenu de la formation sur le code sécurisé
Our industry-leading content is always evolving to fit the ever changing software development landscape with your role in mind. Topics covering everything from AI to XQuery Injection, offered for a variety of roles from Architects and Engineers to Product Managers and QA. Get a sneak peek of what our content catalog has to offer by topic and role.
Loi sur la cyber-résilience (CRA) Parcours d'apprentissage alignés
SCW soutient la préparation à la loi sur la cyber-résilience (CRA) grâce à des quêtes alignées sur la CRA et des collections d'apprentissage conceptuel qui aident les équipes de développement à acquérir les compétences nécessaires en matière de conception sécurisée, de SDLC et de codage sécurisé, conformément aux principes de développement sécurisé de la CRA.
La Chambre de commerce établit la norme en matière de sécurité à grande échelle axée sur les développeurs
La Chambre de commerce néerlandaise explique comment elle a intégré le codage sécurisé dans le développement quotidien grâce à des certifications basées sur les rôles, à l'évaluation comparative du Trust Score et à une culture de responsabilité partagée en matière de sécurité.
Ressources pour vous aider à démarrer
Observe and Secure the ADLC: A Four-Point Framework for CISOs and Development Teams Using AI
While development teams look to make the most of GenAI’s undeniable benefits, we’d like to propose a four-point foundational framework that will allow security leaders to deploy AI coding tools and agents with a higher, more relevant standard of security best practices. It details exactly what enterprises can do to ensure safe, secure code development right now, and as agentic AI becomes an even bigger factor in the future.
Cybermon est de retour : Missions IA « Battez le boss » sont Missions disponibles à la demande.
Cybermon 2025 Beat the Boss est désormais disponible toute l'année dans SCW. Déployez des défis de sécurité avancés en matière d'IA/LLM afin de renforcer le développement sécurisé de l'IA à grande échelle.
L'IA peut écrire et réviser du code, mais les humains assument toujours le risque
Le lancement de Claude Code Security par Anthropic marque un point de convergence décisif entre le développement de logiciels assisté par l'IA et l'évolution rapide de notre approche de la cybersécurité moderne.