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进行保存,以便服务器端验证用户的身份和权限
优点
- 安全性高;让用户能够选择信任的身份提供者登录。
缺点
- 生命周期由第三方控制