JWT、seesion、cookie、csrf漏洞

JWT、seesion、cookie、csrf漏洞

JWT

概念

1. JWT：Json Web Token跨域认证解决方案，一种规范化之后的JSON结构的Token

2. 自身包含了身份验证所需要的所有信息：服务器不需要存储seesion信息

3. 更符合设计Restful API时的无状态原则

4. JWT认证可以有效避免CSRF攻击，一般存在在localStorage，身份验证过程中不会设计Cookie

5. 适合移动端应用：通常是无状态；面向多个平台，跨平台兼容性问题；处于不受信任的网络环境

解决注销登录等场景JWT仍然有效的方法

1. 将JWT存入数据库：违背JWT无状态原则

2. 黑名单机制：违背无状态原则（一般实际项目中通常会使用1、2两种方案）

3. 修改密钥：每个用户创建一个专属密钥。危害更大

   • 分布式服务：新的JWT必须多台机器同步密钥

   • 两个浏览器或手机端打开系统：都要重新进行登录

4. 保持令牌的有效期限短并经常轮换

组成

1. Header头部：描述JWT的元数据，定义生成签名的算法和Token类型

   • JSON 格式的数据

2. Payload载荷：存放实际需要传递的数据

   • JSON 格式的数据

   • 默认不加密：一定不要将隐私信息存放在 Payload 当中

3. Signature签名：服务器通过 Payload、Header 和一个密钥(Secret)使用 Header 里面指定的签名算法生成

   • 特定的计算公式和加密算法得到

4. 格式：xxxxx.yyyyy.zzzzz（通常三部分）

验证步骤

1. 用户向服务器发送用户名、密码以及验证码用于登陆系统

2. 如果用户用户名、密码以及验证码校验正确的话，服务端会返回已经签名的 Token，也就是 JWT

3. 用户以后每次向后端发请求都在 Header 中带上这个 JWT （放在 HTTP Header 的 Authorization 字段中）

4. 服务端检查 JWT 并从中获取用户相关信息

Session

概述

1. 服务器和客户端一次会话的过程

2. 包含有关用户会话信息：用户ID、登录状态等。

   • 保存在服务器端

   • 存任意数据类型

   • 保存对象

3. 只有当关闭客户端会话orSession超时失效时会话结束

4. 访问增多，会消耗服务器性能

用途

1. 编辑文章、发表评论等：可确保用户数据安全传输

Cookie

概述

1. 由服务器发送到用户浏览器，存储在用户计算机上的小型文本文件

2. 包含用户信息：用户ID、密码、浏览记录等

3. 当用户再次访问网站时，浏览器会将Cookie信息发送回服务器，帮助服务器识别用户身份

   • 保存在客户端（浏览器）

   • 只保存ASCII

   • 保存字符串

4. 打开浏览器，看Cookie内容：Fn+F12。

   • 明文传输：非常不安全

5. 设置了路径参数：同一个网站不同路径的cookie互相访问不到

用途

1. 用户会话：Cookie有助于将网站活动与特定用户关联

2. 个性化：Cookie 帮助网站“记住”用户行为或用户偏好

3. 追踪：有些 Cookie 会记录用户访问的网站。当浏览器下次需要从该服务器加载内容时，这些信息会被发送到产生 Cookie 的服务器

CSRF攻击

CORS

1. 跨域资源共享：需要在后端设置允许跨域，在前端单独设置允许跨域的 Cookie 传递，非常麻烦

概述

1. 跨站请求伪造：强迫使用者在他们已经验证身份的网站中，执行某些恶意的伪造操作，因为已经验证过该使用者，所以网站就会认为该操作来自使用者

攻击流程

1. 使用者成功登入 A 银行网站的帐户，cookie 在本地保存下来，所以下次再来 A 银行网站时，不用重新登入

2. 由于使用者没有登出 A 银行网站的帐户，在浏览 B 恶意网站时，B 网站有个被设为透明的图片，因为是透明的，所以使用者在画面上看不到，然而该图片包含一段恶意代码

3. 使用者虽然将看不到此图片， 但是，浏览器仍会提交请求，同时此请求是带有使用者的 cookie，所以 A 银行可以辨识使用者身份，此恶意攻击执行成功

防御方法

1. 加上验证：增加一些验证，像是图形验证码、简讯验证码等

2. 不用GET请求做关键操作，建议用POST(不绝对安全)

   • Get请求，使用者可能在完全不知情下，进到网站就马上被攻击

   • POST请求，需要有使用者的提交动作才能触发。许多钓鱼网站，都会引诱使用去点击某些按钮，正是因为要有点击这个提交动作，才能触发 CSRF 攻击

3. 检查Referrer

   • 在 HTTP 的标头中有 Referrer 的字段，我们可以检查这个字段，来确保请求不是来自于其他网站

   • 依赖于浏览器这个第三方角色，仍不太安全

4. CSRF token

   • 用于认证身份的 cookie:让网站用其他方式验证使用者的身份，而不是透过 cookie

5. 浏览器本身防护—SameSite cookies

   • Google 在 Chrome 51 版之后加入的 SameSite Cookie 的功能，只要将原本设置 Cookie 的方式后面加上 SameSite 即可

   • 是 HTTP 回应标头中的 Set-Cookie 的属性之一

   • 此属性的可能值为 Lax、Strict 或 None

参考

JWT 基础概念详解 | JavaGuide

你真的了解 Cookie 和 Session 吗? - 纯洁的微笑 - 博客园

https://www.cloudflare.com/zh-cn/learning/privacy/what-are-cookies/

Cookie、Session、Token 的区别与用途_cookie和session和token的作用和区别-CSDN博客

什么是 CSRF 攻击？如何防范？｜ExplainThis