Wie sich die Richtlinien für sichere Codierung entwickeln
Last week I was researching vulnerabilities in Java Spring to bring our secure coding guidelines up to date. I was going through the existing challenges on our platform and noticed a few on XSS through displaying url parameters in JSP pages. The incorrect code example would look something similar to the following:
<input type="text" name="username" value="${param.username}">
The correct solution was removing the URL parameter altogether and the description mentions that escaping the URL parameter the correct way is also safe.
Now, my job is to formulate the secure coding guideline in a way that is clear to developers and restricts them as little as possible while still writing secure code. In this case, I would prefer to let developers keep their intended functionality and recommend them to do it securely by escaping the URL parameter. This way, the code no longer contains a XSS vulnerability. The above example can be secured like this:
<input type="text" name="username" value="${fn:escapeXml(param.username)}">
And this was our secure coding guideline for a few days, until I stumbled on an OWASP page on expression language injection. This page describes how the Spring Expression Language (SpEL) can be abused for injection with some serious impact, including remote code execution. It was up to me to figure out if there could be cases where code adhering to our secure coding guideline can still be affected by this vulnerability. So I wrote a quick test application to evaluate SpEL expressions, and tested input with and without Xml escaping to see if I could find some scenarios that would not be caught. And I did, there are malicious expressions that do not contain any characters caught by XmlEscape. I published the working demo on our github, which you can find here.
And of course I updated our secure coding guideline which now reads: "Do not display or evaluate URL parameters using the Spring Expression Language (SpEL)."
The overall impact of this issue is High, for the following reasons: - An attacker could modify and invoke functionality on the application server. - Unauthorized access to data and functionality, as well as account hijacking and remote code execution. - Confidentiality, and Integrity concerns from a successful attack.
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 ist für Ihr Unternehmen da, um Ihnen zu helfen, Code während des gesamten Softwareentwicklungszyklus zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder jemand anderes sind, der sich mit Sicherheit befasst, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Eine Demo buchen
Forscher für Anwendungssicherheit - Forschungs- und Entwicklungsingenieur - Doktorand
Last week I was researching vulnerabilities in Java Spring to bring our secure coding guidelines up to date. I was going through the existing challenges on our platform and noticed a few on XSS through displaying url parameters in JSP pages. The incorrect code example would look something similar to the following:
<input type="text" name="username" value="${param.username}">
The correct solution was removing the URL parameter altogether and the description mentions that escaping the URL parameter the correct way is also safe.
Now, my job is to formulate the secure coding guideline in a way that is clear to developers and restricts them as little as possible while still writing secure code. In this case, I would prefer to let developers keep their intended functionality and recommend them to do it securely by escaping the URL parameter. This way, the code no longer contains a XSS vulnerability. The above example can be secured like this:
<input type="text" name="username" value="${fn:escapeXml(param.username)}">
And this was our secure coding guideline for a few days, until I stumbled on an OWASP page on expression language injection. This page describes how the Spring Expression Language (SpEL) can be abused for injection with some serious impact, including remote code execution. It was up to me to figure out if there could be cases where code adhering to our secure coding guideline can still be affected by this vulnerability. So I wrote a quick test application to evaluate SpEL expressions, and tested input with and without Xml escaping to see if I could find some scenarios that would not be caught. And I did, there are malicious expressions that do not contain any characters caught by XmlEscape. I published the working demo on our github, which you can find here.
And of course I updated our secure coding guideline which now reads: "Do not display or evaluate URL parameters using the Spring Expression Language (SpEL)."
The overall impact of this issue is High, for the following reasons: - An attacker could modify and invoke functionality on the application server. - Unauthorized access to data and functionality, as well as account hijacking and remote code execution. - Confidentiality, and Integrity concerns from a successful attack.
https://www.owasp.org/index.php/Expression_Language_Injection
Last week I was researching vulnerabilities in Java Spring to bring our secure coding guidelines up to date. I was going through the existing challenges on our platform and noticed a few on XSS through displaying url parameters in JSP pages. The incorrect code example would look something similar to the following:
<input type="text" name="username" value="${param.username}">
The correct solution was removing the URL parameter altogether and the description mentions that escaping the URL parameter the correct way is also safe.
Now, my job is to formulate the secure coding guideline in a way that is clear to developers and restricts them as little as possible while still writing secure code. In this case, I would prefer to let developers keep their intended functionality and recommend them to do it securely by escaping the URL parameter. This way, the code no longer contains a XSS vulnerability. The above example can be secured like this:
<input type="text" name="username" value="${fn:escapeXml(param.username)}">
And this was our secure coding guideline for a few days, until I stumbled on an OWASP page on expression language injection. This page describes how the Spring Expression Language (SpEL) can be abused for injection with some serious impact, including remote code execution. It was up to me to figure out if there could be cases where code adhering to our secure coding guideline can still be affected by this vulnerability. So I wrote a quick test application to evaluate SpEL expressions, and tested input with and without Xml escaping to see if I could find some scenarios that would not be caught. And I did, there are malicious expressions that do not contain any characters caught by XmlEscape. I published the working demo on our github, which you can find here.
And of course I updated our secure coding guideline which now reads: "Do not display or evaluate URL parameters using the Spring Expression Language (SpEL)."
The overall impact of this issue is High, for the following reasons: - An attacker could modify and invoke functionality on the application server. - Unauthorized access to data and functionality, as well as account hijacking and remote code execution. - Confidentiality, and Integrity concerns from a successful attack.
https://www.owasp.org/index.php/Expression_Language_Injection
Klicken Sie auf den Link unten und laden Sie das PDF dieser Ressource herunter.
Secure Code Warrior ist für Ihr Unternehmen da, um Ihnen zu helfen, Code während des gesamten Softwareentwicklungszyklus zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder jemand anderes sind, der sich mit Sicherheit befasst, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Bericht ansehenEine Demo buchen
Forscher für Anwendungssicherheit - Forschungs- und Entwicklungsingenieur - Doktorand
Last week I was researching vulnerabilities in Java Spring to bring our secure coding guidelines up to date. I was going through the existing challenges on our platform and noticed a few on XSS through displaying url parameters in JSP pages. The incorrect code example would look something similar to the following:
<input type="text" name="username" value="${param.username}">
The correct solution was removing the URL parameter altogether and the description mentions that escaping the URL parameter the correct way is also safe.
Now, my job is to formulate the secure coding guideline in a way that is clear to developers and restricts them as little as possible while still writing secure code. In this case, I would prefer to let developers keep their intended functionality and recommend them to do it securely by escaping the URL parameter. This way, the code no longer contains a XSS vulnerability. The above example can be secured like this:
<input type="text" name="username" value="${fn:escapeXml(param.username)}">
And this was our secure coding guideline for a few days, until I stumbled on an OWASP page on expression language injection. This page describes how the Spring Expression Language (SpEL) can be abused for injection with some serious impact, including remote code execution. It was up to me to figure out if there could be cases where code adhering to our secure coding guideline can still be affected by this vulnerability. So I wrote a quick test application to evaluate SpEL expressions, and tested input with and without Xml escaping to see if I could find some scenarios that would not be caught. And I did, there are malicious expressions that do not contain any characters caught by XmlEscape. I published the working demo on our github, which you can find here.
And of course I updated our secure coding guideline which now reads: "Do not display or evaluate URL parameters using the Spring Expression Language (SpEL)."
The overall impact of this issue is High, for the following reasons: - An attacker could modify and invoke functionality on the application server. - Unauthorized access to data and functionality, as well as account hijacking and remote code execution. - Confidentiality, and Integrity concerns from a successful attack.
https://www.owasp.org/index.php/Expression_Language_Injection
Inhaltsverzeichniss
Forscher für Anwendungssicherheit - Forschungs- und Entwicklungsingenieur - Doktorand
Secure Code Warrior ist für Ihr Unternehmen da, um Ihnen zu helfen, Code während des gesamten Softwareentwicklungszyklus zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder jemand anderes sind, der sich mit Sicherheit befasst, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Eine Demo buchenHerunterladenRessourcen für den Einstieg
Themen und Inhalte der Securecode-Schulung
Unsere branchenführenden Inhalte werden ständig weiterentwickelt, um der sich ständig ändernden Softwareentwicklungslandschaft unter Berücksichtigung Ihrer Rolle gerecht zu werden. Themen, die alles von KI bis XQuery Injection abdecken und für eine Vielzahl von Rollen angeboten werden, von Architekten und Ingenieuren bis hin zu Produktmanagern und QA. Verschaffen Sie sich einen kleinen Einblick in das Angebot unseres Inhaltskatalogs nach Themen und Rollen.
%20(1).avif)
.avif)
Threat Modeling with AI: Turning Every Developer into a Threat Modeler
Walk away better equipped to help developers combine threat modeling ideas and techniques with the AI tools they're already using to strengthen security, improve collaboration, and build more resilient software from the start.
Ressourcen für den Einstieg
Cybermon is back: Beat the Boss KI-Missionen jetzt auf Abruf verfügbar
Cybermon 2025 Beat the Boss ist jetzt das ganze Jahr über in SCW verfügbar. Setzt fortschrittliche KI/LLM-Sicherheitsanforderungen ein, um die sichere KI-Entwicklung in einem großen Maßstab zu stärken.
Cyber-Resilienz-Gesetz erklärt: Was das für die Entwicklung von Secure by Design-Software bedeutet
Erfahren Sie, was der EU Cyber Resilience Act (CRA) verlangt, für wen er gilt und wie sich Entwicklungsteams mit sicheren Methoden, der Vorbeugung von Sicherheitslücken und dem Aufbau von Fähigkeiten für Entwickler darauf vorbereiten können.
