如果我在 headers 中发送 session-id 是否可以在没有 CSRF 令牌的情况下阻止 CSRF 攻击
Can CSRF attacks be blocked without CSRF tokens if I send the session-id in the headers
我在我的应用程序中使用 Session-based 身份验证，我想防止 CSRF 攻击我想过只在请求的 header 中发送 session id。
需要明确的是，支持的服务器将在 cookie 中设置 session id，但会根据 header 中的 id 验证请求。所以前端必须读取cookie的值并在自定义header
中发送
这样，在不知道 session id 的情况下，任何请求都无法通过安全检查（攻击者无法像 cookie 一样依赖浏览器发送它）。
这是一种不好的做法，还是我遗漏了什么。
为此，您必须在 non-httpOnly cookie 中设置 session id，这违反了传统的最佳做法。
但是，如果你只是称它为令牌，它就会神奇地变得正常。 :)
说真的，你需要评估并接受（或不接受）风险。您可以在登录时在响应 body 中生成您的 session id 和 return 它。它的行为就像一个令牌，您可能会将其存储在 localStorage 中（或将其保留在 cookie 中，这更糟糕，因为 cookie 有时作为纯文件存储在客户端文件系统中）并将其作为请求发送 header . javascript 可以访问它，这意味着它很容易受到潜在的 xss 攻击。对于任何 token-based 身份验证也是如此。这将有效地缓解 csrf，并且是一种常见的做法。
但是，当您实际上并不需要 token-based 解决方案时，将 csrf 换成 xss 听起来不是什么好事。如果它变得足够大，你的应用程序中就会有 xss。请求身份验证信息（即 session id）的最佳位置是 httpOnly cookie，这样它就可以防止 xss。那么当然你需要单独的csrf保护。
您将使用令牌的唯一场景是如果您需要将令牌发送到多个来源（例如，不同域上的多个 api），或者在身份提供者和服务的单个 sign-on 场景中提供者不同。 Cookie 无法做到这一点。
所以如果你不需要令牌，最好避免风险较高的 xss（至少对于 session id）并实施单独的 csrf 保护。
不，不要那样做。
我假设 session ID 是等同于密码的 token/string/whatever。 IE，如果攻击者可以获得sessionid，那么他们就可以冒充用户。
显示 javascript sessionid 的唯一方法是将其公开给 javascript。
RFC 中有一节讨论 cookie 安全问题。让我们接受它作为一个事实，你想对 javascript.
保密
如果您想跳过 XSRF 检查，那么您需要确保在今天和一年后完美地完成某些事情。
- 从不允许获取更改状态的请求。他们没有受到保护。
- 永远不要将 CORS 策略设置为允许其他来源。
- 永远不要相信查询字符串参数。
- 始终验证引用 header。
- 可能还有其他事情。
XSRF 令牌要容易得多。这是标准方法。
- 当您生成 session ID 时，对其进行单向哈希，并将其设置为不带 httpOnly 的 cookie。
- 从您的 javascript 中读取该 cookie 的值并在请求中设置它 header。
这比上面的 1-4 更容易。
像 axios 这样的库内置了对将 xsrf 令牌应用于所有请求的支持 (search for xsrf)。
维基百科也有 good writeup on xsrf...
我在我的应用程序中使用 Session-based 身份验证，我想防止 CSRF 攻击我想过只在请求的 header 中发送 session id。
需要明确的是，支持的服务器将在 cookie 中设置 session id，但会根据 header 中的 id 验证请求。所以前端必须读取cookie的值并在自定义header
中发送这样，在不知道 session id 的情况下，任何请求都无法通过安全检查（攻击者无法像 cookie 一样依赖浏览器发送它）。
这是一种不好的做法，还是我遗漏了什么。
为此，您必须在 non-httpOnly cookie 中设置 session id，这违反了传统的最佳做法。
但是，如果你只是称它为令牌，它就会神奇地变得正常。 :)
说真的，你需要评估并接受（或不接受）风险。您可以在登录时在响应 body 中生成您的 session id 和 return 它。它的行为就像一个令牌，您可能会将其存储在 localStorage 中（或将其保留在 cookie 中，这更糟糕，因为 cookie 有时作为纯文件存储在客户端文件系统中）并将其作为请求发送 header . javascript 可以访问它，这意味着它很容易受到潜在的 xss 攻击。对于任何 token-based 身份验证也是如此。这将有效地缓解 csrf，并且是一种常见的做法。
但是，当您实际上并不需要 token-based 解决方案时，将 csrf 换成 xss 听起来不是什么好事。如果它变得足够大，你的应用程序中就会有 xss。请求身份验证信息（即 session id）的最佳位置是 httpOnly cookie，这样它就可以防止 xss。那么当然你需要单独的csrf保护。
您将使用令牌的唯一场景是如果您需要将令牌发送到多个来源（例如，不同域上的多个 api），或者在身份提供者和服务的单个 sign-on 场景中提供者不同。 Cookie 无法做到这一点。
所以如果你不需要令牌，最好避免风险较高的 xss（至少对于 session id）并实施单独的 csrf 保护。
不，不要那样做。
我假设 session ID 是等同于密码的 token/string/whatever。 IE，如果攻击者可以获得sessionid，那么他们就可以冒充用户。
显示 javascript sessionid 的唯一方法是将其公开给 javascript。
RFC 中有一节讨论 cookie 安全问题。让我们接受它作为一个事实，你想对 javascript.
保密如果您想跳过 XSRF 检查，那么您需要确保在今天和一年后完美地完成某些事情。
- 从不允许获取更改状态的请求。他们没有受到保护。
- 永远不要将 CORS 策略设置为允许其他来源。
- 永远不要相信查询字符串参数。
- 始终验证引用 header。
- 可能还有其他事情。
XSRF 令牌要容易得多。这是标准方法。
- 当您生成 session ID 时，对其进行单向哈希，并将其设置为不带 httpOnly 的 cookie。
- 从您的 javascript 中读取该 cookie 的值并在请求中设置它 header。
这比上面的 1-4 更容易。
像 axios 这样的库内置了对将 xsrf 令牌应用于所有请求的支持 (search for xsrf)。
维基百科也有 good writeup on xsrf...