会话ID位置：表单隐藏字段与HTTPOnly Cookie [英] Session Id placement: Form Hidden Field vs. HTTPOnly Cookie

问题描述

将会话ID放在隐藏形式输入中与cookie相比有什么优缺点？

What are the advantages and disadvantages of placing session id in a hidden form input vs a cookie?

将CSRF-Tag放在隐藏形式输入中是否正确？ httpOnly Cookie中的字段和会话ID？哪个更安全？

Is it correct to put CSRF-Tag in a hidden form input field and session id in an httpOnly cookie? Which is more secure?

推荐答案

我不认为一个安全性就比另一个安全性低。安全性通常是分层构建的。通过断言选择A可能比选择B 更安全，则当两个选择都在同一个行业中发挥作用时，您就断言安全性就此止步。

I don't think that one is inherently less secure than the other. Security is generally built in layers. By asserting that choice A can be more secure than choice B, when both choices play on the same vertical, you are asserting that security stops there. This is completely false and unsubstantiated in practice.

通过以隐藏形式输入的形式传递会话ID，实际上会产生比自己解决的问题更多 。另外，我不同意这样的主张，即无论如何这都会使您从本质上免受CSRF的保护。

By passing around session ids primarily in the form of hidden form inputs you actually create more problems than you solve for yourself. Also, I disagree with the assertion that this in anyway makes you inherently protected from CSRF.

当您考虑会话的目的时（在服务器和客户端之间保持状态，而在其他情况下则保持无状态）协议），那么说我将通过隐藏的输入字段传递所有会话ID并没有实际意义。因为，并不是所有对服务器的请求都涉及表单的使用。另外，当用户刷新页面或关闭其浏览器时，状态就会丢失。

When you think about what purpose a session serves (retaining state between the server and client over an otherwise stateless protocol), it doesn't actually make sense to say I will pass all of my session ids via hidden input fields. Because, for one, not every request made to your server involves the use of a form. For another, the state is lost the moment the user refreshes the page or closes their browser. This isn't pragmatic at all.

将CSRF令牌放置在隐藏的输入中是正确的。通过HTTP标头将它们发送到客户端也是正确的。 CSRF令牌本身不足以阻止攻击。还需要服务器理解如何识别该令牌（该令牌原本是为此客户端唯一生成的）不会被重用，并且不会由同一用户绑定到另一个会话。

It is correct to place CSRF tokens in hidden inputs. It's also not incorrect to send them along to the client via HTTP headers. The CSRF token by itself isn't enough to prevent the attack. What's also needed is that the server understands how to recognize that this toke, which was supposedly uniquely generated for this client, is not reused and not tied to another session by the same user.

自通常，CSRF攻击的前提是您无法区分真实用户和恶意伪造，其想法是通过为每个请求重新生成令牌来使伪造者的工作更加困难。加上只能使用一次的要求，会话被劫持实际上不再重要。因此，您真的不应该尝试以错误的方式解决此问题，方法是假设您可以通过依靠在隐藏输入中传递会话ID并说服自己比将会话ID存储在文件中更安全来以某种方式解决这两个问题。曲奇饼。 不是。应该有附加的安全层来保护您的会话免受会话劫持或会话固定攻击，例如使用仅SSL cookie ， HSTS ，并在重新认证请求后重新注册会话ID（同时删除旧的会话文件）。另外，强制对用户级非幂等操作进行重新认证。

Since generally a CSRF attack is based on the premise that you cannot distinguish the real user from the malicious forgery, the idea is to make the forger's job more difficult by regenerating the token for every request. Coupled with a use-only-once requirement and it doesn't actually matter anymore that the session is hijacked. So you really shouldn't try to solve this problem at the wrong level, by assuming that you can somehow solve both problems by relying on passing your session ids in hidden inputs and convincing yourself that this is more secure than storing the session id in a cookie. It's not. There should be additional layers of security to protect your sessions from session hijacking or session fixation attacks like using SSL only cookies, HSTS, and regnerating session ids (while deleting the old session files) upon re-authentication requests. Also, forcing re-authentication for user-level non-idempotent actions.

这篇关于会话ID位置：表单隐藏字段与HTTPOnly Cookie的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！