了解CSRF

问题描述

我不明白使用挑战令牌会带来什么预防措施：将什么值与什么进行比较？

来自：

如果我正确理解该过程，就会发生这种情况。

我登录，并创建一个包含此随机令牌的会话/ cookie。然后，每个表单都包含一个隐藏的输入，其中还包含会话中的该随机值，并将其与表单提交后的会话/ cookie进行比较。

但是，这能完成什么工作？您不是只是获取会话数据，将其放入页面中，然后将其与完全相同的会话数据进行比较吗？好像是循环推理。这些文章一直在谈论遵循同源策略，但这没有任何意义，因为所有CSRF攻击都与用户具有相同的起源，只是诱使用户执行他/她不想要的操作。

除了将令牌作为查询字符串附加到每个URL之外，还有其他选择吗？

解决方案

攻击者无法获取令牌。

解决方案

因此，这些请求不会生效。

我推荐Gnucitizen发表这篇文章。它有一个相当不错的CSRF解释：

I don't understand how using a 'challenge token' would add any sort of prevention: what value should compared with what?

From OWASP:

If I understand the process correctly, this is what happens.

I log in at http://example.com and a session/cookie is created containing this random token. Then, every form includes a hidden input also containing this random value from the session which is compared with the session/cookie upon form submission.

But what does that accomplish? Aren't you just taking session data, putting it in the page, and then comparing it with the exact same session data? Seems like circular reasoning. These articles keep talking about following the "same-origin policy" but that makes no sense, because all CSRF attacks ARE of the same origin as the user, just tricking the user into doing actions he/she didn't intend.

Is there any alternative other than appending the token to every single URL as a query string? Seems very ugly and impractical, and makes bookmarking harder for the user.

解决方案

The attacker has no way to get the token. Therefore the requests won't take any effect.

I recommend this post from Gnucitizen. It has a pretty decent CSRF explanation: http://www.gnucitizen.org/blog/csrf-demystified/

这篇关于了解CSRF的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！