我需要处理使用 Jekyll 构建的静态网站的查询表。
查询表单将 JSONP 请求 (GET) 提交到处理请求的另一个域上的 PHP 应用程序。
由于表单是静态的,是否可以防止 CSRF?
我注意到 PHP Slim 框架的 CSRF 中间件只保护 POST、PUT 和 DELETE 方法,而不是 GET。
如果我在静态站点中有一个脚本,在每个页面加载表单时都使用从服务器请求的数据(cookie 值、csrf 令牌以及字段值等)可以工作吗?
谢谢你的时间
我需要处理使用 Jekyll 构建的静态网站的查询表。
查询表单将 JSONP 请求 (GET) 提交到处理请求的另一个域上的 PHP 应用程序。
由于表单是静态的,是否可以防止 CSRF?
我注意到 PHP Slim 框架的 CSRF 中间件只保护 POST、PUT 和 DELETE 方法,而不是 GET。
如果我在静态站点中有一个脚本,在每个页面加载表单时都使用从服务器请求的数据(cookie 值、csrf 令牌以及字段值等)可以工作吗?
谢谢你的时间
不。
对 CSRF 的防御取决于发送请求的页面和发送请求的服务器是否同意用户的唯一标识符。
由于表单是静态的,因此您不能在表单中放置该唯一标识符。
如果我在静态站点中有一个脚本,在每个页面加载表单时都使用从服务器请求的数据(cookie 值、csrf 令牌以及字段值等)可以工作吗?
仅当它是服务器端脚本时(因此表单不是静态的),否则任何站点都可以包含它来获取令牌。
我注意到 PHP Slim 框架的 CSRF 中间件只保护 POST、PUT 和 DELETE 方法,而不是 GET。
这是因为GET 请求首先不应该做任何事情,所以(除非你滥用它们)没有必要对它们应用 CSRF 保护。
特别是,已经建立了约定,即 GET 和 HEAD 方法不应该具有采取除检索之外的操作的意义。这些方法应该被认为是“安全的”。这允许用户代理以特殊的方式表示其他方法,例如 POST、PUT 和 DELETE,以便用户意识到正在请求可能不安全的操作。
无需防范 CSRF,因为在当前用户的上下文中提交表单不会获得任何收益 - 如果攻击者想在您的网站上提交表单,则无需“跨站点”...他们只会提交它。
听起来您正在使用验证码来阻止机器人提交表单(如果那是您真正想要的?)。