Security 在JSF组件中使用呈现的安全性是否足以防止伪造的操作调用？

我们一直在使用定制的@Secure拦截器保护我们的支持bean方法，以防止伪造方法调用

但最近，我突然意识到，如果调用动作的组件没有呈现，那么这些方法是不可访问的。据我所知，JSF将生成该视图，如果该组件不是基于权限呈现的（例如，使用isUserInRole的EL），则将该组件作为源的任何伪造帖子都不会触发，因为在还原的视图中找不到该组件。这是正确的吗

本质上，任何伪造都必须有一个泄露的当前JSESSIONID，甚至可能还有ViewState，这取决于它们是否需要相同的视图

有人能确认我的假设是正确的吗？如果可能的话，给我指出规范中的一个地方

---

谢谢

绝对需要会话ID。但是如果一个用户登录了，就可以很容易地访问它——我指的是一个用户登录的情况，但是假定用户没有访问特定方法的权限

另一部分比较棘手。如果状态存储在客户端，则可以伪造。除此之外，还有一些机制可以提供到操作和页面的直接链接，比如漂亮链接或简单链接。如果该方法以上述任何一种方式公开，则应加以限制

---

我将保护它们，以防止将来不断监视以何种方式公开哪种方法的麻烦——想象一下，如果您想为应用程序添加REST或SOA接口

好的，我想我已经确认，根据规范，非渲染组件的操作确实是不可访问的

本规范第2.2.2节规定：

在应用请求值阶段，JSF实现必须 调用组件的UIViewRoot的processDecodes（）方法 树。[P1 end]这通常会导致 树中要递归调用的每个组件，如中所述 UIComponent.processDecodes（）方法的Javadocs

它还指出：

在请求值的解码期间，一些组件执行特殊操作 处理，包括：实现ActionSource的组件（例如 UICommand），识别它们已激活，将对 行动事件。事件将在应用请求结束时交付 如果组件的立即数属性为true，则为阶段值，或者 如果为false，则为调用应用程序阶段的结束

因此，ActionSource组件只有在根据processDecodes进行处理时才会对操作进行排队。查看javadoc以了解这一点：

执行应用请求所需的组件树处理 在请求处理生命周期的各个方面为 此组件、此组件的所有子组件和此组件 其本身，如下所示

• 如果此UIComponent的渲染属性为false，请进一步跳过 处理

因此，第一个检查必须是组件是否已渲染，如果未渲染，则跳过其余部分。ActionSource从不排队，也从不调用该操作

还有一点需要注意的是，根据规范，从JSF 2.2开始，ViewState似乎只对CSFR预防可靠：

以前的实现显然过于可预测，没有涵盖GET请求。规范现在要求这样做

---

因此，虽然保护服务器端可能仍然是一种良好的做法，但似乎控制ActionSource组件的呈现就足够了。

我同意，我认为最好先为将来的REST服务保护它，并了解在这种情况下，任何伪造请求都需要JSSessionID。我也不使用客户端状态保存，但承认我没有想到这一点。我想我正在寻找确认，如果我在一个支持bean上有一个像“save”这样的方法，并且我唯一调用的地方是通过一个有条件呈现的命令按钮，那么是否可以安全地假设它不可访问，除非该按钮被呈现？规范中有没有提到过这个问题？顺便说一句：我认为使用我自己的JSESSIONID来“提升”我的权限是不够的，因为我还必须提供一个ViewState id，该id与使用按钮恢复的视图相关联，如果我没有合适的角色，这就不会发生。另一点是如何防止按钮渲染。如果render属性为false，则按钮仍在树中，我认为可以伪造调用。另一方面，如果使用了c:if，那么它根本不在树中，调用失败。嗯，我不是说你错了，但我认为如果按钮的计算结果为false，它实际上不在视图树中。至少这是我的假设。我将进行一个测试并返回报告。我确认，如果使用条件按钮创建一个页面并让该按钮呈现，我可以使用get获得具有适当URL参数的相同页面。如果随后更改条件使按钮不呈现，则不会调用该操作。如果我通过FacesContext检查ViewRoot，我可以确认您是对的，按钮仍然在那里，但不确定这是否与JSF在生命周期中执行的树和/或验证相同。简言之，我可以确认，至少对于Mojarra来说，伪造请求是无法实现操作的。我只是不知道这是Mojara还是规范。我想我可能已经在这里找到了答案，只是不知道它是否规范：