如果我在标头中发送会话ID，是否可以在没有CSRF令牌的情况下阻止CSRF攻击

如何解决如果我在标头中发送会话ID，是否可以在没有CSRF令牌的情况下阻止CSRF攻击

我在我的应用中使用基于会话的身份验证，并且我想防止CSRF攻击，我想到了只在请求的标头中发送会话ID。

为清楚起见，支持备份的服务器将在cookie中设置会话ID，但将根据标头中的ID验证请求。因此前端必须读取cookie的值并将其发送到自定义标头中

这样，在不知道会话ID的情况下，任何请求都不会通过安全检查（攻击者无法像在cookie上那样在浏览器上进行中继发送该消息）。

被认为是不好的做法，或者在这里我缺少一些东西。

解决方法

为此，您必须在非httpOnly cookie中设置会话ID，这与传统的最佳做法背道而驰。

但是，如果您仅将其称为令牌，它就可以正常使用。 ：）

认真地说，您需要评估和接受（或不接受）风险。您可以生成会话ID，并在登录后将其返回到响应正文中。它的行为就像一个令牌，您可能将其存储在localStorage中（或将其保留在cookie中，这更糟糕，因为cookie有时以纯文件的形式存储在客户端文件系统中）并作为请求标头发送。它可以通过javascript访问，这意味着它可能会受到潜在的xss的影响。对于任何基于令牌的身份验证都是如此。这将有效地减轻csrf的负担，这是通常的事情。

但是，当您实际上不需要基于令牌的解决方案时，将csrf交换为xss听起来并不好。如果它足够大，您的应用程序中将包含xss。请求认证信息（即会话ID）的最佳可能位置是httpOnly cookie，这样可以防止它受到xss的攻击。当然，您当然需要单独的csrf保护。

您将使用令牌的唯一方案是，如果您需要将令牌发送到多个来源（例如，不同域上的多个api），或者在身份提供商和服务提供商不同的单点登录方案中。 Cookies无法做到这一点。

因此，如果您不需要令牌，则最好避免较高的风险xss（至少对于会话ID），并实施单独的csrf保护。

,

不，不要那样。

我假设会话ID是令牌/字符串/与密码等效的任何东西。 IE，如果攻击者可以获取sessionid，则他们可以冒充用户。

显示javascript sessionID的唯一方法是将其公开给javascript。

RFC中有一节讨论Cookie安全性问题。让我们接受一个事实，那就是您希望对javascript保密。

如果要跳过XSRF检查，则需要确保在今天和一年之后再次做一些完美的事情。

1. 永远不允许get请求更改状态。他们没有受到保护。
2. 从不设置CORS政策以允许其他来源。
3. 从不信任查询字符串参数。
4. 始终验证引荐来源标头。
5. 可能还有其他事情。

XSRF令牌要容易得多。这是标准方法。

1. 生成会话ID时，请对其进行单向哈希处理，然后将其设置为不带有httpOnly的cookie。
2. 从您的javascript中读取该cookie的值，并将其设置在请求标头中。

比上面的1-4容易。

像axios这样的库已经内置了对将xsrf令牌应用于所有请求（search for xsrf）的支持。

维基百科也有good writeup on xsrf ...