业务记录：登录

业务记录：登录

  1. 加入验证码
  2. 可自动登录
  3. 维护前后端登录状态

1. 验证码

可以使用验证码来防止脚本无限次登录，来破解用户密码或攻击服务器

滑动验证码的实现可以参考这篇博文：https://www.cnblogs.com/top-housekeeper/p/11392439.html

2. 自动登录

自动登录，说明登录时无需手动输入登录信息，

这意味着登录信息存储在了用户这边，可以说是不安全的！

不过碍于这样很方便，我们会尝试提高其安全性：

  1. 进行加密存储
  2. 降低自动登录后的权限（在进行一些操作时要求用户再次验证）
  3. 进行ip检测，不一致不可以进的哦！

数据在前端存储的位置

浏览器有3个经常保存数据的地方：(可以在浏览器F12查看)

  1. Cookie
  2. LocalStorage
  3. SessionStorage
  • 在多数网站中，SessionStorage不会被用来存储数据，它的生命周期是一个会话，数据仅会存储在当前标签页
  • LocalStorage的数据会无限期存储在本地，后端无法感知，或许是处于安全的考虑，使用不多。
  • 那么，就剩Cookie了，没错，它是使用最普遍的那个。

2.1 SessionStorage

sessionStorage 属性允许你访问一个，对应当前源的 session Storage 对象。存储在 sessionStorage 里面的数据在页面会话结束时会被清除。

  1. 页面会话在浏览器打开期间一直保持，并且重新加载或恢复页面仍会保持原来的页面会话。
  2. 在新标签或窗口打开一个页面时会复制顶级浏览会话的上下文作为新会话的上下文，这点和 session cookie 的运行方式不同。
  3. 打开多个相同的 URL 的 Tabs 页面，会创建各自的 sessionStorage。
  4. 关闭对应浏览器标签或窗口，会清除对应的 sessionStorage。
  5. 特定于页面的协议

2.2 LocalStorage

localStorage 属性允许你访问一个 Document 源的对象 Storage，存储的数据将保存在浏览器会话中。

  1. 存储在 localStorage 的数据可以长期保留；
  2. localStorage 中的键值对总是以字符串的形式存储。
  3. 特定于页面的协议

HTTP Cookie（也叫 Web Cookie 或浏览器 Cookie）是服务器发送到用户浏览器并保存在本地的一小块数据。

浏览器会存储 cookie 并在下次向同一服务器再发起请求时携带并发送到服务器上。

通常，它用于告知服务端两个请求是否来自同一浏览器——如保持用户的登录状态。

Cookie 使基于无状态的 HTTP 协议记录稳定的状态信息成为了可能。

Cookie 主要用于以下三个方面：

  1. 会话状态管理
  2. 个性化设置
  3. 浏览器行为跟踪

3. 维护前后端登录状态

最简单的方法是用Session来维护，(你问什么是Session?，它在后端存储一个sessionId -> value映射的哈希表，前端在cookie中持有sessionId)，

不过，这个东西对分布式不友好（用不到，考虑一下也没问题的，需要考虑session的同步问题

有一个常用解决方法：Token，一串字符串，代替用户信息存入Cookie中（或者放在http头部）

3.1 Token

token可以考虑放在Cookie中或者http的header中

3.1.1 放在Cookie中

动态token，有失效时间，可以考虑存在cookie中

  1. 浏览器会自动管理 Cookie 的发送，无需手动设置。
  2. 可以设置 Cookie 的过期时间，到期自动失效。
  3. 默认情况下，Cookie 不能跨域发送。

3.1.2 放在header中

静态token，不会失效，可以考虑存在header中

  1. 通过 HTTPS 传输时，Header 中的 Token 不会暴露在 URL 中，减少了被窃取的风险。
  2. 适用于跨域请求（CORS），因为可以在不同的域之间传递 Token。
  3. 能够抵挡下简单的CSRF攻击

3.2 CSRF

CSRF 通过构造请求，利用用户已认证的会话凭证，让服务器误以为是用户的合法操作。

token放在头部时，可以避免直接调用cookie的攻击

不过，在攻击者针对时，攻击者可以附带头部的token进行攻击，所以这只是简单的防御，不可靠

正确做法：在后端检测头部的Referer字段，不是自己网址发出的，拦截即可。

3.3 CORS

  1. 同源策略是一个重要的安全策略，它用于限制一个源的文档或者它加载的脚本如何能与另一个源的资源进行交互
  2. 如果两个 URL 的协议、端口（如果有指定的话）和主机都相同的话，则这两个 URL 是同源的。
  3. 跨源资源共享（CORS）是一种基于 HTTP 头的机制，

    该机制通过允许服务器标示除了它自己以外的其他源（域、协议或端口），使得浏览器允许这些源访问加载自己的资源。

3.4 XSS攻击（待补充）

跨站脚本攻击(xss)，指攻击者通过篡改网页，嵌入脚本程序，在用户浏览网页时，控制用户浏览器进行操作的一种攻击方式。

3.5 半路被截和重放攻击（待补充）

采用Https协议

3.6 Token的生成

3.6.1 使用JWT

JWT全称JSON Web Tokens 是一种规范化的 token

一个 JWT token 是一个字符串，它由三部分组成，头部、载荷与签名，中间用 . 分隔，例如：xxxxx.yyyyy.zzzzz

头部

头部通常由两部分组成：令牌的类型（即 JWT）和正在使用的签名算法（如 HMAC SHA256 或 RSA.）。

载荷（Payload）

载荷中放置了 token 的一些基本信息，以帮助接受它的服务器来理解这个 token。同时还可以包含一些自定义的信息，用户信息交换

签名（Signature）

签名时需要用到前面编码过的两个字符串，以 HMACSHA256 加密或者其他加密算法。

签名的作用：保证 JWT 没有被篡改过，原理如下：

HMAC 算法是不可逆算法，类似 MD5 和 hash ，但多一个密钥，密钥（即上面的 secret）由服务端持有，客户端把 token 发给服务端后，

服务端可以把其中的头部和载荷再加上事先共享的 secret 再进行一次 HMAC 加密，

得到的结果和 token 的第三段进行对比，如果一样则表明数据没有被篡改。

读取登录信息 -> 进行验证 -> 验证通过 -> 返回true
                       -> 验证失败 -> 返回false

验证:
读取数据库信息 -> 存在则进行比对
              -> 不存在 -> 返回"用户不存在"

存储信息的选取：
Mysql，
常用数据存入缓存
posted @ 2025-10-21 13:34  Insanial  阅读(4)  评论(0)    收藏  举报