token令牌问题
# token 令牌问题
# 为什么 Token 存储在 Cookie 中而非 Session 中
将 Token 存储在 Cookie 中而非 Session 中，通常基于以下几个原因：
跨域支持：
Cookie：由于 Cookie 遵循同源策略，只有在相同域名下才能访问对应的 Cookie。因此，如果应用程序需要跨多个子域或完全不同的域共享用户身份信息（如单点登录场景），可以将 Token 存储在 HTTP-only、Secure 和 SameSite 属性设置得当的 Cookie 中，以实现安全的跨域身份验证。通过设置正确的 Cookie 属性，可以在一定程度上防止 CSRF 攻击，同时确保 Token 在多个相关域之间共享。
Session：Session 通常是服务器端维持的状态，与特定客户端（通过 Session ID 标识）相关联。Session ID 通常通过 Cookie 传递，但 Session 本身并不直接支持跨域共享。要在不同域名间共享 Session 状态，通常需要额外的跨域 Session 共享机制（如服务器端的 Session 粘滞、分布式 Session 存储等），实现起来较为复杂。
无状态服务与水平扩展：
Token（尤其是JWT等自包含Token）：Token 本身包含了必要的用户身份信息和可能的权限声明，服务器无需存储任何状态即可验证 Token 的有效性。这种无状态设计极大地简化了服务器端架构，使得服务端可以轻松实现水平扩展，因为每个服务节点都能独立验证 Token，无需依赖共享的 Session 存储。这对于云原生环境、微服务架构以及大规模分布式系统尤为有利。
Session：Session 机制依赖于服务器端的 Session 存储（如内存、数据库或专用缓存服务）。当需要水平扩展时，必须确保客户端的 Session ID 能够被集群中的任意节点正确解析，通常需要采用 sticky session（会话粘滞）或分布式 Session 存储方案，增加了系统的复杂性和潜在故障点。
移动端与API友好：
Token：在移动应用、SPA（Single Page Application）或 API 驱动的应用中，Token 可以直接包含在 HTTP 请求的 Authorization 头中，便于进行无状态的 RESTful API 调用。客户端（如移动 APP）可以将 Token 安全地存储在本地（如 Keychain、SharedPreferences），不受浏览器环境限制。
Session：Session 机制更适合传统的基于 Cookie 的 Web 应用，对于需要直接与 API 交互的非浏览器客户端，处理 Session ID 和维持 Session 状态可能会带来额外的复杂性。
性能与资源消耗：
Token：由于 Token 验证过程无须查询后端存储，只需执行一次签名验证或密钥解密（对于JWT），因此在高并发场景下，Token 验证的性能通常优于需要查询 Session 存储的机制。
Session：每次请求到达服务器时，如果使用 Session，服务端可能需要查询 Session 存储来验证用户身份和权限，尤其是在 Session 存储位于外部服务（如 Redis、Memcached）时，这会增加网络延迟和资源消耗。
综上所述，将 Token 存储在 Cookie 中而非 Session 中，主要是为了更好地支持跨域、适应无状态服务架构、便于移动端和 API 调用，以及提高性能和减少资源消耗。当然，具体选择应根据应用的具体需求、安全要求和架构特点来决定，有时也会结合使用 Token 与 Session 以充分利用各自优点。
# 什么是 CSRF 攻击
CSRF（Cross-Site Request Forgery，跨站请求伪造）是一种网络攻击手段，它利用用户已登录的身份在不知情的情况下，通过用户的浏览器向目标网站发起恶意请求。
危害：
这种攻击方式旨在欺骗用户的可信浏览器，使其在用户与目标网站已建立的认证上下文中执行攻击者预设的操作，如转账、修改密码、发布内容等，而用户本人对此毫不知情。
**CSRF 攻击的基本原理与步骤 **：
用户登录：受害者在浏览器中正常登录受信任的目标网站（如网上银行、社交媒体平台等），服务器为此用户创建一个有效的会话（如通过 Cookie、Token 等方式），并在浏览器中设置相应的认证信息。
用户访问恶意链接：攻击者通过电子邮件、社交网络、论坛帖子、恶意广告等途径，诱导受害者点击一个包含恶意请求的链接，或者加载一个嵌入了恶意脚本的网页。
浏览器发起恶意请求：当受害者点击链接或加载恶意网页时，浏览器在用户的无意识状态下，根据页面内容向目标网站发起一个经过精心构造的请求。由于此时浏览器仍携带着用户在目标网站的有效认证信息（如 Session Cookie），该恶意请求看上去就像是由真实用户授权并发起的。
服务器处理请求：目标网站服务器接收到该请求后，由于请求中包含了有效的认证信息，误认为这是用户的真实意图，于是执行了请求所指示的操作，如转账、修改账户设置等，导致用户的利益受损。
**CSRF 攻击的特点 **：
隐蔽性：攻击通常在用户无感知的情况下进行，受害者只是简单地访问了一个看似无害的链接或网页。
依赖用户已登录状态：攻击依赖于用户已经在目标网站处于认证状态，攻击者无法获取用户的登录凭据，而是利用浏览器自动发送的认证信息。
跨站性：攻击发生在用户访问的恶意网站与目标网站之间，攻击者通过第三方站点发起针对目标站点的恶意请求。
防范 CSRF 攻击的常用措施：
使用 CSRF Token：服务器在处理敏感操作请求时，要求客户端在请求中附带一个一次性、难以预测的令牌（CSRF Token）。这个令牌通常在用户登录后生成，存储在服务器端（如数据库）并与用户的会话关联。同时，服务器将其作为隐藏字段嵌入到表单中，或通过其他安全方式（如 HTTP Only Cookie）发送给客户端。客户端在发起请求时必须携带这个 Token，服务器会对收到的 Token 进行验证，确保请求确实来自合法的、预期的用户操作。
检查 Referer 头或 Origin 头：服务器可以检查请求的 Referer 或 Origin 头部信息，判断请求是否真正源自自己的网站。但这不是一个可靠的防护手段，因为 Referer 和 Origin 头可以被浏览器禁用或篡改，且不适用于跨域请求。
使用 POST 请求代替 GET 请求：对于敏感操作，尽可能使用 POST 请求，因为 GET 请求的参数可以直接嵌入 URL 中，更容易被利用。虽然这不是绝对的安全，但增加了攻击的难度。
实施严格的身份验证和会话管理：例如，设置短时有效的 Session，对重要操作要求二次确认（如短信验证码、二次密码等），以及定期更换 Session ID 等。
总的来说，CSRF 攻击是利用浏览器的同源策略和用户已有的认证状态，通过社会工程学手段诱使用户触发恶意请求的一种安全威胁。防范 CSRF 攻击需要结合多种策略，其中使用 CSRF Token 是最常用且有效的手段之一。
# 什么是 XSS 攻击
XSS（跨站脚本攻击，Cross-Site Scripting）是一种常见的网络安全漏洞，它允许攻击者将恶意的脚本注入到受信任的网页中，使其在用户浏览器上执行。
XSS 攻击通常利用了 Web 应用程序对用户输入数据的不充分过滤或验证。攻击者可以通过在网页中插入恶意的脚本，例如 JavaScript，来窃取用户的敏感信息、劫持用户会话、修改网页内容或执行其他恶意操作。
XSS 攻击可以分为三种常见类型：
- 存储型 XSS：恶意脚本被注入到目标网站的服务器端，存储在数据库中，当用户请求包含恶意脚本的页面时，恶意脚本会被服务器返回并在用户的浏览器上执行。
- 反射型 XSS：恶意脚本作为用户的输入参数，例如通过 URL 的查询参数传递，当用户访问包含恶意脚本的链接时，恶意脚本会被注入到页面中并在用户的浏览器上执行。
- DOM 型 XSS：恶意脚本通过修改网页的 DOM（文档对象模型）结构，例如修改网页中的 JavaScript 代码或元素属性，当用户浏览被攻击的页面时，恶意脚本会被执行。
危害：
XSS 攻击的危害包括窃取用户敏感信息（如登录凭据、个人信息）、盗取用户会话、篡改网页内容、重定向用户到恶意网站等。为了防止 XSS 攻击，开发人员应该采取适当的安全措施，如对用户输入进行严格的验证和过滤、使用安全的编码方式输出数据、设置合适的 HTTP 头部等。
用户也应保持警惕，避免点击来自不可信来源的链接，尤其是那些看起来可疑或提供了用户敏感信息的网页。此外，使用最新版本的浏览器和安全插件可以帮助减少 XSS 攻击的风险。