centos系统安装皮卡丘靶场报错 皮卡丘靶场通关

文章目录

• 暴力破解

• 基于表单的暴力破解
• 暴力破解不安全的验证码

• on client
• on server

• token 防爆破？
• 这里借用大佬的wp

• Cross-Site Scripting(XSS)

• XSS(get)
• XSS (post)

• XSS（get&post典型区别）

• 存储型XSS
• DOM型XSS
• DOM型XSS-x
• XSS之盲打

• XSS之过滤

暴力破解

基于表单的暴力破解

点击Username，直接弹出个admin匹配此网站。我随便输了个123456，成功进入后来我尝试爆破，用的是炸弹集。但是用户名和密码组合起来实在是太多了，爆出来不知道猴年马月。删删减减后保留了还是剩了很多

• Sniper模式逻辑：先将第一个变量也就是用户名替换，第二个变量不动。当第一个变量替换完之后，对第二个变量进行依次替换。直白一点就是说一个变，另外一个不变，第一个变完，变第二个。
  Battering ram模式逻辑：所有变量进行同时同样的替换。就是说你变我也变，你变什么我也变什么。
• Pitchfork模式逻辑：所有变量同时替换，但是各自变量替换各自的字典，同时进行，但是互不相干。替换时第一个变量的第一替换值对应第二个变量的第一个替换值，不进行排列组合，就是1对1，2对2。不会将密码进行随机的排列组合。
• Cluster bomb模式逻辑：与Pitchfork模式逻辑类似，不同点是Cluster bomb模式会进行随机的排列组合。

暴力破解不安全的验证码

on client

这道题我打开的时候，已经有了用户名和密码。应该是上一题剩下的
输入验证码，居然登录成功了。我觉得好奇怪

查看了wp才知道预期解：

先删掉之前的用户名和密码进行抓包。

在reapeter里面看反应

我们发现，验证码不管怎么改，都没有提示验证码错误，也就是后台不会验证验证码

那么接下来就跟第一题一样了，直接爆破出用户名和密码

不安全的验证码- on client常见问题 ●使用前端js实现验证码(纸老虎) ;
●将验证码在cookie中泄露,容易被获取;
●将验证码在前端源代码中泄露,容易被获取;

on server

我们随机输入用户名和密码，在输入正确的验证码。登录失败，验证码更新

进行抓包，把验证码设置为空

从这我们可以推断出 后台对验证码是有校检的

我们不妨这么想，如果验证码不会过期，那我们输入正确的验证码后就可以只爆破用户名和密码了

怎样验证不会过期呢？那我们先更新验证码，把正确的验证码输入进包里

不停的修改用户名和密码，都只显示用户名和密码不存在。而验证码没有报错。证明验证码是不会过期的

那就好办了，直接和第一题一样爆破喽

不安全的验证码-on server常见问题 ●验证码在后台不过期，导致可以长期被使用;
●验证码校验不严格,逻辑出现问题;
●验证码设计的太过简单和有规律,容易被猜解

token 防爆破？

这里借用大佬的wp

• 查看源码发现提交的表单里面有个hidden属性的token值，每次拉取表单的时候生成的token值会不一样,提交的表单必须含有该token值才有效，burp的intruder模块中递归grep （Recursive grep）正合适这种模式。
• 此Payload类型主要使用于从服务器端提取有效数据的场景，需要先从服务器的响应中提取数据作为Payload，然后替换Payload的位置，进行攻击。它的数据来源了原始的响应消息，基于原始响应，在Payload的可选项设置（Options）中配置Grep规则，然后根据grep去提取数据才能发生攻击。
• 提取token值用于爆破的步骤为：
• 在token防爆破页面提交一次表单
• Burp抓包
• ctrl+i将报文发送到intrude模块
• position里面设置username,password,token的值为payload
• payload子选项里面payload set 设置1为用户名字典，2为密码字典，3的payload type选择recursive grep
• payload3的payload option 的initial payload for first payload填上第一次爆破的token值
• 在option模块的子选项grep-extract中定位到第一次请求返回的form表单里面的toke的value值
• recursive grep是不支持的多线程的，所以还要在request engine里面设置线程数为1
• 点start attack 按钮开始攻击

