JSF与PrimeFaces 10.0.0的CSRF防护异常问题求助

可能的问题根源 #

• PrimeFaces CSRF防护未正确触发
• 混淆了PrimeFaces nonce与JSF原生CSRF机制的作用范围
• 配置缺失或容器（WildFly）默认设置干扰

排查与修复步骤 #

1. 确认PrimeFaces CSRF防护配置 #

PrimeFaces 10的CSRF防护默认启用，但显式配置可避免潜在的默认值覆盖问题。在web.xml中添加以下参数：

<context-param>
    <param-name>primefaces.CSRF_PROTECTION</param-name>
    <param-value>true</param-value>
</context-param>

2. 区分请求类型对应的防护机制 #

• PrimeFaces AJAX请求：依赖primefaces.nonce参数（或X-PrimeFaces-CSRF-TOKEN请求头），若删除/修改该参数后请求仍能执行，需排查：
  • 页面交互组件是否被<h:form>或<p:form>包裹（nonce仅注入到表单内的AJAX请求）
  • 是否有自定义过滤器绕过了PrimeFaces的CSRF校验逻辑
  • 查看服务器日志，确认是否存在Invalid CSRF token类错误（无日志则说明校验逻辑未触发）
• 普通JSF表单请求：依赖JSF原生的ViewState签名防护（当STATE_SAVING_METHOD=server时，ViewState为加密签名格式）。此时修改primefaces.nonce不会影响请求，需测试修改javax.faces.ViewState值是否被拦截——若仍能执行，说明JSF原生CSRF防护未生效：
  • 确认javax.faces.ENABLE_CSRF=true配置已正确加载（可通过打印上下文参数验证）
  • 检查WildFly是否配置了自定义JSF密钥（javax.faces.SECRET），缺失密钥可能导致签名校验失效

3. 验证容器层面的干扰 #

WildFly 23自带Mojarra 2.3.x，需确保：

• 未部署冲突的JSF实现包（避免覆盖容器自带版本）
• 未配置全局安全过滤器（如OAuth、自定义Auth过滤器）跳过CSRF校验步骤

4. 标准场景测试 #

创建最小测试页面验证防护是否生效：

<h:form>
    <p:commandButton value="Test AJAX CSRF" action="#{bean.test}" ajax="true" />
    <h:commandButton value="Test JSF CSRF" action="#{bean.test}" />
</h:form>

用Burp分别修改两个请求的primefaces.nonce和javax.faces.ViewState，观察是否被拦截。

常见误区澄清 #

• primefaces.nonce仅对PrimeFaces的AJAX请求生效，普通JSF表单不依赖该参数，请勿混淆两种防护机制
• JSF的javax.faces.ENABLE_CSRF=true仅启用原生CSRF防护，不会直接控制PrimeFaces的nonce校验逻辑

内容的提问来源于stack exchange，提问作者Marc Jordana Vilà