PROSAGA码农传奇-恶意代码防范-将CSRF预防令牌放在cookie中为什么很常见？

您碰到的一个很好的理由是，一旦收到CSRF cookie，就可以在客户端脚本中的整个应用程序中使用它，以常规形式和AJAX POST形式使用。这在AngularJS所使用的JavaScript繁重的应用程序中是有意义的（使用AngularJS不需要该应用程序将是单个页面应用程序，因此在状态需要在不同页面请求之间流动且CSRF值需要流动的情况下将很有用）通常无法在浏览器中保留）。

考虑典型应用程序中的以下场景和过程，以了解您描述的每种方法的利弊。这些基于“ 同步器令牌模式”。

请求正文方法
用户成功登录。
服务器发布身份验证Cookie。
用户单击以导航到表单。
如果尚未为此会话生成，则服务器生成CSRF令牌，将其存储在用户会话中，并将其输出到隐藏字段。
用户提交表格。
服务器检查隐藏字段与会话存储的令牌是否匹配。
优点：

易于实现。
与AJAX一起使用。
使用表格。
Cookie实际上可以是HTTP Only。
缺点：

所有表单都必须输出HTML中的隐藏字段。
任何AJAX POST也必须包含该值。
该页面必须事先知道它需要CSRF令牌，以便它可以将其包含在页面内容中，因此所有页面都必须在某处包含该令牌值，这可能会使大型站点的实现很耗时。
自定义HTTP标头（下游）
用户成功登录。
服务器发布身份验证Cookie。
用户单击以导航到表单。
页面加载到浏览器中，然后发出AJAX请求以检索CSRF令牌。
服务器生成CSRF令牌（如果尚未为会话生成），将其存储在用户会话中，并将其输出到标头。
用户提交表单（令牌通过隐藏字段发送）。
服务器检查隐藏字段与会话存储的令牌是否匹配。
优点：

与AJAX一起使用。
Cookie可以是仅HTTP。
缺点：

没有AJAX请求就无法获得标头值。
所有表单必须将值动态添加到其HTML中。
任何AJAX POST也必须包含该值。
该页面必须首先发出AJAX请求才能获得CSRF令牌，因此每次都意味着一次额外的往返。
可能只需将令牌输出到页面即可，这将节省额外的请求。
自定义HTTP标头（上游）
用户成功登录。
服务器发布身份验证Cookie。
用户单击以导航到表单。
如果尚未为此会话生成，则服务器生成CSRF令牌，将其存储在用户会话中，并将其输出到页面内容中的某处。
用户通过AJAX提交表单（令牌通过标头发送）。
服务器检查自定义标头与会话存储的令牌是否匹配。
优点：

与AJAX一起使用。
Cookie可以是仅HTTP。
缺点：

不适用于表格。
所有AJAX POST必须包含标头。
自定义HTTP标头（上游和下游）
用户成功登录。
服务器发布身份验证Cookie。
用户单击以导航到表单。
页面加载到浏览器中，然后发出AJAX请求以检索CSRF令牌。
服务器生成CSRF令牌（如果尚未为会话生成），将其存储在用户会话中，并将其输出到标头。
用户通过AJAX提交表单（令牌通过标头发送）。
服务器检查自定义标头与会话存储的令牌是否匹配。
优点：

与AJAX一起使用。
Cookie可以是仅HTTP。
缺点：

不适用于表格。
所有AJAX POST也必须包含该值。
该页面必须首先发出AJAX请求才能获得CRSF令牌，因此每次都意味着一次额外的往返。
Set-Cookie
用户成功登录。
服务器发布身份验证Cookie。
用户单击以导航到表单。
服务器生成CSRF令牌，将其存储在用户会话中，并将其输出到cookie。
用户通过AJAX或HTML表单提交表单。
服务器检查自定义标头（或隐藏的表单字段）是否与会话存储的令牌匹配。
Cookie在浏览器中可用，可用于其他AJAX和表单请求，而无需向服务器发送其他请求来检索CSRF令牌。
优点：

易于实现。
与AJAX一起使用。
使用表格。
不一定需要AJAX请求即可获取Cookie值。任何HTTP请求都可以检索它，并且可以通过JavaScript将其附加到所有表单/ AJAX请求中。
一旦检索到CSRF令牌（因为它存储在cookie中），该值就可以重复使用，而无需其他请求。
缺点：

所有表单必须将值动态添加到其HTML中。
任何AJAX POST也必须包含该值。
将为每个请求（即CSRF流程中不涉及的所有图像，CSS，JS等GET）提交cookie ，从而增加请求大小。
Cookie不能仅HTTP。
因此，cookie方法是相当动态的，提供了一种检索cookie值（任何HTTP请求）和使用它的简便方法（JS可以自动将该值添加到任何形式，并且可以在AJAX请求中用作标头或表单值）。一旦已为会话接收到CSRF令牌，就无需重新生成它，因为采用CSRF漏洞的攻击者没有获取此令牌的方法。如果恶意用户尝试以上述任何一种方法读取用户的CSRF令牌，则将通过Same Origin Policy阻止。如果恶意用户试图检索CSRF令牌服务器端（例如，通过curl），则此令牌将不会与同一用户帐户相关联，因为受害者的auth会话cookie将在请求中丢失（这将是攻击者的，因此不会将服务器端与受害者的会话相关联）。

除了同步器令牌模式外，还有Double Submit CookieCSRF预防方法，它当然使用cookie来存储一种CSRF令牌。这很容易实现，因为它不需要CSRF令牌的任何服务器端状态。实际上，使用此方法时，CSRF令牌可能是标准的身份验证cookie，并且该值通常通过cookie与请求一起提交，但是该值也会在隐藏字段或标头中重复，攻击者无法将其复制为他们不能首先读取该值。但是，建议选择除身份验证Cookie以外的其他cookie，以便可以通过将HttpOnly标记为安全来保护身份验证cookie。因此，这是使用基于cookie的方法来预防CSRF的另一个常见原因。