JWT安全

文章目录

    • 理论知识
      • cookie(放在浏览器)
      • session(放在 服务器)
      • token
      • jwt(json web token)
        • header
        • payload
        • Signature
        • JWT通信流程
      • JWT与Token 区别
        • 相同点
        • 区别
    • WebGoat靶场--JWT tokens
      • 环境启动
      • 第四关
      • 第五关
      • 第七关

属于越权漏洞

理论知识

cookie(放在浏览器)

​ cookie 是一个非常具体的东西,指的就是浏览器里面能永久存储的一种数据,仅仅是浏 览器实现的一种数据存储功能。

cookie 由服务器生成,发送给浏览器,浏览器把 cookie 以 kv 形式保存到某个目录下的 文本文件内,下一次请求同一网站时会把该 cookie 发送给服务器。由于 cookie 是存在客户 端上的,所以浏览器加入了一些限制确保 cookie 不会被恶意使用,同时不会占据太多磁盘空 间,所以每个域的 cookie 数量是有限的

session(放在 服务器)

session 从字面上讲,就是会话。这个就类似于你和一个人交谈,你怎么知道当前和你交 谈的是张三而不是李四呢?对方肯定有某种特征(长相等)表明他就是张三。

session 也是类似的道理,服务器要知道当前发请求给自己的是谁。为了做这种区分,服 务器就要给每个客户端分配不同的“身份标识”,然后客户端每次向服务器发请求的时候,都 带上这个“身份标识”,服务器就知道这个请求来自于谁了。至于客户端怎么保存这个“身份 标识”,可以有很多种方式,对于浏览器客户端,大家都默认采用 cookie 的方式。

服务器使用 session 把用户的信息临时保存在了服务器上,用户离开网站后 session 会被 销毁。这种用户信息存储方式相对 cookie 来说更安全,可是 session 有一个缺陷:如果 web 服务器做了负载均衡,那么下一个操作请求到了另一台服务器的时候 session 会丢失。

token

Token是用户进行一些权限操作时的许可凭证。token本质是字符串,里面包含了用户信息,过期时间,加密方式等。token是在前端进行登录之后,由服务器分发给前端,然后前端进行权限操作时,再将token发送给服务器,由服务器来验证。token是有过期时间的,一但token过期,用户就要重新登陆让服务器生成新的token。

在 Web 领域基于 Token 的身份验证随处可见。在大多数使用 Web API 的互联网公司中, tokens 是多用户下处理认证的最佳方式。

以下几点特性会让你在程序中使用基于 Token 的身份验证

  1. 无状态、可扩展
  2. 支持移动设备
  3. 跨程序调用
  4. 安全

jwt(json web token)

一个 JWT 实际上就是一个字符串,它由三部分组成:

  • 头部(head)
  • 负载(payload)
  • 签名(Signature)

JWT安全_第1张图片

前两部分需要经过 Base64 编码,后一部分通过前两部分Base64编码后再加密而成

header

头部通常由两部分组成:算法类型和令牌类型。

  • 算法类型:指定用于生成签名的算法,例如 HMAC、RSA 或者 ECDSA。
  • 令牌类型:指定令牌的类型,常见的是 JWT。

头部使用 Base64URL 编码表示,并作为整个 JWT 的第一部分。头部的一个示例:

{
  "alg": "HS256",
  "typ": "JWT"   
}

alg:
	是说明这个 JWT 的签名使用的算法的参数,常见值用 HS256(默认),HS512 等,也可以为
None。HS256 表示 HMAC SHA256typ:
	说明这个 token 的类型为 JW

算法类型也可以是 none,表示不加密,不加密的话签名就没用了,但是最后那个 点 必须要有

payload

载荷存储了有关用户或实体的声明和其他有关信息

  • 声明:如用户 ID、角色、权限等信息
  • 注册声明:包含一些标准的声明(比如发行人、过期时间等)和一些自定义的 声明

载荷也使用 Base64URL编码表示,并作为整个 JWT 的第二部分。载荷的一个示例:

{
 "sub": "1234567890",
 "name": "John Doe",
 "iat": 1516239022
}

