初次使用Pikachu漏洞平台进行测试实验

初次实验具体操作

第一部分：XSS漏洞

1、pikachu平台上的反射型XSS漏洞（get）

1、pikachu平台上的反射型XSS漏洞（get）.
首先测试是否存在漏洞，在输入框里，随便输入一组特殊字符 “<>6666”
查看网页源码后，在右上角搜索框里 搜索6666
可以发现刚刚输入的字符插入到标签<p>中
看起来是没做任何xss过滤和转义的处理
我们尝试在输入框中输入一段script的代码：
<script>alert('xss')</script>
果然不出意料，发现弹出了一个警告框

2、反射型XSS漏洞（post）

2、反射型XSS漏洞（post）
Login默认 账号、密码是admin 123456

与刚刚一样，在框里写一些特殊字符，发现它被插入<p>标签中
我们输入script的代码：<script>alert('xss')</script>
发现又弹出了与刚刚一样的警告框

3、存储型xss

3、存储型xss
首先测试是否存在，xss漏洞（输入特殊字符 ‘”<>?&666）
查看网页源码，看起来是没做任何xss过滤和转义的处理
输入一个简单的弹窗<script>alter('你看到我啦么')</script)
存储型xss和反射型的区别：就是当你刷新这个界面，还是会出现这个弹窗

4、dom型xss

4、dom型xss
随便输入文本后，显示what do you see? 搜索what得到该段代码：

从源代码中我们可以看到，getElementByld将获取到的前端dom的值插入到<a href=‘ “+str+”>‘>what do you see?中，我们按照源码中给出的提示了，直接闭合掉就行了：
ａ‘ οnclick=“alert(‘xss‘)”> 试一下：将 #’ οnclick=“alert(111)”> 输入到输入框里

5、xss之盲打

5、xss之盲打
我们随便输入几个字符，发现我们的输入不会在前端输出，只会在后台输出，只有管理员能看到我们的内容。
我们按照之前的思路输入一下payload，当然前端也没有输出

点击右上角的提示：登录后台,看会发生啥?后台登录地址是 /xssblind/admin_login.php
我们就去登录后台看看

登录进去后发现刚才的payload果然被插入进去了

6、xss之过滤

6、xss之过滤
输入<script>alert(1)</script>后，并没有弹窗

查看网页源码

可以看到我们写的那句话都不显示，证明我们输入的js被过滤掉了，猜想可能过滤了小写字母，那试试大写字母：<SCrIPT>alert('xss');</ScRiPt>

7、xss之htmlspecialchars

7、xss之htmlspecialchars
还是一样先输入<>666 康康有啥情况

查看源码

发现只有单引号没被转义，那我们就构造一个特殊字符只有单引号的句子输入 ’ οnclick=‘alert(111)’ ，回车之后需要点击蓝色的记录，成功出来弹框
现在介绍下函数htmlspecialchars()是PHP里面把预定义的字符转换为
HTML实体的函数
预定义的字符是
& 成为 &amp
” 成为 &quot
’ 成为 &#039
< 成为 &lt
成为 &gt

8、XSS之herf输出

8、XSS之herf输出
试着输入京东网址： www.jd.com

试着让它出现弹窗，尝试了各种语句，发现之前常用的语句都不行
猜想输入的语句都被转义了
查看源码
输出：在a标签的href属性里面,可以使用javascript协议来执行js
防御:只允许http,https,其次在进行htmlspecialchars处理

设置payload： javascript:alert(666) 成功弹框了

从上可知：在a标签的href属性里面,可以使用javascript协议来执行js

9、xss之js输出

9、xss之js输出
提示中讲到：输入动态的生成到了js中,形成xss
查看网页源代码 发现是把对应的输入放在了js里面，进行判断，在进行相应的输出

它会把我们的输入放到js中，然后对这个变量进行判断，然后再输出
javascript里面是不会对tag和字符实体进行解释的,所以需要进行js转义
构造闭合，把原本的<script>闭合掉，再插入我们自己的<script>
输入：</script><script>alert("xss")</script>
弹框

通过这个实验，我们知道输出点在js中的xss问题,应该怎么进行修复：
这里如果进行html的实体编码,虽然可以解决XSS的问题,但是实体编码后的内容,在JS里面不会进行翻译,这样会导致前端的功能无法使用。
所以在JS的输出点应该使用 对特殊字符进行转义

第二部分：CSRF(跨站请求伪造)—Cross-site request forgery

1、CSRF(get)

1、CSRF(get)
根据右上角的tip，任选一进行登录
aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3BvcHRhcg==,size_16,color_FFFFFF,t_70)
修改数据：


输入修改的信息之后, submit, 就可以看到数据包:

当攻击者知道了修改信息的URL之后, 就可以构造出CSRF攻击的URL:
https://localhost/pikachu-master/vul/csrf/csrfget/csrf_get_edit.php?sex=hack&phonenum=hack&add=hack&email=hack&submit=submit
然后诱使登录状态的用户点击该URL就可以完成CSRF攻击:

2、CSRF(Post)

2、CSRF(Post)
如果修改信息的请求方式是POST型的, 攻击者则不能通过构造恶意
URL来攻击
类似于 XSS的Post型 攻击一样, 攻击者会构造一个自己的攻击站点(服务器), 站点上有一个post.html, 诱使用户点击该地址
当用户点击时，就会自动向存在CSRF的服务器提交POST请求修改个人信息, 从而完成攻击。
可以编写一个post.html:

(代码来自 https://www.cnblogs.com/dogecheng/p/11583412.html )
诱使用户(登录状态)点击, 就会自动往服务器发送POST请求，修改地址信息, 即可完成CSRF攻击:

3、CSRF Token

3、CSRF Token
在增加了Token来反CSRF的机制中, 用户每次访问改密页面时，服务器会返回一个随机的token （需要够随机，不容易被伪造），向服务器发起请求时，需要提交token参数，而服务器在收到请求时，会优先检查token，只有token正确，才会处理客户端的请求。
分析
这里可以看到, 虽然是Get方式请求, 但是有一个随机的Token验证:

即使用户点击了CSRF攻击的链接, 请求因Token不合法而遭到拒绝: