前端 保存登陆态方式

cookie

存储用户登录态的传统方法—Cookie，是通过Web服务器设置在用户浏览器中的一小段文本

• 优点
  • 跨平台兼容性好，服务器可以轻松读取和写入
• 缺点
  • 容量有限(4KB)
  • 容易 csrf 攻击
  • xss 攻击
  • 容易被窃取和篡改
• 安全性解决方案：
  • secure:只有在使用SSL链接时候才能发送到服务器，如果是http链接则不会传递该信息，但不绝对
  • httpOnly: 防止客户端脚本通过 document.cookie 等方式访问 Cookie，有助于避免 XSS 攻击
  • SameSite：让 Cookie 在跨站请求时不会被发送，从而可以阻止跨站请求伪造攻击，取值:strict
  • 使用加密和签名等技术来保护数据的安全性和完整性

localStorage

• 优点
  • 容量较大（约 5-10MB)
  • 跨平台兼容性好
• 缺点
  • 容易遭受 XSS 、CSRF攻击
  • 不自动提交给服务器
• 安全性解决方案：
  • 使用加密和签名等技术来保护数据的安全性和完整性
  • csrf
    • 产生原因：
      • 因为localStorage是基于域名的，也就是说，只要攻击者能够向目标网站发送请求，就可以访问目标网站的 localStorage 数据。
      • 在 localStorage CSRF 攻击中，攻击者会在恶意网站中构造一个表单，将表单的 action 属性设置为目标网站的 URL，然后将表单中的数据设置为恶意数据，最后使用 JavaScript 代码自动提交表单。当用户在恶意网站上执行该操作时，表单数据会被自动提交到目标网站，如果在表单回调中操作了localStorage，就能实现对目标网站 localStorage 中数据的篡改
    • 检查网站来源
      • 在每个页面中添加一个隐藏的表单字段，该字段的值为当前页面的域名。
        • 在每个表单提交时，检查表单数据中的来源网站是否与当前页面的域名匹配，如果不匹配，则拒绝表单提交。
      • 检查请求头中的 Referer 字段是否为合法的网站
    • 随机令牌
      • 服务端下发一个隐藏表单，表单中有隐藏的表单字段，每次提交时带上这个令牌内容进行校验
      • 也可以将令牌存到cookie中，但需要保证会话的安全性。如果会话被攻击者劫持，那么攻击者就可以获取到会话中的令牌，并使用该令牌来伪造表单提交。因此，目标网站需要采取一些措施来保护会话的安全性，如使用 HTTPS 协议、设置会话超时时间、使用安全的会话管理机制等。
    • 双重cookie
      • 在用户访问网站页面时，向请求域名注入一个Cookie，内容为随机字符串（例如csrfcookie=v8g9e4ksfhw）。
      • 在前端向后端发起请求时，取出Cookie，并添加到URL的参数中（接上例POST https://www.a.com/comment?csrfcookie=v8g9e4ksfhw）。
      • 后端接口验证域名下的cookie中的字段与URL参数中的字段是否一致，不一致则拒绝。
      • 双重cookie问题:
        • 任何跨域都会导致前端无法获取Cookie中的字段
        • 如果用户访问的网站为 www.a.com，而后端的 api 域名为 api.a.com。那么在 www.a.com下，前端拿不到 api.a.com 的cookie，也就无法完成双重 cookie 认证
          • 这个认证 cookie 必须被种在 a.com下，这样每个子域都可以访问。
        • 任何一个子域都可以修改 a.com 下的 cookie, 如果攻击者修改了 a.com 下的 cookie。攻击者可以直接使用自己配置的cookie，对 xss 中招的用户再向 www.a.com 下，发起 csrf 攻击。
    • 双重验证：需要用户提供多个因素来验证身份，例如密码和手机验证码。攻击者无法伪造这些因素，因此无法通过 CSRF 攻击来窃取用户的身份验证信息。

<input type="hidden" name="csrf_token" value="">

IndexedDB 等 web 存储

