双提交Cookie和多个标签？ [英] Double Submit Cookies and multiple tabs?

问题描述

重复提交Cookie 机制需要使用Cookie。但是，Cookie会在所有浏览器标签中共享。 如何在不中断后退按钮和浏览器标签的情况下实现此机制？

含义：如果所有标签使用相同的Cookie存储CSRF令牌，每次打开一个新选项卡时，它会破坏所有旧选项卡的cookie值。

另一方面，如果我每个标签使用单独的cookie，那么服务器将如何处理知道要查看哪个Cookie？而且，如果你需要使用一个隐藏字段指向cookie名称，它会以某种方式打开你新的安全攻击（因为使用CSRF的攻击者可以改变表单值）？

UPDATE ：

• 实施需要是无状态/ RESTful。没有服务器会话。


• 您可以假设我控制所有子域，所以攻击者将无法写自己的Cookie。

解决方案

您可以创建每个用户会话生成一次的特定Cookie。例如一个命名为 CSRFCookie 。请务必设置安全标记，以便仅通过HTTPS发送。

由于您不能维护服务器状态，请注意这很容易受到 MiTM攻击，因为我在此处：

即使您的网站只能通过HTTPS访问，并且您正确设置了安全标志，必须注意这种方法，因为攻击者可能潜在MiTM从受害者到任何HTTP网站的任何连接（如果攻击者适当放置当然）通过HTTP将它们重定向到您的域，这也是MiTM'd，然后设置所需的cookie值。这将是会话锁定攻击。为了防止这种情况，您可以在每次加载此页面时（通过HTTPS）将Cookie值输出到标题和隐藏的表单字段，而不是重复使用任何已设置的Cookie值。这是因为虽然浏览器可以设置安全标志，它仍然会通过HTTPS连接发送没有安全标志的cookie，并且服务器将无法判断是否设置了安全标志。 （Cookie属性，例如安全标志只有在设置cookie时才可见，而不是在读取时才可见）。服务器唯一可以看到的是cookie名称和值。）

因此，如果您希望防止此和不会通过多个标签打破您的网站，您必须跟踪 CSRFCookie

否则，如果未存储服务器状态：

< >

对于MiTM的安全方法，这个值必须在
的每个表单加载时生成，但是因为cookie值每次
的时间更改而中断选项卡。

如果你不想保护MiTM，你可以只生成一个 CSRFCookie 值，这将允许多个标签/回来工作。 li>

可能有一个解决方案（1），它涉及检查cookie值是否存在，如果它已经存在，结束cookie值和隐藏表单字段的名称。例如 CSRFCookie1 ， CSRFCookie2 等，所以每个表单都可以有自己的cookie。请注意，这可能会建立大量的数据，将与浏览器的每个HTTP请求提交到您的服务器（即使是图像， .js 等）。

另一个选择是使用 HSTS 确保浏览器始终在发出任何请求之前将与您的服务器的任何HTTP连接重定向到HTTPS。然而，在对您的服务器和HSTS策略集进行任何请求之前，仍然有一个机会的HTTP连接被MiTM'。但是，您可以安排您的网站在HSTS预装的最流行的浏览器列表，以降低风险。这将使您可以使用多个选项卡无服务器状态，因为您只需使用相同的cookie（ CSRFCookie ）和值生成的每个窗体，如果未设置或读取if已经设置然后从未重新生成。请注意，IE 目前尚不支持HSTS，但支持可能在IE 12 中添加，但请参阅此处查看Edge浏览器支持。

The double-submit cookies mechanism requires the use of cookies. However, cookies are shared across all browser tabs. How do you implement this mechanism without breaking the back button and browser tabs?

Meaning: if all tabs use the same cookie to store the CSRF token, every time a new tab is opened it would clobber the cookie value of all older tabs. When the forms in those older tabs are then submitted they will fail with a token mismatch.

On the other hand, if I use a separate cookie per tab how will the server know which cookie to look in? And also, if you need to use a hidden field to point to the cookie name, does it somehow open you up to new security attacks (since attackers that use CSRF can change form values)?

UPDATE:

• The implementation needs to be stateless/RESTful. There is no server "session".
• You can assume I control all sub-domains, so attackers won't be able to write their own cookies.

解决方案

You can create a specific cookie that is generated once per user session. e.g. One named "CSRFCookie". Be sure to set the Secure Flag so this in only sent via HTTPS.

As you are not maintaining server state be aware that this is vulnerable to MiTM attacks as I've covered here:

Even if your site is only accessible over HTTPS and you correctly set the Secure Flag, care must be taken with this approach as an attacker could potentially MiTM any connection from the victim to any HTTP website (if the attacker is suitably placed of course), redirect them to your domain over HTTP, which is also MiTM'd and then set the required cookie value. This would be a Session Fixation attack. To guard against this you could output the cookie value to the header and the hidden form field every time this page is loaded (over HTTPS) rather than reuse any already set cookie value. This is because although a browser can set the Secure Flag, it will still send cookies without the Secure Flag over a HTTPS connection, and the server will not be able to tell whether the Secure Flag was set. (Cookie attributes such as the Secure Flag are only visible when the cookie is set, not when it is read. The only thing the server gets to see is the cookie name and value.)

So if you wish to protect against this and not break your site over multiple tabs, you must keep track of the "CSRFCookie" value server side.

Otherwise, if server state is not stored:

1. For a secure approach against MiTM, this value must be generated on each form load but breaks tabs as the cookie value is changed each time.
2. If you do not wish to protect against MiTM you could just generate the "CSRFCookie" value once, which will allow multiple tabs/back to work.

There may be a solution for (1), which involves checking whether a cookie value exists, and if it already does you increment a number at the end of the name of the cookie value and hidden form field. e.g. "CSRFCookie1", "CSRFCookie2", etc, so each form can have their own cookie. Be aware though that this may build up a huge amount of data that will be submitted with every HTTP request by the browser to your server (even images, .js etc).

Another option is to use HSTS to ensure the browser always redirects any HTTP connection to your server to HTTPS before any request is made. However, there is still a window of opportunity for the HTTP connection to be MiTM'd before any request is made to your server and the HSTS policy set. You could however arrange for your site to be in the HSTS pre-loaded list of the most popular browsers to reduce the risk. This will enable you to use multiple tabs without server state as you simply use the same cookie ("CSRFCookie") and value on every form that is generated if not set or read if already set then never regenerated. Please note that HSTS is not yet supported in IE, but support may be added in IE 12, however see here for Edge browser support.

这篇关于双提交Cookie和多个标签？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！