「Burpsuite练兵场」验证机制漏洞

Burpsuite练兵场系列文章更新啦，今天的内容是延续上期关于验证机制漏洞的讲解，对实验感兴趣的小伙伴千万别错过了呦！

身份验证机制中的其他一些漏洞

这一次的实验仍然聚焦于身份验证机制。可以发现，一个看似简单的功能背后其实存在许多可以利用的点，我们在实际的漏洞挖掘中也要充分考虑各种业务逻辑中会出现的问题，寻找可能存在的突破口。

实验一：“记住我”功能cookie爆破

如果没有提示的话，常见的方式一般为直接在登录功能处进行爆破，我们也可以使用Repeater功能查看Web应用是否对此进行了限制，可以发现确实遭到了限制。

使用实验提供的第一个进行账号登录，第一次先不勾选Stay logged in功能，之后退出登录勾选该功能后再次登录。

通信流如图所示：

这里说一下显示过滤的配置，为了方便分析通信流程，可以把不需要的信息隐藏掉(101 Switching Protocol 是用于过滤 GET /academyLabHeader的请求信息)。

可以观察到勾选Stay logged in功能以wiener账户登录后，服务器赋予了一个新的Cookie项目。

使用Decoder功能尝试Base64解码，发现成功。

推测用户名后的一串字符为MD5加密，使用在线MD5解密网站进行验证（当然也可以对peter进行md5计算比对结果）。

现在已经清楚了该cookie字段内容的组成方式，退出账号重新访问home页面，拦截GET请求进行设置尝试爆破。

配置使用Payload Processiong功能，注意不要搞错顺序。

根据结果按照返回报文长度排序确定正确Cookie值，注意这里使用Request in browser in original session的方式。

成功登录访问My account页面完成实验。

注意：这里有一个地方可能大家会感觉很奇怪，就是为什么之前实验是Show response in browser，而这次实验又变成了Request in browser，没错，这些方法之间确实存在一定差异。

Show response in browser：复制url到浏览器中访问后，并不会发送新的页面请求（但会请求图片资源），而只是将其响应显示在浏览器中，之前的实验使用这种方式是因为发送的是POST请求，返回结果中包含了我们想要的字段信息（正确的csrf字段值等），后续可以成功访问My account页面；

Request in browser in original session：在原会话中发送请求，复制到浏览器后会使用原先的cookie等字段信息发送请求。在本次实验中，我们需要正确的stay-logged-in参数值以伪造carlos用户登录，因此使用了这一方式；

Request in browser in current session：复制到浏览器后访问会使用当前浏览器会话中的cookie等字段信息发送请求。

实验二：离线密码破解

这题主要考察了对于存储型XSS漏洞的利用，关于XSS的原理及利用这里不再叙述。

使用wiener账户登录后可以发现实验给了我们一个exploit服务器，我们可以构造自己所需要的payload，并且在Access log中可以看到所有发送给该服务器的请求记录。

因此，我们只需要构造一个带参的GET请求，使得carlos点击之后记录其cookie等请求信息。

使用javascript构造一个对服务器的ajax请求，并附加上页面cookie，注意参数要替换为自己的exploit服务器地址，点击保存。

返回博客页面，任意选择一个点击view post进入评论界面，构造XSS利用payload并提交。

返回Access log界面可以发现carlos已经上钩了。

我们返回home页面退出登录，并重新请求home页面拦截替换stay-login-in参数值。

成功登录后需要删除账户才能完成实验，访问My account页面并点击Delete account发现需要确认密码，所以我们还要对cookie值进行解密。

其结构仍然为之前的md5+base64方式，我们使用在线md5解密网站进行破解。

输入破解出的密码成功删除，实验完成。

实验三：密码重置逻辑损坏

还是跟之前一样，访问应用各种功能，寻找可以利用的位置。

在POST新密码的请求中发现了username参数疑似存在利用点。

将该通信发送到Repeater模块，修改参数值为carlos并发送。

返回登录页面，用修改的密码尝试登录，发现成功了。

后来看了下实验solution，该实验其实际漏洞为对temp-forgot-password-token这一参数的验证不严，大家也可以按照solution一步步进行验证。

实验四：密码重置毒化

可以看到实验提示：Carlos 会点击所有发往其邮箱中的密码重置链接，所以我们需要构造一个恶意链接。

先重置wiener的账号密码，登录并访问各个功能，发现之前的各种突破手段就失效了。

观察这个密码重置链接，这里存在的问题为url中的访问路径是动态构造的，可以使用X-Forwarded-Host进行伪造（如果之前没有经验确实很难推断）。

拦截密码重置请求，新增X-Forwarded-Host字段，将值设置为exploit服务器地址。

查看访问日志可以发现carlos携带temp-forgot-password-token参数的访问请求。

复制参数构造url重置密码，最后登录以完成实验。

实验五：通过密码重置功能爆破账户密码

登录后访问My account页面可以发现存在一个重置密码功能。

进行几次尝试后会发现如果输错Current password会被弹出登录，但如果New password和Confirm new password中输入的值不同，则会显示Current password is incorrect。

而如果密码错误，输入值不同则会显示。

同时，POST密码重置请求中的username字段可以进行更改，利用这些特性，我们就可以爆破carlos账户的密码了。

配置payload

成功爆破密码，登录访问My account页面完成实验。

总 结

到这里整个身份验证机制有关的实验就结束了，从其中我们也可以总结出一个良好的验证机制设计应该具有哪些要素：

1、在用户登录，注册，找回密码等与账户验证有关的地方启用高强度的验证码（简单的图形验证码现在基本都可以使用机器学习等方法自动破解了）；

2、不要在这三个功能的相关页面中透露太多信息，如是密码错误还是用户名错误；

3、做好防爆破验证，如几次密码错误后需要间隔多少时间才能重新登录，间隔时间不断递增；

4、做好cookie等相关字段的加密，不要使用易于被破解的结构。

同样，我们在实际的Web安全审计中如果发现应用没有依循这些要素，就说明可能存在可被利用的点。

好cookie等相关字段的加密，不要使用易于被破解的结构。

同样，我们在实际的Web安全审计中如果发现应用没有依循这些要素，就说明可能存在可被利用的点。

以上是今天要分享的内容，大家看懂了吗？

本文作者：i春秋聚集地

本文为安全脉搏专栏作者发布，转载请注明：https://www.secpulse.com/archives/136698.html