How secure coding guidelines evolve
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.
Application Security Researcher - R&D Engineer - PhD Candidate
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
Book a demo
Application Security Researcher - R&D Engineer - PhD Candidate
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
Click on the link below and download the PDF of this resource.
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
View reportBook a demo
Application Security Researcher - R&D Engineer - PhD Candidate
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
Table of contents
Application Security Researcher - R&D Engineer - PhD Candidate
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
Book a demoDownloadResources to get you started
Secure by Design: Defining Best Practices, Enabling Developers and Benchmarking Preventative Security Outcomes
In this research paper, Secure Code Warrior co-founders, Pieter Danhieux and Dr. Matias Madou, Ph.D., along with expert contributors, Chris Inglis, Former US National Cyber Director (now Strategic Advisor to Paladin Capital Group), and Devin Lynch, Senior Director, Paladin Global Institute, will reveal key findings from over twenty in-depth interviews with enterprise security leaders including CISOs, a VP of Application Security, and software security professionals.
Benchmarking Security Skills: Streamlining Secure-by-Design in the Enterprise
Finding meaningful data on the success of Secure-by-Design initiatives is notoriously difficult. CISOs are often challenged when attempting to prove the return on investment (ROI) and business value of security program activities at both the people and company levels. Not to mention, it’s particularly difficult for enterprises to gain insights into how their organizations are benchmarked against current industry standards. The President’s National Cybersecurity Strategy challenged stakeholders to “embrace security and resilience by design.” The key to making Secure-by-Design initiatives work is not only giving developers the skills to ensure secure code, but also assuring the regulators that those skills are in place. In this presentation, we share a myriad of qualitative and quantitative data, derived from multiple primary sources, including internal data points collected from over 250,000 developers, data-driven customer insights, and public studies. Leveraging this aggregation of data points, we aim to communicate a vision of the current state of Secure-by-Design initiatives across multiple verticals. The report details why this space is currently underutilized, the significant impact a successful upskilling program can have on cybersecurity risk mitigation, and the potential to eliminate categories of vulnerabilities from a codebase.
Secure code training topics & content
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 peak of what our content catalog has to offer by topic and role.
Resources to get you started
Revealed: How the Cyber Industry Defines Secure by Design
In our latest white paper, our Co-Founders, Pieter Danhieux and Dr. Matias Madou, Ph.D., sat down with over twenty enterprise security leaders, including CISOs, AppSec leaders and security professionals, to figure out the key pieces of this puzzle and uncover the reality behind the Secure by Design movement. It’s a shared ambition across the security teams, but no shared playbook.
Is Vibe Coding Going to Turn Your Codebase Into a Frat Party?
Vibe coding is like a college frat party, and AI is the centerpiece of all the festivities, the keg. It’s a lot of fun to let loose, get creative, and see where your imagination can take you, but after a few keg stands, drinking (or, using AI) in moderation is undoubtedly the safer long-term solution.
Developer-driven coding.
Securely.
Contact us today and make software security an intrinsic part of your development process.
