Wie sich die Richtlinien für sichere Codierung entwickeln
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
Letzte Woche habe ich nach Sicherheitslücken in Java Spring gesucht, um unsere Richtlinien für sicheres Codieren auf den neuesten Stand zu bringen.
Forscher für Anwendungssicherheit - Forschungs- und Entwicklungsingenieur - Doktorand
Secure Code Warrior là pour aider votre entreprise à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture où la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité des systèmes d'information ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre entreprise à réduire les risques liés à un code non sécurisé.
Réserver une démonstration
Forscher für Anwendungssicherheit - Forschungs- und Entwicklungsingenieur - Doktorand
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
Veuillez cliquer sur le lien ci-dessous et télécharger le PDF de cette ressource.
Secure Code Warrior là pour aider votre entreprise à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture où la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité des systèmes d'information ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre entreprise à réduire les risques liés à un code non sécurisé.
Consulter le rapportRéserver une démonstration
Forscher für Anwendungssicherheit - Forschungs- und Entwicklungsingenieur - Doktorand
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
Forscher für Anwendungssicherheit - Forschungs- und Entwicklungsingenieur - Doktorand
Secure Code Warrior là pour aider votre entreprise à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture où la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité des systèmes d'information ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre entreprise à réduire les risques liés à un code non sécurisé.
Réserver une démonstrationTéléchargerRessources pour débuter
Trust Agent:AI - Secure and scale AI-Drive development
AI is writing code. Who’s governing it? With up to 50% of AI-generated code containing security weaknesses, managing AI risk is critical. Discover how SCW's Trust Agent: AI provides the real-time visibility, proactive governance, and targeted upskilling needed to scale AI-driven development securely.
La puissance de la sécurité des applications OpenText + Secure Code Warrior
OpenText Application Security and Secure Code Warrior combine vulnerability detection with AI Software Governance and developer capability. Together, they help organizations reduce risk, strengthen secure coding practices, and confidently adopt AI-driven development.
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 contenus de la formation Securecode
Nos contenus de pointe sont constamment développés afin de s'adapter à l'évolution constante du paysage du développement logiciel, en tenant compte de votre rôle. Les thèmes abordés couvrent tous les domaines, de l'IA à l'injection XQuery, et sont proposés pour une multitude de rôles, des architectes et ingénieurs aux chefs de produit et responsables assurance qualité. Nous vous invitons à découvrir un aperçu de notre catalogue de contenus classés par thème et par rôle.
Ressources pour débuter
Cybermon est de retour : les missions KI « Beat the Boss » sont désormais disponibles sur demande.
Cybermon 2025 Beat the Boss est désormais disponible toute l'année dans SCW. Il utilise des exigences de sécurité IA/LLM avancées pour renforcer le développement sécurisé de l'IA à grande échelle.
Explication de la loi sur la cyber-résilience : implications pour le développement de logiciels sécurisés dès la conception
Découvrez les exigences de la loi européenne sur la cyber-résilience (CRA), à qui elle s'applique et comment les équipes de développement peuvent s'y préparer en adoptant des méthodes sécurisées, en prévenant les failles de sécurité et en renforçant les compétences des développeurs.
Facteur 1 : Critères de réussite définis et mesurables
Le catalyseur n° 1 inaugure notre série en dix parties intitulée « Les catalyseurs de la réussite » et démontre comment un codage sécurisé peut être associé à des résultats commerciaux tels que la réduction des risques et la rapidité afin d'atteindre une maturité programmatique à long terme.