Security 理解CSRF

我不明白使用“挑战令牌”将如何增加任何类型的预防：与什么相比应该有什么价值

发件人：

一般来说，开发人员只需要 为服务器生成此令牌一次 本届会议。最初的 生成此令牌时，值为 存储在会话中并被利用 对于每个后续请求，直到 会话过期

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

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

但这能实现什么呢？您不只是获取会话数据，将其放入页面，然后将其与完全相同的会话数据进行比较吗？似乎是循环推理。这些文章一直在谈论遵循“同源策略”，但这毫无意义，因为所有CSRF攻击都与用户来自同一个来源，只是诱使用户做出他/她不想做的行为

---

除了将令牌作为查询字符串附加到每个URL之外，还有其他选择吗？看起来非常丑陋和不切实际，这使得用户更难使用书签。

攻击者无法获取令牌。因此，请求不会产生任何效果

---

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

你需要自己继续研究这个话题，但我想这就是你为什么要发布到SO:）。是一种非常严重且广泛存在的漏洞类型，所有web应用程序开发人员都应该知道

首先，有不止一个。但最重要的是，托管的脚本无法从中读取数据，但它可以通过POST和GET发送数据。如果请求仅包含攻击者已知的信息，则攻击者可以在victom浏览器上伪造请求并将其发送到任何地方。这里有3个是构建不包含随机令牌的请求

如果站点包含随机令牌，则必须使用XSS绕过同源策略提供的保护。使用XSS可以强制javascript从另一个域“发起”，然后它可以使用XmlHttpRequest读取令牌并伪造请求。这是我写的一个例子

除此之外还有别的选择吗 将令牌附加到每个 作为查询字符串的URL？看起来很难看 而且不切实际，并使书签 对用户来说更难

没有理由将令牌附加到站点上的每个URL，只要您确保站点上的所有GET请求都是只读的。如果使用GET请求修改服务器上的数据，则必须使用CSRF令牌对其进行保护

CSRF的有趣之处在于，尽管攻击者可以向您的站点发出任何http请求，但他无法读回响应

如果您获取的URL没有随机标记，攻击者将能够发出请求，但无法读回响应。如果该url改变了服务器上的某些状态，攻击者的工作就完成了。但是，如果只是生成了一些html，那么攻击者什么也得不到，而您什么也没有损失。

CSRF用一个类比解释-示例： 想象你正在用钥匙打开前门——你的钥匙。没有人有你的钥匙。你打开门——但在你进去之前，你的邻居从马路对面给你打电话，你们两人就天气或特朗普总统最新的凌晨3点45分推特等进行了非常友好的交谈。当你在交谈时，别人在你不知情的情况下看到你在外面，并决定穿上你同样的衣服和发型来模仿你，然后决定假装成你走进你自己的房子

在你家里没有人注意到任何不同的东西——你的妻子就像‘哦，克鲁德，他在家’

冒名顶替者帮他自己赚了你所有的钱，也许在出去的路上玩了一些Xbox游戏，没有人比他更聪明

CSRF基本上依赖于这样一个事实：你打开了你家的门，然后让它开着，允许其他人简单地走进来假装是你

解决这个问题的方法是什么？ 当你第一次打开房门时，门卫会给你一张纸，上面写着一个长长的随机数字：

“ASDFLJWERLI234324”

现在，如果你想进入自己的房子，你必须把那张纸交给门卫才能进去

所以现在当模拟者试图进入你的房子时，门卫问：

“纸上写的随机数是多少？”

如果冒充者没有正确的号码，他就不会进去。或者他必须正确地猜出随机数，这是一项非常困难的任务。更糟糕的是，随机数仅在20分钟内有效（例如）。所以要知道，模仿者必须猜对，不仅如此，他只有20分钟的时间来得到正确的答案。那太费劲了！所以他放弃了

当然，这个类比有点牵强，但我希望它对你有所帮助

---

**crud=（创建、读取、更新删除）

如今，我们有了新的防御方法“SameSite”Cookie属性，但并非所有浏览器都支持它。此外，所有可能的保护方法都可以在这里找到