根据实验要求需要⾸先登录,尝试将⾃⼰的邮箱修改成管理员邮箱
发现如果要更改邮箱还要去本邮箱进⾏确认


尝试将邮箱修改为⾃⼰本来的邮箱,然后去邮箱客⼾端⾥⾯去看

并在⾃⼰的邮箱中发现了修改链接,点进去提⽰邮箱已经更改

⼤致流程就是提交 要更改的邮箱 → 发送信息验证 → 邮箱确认,然后更改成功

当⻚⾯再次刷新时,提⽰此链接⽆效了
由此,可以推断该⽹站⼀次只存储⼀个待处理的电⼦邮件地址。由于提交新的电⼦邮件地址会在数据库
中编辑此条⽬,⽽不是追加到该条⽬,因此可能会发⽣冲突

通过从AAA到DDD的顺序点击确认链接,发现就DDD开头那⼀次更改是⽣效了,之前的相当于被覆盖了
接下来发送⾄爆破模块,⽤枚举的⽅式进⾏发送,将@符号前⾯添加为payload的位置

发现邮箱并不是按照规律发送,收件⼈地址并不总是与挂起的新电⼦邮件地址匹配
考虑到⽹站发送邮箱处可能存在⼀个条件竞争的可能性
推断,当邮箱处理正常发送时,使⽤了并⾏条件竞争,会导致确认电⼦邮件发送到错误的地址
修改payload如下,payload的位置为整个邮箱地址
.

点击爆破

点击确认,已经成功修改为carlos@ginandjuice.shop

实验室:利⽤时间敏感漏洞
使⽤wiener:peter登录账⼾

重置密码需要输⼊邮箱地址,填写邮箱客⼾端⾥⾯的地址

重置密码的链接中包含我们的⽤⼾名和token
将POST /forgot-password这个数据包发送到重放模块,通过观察发现token是随机的。但是⻓度都⼀ 样

将重置密码数据包中的get请求的cookies删除并发送出去,然后在响应中获取新的cookies和csrf(因为
每⼀个csrf只能⽤⼀次)替换到新复制出来的数据包中,然后将它与原来的数据包加⼊同⼀个group 然
后并发发送。
为什么需要重新获取cookie和csrf:因为观察到数据包请求Cookie中包含了phpsessionid=xxx
说明⽹站后端使⽤了php语⾔,这意味着服务器处理时,对每个会话⼀次只处理⼀个请求,⽽我们
从回显中可以看出每⼀个csrf也只能⽤⼀次



token为什么要保持⼀致:由于user参数是独⽴的,这表明token中的hash⽣成时并不将user加
⼊其中,那么这就有可能导致两个不同的user理论上具有相同的token,既然token⼀样⽽token
⼜与时间戳互相挂钩⽽时间戳我们⼜可以通过并发保证相同,那么实现相同token也就是可⾏的
将其中⼀个数据包的username改为carlos
然后点击发送

这⾥来到邮箱只收到了⼀封邮件
尝试将
wiener
改成
carlos
访问,如果没有提⽰
"Invalid token"
说明就是成功了,改掉的密码就
是
carlos
密码

