pikachu通关教程佛系更新
暴力破解
基于表单：抓包，发送给测试器，设置payload爆破
验证码绕过（on server）：验证码不提交的话不会变化
验证码绕过（on client）：基于客户端，验证码是本地源代码生产的F12找到删除
Token放爆破：正常抓包，看到加入了token，每次提交token的值都会变化
但是这里抓服务器响应的包里面可以找到下次的token
发送到测试器，为密码和token值添加变量，攻击类型选择pitchfork
Token是一次一次变换的，所以线程数设置成 1
设置payload_1密码正常设置字典，payload_2 token，点击测试器中的options，找到 Grep-Extract获取响应请求，搜索value值，找到token复制点击OK
1
2
3点击添加
4 点击OK
设置payload_2token的值，有效载荷选择递归搜索，复制的token放上去，开始攻击
跨站脚本XSS
反射型XSS(get)：
搜索框做了长度限制，可通过F12修改，也可以直接在地址栏添加
反射型XSS(post)：
登录之后直接输入框里输入
存储型XSS：
直接留言框里输入
Dom型XSS（很鸡肋）：
这里介绍一款工具，xss神器
https://github.com/s0md3v/XSStrike
直接把连接放上去扫一下就自动检测出了不安全的dom树，直接根据提示，构造pyload
python xsstrike.py http://192.168.1.201/pikachu/vul/xss/xss_dom.php
根据 what do you see?
构造pyload ' onclick="alert('xss')">
输进去点一下，就会成功弹出框
xss之盲打：
直接输入
之后去后台看一下，会有弹窗
SQL注入
数字型：
抓包，直接构造payload
字符型：
单引号闭合，直接抓包构造payload
搜索型：
直接输入%进行查询，因为没有做过滤，%在数据库的查询中匹配任意字符
xx型注入：
就是猜闭合罢了，这里闭合是单引号加括号 ')
可以看到没报错
这里我是用sqlmap爆破的
sqlmap -u 'http://192.168.220.129/pikachu/vul/sqli/sqli_x.php?name=111&submit=%E6%9F%A5%E8%AF%A2#' --current-dbsqlmap -u 'http://192.168.220.129/pikachu/vul/sqli/sqli_x.php?name=111&submit=%E6%9F%A5%E8%AF%A2#' -D pikachu --tablessqlmap -u 'http://192.168.220.129/pikachu/vul/sqli/sqli_x.php?name=111&submit=%E6%9F%A5%E8%AF%A2#' -D pikachu -T users --columnssqlmap -u 'http://192.168.220.129/pikachu/vul/sqli/sqli_x.php?name=111&submit=%E6%9F%A5%E8%AF%A2#' -D pikachu -T users -C "username,password" --dumpinsert&update注入：插入和更新的意思，这两个场景的注入，post数据包里的每一个参数都可以注入
Sqlmap报错注入：
抓一下注册时候的数据包，保存路劲记得
# sqlmap -r /home/kali/Desktop/1.txt --technique=E --current-db
手动：
查询到数据库名：
username=' or updatexml(1,concat(0x7e,(select database())),1),1) --+查询到数据库pikachu下的所有表名为httpinfo,member,message,users,x发现不能全部显示
username=' or updatexml(1,concat(0x7e,(select group_concat(table_name) from information_schema.tables where table_schema='pikachu')),1)or'可以用limit函数逐个读取数据库中的表名
username=' or updatexml(1,concat(0x7e,(select table_name from information_schema.tables where table_schema='pikachu' limit 0,1)),1)or'CSRF与SSRF
看这篇，比较详细
浅谈一下CSRF（跨站请求伪造）和SSRF（服务器端请求伪造）漏洞形成原因，二者区别，pikachu csrf、ssrf复现
RCE命令执行
概述
RCE漏洞，可以让攻击者直接向后台服务器远程注入操作系统命令或者代码，从而控制后台系统。 远程系统命令执行一般出现这种漏洞，是因为应用系统从设计上需要给用户提供指定的远程命令操作的接口比如我们常见的路由器、防火墙、入侵检测等设备的web管理界面上一般会给用户提供一个ping操作的web界面，用户从web界面输入目标IP，提交后，后台会对该IP地址进行一次ping测试，并返回测试结果。 而，如果，设计者在完成该功能时，没有做严格的安全控制，则可能会导致攻击者通过该接口提交“意想不到”的命令，从而让后台进行执行，从而控制整个后台服务器 远程代码执行同样的道理,因为需求设计,后台有时候也会把用户的输入作为代码的一部分进行执行,也就造成了远程代码执行漏洞。 不管是使用了代码执行的函数,还是使用了不安全的反序列化等等。 因此，如果需要给前端用户提供操作类的API接口，一定需要对接口输入的内容进行严格的判断，比如实施严格的白名单策略会是一个比较好的方法。 exec “ping”
使用管道符同时执行多个系统命令
exec “eval”
输入phpinfo(); 会被当做代码执行
文件包含漏洞
概述
文件包含，是一个功能。在各种开发语言中都提供了内置的文件包含函数，其可以使开发人员在一个代码文件中直接包含（引入）另外一个代码文件。 比如 在PHP中，提供了：include(),include_once()require(),require_once()这些文件包含函数，这些函数在代码设计中被经常使用到。大多数情况下，文件包含函数中包含的代码文件是固定的，因此也不会出现安全问题。 但是，有些时候，文件包含的代码文件被写成了一个变量，且这个变量可以由前端用户传进来，这种情况下，如果没有做足够的安全考虑，则可能会引发文件包含漏洞。 攻击着会指定一个“意想不到”的文件让包含函数去执行，从而造成恶意操作。 根据不同的配置环境，文件包含漏洞分为如下两种情况：1.本地文件包含漏洞：仅能够对服务器本地的文件进行包含，由于服务器上的文件并不是攻击者所能够控制的，因此该情况下，攻击着更多的会包含一些 固定的系统配置文件，从而读取系统敏感信息。很多时候本地文件包含漏洞会结合一些特殊的文件上传漏洞，从而形成更大的威力。2.远程文件包含漏洞：能够通过url地址对远程的文件进行包含，这意味着攻击者可以传入任意的代码，这种情况没啥好说的，准备挂彩。 因此，在web应用系统的功能设计上尽量不要让前端用户直接传变量给包含函数，如果非要这么做，也一定要做严格的白名单策略进行过滤。 本地文件包含
为了方便演示，我在服务器创建了个文本
这是正常url
http://192.168.1.201/pikachu/vul/fileinclude/fi_local.php?filename=file2.php&submit=%E6%8F%90%E4%BA%A4%E6%9F%A5%E8%AF%A2更改一下filename的参数
http://192.168.1.201/pikachu/vul/fileinclude/fi_local.php?filename=../../../test.txt&submit=%E6%8F%90%E4%BA%A4%E6%9F%A5%E8%AF%A2成功读取到了服务器里的其他文件
不安全的文件下载
概述
文件下载功能在很多web系统上都会出现，一般我们当点击下载链接，便会向后台发送一个下载请求，一般这个请求会包含一个需要下载的文件名称，后台在收到请求后 会开始执行下载代码，将该文件名对应的文件response给浏览器，从而完成下载。 如果后台在收到请求的文件名后,将其直接拼进下载文件的路径中而不对其进行安全判断的话，则可能会引发不安全的文件下载漏洞。
此时如果 攻击者提交的不是一个程序预期的的文件名，而是一个精心构造的路径(比如…/…/…/etc/passwd),则很有可能会直接将该指定的文件下载下来。 从而导致后台敏感信息(密码文件、源代码等)被下载。
实战
右击一个图片的链接地址，观察filename参数
http://192.168.1.201/pikachu/vul/unsafedownload/execdownload.php?filename=kb.png更改为其他文件
http://192.168.1.201/pikachu/vul/unsafedownload/execdownload.php?filename=../../../test.txt成功下载
文件上传
概述
文件上传功能在web应用系统很常见，比如很多网站注册的时候需要上传头像、上传附件等等。当用户点击上传按钮后，后台会对上传的文件进行判断 比如是否是指定的类型、后缀名、大小等等，然后将其按照设计的格式进行重命名后存储在指定的目录。 如果说后台对上传的文件没有进行任何的安全判断或者判断条件不够严谨，则攻击着可能会上传一些恶意的文件，比如一句话木马，从而导致后台服务器被webshell。 所以，在设计文件上传功能时，一定要对传进来的文件进行严格的安全考虑。比如：--验证文件类型、后缀名、大小;--验证文件的上传方式;--对文件进行一定复杂的重命名;--不要暴露文件上传后的路径;--等等...客户端check
将shell后缀先改成png格式
上传的时候进行抓包修改回原格式
上传成功
访问成功
服务端check
服务端做了MIME验证，正常上传shell，进行抓包
修改content类型为image/png,之后放行，成功上传
getimagesize()
先介绍一下这个函数：
getimagesize() 函数将测定任何 GIF，JPG，PNG，SWF，SWC，PSD，TIFF，BMP，IFF，JP2，JPX，JB2，JPC，XBM 或 WBMP 图像文件的大小并返回图像的尺寸以及文件类型及图片高度与宽度。
就是说这关只能上传图片马，配合文件包含
越权
概述
如果使用A用户的权限去操作B用户的数据，A的权限小于B的权限，如果能够成功操作，则称之为越权操作。 越权漏洞形成的原因是后台使用了 不合理的权限校验规则导致的。 一般越权漏洞容易出现在权限页面（需要登录的页面）增、删、改、查的的地方，当用户对权限页面内的信息进行这些操作时，后台需要对 对当前用户的权限进行校验，看其是否具备操作的权限，从而给出响应，而如果校验的规则过于简单则容易出现越权漏洞。 因此，在在权限管理中应该遵守：1.使用最小权限原则对用户进行赋权;2.使用合理（严格）的权限校验规则;3.使用后台登录态作为条件进行权限判断,别动不动就瞎用前端传进来的条件;水平越权
这里有几个自带的用户lucy/123456,lili/123456,kobe/123456
随便取一个登录进去
进去后点击查看个人信息，进行抓包
这个是正常的返回值
把数据包里的名字换一个，可实现越权查看他人信息
垂直越权
这里有两个用户admin/123456,pikachu/000000,admin是超级boss，我们用admin登录进去后可添加删除用户
这里我们先用admin创建一个用户，并抓包记录，注意：记住这个可以添加用户的ur地址/pikachu/vul/overpermission/op2/op2_admin_edit.php
接下来我们使用pikachu用户登录
直接把刚才的url放上去，发现可以直接访问并添加用户
目录遍历
概述
在web功能设计中,很多时候我们会要将需要访问的文件定义成变量，从而让前端的功能便的更加灵活。 当用户发起一个前端的请求时，便会将请求的这个文件的值(比如文件名称)传递到后台，后台再执行其对应的文件。 在这个过程中，如果后台没有对前端传进来的值进行严格的安全考虑，则攻击者可能会通过“../”这样的手段让后台打开或者执行一些其他的文件。 从而导致后台服务器上其他目录的文件结果被遍历出来，形成目录遍历漏洞。看到这里,你可能会觉得目录遍历漏洞和不安全的文件下载，甚至文件包含漏洞有差不多的意思，是的，目录遍历漏洞形成的最主要的原因跟这两者一样，都是在功能设计中将要操作的文件使用变量的 方式传递给了后台，而又没有进行严格的安全考虑而造成的，只是出现的位置所展现的现象不一样，因此，这里还是单独拿出来定义一下。 需要区分一下的是,如果你通过不带参数的url（比如：http://xxxx/doc）列出了doc文件夹里面所有的文件，这种情况，我们成为敏感信息泄露。 而并不归为目录遍历漏洞。实战
点击第一个，显示正常的内容
改一下title的参数
http://192.168.1.201/pikachu/vul/dir/dir_list.php?title=../../../test.txt成功遍历到其它文件夹下面，这里可以配合前期的目录扫描，访问其它文件
敏感信息泄露
概述
由于后台人员的疏忽或者不当的设计，导致不应该被前端用户看到的数据被轻易的访问到。 比如：---通过访问url下的目录，可以直接列出目录下的文件列表;---输入错误的url参数后报错信息里面包含操作系统、中间件、开发语言的版本或其他信息;---前端的源码（html,css,js）里面包含了敏感信息，比如后台登录地址、内网接口信息、甚至账号密码等;类似以上这些情况，我们成为敏感信息泄露。敏感信息泄露虽然一直被评为危害比较低的漏洞，但这些敏感信息往往给攻击着实施进一步的攻击提供很大的帮助,甚至“离谱”的敏感信息泄露也会直接造成严重的损失。 因此,在web应用的开发上，除了要进行安全的代码编写，也需要注意对敏感信息的合理处理。 实战
随便输入一个错误的账号密码登录
之后看下在登录过程中产生了哪些数据包，数据包里有哪些内容
发现只有一个数据包，并且在数据包里找到了一个测试账号，登录看看
PHP反序列化
概述
序列化serialize()：序列化说通俗点就是把一个对象变成可以传输的字符串,比如下面是一个对象
class S{ public $test="pikachu"; } $s=new S(); //创建一个对象 serialize($s); //把这个对象进行序列化 序列化后得到的结果是这个样子的:O:1:"S":1:{s:4:"test";s:7:"pikachu";} O:代表object 1:代表对象名字长度为一个字符 S:对象的名称 1:代表对象里面有一个变量 s:数据类型 4:变量名称的长度 test:变量名称 s:数据类型 7:变量值的长度 pikachu:变量值 反序列化unserialize()：就是把被序列化的字符串还原为对象,然后在接下来的代码中继续使用
$u=unserialize("O:1:"S":1:{s:4:"test";s:7:"pikachu";}"); echo $u->test; //得到的结果为pikachu 序列化和反序列化本身没有问题,但是如果反序列化的内容是用户可以控制的,且后台不正当的使用了PHP中的魔法函数,就会导致安全问题
常见的几个魔法函数: __construct()当一个对象创建时被调用 __destruct()当一个对象销毁时被调用 __toString()当一个对象被当作一个字符串使用 __sleep() 在对象在被序列化之前运行 __wakeup将在序列化之后立即被调用 漏洞举例: class S{ var $test = "pikachu"; function __destruct(){ echo $this->test; } } $s = $_GET['test']; @$unser = unserialize($a); payload:O:1:"S":1:{s:4:"test";s:29:"";} 实战
通过前面的了解，我们直接输入这个看看会发生什么
O:1:"S":1:{s:4:"test";s:7:"pikachu";}"输出了pikachu
构造xss的pyload
O:1:"S":1:{s:4:"test";s:29:"";}
URL重定向
概述
不安全的url跳转问题可能发生在一切执行了url地址跳转的地方。
如果后端采用了前端传进来的(可能是用户传参,或者之前预埋在前端页面的url地址)参数作为了跳转的目的地,而又没有做判断的话
就可能发生"跳错对象"的问题。url跳转比较直接的危害是:
–>钓鱼,既攻击者使用漏洞方的域名(比如一个比较出名的公司域名往往会让用户放心的点击)做掩盖,而最终跳转的确实钓鱼网站
实战
随便点击一个连接，记得抓包
把上面抓到的数据包url后的地址改为 http://www.baidu.com,成功跳转到百度
结束
来源地址：https://blog.csdn.net/qq_47289634/article/details/129463746
