pikachu靶场分析笔记

pikachu靶场分析笔记

一、暴力破解

1、基于表单的暴力破解

一个登录表单，也没有验证码之类的安全验证。可以直接抓包爆破

一开始想看看这里是不是存在SQL注入的，但发现使用了 mysqli 扩展进行预处理：

1. 使用 $link->prepare() 函数来准备 SQL 语句，得到一个 mysqli_stmt 对象。
2. 使用 $line_pre->bind_param() 函数来绑定参数，第一个参数为参数类型，第二个参数为要绑定的参数值。
3. 使用 $line_pre->execute() 函数执行准备好的语句，并返回执行结果。
4. 使用 $line_pre->store_result() 函数将查询结果存储在 mysqli_stmt 对象中。
5. 使用 $line_pre->num_rows 函数获取查询结果的行数。

虽然SQL注入没有，但是这里没有任何防御爆破的措施可以直接抓包爆破

2、验证码绕过—前端（客户端）验证

这里采用了验证码来防止暴力破解，但是验证码却是由前端生成并校验的

这种验证码，抓包即可绕过

验证码只在前端校验，删掉这个字段都可以

3、验证码绕过—服务端验证码复用

这里的验证码由服务器生成

当登录请求到达服务端后，服务端返回响应包，客户端再次请求验证码，达到刷新的目的。乍一看好像并没有什么问题，但是如果客户端没有收到响应包呢？这样就不会刷新验证码。

而且服务端在校验验证码非空且正确后，便校验提交的用户名和字典。正常情况下不管校验结果如何，验证码一旦提交到服务端，在验证后，不管对不对，都应该销毁，重新刷新。但这里服务端没有及时销毁更新验证码

使得抓到请求包后丢弃，便不会刷新验证码，从而达到验证码重复利用，爆破账户的目的

这里还有一个问题：服务端将验证码字符串以明文COOKIE的方式给了前端

4、token防爆破

这里使用了token验证来代替验证码，每次登录请求都会带上上一次生成的token

但是这里有一个问题，那就是生成的token，直接储存在前端，方便下一次请求携带

只要我们爆破时，把上一次的请求响应包中的token值当作这一次的token一起提交到服务端即可完成token验证，也就达到了爆破的目的。

将token和password两项设置为变量 攻击模式使用Pitchfork。选择Resource Pool将线程数设置为1（递归查找，将上一个请求的相应token作为下一个请求的payload的token，所以就不并发）

Grep-Extract模块进行相应设置，获取相应的token，截取相应token的前后标识，用于下次截取

Redirections模块设置允许重定向，选择always

payloa设置

开始爆破，成功!

二、XSS

1、反射型XSS（get）

这里对输入的参数没有任何过滤，就直接拼接在要显示在页面的语句中

但是前端对输入的内容有字数限制，秉持着”我的地盘我做主“的原则，手动改一下就行了

输入xss语句，提交触发

2、反射型XSS（post）

这里和1类似，只是提交参数的方法不同，而且这里还没有字数限制

输入XSS语句，提交触发

3、存储型XSS

这里模拟的是留言场景，未经过滤的留言，直接写入数据库，然后显示在页面上，造成了存储型XSS

我还尝试测试了一下SQL注入，但是很遗憾，这里会转义单引号

构造XSS语句，提交，触发弹框

这里源代码提示还有一个SQL注入彩蛋，虽然insert语句中参数有引号保护，但是删除留言的delete语句没有。但是这里有一个id是否为数字的判断，无法注入

如果没有这个确实可以注入