CSRF 请求 nonce 使得恶意 POST 成为可能？
CSRF Requesting the nonce makes malicious POST possible?
我正在努力解决 csrf 保护问题，但有些事情我很难理解。也许有人可以给我所需的见解:)。
我的理解
假设我们没有 csrf 保护。有人使用 his/her 凭据登录网站 A。有效登录后，会话 cookie 将存储在浏览器中。用户通过表单发布一些数据，服务器可以毫不费力地接受它。由于我们没有 csrf 保护，因此系统容易出现漏洞。
用户访问另一个网站B，一个类似钓鱼的恶意网站。例如，该网站正在 post 向网站 A 发送一些 javascript xhr 请求。浏览器存储了网站 A 的 cookie，并且由于用户已经登录，所以这是一个有效的会话。因此网站 A 将毫无困难地接受 post。
为了解决这个 csrf 保护，从服务器加载网站 A 上的表单页面时，会生成一个随机数（一次性代码）。此代码必须与表单一起提交，以便服务器可以检查此 post 是否来自请求表单的同一会话。如果代码与刚刚生成的代码相同，则接受表单。如果代码丢失或不正确，服务器将拒绝。
问题
如果恶意网站B首先向呈现表单的页面发出get请求。它将能够获取令牌以便随后与 post 请求一起发送。正确的？我是否漏掉了一些明显的东西？
谢谢！
我了解到您担心恶意网站可以请求您的 anti-CSRF 令牌。
您需要防止 cross-origin 读取或嵌入 returns CSRF 令牌的页面或端点。要记住的重要事情之一是 CORS 不提供 CSRF 保护，因为预检 CORS 请求并不总是由浏览器执行，例如在使用常规 html 表单时。
大多数现代浏览器默认阻止跨源请求。当您确实需要对自己的域进行跨源请求时，您可以通过设置正确的跨源 headers 来做到这一点，例如 Access-Control-Allow-Origin: sub.domain.com。
要防止嵌入 iframe，您可以将 X-Frame-Options: 实现为 DENY，或 SAMEORIGIN。
您可以在 https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy
上找到更多信息
我正在努力解决 csrf 保护问题，但有些事情我很难理解。也许有人可以给我所需的见解:)。
我的理解
假设我们没有 csrf 保护。有人使用 his/her 凭据登录网站 A。有效登录后，会话 cookie 将存储在浏览器中。用户通过表单发布一些数据，服务器可以毫不费力地接受它。由于我们没有 csrf 保护，因此系统容易出现漏洞。
用户访问另一个网站B，一个类似钓鱼的恶意网站。例如，该网站正在 post 向网站 A 发送一些 javascript xhr 请求。浏览器存储了网站 A 的 cookie，并且由于用户已经登录，所以这是一个有效的会话。因此网站 A 将毫无困难地接受 post。
为了解决这个 csrf 保护，从服务器加载网站 A 上的表单页面时，会生成一个随机数（一次性代码）。此代码必须与表单一起提交，以便服务器可以检查此 post 是否来自请求表单的同一会话。如果代码与刚刚生成的代码相同，则接受表单。如果代码丢失或不正确，服务器将拒绝。
问题
如果恶意网站B首先向呈现表单的页面发出get请求。它将能够获取令牌以便随后与 post 请求一起发送。正确的？我是否漏掉了一些明显的东西？
谢谢！
我了解到您担心恶意网站可以请求您的 anti-CSRF 令牌。
您需要防止 cross-origin 读取或嵌入 returns CSRF 令牌的页面或端点。要记住的重要事情之一是 CORS 不提供 CSRF 保护，因为预检 CORS 请求并不总是由浏览器执行，例如在使用常规 html 表单时。
大多数现代浏览器默认阻止跨源请求。当您确实需要对自己的域进行跨源请求时，您可以通过设置正确的跨源 headers 来做到这一点，例如 Access-Control-Allow-Origin: sub.domain.com。
要防止嵌入 iframe，您可以将 X-Frame-Options: 实现为 DENY，或 SAMEORIGIN。
您可以在 https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy
上找到更多信息