pikachu靶场1-3

一、Burte Force（暴力破解）

概述

"暴力破解"是一攻击具手段，在web攻击中，一般会使用这种手段对应用系统的认证信息进行获取。 其过程就是使用大量的认证信息在认证接口进行尝试登录，直到得到正确的结果。 为了提高效率，暴力破解一般会使用带有字典的工具来进行自动化操作。

理论上来说，大多数系统都是可以被暴力破解的，只要攻击者有足够强大的计算能力和时间，所以断定一个系统是否存在暴力破解漏洞，其条件也不是绝对的。

我们说一个web应用系统存在暴力破解漏洞，一般是指该web应用系统****没有采用或者采用了比较弱的认证安全策略，****导致其被暴力破解的"可能性"变的比较高。 这里的认证安全策略, 包括：

1.是否要求用户设置复杂的密码；

2.是否每次认证都使用安全的验证码（想想你买火车票时输的验证码～）或者手机otp；

3.是否对尝试登录的行为进行判断和限制（如：连续5次错误登录，进行账号锁定或IP地址锁定等）；

4.是否采用了双因素认证；

...等等。

千万不要小看暴力破解漏洞,往往这种简单粗暴的攻击方式带来的效果是超出预期的!

1.基于表单暴力破解

先祟随便输入一个username和passwd，进行捉包

将捉到的包send to Intruder准备进行爆破。

首先选择clear，然后分别选中username和password输入的数据进行标记，点击Add，最后选择攻击方式Cluster bomb

随后进入Payloads模块，在payload set 1位置，也就是username位置，上传关于我们的账号的字典，在2位置选择我们的密码字典，这里如果没有字典，可以去网上查找，或者直接手动添加爆破的数据

设置好payload后 点击右上角start attack进行爆破

爆破结束后，我们可以根据返回数据长度来判断正确的账号密码，返回长度不同于其他数据包的，就是正确的账号密码，此处账号：admin 密码：123456

代码审计

没有进行任何的限制，只是对正确账号密码进行匹配直至成功，可以利用自动化工具发送批量请求

2.验证码绕过（on server）

当我们输入错误的用户名密码以及验证码时，提示我们验证码输入错误

当我输入错误的账号密码，但输入正确的验证码时，提示我们username or password is not exists

并且我们发现，只有当页面刷新时，验证码才会重新刷新，下面我们就来验证一下这个猜想

我们先来抓一个包，输入正确的验证码和任意的账号密码

不改变验证码，只修改username和password

我们发现还是返回username和password不存在，由此验证我们的猜想是对的，只要页面不刷新，验证码就不会改变。

剩下的步骤就和上一关一样了，我们将数据包发送到攻击模块，暴力破解

代码审计

增加了验证码空白和对错判断，但没有对使用过的验证码进行销毁避免重复使用，攻击者可以先手动输入一次正确的验证码，然后使用该验证码无限次发起登录请求，绕过验证码限制

也没有对同一个IP进行登陆限制，导致攻击者可以发送大量请求

3.验证码绕过（on client）

依旧填入错误的账户密码和正确的验证码

输入错误的验证码时

有个提示验证码错误的弹窗

我们查看源代码发现了验证验证码的代码在前端

任何在前端进行的验证，都是可以绕过的

打开开发者工具，选择禁用JavaScript

目的：

禁用 JavaScript 后，前端的校验逻辑（如validate() 函数）会完全失效，能直接验证「仅前端校验」的安全性 ------ 如果服务器没做后端校验，就能直接上传恶意文件。

临时禁用（单页面，关闭即恢复）

1. 打开目标网页
2. 按F12打开开发者工具，切换到「Settings」（F1）
3. 找到「Debugger」→ 勾选「Disable JavaScript」
4. 刷新页面，此时该页面的所有 JS 代码都不会执行

关闭后便可以正常进行爆破

代码审计

这是一个在前端使用Js做的验证码校验

成因

验证码与校验均在前端完成：

验证码 code 是在全局 JavaScript 变量中生成和存储的，攻击者可以直接通过浏览器控制台或抓包工具读取其值。

校验逻辑 validate() 函数也在前端执行，攻击者可以通过禁用 JavaScript、篡改代码或直接构造请求来绕过校验。

无服务端校验：验证码的生成和校验完全依赖客户端，服务端没有任何校验逻辑，导致整个验证码机制形同虚设。

原理

直接读取验证码：攻击者可以在浏览器控制台中直接输入 code，就能看到当前的验证码值，无需识别图片或输入。

禁用 JavaScript：通过浏览器开发者工具禁用 JavaScript，validate() 函数不会执行，直接提交表单即可绕过验证码校验。

篡改校验逻辑：攻击者可以通过篡改 validate() 函数的返回值，让其始终返回 true，从而绕过校验。

直接构造请求：攻击者可以直接构造包含任意 vcode 的 POST 请求，由于服务端不做校验，请求会被直接处理，从而实现暴力破解。

4.token爆破

