文章目录
属于越权漏洞
理论知识
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 的身份验证
- 无状态、可扩展
- 支持移动设备
- 跨程序调用
- 安全
jwt(json web token)
一个 JWT 实际上就是一个字符串,它由三部分组成:
- 头部(head)
- 负载(payload)
- 签名(Signature)
前两部分需要经过
Base64
编码,后一部分通过前两部分
Base64
编码后再
加密
而成
header
头部通常由两部分组成:算法类型和令牌类型。
- 算法类型:指定用于生成签名的算法,例如 HMAC、RSA 或者 ECDSA。
- 令牌类型:指定令牌的类型,常见的是 JWT。
头部使用
Base64URL
编码表示,并作为整个 JWT 的第一部分。头部的一个示例:
{"alg":"HS256","typ":"JWT"}alg:
是说明这个 JWT 的签名使用的算法的参数,常见值用 HS256(默认),HS512 等,也可以为
None。HS256 表示 HMACSHA256。
typ:
说明这个 token 的类型为 JW
算法类型也可以是 none,表示不加密,不加密的话签名就没用了,但是最后那个 点 必须要有
payload
载荷存储了有关用户或实体的声明和其他有关信息
- 声明:如用户 ID、角色、权限等信息
- 注册声明:包含一些标准的声明(比如发行人、过期时间等)和一些自定义的 声明
载荷也使用
Base64URL
编码表示,并作为整个 JWT 的第二部分。载荷的一个示例:
{"sub":"1234567890","name":"John Doe","iat":1516239022}
Signature
签名是拿到被base64编码的头部和负载后,用标头里的加密算法对拿到的标头和负载进行加密,然后作为jwt的第三部分。签名是用来验证标头和负载中的信息有没有被篡改。如果标头和负载的信息被篡改,则这个jwt是失效的。反之验证通过 ----------------用于验证 JWT 的完整 性和真实性
服务器有一个不会发送给客户端的密码(secret),用头部中指定的算法对头部和声明的内容用 此密码进行加密,生成的字符串就是 JWT 的签名
签名生成方式:将头部和载荷进行
Base64URL
编码后拼接在一起,然后使 用指定的加密算法(如
HMAC、RSA
)进行签名,将生成的签名添加到
JWT
中
JWT通信流程
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
注册一个用户
第四关
通过目标:以管理员的身份清楚普通用户的投票数
点击删除投票的按钮,
BurpSuite
拦截数据包,并观察数据包
访问jwt.io网站,粘贴进去
可以看出使用的加密算法为
HS512
Payload:
admin
为
false
,
user
不是
admin
,而是
Tom
选中
Payload
来到base64这个网站,
admin
修改为
true
,
再把JWT头部的算法类型改为
none
,如果改为了
none
,后面的签名就没有意义了
签名的意义就是为了加密算法是否正确,内容是否正确,现在不用加密了,所以最后一个
.
后面的签名部分就不要了
刷新页面
成功重置!!
第五关
修改 exp 有效时间 ,修改username为 WebGoat
爆破秘钥
hashcat -m 16500 jwt.txt -a 3-w 31.txt
-m 16500 这里的 16500 对应的就是 jwt 的 token 爆破;
-a 3 代表蛮力破解
-w 3 可以理解为高速破解,就是会让桌面进程无响应的那种高速
jwt.txt 是我把题目要求破解的 token 保存到的文件
pass.txt 密码字典
得出密钥是
victory
第七关
通过目标:冒充tom用户,让tom帮我们付钱
BurpSuite
拦截数据包,并观察数据包
并不是说一定要把
JWT
放到
Cookie
字段里
靶场提供了一个JWT ,点击
here
跳转链接
修改Payload的过期时间和头部的算法类型
unix时间互换
版权归原作者 过期的秋刀鱼- 所有, 如有侵权,请联系我们删除。