JWT安全_第2张图片

Signature

签名是拿到被base64编码的头部和负载后,用标头里的加密算法对拿到的标头和负载进行加密,然后作为jwt的第三部分。签名是用来验证标头和负载中的信息有没有被篡改。如果标头和负载的信息被篡改,则这个jwt是失效的。反之验证通过 ----------------用于验证 JWT 的完整 性和真实性

服务器有一个不会发送给客户端的密码(secret),用头部中指定的算法对头部和声明的内容用 此密码进行加密,生成的字符串就是 JWT 的签名

签名生成方式:将头部和载荷进行 Base64URL 编码后拼接在一起,然后使 用指定的加密算法(如 HMAC、RSA)进行签名,将生成的签名添加到JWT

JWT通信流程

JWT安全_第3张图片

JWT与Token 区别

相同点

  • 都是访问资源的令牌
  • 都可以记录用户的信息
  • 都是使服务端无状态变化
  • 都是验证成功后,客户端才能访问服务端上受保护的资源

区别

  • Token: 服务端验证客户端发送过来的Token 时,还需要查询数据库获取用户信息,然后验证Token 是否有效
  • JWT: 将token 和 Payload 加密后存储于客户端,服务端只需要使用秘钥进行校验即可,不需要查询或者减少查询数据库,因为JWT自包含了用户信息和加密的数据

WebGoat靶场–JWT tokens

环境启动

启动WebGoat靶场

java -jar webgoat-server-8.0.0.M17.jar --server.port=8888 --
server.address=192.168.8.8

访问WebGoat靶场

127.0.0.1:8888/WebGoat

JWT安全_第4张图片

注册一个用户

JWT安全_第5张图片

第四关

通过目标:以管理员的身份清楚普通用户的投票数

JWT安全_第6张图片

JWT安全_第7张图片

点击删除投票的按钮, BurpSuite拦截数据包,并观察数据包

JWT安全_第8张图片

JWT安全_第9张图片

访问jwt.io网站,粘贴进去

JWT安全_第10张图片

可以看出使用的加密算法为HS512

Payload:adminfalseuser不是admin,而是Tom

选中Payload

JWT安全_第11张图片

来到base64这个网站,admin修改为true

JWT安全_第12张图片

JWT安全_第13张图片

JWT安全_第14张图片

再把JWT头部的算法类型改为none,如果改为了none,后面的签名就没有意义了

签名的意义就是为了加密算法是否正确,内容是否正确,现在不用加密了,所以最后一个.后面的签名部分就不要了

JWT安全_第15张图片

JWT安全_第16张图片

JWT安全_第17张图片

JWT安全_第18张图片

刷新页面

JWT安全_第19张图片

成功重置!!

第五关

修改 exp 有效时间 ,修改username为 WebGoat

JWT安全_第20张图片

JWT安全_第21张图片

JWT安全_第22张图片

爆破秘钥

 hashcat -m 16500 jwt.txt -a 3 -w 3 1.txt
 
-m 16500 这里的 16500 对应的就是 jwt 的 token 爆破;
-a 3 代表蛮力破解 
-w 3 可以理解为高速破解,就是会让桌面进程无响应的那种高速
jwt.txt 是我把题目要求破解的 token 保存到的文件 
pass.txt 密码字典

JWT安全_第23张图片

得出密钥是victory

JWT安全_第24张图片

第七关

通过目标:冒充tom用户,让tom帮我们付钱

BurpSuite拦截数据包,并观察数据包

JWT安全_第25张图片

JWT安全_第26张图片

并不是说一定要把JWT放到Cookie字段里

靶场提供了一个JWT ,点击here跳转链接

JWT安全_第27张图片

JWT安全_第28张图片

JWT安全_第29张图片

JWT安全_第30张图片

JWT安全_第31张图片

修改Payload的过期时间和头部的算法类型

unix时间互换

JWT安全_第32张图片

JWT安全_第33张图片

JWT安全_第34张图片

JWT安全_第35张图片

JWT安全_第36张图片

你可能感兴趣的:(#,渗透测试,安全,网络安全,web安全,JWT,token)