"token"通常指的是一个用于验证用户身份和授权访问的令牌。它是一种特殊的字符串或代码，由服务器生成并分配给经过身份验证的用户。用户在成功登录后，服务器会颁发一个token给客户端（例如Web浏览器），客户端将在随后的请求中将该token作为身份验证凭据发送给服务器。

对于有token的的验证，我们适用于已经知道账号的情况 ，或者账号和密码一一对应的情况，并且我们的暴力破解方式就要有所调整，我们依旧是先抓包，并发送到攻击模块

我们这里的攻击目标要选择password，以及token，攻击方式选择Pitchfork

下面我们来到payloads模块，password设置和之前一样，上传我们的爆破字典即可，第二个位置token处进行如下设置，我们首先来到setting模块

payloads模块，前两个位置和前面一样，正常选择字典即可，第二个位置选择Secursive grep（递归搜索），并且将我们刚刚复制的token粘贴到下面的框里，开始攻击即可。

通过比较返回数据包长度判断正确密码

代码审计

此处虽然引入了token值的校验

但是token值没有在验证后进行销毁，导致token值可以被重复使用

二、XSS（跨站脚本）

概述

本质：攻击者向web页面中插入恶意脚本代码，当其他用户浏览该页面时，嵌入的脚本就会被执行

类型：

反射型xss（非持久型）：恶意脚本来自当前http请求，随响应"反射"给用户

漏洞成因：

防范策略分析：

存储型xss（持久型）：恶意脚本会通过前端发送给服务器，最终保存在数据库或文件等，所有访问该页面的用户都将受到影响

漏洞成因：

防范策略分析：

DOM型xss：漏洞存在于客户端的js代码中，不涉及服务器，当前端js操作DOM时，将此当作代码执行

1.反射型xss（get）

任意输的入，检查，它是没有做任何的处理，直接写在p标签内容里的，如果写入JavaScript代码将会输出到前端

构造payload弹窗<script>alert('xss')</script>

这时发现输入是有长度限制的，修改长度限制

修改长度限制后，输入，成功弹窗

漏洞成因：

从后端代码可以看到，get的message将会被原封不动的输出到前端的<p>，用户就可以通过message参数将恶意代码直接插入到HTML的<p>，页面渲染时就会执行用户插入的恶意脚本，触发xss

防范策略分析：

使用htmlspecialchars()函数对特殊字符（<>' "等）进行转义；

限制用户输入，如密码只能输入数字等

2.反射型xss（post）

我们发现一个登录框，我们在暴力破解那一关，获取到了管理员账号和密码，即

username：admin

password：123456

任意输入，发现与上一题相似

payload：<script>alert('xss')</script>

成功弹窗

漏洞成因：

用户输入未经任何处理便直接拼接到html中输出，如果用户植入恶意脚本也将会被拼接到html中，当其他用户访问是便会出发恶意脚本

防范策略分析：

使用htmlspecialchars()函数对特殊字符（<>' "等）进行转义；

限制用户输入，如密码只能输入数字，字母和特定字符等

3.存储型xss

依旧先尝试我们的payload

提交后出现弹窗

这是一个存储型xss，当我们刷新页面，弹窗还是会出现，这说明我们的数据被存储起来了

漏洞成因：

后端代码对message仅对数据库做了转义，防止sql注入，但是并未对html输出环节做转义，当用户将恶意脚本提交时将会被存储到数据库中，后续页面读取该内容将会直接输出到html中，浏览器将会执行恶意脚本，触发xss攻击

防范策略分析：

在html输出环节，使用htmlspecialchars()函数对特殊字符（<>' "等）进行转义；

限制用户输入，如密码只能输入数字，字母和特定字符等

4.DOM型xss

DOM是一种用于表示和操作HTML、XML等文档结构的编程接口，通过它可以使用代码来访问、修改和操作Web页面的内容和结构。

随便输入字符串，检查我们的输入，在进行payload构造

检查网页源码，找到我们输入的内容，构造一个payload，闭合语句

"<a href='"+str+"'>what do you see?</a>"：' onclick="alert('hello')">#

"<a href=' ' onclick="alert('hello')">#'>what do you see?</a>":#注释后面所有内容

漏洞成因：

读取输入框（id="text"）的value值；

将该值直接拼接为 HTML代码（<a href=" + str + ">...</a>）并通过innerHTML插入到页面中

如果用户构造闭合拼接恶意脚本，拼接后端的html包含可执行的恶意脚本，触发xss攻击

防范策略分析：

避免innerHTML直接拼接不可信内容，若拼接，要将插入内容进行html转义

5.DOM型xss-x

可尝试特殊字符等尝试，检查输入发现<a href=' '>'hello'>what do you see?</a>,前面是已闭合，后部分被返回，且无特殊字符过滤

构造闭合：<a href=' ' onclick="alert('xss')">#'>what do you see?</a>,输入payload，再点击一下，弹窗出现

漏洞成因：

提取URL中text内容，分割出text参数的值，经decodeURIComponent解码、替换+为空格后，直接拼接为<a>标签的href属性，通过innerHTML将拼接后的 HTML 插入页面。

用户可以通过构造恶意text参数，将其拼接到html中，用户访问URL时将会执行该脚本，触发xss攻击

