答案：使用CSRF令牌结合SameSite Cookie是防止CSRF攻击的主要方法；通过在会话中存储并表单中嵌入随机令牌，提交时验证其一致性，同时设置SameSite属性为Strict或Lax以增强安全性。
使用令牌（Token）是PHP中防止CSRF（跨站请求伪造）攻击的主要方法。它通过在用户请求中包含一个随机生成的、服务器端验证的令牌，来确保请求确实来自合法的用户操作，而不是恶意网站的伪造。
解决方案：
生成CSRF令牌： 在用户会话中存储一个随机生成的令牌。可以使用
bin2hex(random_bytes(32))
生成一个安全的令牌。-
在表单中包含令牌： 将令牌作为一个隐藏字段添加到所有需要保护的表单中。
立即学习“PHP免费学习笔记（深入）”；
验证令牌： 在处理表单提交时，验证请求中包含的令牌是否与会话中存储的令牌匹配。如果匹配，则继续处理请求；否则，拒绝请求。
令牌轮换： 为了增强安全性，可以定期轮换CSRF令牌，例如每次表单提交后或一段时间后。
使用
SameSite
Cookie属性： 设置SameSite
属性为Strict
或Lax
，可以阻止跨站请求携带Cookie，从而降低CSRF攻击的风险。
如何选择合适的CSRF防护策略？
选择合适的CSRF防护策略取决于应用的具体需求和风险承受能力。以下是一些考虑因素：
-
安全性要求： 对于高度敏感的应用，建议使用更严格的策略，例如令牌轮换和
SameSite=Strict
。 - 用户体验： 过于严格的策略可能会影响用户体验，例如频繁的令牌过期会导致用户需要重新登录。
-
兼容性： 某些浏览器可能不支持
SameSite
属性，因此需要考虑兼容性问题。 - 开发成本： 实现复杂的CSRF防护策略可能需要更多的开发工作。
通常，一个好的做法是结合多种策略，例如使用令牌和
SameSite属性，以提供更全面的保护。
CSRF令牌应该存储在哪里？
CSRF令牌主要存储在两个地方：
服务器端： CSRF令牌存储在用户的会话中。这允许服务器验证提交的表单是否包含正确的令牌。会话存储确保只有服务器可以访问令牌，防止客户端篡改。
客户端： CSRF令牌作为隐藏字段嵌入到HTML表单中。当用户提交表单时，令牌会随其他表单数据一起发送到服务器。
为什么仅仅使用Referer头部进行CSRF防护是不够的？
虽然检查HTTP Referer头部可以提供一些初步的保护，但它并不可靠，原因如下：
- Referer头部可以被伪造： 恶意用户可以使用各种工具和技术来伪造Referer头部，使其看起来像是来自合法的来源。
- Referer头部可能被禁用： 某些浏览器或安全设置可能会禁用Referer头部，导致服务器无法验证请求的来源。
- Referer头部不总是存在： 在某些情况下，例如用户直接在浏览器中输入URL或通过书签访问网站时，Referer头部可能不存在。
由于Referer头部的不可靠性，不应将其作为唯一的CSRF防护手段。建议使用更可靠的策略，例如CSRF令牌。
