在其他会话(CSRF)中重用ViewState值 [英] Reusing ViewState value in other session (CSRF)

问题描述

我正在使用* myfaces-api-2.2.3，并将 javax.faces.STATE_SAVING_METHOD 设置为 client ，

I'm using a *myfaces-api-2.2.3 with javax.faces.STATE_SAVING_METHOD set to client ,

我遇到以下情况，

1)用户X登录到系统并添加用户XXX(使用jsf f:ajax操作)，在检查chrome开发工具时，您可以看到与 ViewState 值.

1) User X logs into the system and adds user XXX (using jsf f:ajax action) , while inspecting the chrome dev tools you can see the form that being submitted along with the ViewState value.

2)复制该 ViewState 值(从chrome开发工具->网络标签)->将其放入具有格式的html文件中(模仿我的原始添加用户X )

2) Copy that ViewState value (from chrome dev tools --> network tab) --> place it into html file with form (that mimics my original add user X)

3)从用户X会话注销(该会话在该过程中无效)

3) Logout from user X session (session being invalidated during that process)

4)使用用户Y登录->在浏览器中打开那个 html文件，然后点击表单的提交按钮->您会注意到用户XXX是添加(尽管表单中使用的 ViewState 值属于其他用户(用户X).

4) Login with user Y --> open that html file in browser and hit the submit button of the form --> you will notice that user XXX was added (despite the fact that the ViewState value that was used in form belongs to other user (User X).

我认为 ViewState 值不能以这种方式使用，我认为它应该防止此类操作，为什么可以使用一个 ViewState ViewState 值的全新会话中的em>值，我如何确保用户将无法重用 ViewState ?

I thought that the ViewState value can't be used in that way and I thought that it should prevent this kind of actions, how come it is possible to use one ViewState value in a brand new session that holds its own ViewState value and how can I make sure user wont be able to reuse ViewState?

请参阅我的其他问题和 BalusC 答案:

See my other question and BalusC answer : Prevent CSRF in JSF2 with client side state saving

推荐答案

在使用客户端状态保存时，这是指定的/预期的行为. JSF视图状态未保存在会话中，而是全部保存在客户端HTML表单中的隐藏输入字段中.仅当使用服务器端状态保存时，JSF视图状态才会在用户的HTTP会话中不存在时失效.

This is specified/expected behavior when using client side state saving. The JSF view state is not saved in the session, but in its entirety in a hidden input field in the HTML form in the client side. Only when using server side state saving, the JSF view state will invalidate when it doesn't exist in user's HTTP session.

我没有在MyFaces中看到任何方式无效客户端保存状态，以防在回发期间将其与错误的"会话重新关联. org.apache.myfaces.CLIENT_VIEW_STATE_TIMEOUT上下文参数接近.您可以将其设置为与会话超时相同的时间.

I'm not seeing any way in MyFaces to invalidate the client side saved state in case it's reassociated with the "wrong" session during postback. The org.apache.myfaces.CLIENT_VIEW_STATE_TIMEOUT context param comes close. You could set it to same time as session timeout.

CSRF攻击场景被IMO夸大了.首先，攻击者需要能够掌握客户端状态.最简单的方法是XSS漏洞.只有JSF到处都具有XSS攻击防护功能(如果您对escape="false"谨慎的话).最困难的方法是掌握整个HTML输出.这可以通过中间人攻击来完成.只是，这也为攻击者提供了整个会话cookie，因此对于这种情况，整个CSRF攻击情形对于攻击者而言不必要地过于复杂"，因为攻击者可以简单地劫持会话.最好的保护措施就是简单地使用HTTPS而不是HTTP.

The CSRF attack scenario is IMO a bit exaggerated. First, the attacker need to be able to get a hand of the client side state. The easiest way for that is a XSS hole. Only, JSF has XSS attack prevention everywhere (if you're careful with escape="false"). The hardest way is to have a hand of the entire HTML output. This could be done by a man-in-the-middle attack. Only, this also gives the attacker the whole session cookie, so the whole CSRF attack scenario in that case is "unnecessarily overcomplicated" for the attacker, as the attacker could simply hijack the session. The best protection against that is simply using HTTPS instead of HTTP.

即使那样，即使攻击者以某种方式掌握了客户端的视图状态，如果没有解密，反序列化和操纵它，攻击者也无法使用它进行很多危险的事情.默认情况下，MyFaces会对其进行长时间加密(自2.0.x早期开始).攻击者无法在没有正确密钥的情况下解密它，因此也无法操纵它.客户端状态加密已经成为JSF 2.2规范的必需部分(因此Mojarra也这样做).在重新启动应用程序服务器时，默认情况下会重置此密钥(因此，所有客户端状态都将无效).您可以根据需要在web.xml中的以下环境条目中指定固定密钥:

Even then, if the attacker has got a hand at the client side view state somehow, the attacker can't do much hazardous things with it without decrypting, unserializing and manipulating it. MyFaces encrypts it by default for long time (already since early 2.0.x). The attacker can't decrypt it without having the right key and therefore also not manipulate it. This client side view state encryption has by the way become a required part of JSF 2.2 specification (so Mojarra also does it). This key gets by default reset when you restart the application server (and thus also all client side states will be invalidated). You can if necessary specify a fixed key by below environment entry in 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>

您可以使用此页面在Base64中生成随机AES密钥格式.

You can use this page to generate a random AES key in Base64 format.

即使如此，即使攻击者以某种方式成功解密了视图状态并让另一个用户实际提交了该视图状态(例如，通过XSS漏洞或网络钓鱼站点)，那么最好的选择是在其中包含基于HTTP会话的CSRF令牌. JSF页面.但是，如果该Web应用仍然在某个地方存在XSS攻击孔，或者通过HTTP而不是HTTPS进行服务，那也不安全.

Even then, if the attacker somehow succeeds to decrypt the view state and got another user to actually submit it (e.g. via a XSS hole or a phishing site), then your best bet is to include a HTTP session based CSRF token in the JSF page. But also that is not safe if the webapp has still a XSS attack hole somewhere, or is served over HTTP instead of HTTPS.

• javax.faces.application.ViewExpiredException:视图无法恢复
• JSF中的CSRF，XSS和SQL注入攻击防护
• 的含义使用javax.faces.STATE_SAVING_METHOD在客户端上保存会话

• javax.faces.application.ViewExpiredException: View could not be restored
• CSRF, XSS and SQL Injection attack prevention in JSF
• Implications of saving session on the client with javax.faces.STATE_SAVING_METHOD

这篇关于在其他会话(CSRF)中重用ViewState值的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！