防范措施：

仅插入文本不要使用inerHTML(),使用text Content()插入纯文本，不对HTML进行解析

对text参数值进行html转义

6.Xss之盲打

盲打是指在前端你是无法看见我们代码的，无法判断xss是否成功，只有在后台才可以看到

依旧尝试payload：<script>alert('hello')</script>

登录：http://localhost/pikachu-master/vul/xss/xssblind/admin.php

admin，123456，登录后台出现弹窗

漏洞成因：

仅对输入做了防止sql注入的转义，但并未对html输出进行转义

防范策略分析：

使用htmlspecialchars()对content和name进行转义后在输出

7.Xss之过滤

依旧尝试<script>alert('hello')</script>，这里我们发现<script>标签被过滤了

可以尝试一下换标签、换大小写、换编码、对空格过滤的用特殊符号替代

我们可以先尝试换大小写：<Script>alert('hello')</Script>

也可以尝试换标签：<a href="" onclick="alert('hello')">

漏洞成因：

过滤规则不全：仅对<script>进行过滤

用户依旧可以通过大小写<Script>，拆分标签<scr<script>ipt>,其他标签，如：<a href="" onclick="alert('hello')">等进行绕过

防范策略分析：

使用htmlspecialchars()对输入进行html转义

限制用户输入，如仅允许输入数字，字母，常见字符等

8.Xss之htmlspecialchars

依旧先尝试payload：<script>alert('hello')</script>

并没有什么效果，查看源码，我们发现<>被转译成别的特殊符号，这时可以换一种反方式

可以尝试构造闭合<a href='<script>alert('hello')</script>'>

<a href=''onclick='alert("hello")'>,'onclick='alert("hello")

提交后点击可以成功弹窗

写在href里的，可以试下DOM型，输入javascript:alert("hello")，成功了

那为什么这边不能用<script>alert("hello")</script>呢？因为这边采用了PHP中的htmlspecialchars方法，作用是把特殊字符实体化，让网页解析的时候只把特殊符号当作文字而非变量或标签符号

漏洞成因：

在htmlspecialchars()没有对参数进行设定

Message被插入到<a>中href属性，如果用户对属性进行闭合，将会触发xss

防范策略分析：

完善htmlspecialchars()参数设置，覆盖完全

额外校验属性闭合风险，对href进行协议限制+html转义

9.Xss之href输出

当我们尝试<script>alert=("hello")</script>,payload当中的<>"" ''均被html编码了

我们这里可以利用JavaScript 代码段 :javascript:alert(1)

漏洞成因：

虽然对message使用了htmlspecialchars()转义，但是并没有对href进行协议限制，依然可以对href使用JavaScript：伪协议

防范策略分析：

完善htmlspecialchars()参数设置，额外校验属性闭合风险，对href进行协议限制+html转义

10.Xss之js输出

我们先尝试<scirpt>alert('hello')</script>，并没有反应

检查网页源码我们发现<script>标签对应有问题，这时想办法闭合掉一个标签

</script><script>alert('hello')</script>

<script>alert('hello')</script><script>

成功弹窗

除此之外，我们发现在这段代码中，我们写的东西已被包含在script标签里，而我们要做的就是执行alert("hello"),可以构造$ms='1';alert("hello");//';

漏洞成因：

并未对$jsvar进行转义而是直接输出到JavaScript代码中，用户可以构造恶意代码拼接到ms中，将会触发xss

防范策略分析：

1. 对$jsvar进行js编码转义
2. 限制用户输入$jsvar的内容格式

三、CSRF(跨站请求伪造)

概述

SSRF(Server-Side Request) , 又称为服务器请求伪造, 其形成的原因大都是由于服务端提供了从其他服务器应用获取数据的功能,但又没有对目标地址做严格过滤与限制, 导致攻击者可以传入任意的地址来让后端服务器对其发起请求,并返回对该目标地址请求的数据

1.CSRF（get/post）

先登录一个账号

修改信息进行抓包

右键打开tools，选择CSRF的利用

可以修改对应信息

修改完后我们点击test in browser，然后复制连接，到浏览器打开

点击提交请求，这时我们的信息就被修改了

漏洞成因：

造成CSRF漏洞的主要原因是请求敏感操作的数据包容易被伪造，get和post的请求修改信息中均未验证请求的合法性，攻击者可构造恶意链接或者页面，诱导已登录用户点击，伪造用户操作修改其个人信息

防范策略分析：

添加token令牌认证，在请求处理中校验其合法性

2.CSRF Token

修改信息提交，检查发现有token生成，后台会对我们在url中提交的token和服务器中生成的token进行比较，这里我们就无法通过伪造url进行修改个人信息了

漏洞成因：

代码中虽存在set_token()相关逻辑，但未在请求处理时校验令牌的合法性：

若set_token()仅生成令牌而未验证，攻击者仍可通过伪造请求修改用户信息，令牌机制未发挥作用。

防范策略分析：

在表单页面生成令牌并存储到 Session，在请求时进行令牌校验，令牌一次性使用，校验后立即销毁，避免重复使用