安全编码指南是如何演变的
上周我正在研究 Java Spring 中的漏洞，以更新我们的安全编码指南。我正在研究我们平台上现有的挑战，并通过在JSP页面中显示网址参数在XSS上发现了一些挑战。不正确的代码示例看起来与以下内容类似：
<input type="text" name="username" value="${param.username}">
正确的解决方案是完全删除 URL 参数，描述中提到，以正确的方式转义 URL 参数也是安全的。
现在，我的工作是以开发人员清楚的方式制定安全编码指南，并在编写安全代码的同时尽可能减少对他们的限制。在这种情况下，我更愿意让开发人员保留其预期功能，并建议他们通过转义 URL 参数来安全地执行此操作。这样，代码就不再包含 XSS 漏洞了。上面的例子可以这样保护：
<input type="text" name="username" value="${fn:escapeXml(param.username)}">
这是我们几天来的安全编码指南，直到我偶然发现了一个 关于表达式语言注入的 OWASP 页面。本页介绍如何滥用 Spring 表达式语言 (SpEL) 进行注入，从而产生一些严重影响，包括远程代码执行。我有责任弄清楚是否存在符合我们安全编码指南的代码仍然会受到此漏洞影响的情况。因此，我编写了一个快速测试应用程序来评估 SpEL 表达式，并测试了使用和不使用 Xml 转义的输入，看看能否找到一些无法捕捉到的场景。我做到了，有些恶意表达式不包含 XmleScape 捕获的任何字符。我在我们的 github 上发布了工作演示，你可以找到 这里。
当然，我更新了我们的安全编码指南，现在内容是：“不要使用 Spring 表达语言 (SpEL) 显示或评估 URL 参数。”
此问题的总体影响很大，原因如下：-攻击者可以修改和调用应用程序服务器上的功能。-未经授权访问数据和功能，以及账户劫持和远程执行代码。-成功攻击带来的机密性和完整性问题。
https://www.owasp.org/index.php/Expression_Language_Injection
Application Security Researcher - R&D Engineer - PhD Candidate
Secure Code Warrior可以帮助您的组织在整个软件开发生命周期中保护代码，并营造一种将网络安全放在首位的文化。无论您是 AppSec 经理、开发人员、首席信息安全官还是任何与安全相关的人，我们都可以帮助您的组织降低与不安全代码相关的风险。
预订演示
Application Security Researcher - R&D Engineer - PhD Candidate
上周我正在研究 Java Spring 中的漏洞，以更新我们的安全编码指南。我正在研究我们平台上现有的挑战，并通过在JSP页面中显示网址参数在XSS上发现了一些挑战。不正确的代码示例看起来与以下内容类似：
<input type="text" name="username" value="${param.username}">
正确的解决方案是完全删除 URL 参数，描述中提到，以正确的方式转义 URL 参数也是安全的。
现在，我的工作是以开发人员清楚的方式制定安全编码指南，并在编写安全代码的同时尽可能减少对他们的限制。在这种情况下，我更愿意让开发人员保留其预期功能，并建议他们通过转义 URL 参数来安全地执行此操作。这样，代码就不再包含 XSS 漏洞了。上面的例子可以这样保护：
<input type="text" name="username" value="${fn:escapeXml(param.username)}">
这是我们几天来的安全编码指南，直到我偶然发现了一个 关于表达式语言注入的 OWASP 页面。本页介绍如何滥用 Spring 表达式语言 (SpEL) 进行注入，从而产生一些严重影响，包括远程代码执行。我有责任弄清楚是否存在符合我们安全编码指南的代码仍然会受到此漏洞影响的情况。因此，我编写了一个快速测试应用程序来评估 SpEL 表达式，并测试了使用和不使用 Xml 转义的输入，看看能否找到一些无法捕捉到的场景。我做到了，有些恶意表达式不包含 XmleScape 捕获的任何字符。我在我们的 github 上发布了工作演示，你可以找到 这里。
当然，我更新了我们的安全编码指南，现在内容是：“不要使用 Spring 表达语言 (SpEL) 显示或评估 URL 参数。”
此问题的总体影响很大，原因如下：-攻击者可以修改和调用应用程序服务器上的功能。-未经授权访问数据和功能，以及账户劫持和远程执行代码。-成功攻击带来的机密性和完整性问题。
https://www.owasp.org/index.php/Expression_Language_Injection
上周我正在研究 Java Spring 中的漏洞，以更新我们的安全编码指南。我正在研究我们平台上现有的挑战，并通过在JSP页面中显示网址参数在XSS上发现了一些挑战。不正确的代码示例看起来与以下内容类似：
<input type="text" name="username" value="${param.username}">
正确的解决方案是完全删除 URL 参数，描述中提到，以正确的方式转义 URL 参数也是安全的。
现在，我的工作是以开发人员清楚的方式制定安全编码指南，并在编写安全代码的同时尽可能减少对他们的限制。在这种情况下，我更愿意让开发人员保留其预期功能，并建议他们通过转义 URL 参数来安全地执行此操作。这样，代码就不再包含 XSS 漏洞了。上面的例子可以这样保护：
<input type="text" name="username" value="${fn:escapeXml(param.username)}">
这是我们几天来的安全编码指南，直到我偶然发现了一个 关于表达式语言注入的 OWASP 页面。本页介绍如何滥用 Spring 表达式语言 (SpEL) 进行注入，从而产生一些严重影响，包括远程代码执行。我有责任弄清楚是否存在符合我们安全编码指南的代码仍然会受到此漏洞影响的情况。因此，我编写了一个快速测试应用程序来评估 SpEL 表达式，并测试了使用和不使用 Xml 转义的输入，看看能否找到一些无法捕捉到的场景。我做到了，有些恶意表达式不包含 XmleScape 捕获的任何字符。我在我们的 github 上发布了工作演示，你可以找到 这里。
当然，我更新了我们的安全编码指南，现在内容是：“不要使用 Spring 表达语言 (SpEL) 显示或评估 URL 参数。”
此问题的总体影响很大，原因如下：-攻击者可以修改和调用应用程序服务器上的功能。-未经授权访问数据和功能，以及账户劫持和远程执行代码。-成功攻击带来的机密性和完整性问题。
https://www.owasp.org/index.php/Expression_Language_Injection
上周我正在研究 Java Spring 中的漏洞，以更新我们的安全编码指南。我正在研究我们平台上现有的挑战，并通过在JSP页面中显示网址参数在XSS上发现了一些挑战。不正确的代码示例看起来与以下内容类似：
<input type="text" name="username" value="${param.username}">
正确的解决方案是完全删除 URL 参数，描述中提到，以正确的方式转义 URL 参数也是安全的。
现在，我的工作是以开发人员清楚的方式制定安全编码指南，并在编写安全代码的同时尽可能减少对他们的限制。在这种情况下，我更愿意让开发人员保留其预期功能，并建议他们通过转义 URL 参数来安全地执行此操作。这样，代码就不再包含 XSS 漏洞了。上面的例子可以这样保护：
<input type="text" name="username" value="${fn:escapeXml(param.username)}">
这是我们几天来的安全编码指南，直到我偶然发现了一个 关于表达式语言注入的 OWASP 页面。本页介绍如何滥用 Spring 表达式语言 (SpEL) 进行注入，从而产生一些严重影响，包括远程代码执行。我有责任弄清楚是否存在符合我们安全编码指南的代码仍然会受到此漏洞影响的情况。因此，我编写了一个快速测试应用程序来评估 SpEL 表达式，并测试了使用和不使用 Xml 转义的输入，看看能否找到一些无法捕捉到的场景。我做到了，有些恶意表达式不包含 XmleScape 捕获的任何字符。我在我们的 github 上发布了工作演示，你可以找到 这里。
当然，我更新了我们的安全编码指南，现在内容是：“不要使用 Spring 表达语言 (SpEL) 显示或评估 URL 参数。”
此问题的总体影响很大，原因如下：-攻击者可以修改和调用应用程序服务器上的功能。-未经授权访问数据和功能，以及账户劫持和远程执行代码。-成功攻击带来的机密性和完整性问题。
https://www.owasp.org/index.php/Expression_Language_Injection
帮助您入门的资源
%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.
