SCW图标
英雄背景无分隔线
博客

Wie sich die Richtlinien für sichere Codierung entwickeln

皮特-德-克雷默
发表于 2017 年 9 月 15 日
最后更新于 2026年3月9日

上周,我正在研究Java Spring的漏洞,以使我们的安全编码准则达到最新水平。我浏览了我们平台上现有的挑战,并注意到一些关于通过在JSP页面显示url参数的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

查看资源
查看资源

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 您的Secure Code Warrior 帮助您在整个软件开发周期中保障代码安全,并建立将网络安全置于首位的企业文化。无论您是应用安全经理、开发人员、首席信息安全官,还是其他从事安全工作的人员,我们都能协助您的企业降低不安全代码带来的风险。

预约演示
分享到:
领英品牌社交x 标志
作者
皮特-德-克雷默
发表于2017年9月15日

Forscher für Anwendungssicherheit - Forschungs- und Entwicklungsingenieur - Doktorand

分享到:
领英品牌社交x 标志

上周,我正在研究Java Spring的漏洞,以使我们的安全编码准则达到最新水平。我浏览了我们平台上现有的挑战,并注意到一些关于通过在JSP页面显示url参数的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

查看资源
查看资源

请填写下方表格以下载报告

我们恳请您允许我们向您发送有关我们产品及/或安全编码相关主题的信息。我们将始终以最高标准谨慎处理您的个人数据,绝不会为营销目的将其出售给其他企业。

提交
scw 成功图标
SCW 错误图标
要提交表单,请启用“Analytics”Cookie。完成后,您可随时将其关闭。

上周,我正在研究Java Spring的漏洞,以使我们的安全编码准则达到最新水平。我浏览了我们平台上现有的挑战,并注意到一些关于通过在JSP页面显示url参数的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

观看网络研讨会
开始吧
了解更多

请点击下方链接下载该资源的PDF文件。

Secure Code Warrior 您的Secure Code Warrior 帮助您在整个软件开发周期中保障代码安全,并建立将网络安全置于首位的企业文化。无论您是应用安全经理、开发人员、首席信息安全官,还是其他从事安全工作的人员,我们都能协助您的企业降低不安全代码带来的风险。

查看报告预约演示
下载PDF文件
查看资源
分享到:
领英品牌社交x 标志
想了解更多吗?

分享到:
领英品牌社交x 标志
作者
皮特-德-克雷默
发表于2017年9月15日

Forscher für Anwendungssicherheit - Forschungs- und Entwicklungsingenieur - Doktorand

分享到:
领英品牌社交x 标志

上周,我正在研究Java Spring的漏洞,以使我们的安全编码准则达到最新水平。我浏览了我们平台上现有的挑战,并注意到一些关于通过在JSP页面显示url参数的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

目录

下载PDF文件
查看资源
想了解更多吗?

Forscher für Anwendungssicherheit - Forschungs- und Entwicklungsingenieur - Doktorand

了解更多

Secure Code Warrior 您的Secure Code Warrior 帮助您在整个软件开发周期中保障代码安全,并建立将网络安全置于首位的企业文化。无论您是应用安全经理、开发人员、首席信息安全官,还是其他从事安全工作的人员,我们都能协助您的企业降低不安全代码带来的风险。

预约演示下载
分享到:
领英品牌社交x 标志
资源中心

入门资源

更多文章
资源中心

入门资源

更多文章