安全编码指南是如何演变的

上周我正在研究 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