Flask-Session（服务器端缓存）——CSRF攻击答案

【问题标题】：Flask- Session (server-side cache) - CSRF attacksFlask-Session（服务器端缓存）——CSRF攻击
【发布时间】：2021-02-02 20:50:29
【问题描述】：

来自testdriven.io

CSRF，代表 Cross-Site Request Forgery，是一种攻击针对攻击者试图欺骗的 Web 应用程序经过身份验证的用户执行恶意操作。大多数 CSRF 攻击针对使用基于 cookie 的身份验证的 Web 应用程序，因为 Web 浏览器包括与特定每个请求的域。因此，当从相同的浏览器，攻击者可以很容易地利用存储的cookies。

我决定使用 Flask-Session，这是一个 Flask 扩展，可以简单地集成服务器端缓存，将用户会话数据存储在服务器中。

使用这个扩展（将用户会话存储在redis上）足以防止CSRF攻击？

【问题讨论】：

不，不是，这不是 CSRF 所做的。
感谢您的回答@MartijnPieters。我真的很感激。
请注意，这并不是 Flask 特定的。 CSRF 使用户向服务器发出他们无意提出的请求。服务器假定他们正在与合法用户交谈，并且该请求是有意的。假设您使用会话来识别银行网站的登录用户。如果攻击者可以欺骗用户将资金转移到另一个帐户，那么会话数据的存储位置就无关紧要了。
例如，攻击者可以在 HTML 电子邮件中发送图像，但图像的链接实际上是银行网站的链接。如果用户已经登录到银行站点，并因此将 cookie 从浏览器发送到站点，Flask-Session 扩展仍然使用该 cookie 来识别要加载的 Redis 中的数据。无论如何，请求看起来都来自用户。
CSRF 保护使用 网页中的额外数据，这些数据必须匹配附加到用户帐户且在浏览器页面之外不可用的信息，并且每次加载可能触发敏感请求的页面时都会发生变化。这样，服务器至少知道请求来自刚刚发送给用户的特定浏览器页面。外部攻击者无法获得 CSRF 的“校验和”值，因此由于 CSRF 校验和丢失或错误，因此电子邮件中的图像链接技巧将不起作用。

标签： flask redis csrf

【解决方案1】：

不，Flask-Session 不能防止 CSRF 攻击，因为 CSRF 攻击不依赖于会话身份验证，它依赖于浏览器和您的站点之间预先存在的连接。 Flask-Session 不会删除用户浏览器与您的会话数据之间的连接，只会删除与用户关联的会话数据的存储位置。

Flask-Session 允许您做的只是隐藏与给定用户关联的信息，不让外界看到。但是您仍然需要能够区分用户 A 和用户 B，因此 浏览器中仍然有一个 cookie，它告诉 Flask 服务器从 Redis 为该用户加载哪些数据。如果没有 Flask-Session，任何会话数据都存在于浏览器中，使用 Flask-Session 只会为浏览器提供一个唯一标识符。

CSRF 攻击不需要知道会话中存储了什么，只需要知道会话存在。 CSRF 攻击在以下情况下起作用：

可能会诱使用户向网站发送请求以执行对攻击者有利的操作
用户已登录到站点，因此站点会看到执行所需操作的请求是从已通过身份验证的客户端发送的。

您可以通过要求每个执行有价值操作的请求都附带一个秘密的 CSRF 令牌来缓解 CSRF 攻击，该令牌不存储在会话中。浏览器不得保留 CSRF 值，因此它以后永远不会使用 CSRF 令牌。而是将令牌放在页面的 HTML 或其他请求和响应标头中。这样，服务器不仅可以相信他们拥有经过身份验证的用户，而且该请求是新鲜的，并且不是由没有访问浏览器的攻击者生成的。

如果您使用 WTForm 生成表单，请使用 Flask-WTF CSRF functionality 确保请求来自新网页。您甚至可以在不使用表单时使用他们的 API，例如使用 AJAX 调用或手工制作的表单时。

您可能需要阅读OWASP CSRF prevention page 以进一步了解 CSRF 攻击的工作原理。

【讨论】：