• 优点
  • 数据量大
  • 支持事务和索引等高级功能
• 缺点
  • 容易受xss、csrf攻击
  • 容易被窃取和篡改
  • 数据丢失，如果 IndexedDB 中的数据没有进行备份或同步，那么一旦浏览器崩溃或升级，就可能导致数据丢失。
• 安全性解决方案
  • xss：对用户输入的数据进行过滤和转义，避免 XSS 攻击。
  • csrf：同上
  • 对 IndexedDB 中的数据进行加密或签名，避免数据泄露
  • 定期备份 IndexedDB 中的数据
  • 对 IndexedDB 中的数据进行访问控制
    • 在创建 IndexedDB 数据库时，可以设置数据库的访问控制规则，例如只允许特定的用户或角色访问数据库。这样可以限制非授权用户的访问权限，保护敏感数据的安全。
    • 对 IndexedDB 中的数据进行加密，只有授权用户才能解密数据并访问。这样可以保护数据的机密性，避免数据被窃取或篡改。

session

流程

• 第一次登陆成功后，在服务器端创建一个 session，并响应设置 ‘Set-Cookie’，将 session ID 返回给客户端。
• 客户端在接收到 session ID 后，将其保存在 cookie 中，以便在后续的请求中发送给服务器
• 在用户退出登录时，服务器会销毁对应的 session，以便释放资源和保护用户的安全

优点

• 用户的登录状态保存在服务器端，由服务器进行管理和维护，相对于客户端存储方案更可控。
• 数据安全：由于数据存储在服务器端，不容易被篡改，相对于客户端存储方案（如 cookies）更安全。
• 对敏感数据的保护：可以安全地存储敏感信息。敏感数据不会泄露给客户端。

缺点

• 消耗服务器资源：如果有大量用户登录，服务器需要处理和存储这些 session，可能会影响服务器性能。
• 在集群或分布式环境下，session 同步和共享可能引发问题
• session 在通常情况下依赖于 cookie（sessionid 存储在 cookie 中）。如果用户禁用了 cookie，需要使用其他方法传递 sessionid

安全性解决方案：

• 对 sessionid 使用加密和签名，以防止篡改和猜测。
• 启用安全传输（如 HTTPS），防止中间人攻击和窃听。
• 确保 cookie 安全配置，例如设置 secure 标志以仅通过 HTTPS 传输，设置 HttpOnly 标志以禁止在客户端 JavaScript 访问

JWT

流程

• 将用户的身份信息（如用户名、角色、权限等）编码成一个 JWT 字符串，并将其发送给客户端浏览器。
• 客户端浏览器在后续的请求中将 JWT 字符串发送给服务器，一般是请求头部中添加一个名为 Authorization 的字段

优点

• 无状态：使用 JWT 无需在服务器端保存用户的会话状态，从而避免了服务器端的存储和管理开销。
• 跨平台：使用 JWT 可以在不同的平台和语言之间共享用户的身份信息，从而提高了系统的可扩展性和互操作性。
• 避免csrf：因为 token 一般放在请求头中，cookie 只是存放，第三方网站也不能操作 cookie

缺点

• JWT 信息暴露：由于 JWT 中包含了用户的身份信息，如果 JWT 被窃取或泄露，攻击者可以获取用户的敏感信息
• 与 Session ID 相比，JWT 通常体积更大，这可能会导致每个请求传输更多的数据。

安全性解决方案

• 使用 HTTPS 协议：使用 HTTPS 协议可以加密通信，避免 JWT 被窃取或篡改。
• 在客户端存储 JWT，通常选择使用 Cookie并启用 HttpOnly 及 Secure 标志。这样可以降低 JWT 被恶意脚本窃取的风险，同时在传输过程中令牌保持加密

OAuth2 和 OpenID Connect

流程：

• 采用第三方授权、验证服务，比如 github、google等，将服务商返回的token进行保存，以便服务器端验证用户的身份和权限

优点

• 安全性高；让用户能够选择信任的身份提供者登录。

缺点

• 生命周期由第三方控制