Dan*_*iel 5 viewstate myfaces jsf-2 jsf-2.2
我正在使用*myfaces-api-2.2.3并将javax.faces.STATE_SAVING_METHOD设置为client,
我有以下场景,
1)用户X登录系统并添加用户XXX(使用jsf f:ajax操作),同时检查chrome dev工具,您可以看到与ViewState值一起提交的表单.
2)复制ViewState值(来自chrome dev工具 - >网络选项卡) - >将其放入带有表单的html文件中(模仿我原来的添加用户X)
3)从用户X会话注销(会话在该过程中失效)
4)用户Y登录 - > 在浏览器中打开该 html文件并点击表单的提交按钮 - >你会注意到添加了用户XXX(尽管表格中使用的ViewState值属于其他用户(用户X).
我认为ViewState的价值不能以这种方式被使用,我认为应该阻止这种行为,怎么就可以使用一个的ViewState在拥有自己的一个全新的会话值ViewState的价值,以及如何能我确保用户不能重用ViewState?
请参阅我的另一个问题和BalusC的回答:在客户端状态保存的情况下防止JSF2中的CSRF
使用客户端状态保存时,这是指定/预期的行为.JSF视图状态不保存在会话中,而是保存在客户端HTML表单中的隐藏输入字段中.仅当使用服务器端状态保存时,JSF视图状态将在用户的HTTP会话中不存在时失效.
我在MyFaces中没有看到任何方式使客户端保存状态无效,以防它在回发期间与"错误"会话重新关联.该org.apache.myfaces.CLIENT_VIEW_STATE_TIMEOUT上下文PARAM接近.您可以将其设置为会话超时的同一时间.
CSRF攻击场景有点夸大IMO.首先,攻击者需要能够获得客户端状态.最简单的方法是XSS漏洞.只有,JSF在任何地方都有XSS攻击防范(如果你小心的话escape="false").最难的方法是掌握整个HTML输出.这可以通过中间人攻击来完成.只是,这也为攻击者提供了整个会话cookie,因此在这种情况下整个CSRF攻击场景对于攻击者来说"不必要地过于复杂",因为攻击者可能只是劫持会话.针对此的最佳保护是使用HTTPS而不是HTTP.
即使这样,如果攻击者以某种方式掌握了客户端视图状态,攻击者也无法在不解密,反序列化和操纵它的情况下使用它做很多危险事情.MyFaces默认加密它很长时间(早在2.0.x之前).如果没有正确的密钥,攻击者无法对其进行解密,因此也无法对其进行操作.这种客户端视图状态加密已成为JSF 2.2规范的必需部分(因此Mojarra也这样做).默认情况下,当您重新启动应用程序服务器时,此键会被重置(因此所有客户端状态也将失效).如有必要,您可以通过以下环境条目指定固定密钥web.xml:
<env-entry>
<env-entry-name>jsf.ClientSideSecretKey</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>[AES key in Base64 format]</env-entry-value>
</env-entry>
Run Code Online (Sandbox Code Playgroud)
您可以使用此页面生成Base64格式的随机AES密钥.
即使这样,如果攻击者以某种方式成功解密视图状态并让另一个用户实际提交它(例如通过XSS漏洞或网络钓鱼站点),那么最好的办法就是在JSF页面中包含一个基于HTTP会话的CSRF令牌.但是,如果webapp在某处仍然存在XSS攻击漏洞,或者通过HTTP而不是HTTPS提供服务,那么这也是不安全的.
| 归档时间: |
|
| 查看次数: |
2831 次 |
| 最近记录: |