Question

在我的项目中，我在表示层和持久层上进行了重复验证，希望提高安全性。所以我的问题是：标准JSF验证可以防止代码注入。

<h:inputText id="name" value="#{bean.customer.name}" required="true" requiredMessage="Validation Error: Value is required." title="Name" >
      <f:validateLength maximum="40"/>
</h:inputText>

这里我验证字段是否为空，并验证字段长度。我知道验证字段长度会使代码注入变得更难，但有时你需要一个很长的字段长度，例如textArea。如果这是脆弱的，我将如何解决它？非常感谢你。

Answer 1

默认情况下，JSF通过转发UIInput和UIOutput组件中的用户控制输入来阻止XSS attacks。这可以通过设置h:outputText属性在escape="false"中进行控制。你不必担心这个。

另一方面，预防SQL injection attacks不是JSF的责任。您需要在持久层中处理此问题。例如JPA和/或Hibernate，当使用得很好时（即不在SQL /命名查询字符串中连接用户控制的输入），默认情况下也已经阻止了它。在普通的JDBC中，您需要确保使用PreparedStatement而不是Statement在SQL字符串中包含用户控制的输入。如果使用得当，您也无需在JSF方面担心这一点。

相关问题：

Answer 2

注入攻击有一个共同的主题：由于应用程序中的各种缺陷，输入数据在某个时间点被转换并解释为代码。最常见的缺陷是未经正确编码或转义的未经过数据处理的数据。单独存在或不存在编码不能保护应用程序免受攻击 - 必须对允许将代码转换为数据的字符进行编码，以使它们不被区分为代码。

现在，从JSF的角度来看，设计人员一直在思考如何防范某些类型的攻击。由于它是一个表示层框架，因此存在防止XSS攻击（和CSRF攻击，尽管它与注入无关）的保护。在Cross Site Scripting和Cross Site Request Forgery的Seam框架页面中详细讨论了保护机制及其安全使用。 Seam使用JSF，因此从XSS和CSRF保护JSF应用程序和Seam应用程序没有太大区别;这些页面中的大多数建议都必须在JSF应用程序中保持良好状态。

但是，如果您需要保护自己免受其他突出的注入攻击，特别是SQL注入攻击，您需要查看持久性框架提供的功能（假设您将使用它）。如果您手动编写SQL查询并直接在代码中执行它们，请使用PreparedStatement对象来保护自己免受最常见的SQL注入攻击。如果你正在使用JPA，JDO等，你需要安全地使用这样的框架 - 大多数框架默认创建PreparedStatement对象，当查询被提供给它们时，通常不需要担心。

防止JPA中的SQL注入攻击

命名和本机查询将在内部转换为使用参数化查询的预准备语句。这是JPA提供商的责任。人们需要担心在交付给提供者之前构建的SQL查询。基本上传递给EntityManager.createQuery（）和EntityManager.createNativeQuery（）的字符串不应该有连接的用户输入。

PS ：CSRF保护功能存在于JSF 2中，而不存在于JSF 1.x中。它也仅出现在Seam的某些版本中（2.1.2以后）。

JSF标准验证可以防止代码注入吗？

2 个答案:

相关问题：