Cross-Site Scripting(XSS)

• 简称跨站脚本攻击
• 类型

1.反射性XSS;
  2.存储型XSS;
  3.DOM型XSS;

• 因此在XSS漏洞的防范上，一般会采用“对输入进行过滤”和“输出进行转义”的方式进行处理:

输入过滤：对输入进行过滤，不允许可能导致XSS攻击的字符输入;
  输出转义：根据输出点的位置对输出到前端的内容进行适当转义;

• 跨站脚本漏洞测试流程: ①在目标站点上找到输入点,比如查询接口,留言板等;
  ②输入一组”特殊字符+唯一识别字符”, 点击提交后,查看返回的源码，是否有做对应的处理;
  ③通过搜索定位到唯一字符，结合唯一字符前后语法确认是否可以构造执行js的条件 (构造闭合) ;
  ④提交构造的脚本代码(以及各种绕过姿势)，看是否可以成功执行，如果成功执行则说明存在XSS漏洞;
• 提示： 1.一般查询接口容易出现反射型XSS ,留言板容易出现存储型XSS ;
  2.由于后台可能存在过滤措施，构造的script可能会被过滤掉,而无法生效或者环境限制了执行(浏览器) ;
  3.通过变化不同的script ,尝试绕过后台过滤机制;

XSS(get)

点击一下submit,提示科比。

学到了,但这只是相对于题目而言。

我们要查看其是否存在XSS：

• 先输入一些特殊字符，看看有没有被过滤
  接过发现特殊字符被原封不动的输出，因此我们输入正确的JavaScript语句就有可能会被原封不动的返回
• 输不进去了，应该是长度限制了，改一下

XSS (post)

同理啦

XSS（get&post典型区别）

GET和POST典型区别:
GET是以url方式提交数据;
POST是以表单方式在请求体里面提交;

GET方式的XSS漏洞更加容易被利用, 一般利用的方式是将带有跨站脚本的URL伪装后发送给目标，而POST方式由于是以表单方式提交,无法直接使用URL方式进行攻击。怎么利用？往下看XSS之盲打

存储型XSS

存储型XSS下 攻击者可以将脚本注入到后台储存起来，产生更持久的危害

看，不管输入什么都被保存了起来那我们输入特殊字符，

也是没有任何处理就被输出

那我们设置个弹窗

<script>alert(1)</script>

刷新页面，发现这个弹窗一直都在，说明我们输入的语句已经被存储起来了

DOM型XSS

什么是DOM型？

可以把DOM理解为一个一个访问HTML的标准编程接口。

那么看题

在这一段我们可以看到，在输入框输入的值是直接被拼接的。那我们利用输入构造闭合

直接在输入框输入

'><img src="#" notallow="alert('xss')"> 构成闭合语句<a href=''><img src="#" notallow="alert('xss')">'>what do you see?</a>

DOM型XSS-x

'onclick="alert('xss')">

它的输入实际上是从url上获取的，这就类似反射性。

XSS之盲打

只能从后端看到输入的内容，前端无法看到。怎么办？

先注入再说！

<script>alert(xni)</script> 输入之后提交，点击提示，登录管理员网址。

输入用户名密码后，可以看到

管理员被x到，攻击者成功

XSS之过滤

尝试输入<script>alert(1)</script>

几种方法比较常见(先看源码)

• 'onclick=alert(1)
• onfocus=alert(1)
• <a href=javascript:alert(1);>test</a>
• <script>alert(1)</script>
• 大小写绕过sCript
• 双写绕过 sscriptcript
• 使用r代替r,即javascript
• <img src=x onerror="alert(666)">
• 拼凑:<scri<script> pt> alert(111)</scri</script> pt>
• 注释进行干扰: <scri<!--test--> pt> alert(111)</sc <--test--> ript>
• $ms='tmac';alert(1);//';

这里我使用大小写绕过
<script>alert(1)</script>