安全编码准则是如何演变的
上周，我正在研究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
上周，我正在研究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
上周，我正在研究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
上周，我正在研究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
