Jsf 使用Primefaces inputText小部件时如何解码文本？

我试图将XSS预防功能添加到我的JSF/primefaces系统中。根据参考资料，我理解应该如何做：

数据在后端按原样保存（即解码）。例如，“警报（/xss/）”

当显示为输出时，web服务器（在jsf中为托管bean）将对字符进行编码。例如，“警报（/xss！/）”

浏览器将下载编码脚本并将其转换回解码方式。例如，“警报（/xss/）”要在JSF中实现这一点，我需要设置outputText属性escape=“false”，否则它将转义字符，因为这是默认行为。

除了在我的所有小部件中显式设置escape=“false”的麻烦之外，这个解决方案似乎还可以工作。然而，当我没有让outputText小部件读取我的bean时，问题就来了，我有了inputText，它将始终保持来自托管bean的编码字符串，并且永远不会将其解码回来

---

你知道我该怎么处理吗？

你似乎有一个很大的误解。IBM的这篇文章显然是针对“普通的”JSP应用程序的，这些应用程序实际上没有任何形式的自动XSS预防（尽管您最好在JSP中使用它，而不是本文所描述的那种笨拙）。然而，JSF已经内置了自动XSS预防，特别是当与Facelets一起使用作为视图技术而不是其前身JSP时

首先，您不应该在后端手动解码它。停止第1步将解决所有问题；为了防止双重转义，您不再需要在输出中使用

escape=“false”

，也不再需要担心输入中的正确表示。在JSF中，除了使用

escape=“false”

重新显示用户控制的输入外，默认情况下一切都是XSS安全的

总而言之，对于现代JavaWeb应用程序来说，IBM的那篇文章是垃圾。作者似乎有十年历史的JSP，脑子里想着Scriptlet

另见：

---

顺便说一句，该规则有一个例外：JSF 2.2之前的JSF selectItems确实需要显式转义字符视图属性itemlablescaped=“true”。来源：@Gaara：仅当这些标签包含用户控制的值时（即当将用户提交的数据重新显示为选择项标签时），才是如此。请注意，正是您真实地报告了这个问题。