Brute Force
low等级
先随便输一下账号密码,在bp抓包发送到intruder模块,先点击清除§。
然后选中下面admin和password的值,点击添加§,表明这是要爆破的点。
选择爆破模式集束炸弹(Clusterbomb),对于这几种模式的区别,可以看一下这篇博客。
burpsuite中intruder模块爆破的四种模式_liweibin812的博客-CSDN博客_burp intruder 模式
转到有效载荷(payload)这个界面,加载字典,用户名的话先输入常用的几个,密码直接用bp自带的字典。
线程可以在选项的地方调快一点,建议调到十几二十这样就好了,调太快可能会出现线程丢失的情况,即有些用户名或者密码没有爆破。同时可能需要爆破的平台有线程的限制,调慢点稳妥。
然后选择最长或者最短的那个,进去查看响应就行了。
medium等级
和low的方法基本一样
high等级
抓包发现存在token,这种形式的话麻烦一点,在intruder模块选择密码和token部分作为爆破点,选择音叉(Pitchifork)模式。
然后重点来了,因为token是一个接一个的,所以线程得调到1,同时选择在响应包中获取返回的token值 。
在响应包中找到返回的value值,直接选中value的值,复制备用一下,然后点击ok。
最后在有效载荷模块选择字典。
第二个选择递归搜索,填入刚刚复制的值。
Command Injection
low等级
到RCE了,还是得分析一下源码。
这个直接利用&&或者&,确实我感觉;分割成两条命令也可以。
命令1&&命令2: 若命令1为真,则执行命令2
payload:
127.0.0.1&&ipconfig
medium等级
看一下源码,加了一点过滤,但&还是可以用的。
payload:
127.0.0.1&ipconfig
high等级
看看源码,几乎啥都过滤了
一筹莫展的时候,tnnd,只是过滤了'| ',|后面有个空格,焯。
payload:
1|ipconfig
CSRF
到了csrf这个东西了,可能有些师傅分不清csrf和ssrf的区别,看一下这篇博客。
CSRF与SSRF区别 - blacksunny - 博客园
csrf场景需求:
小黑想要修改大白在购物网站tianxiewww.xx.com上填写的会员地址。
先看下大白是如何修改自己的密码的:
登录---修改会员信息,提交请求---修改成功。
所以小黑想要修改大白的信息,他需要拥有:1,登录权限 2,修改个人信息的请求。
但是大白又不会把自己xxx网站的账号密码告诉小黑,那小黑怎么办?
于是他自己跑到www.xx.com上注册了一个自己的账号,然后修改了一下自己的个人信息(比如:E-mail地址),他发现修改的请求是:
【http://www.xxx.com/edit.php?email=xiaohei@88.com&Change=Change】
于是,他实施了这样一个操作:把这个链接伪装一下,在小白登录xxx网站后,欺骗他进行点击,小白点击这个链接后,个人信息就被修改了,小黑就完成了攻击目的。
为啥小黑的操作能够实现呢。有如下几个关键点:
1.www.xxx.com这个网站在用户修改个人的信息时没有过多的校验,导致这个请求容易被伪造;
---因此,我们判断一个网站是否存在CSRF漏洞,其实就是判断其对关键信息(比如密码等敏感信息)的操作(增删改)是否容易被伪造。
2.小白点击了小黑发给的链接,并且这个时候小白刚好登录在购物网上;
---如果小白安全意识高,不点击不明链接,则攻击不会成功,又或者即使小白点击了链接,但小白此时并没有登录购物网站,也不会成功。
---因此,要成功实施一次CSRF攻击,需要“天时,地利,人和”的条件。
当然,如果小黑事先在xxx网的首页如果发现了一个XSS漏洞,则小黑可能会这样做: 欺骗小白访问埋伏了XSS脚本(盗取cookie的脚本)的页面,小白中招,小黑拿到小白的cookie,然后小黑顺利登录到小白的后台,小黑自己修改小白的相关信息。
---所以跟上面比一下,就可以看出CSRF与XSS的区别:CSRF是借用户的权限完成攻击,攻击者并没有拿到用户的权限,而XSS是直接盗取到了用户的权限,然后实施破坏。
因此,网站如果要防止CSRF攻击,则需要对敏感信息的操作实施对应的安全措施,防止这些操作出现被伪造的情况,从而导致CSRF。比如:
--对敏感信息的操作增加安全的token;
--对敏感信息的操作增加安全的验证码;
--对敏感信息的操作实施安全的逻辑流程,比如修改密码时,需要先校验旧密码等。
low等级
先看一下源码,看看这个东西怎么玩,发现它没有做什么安全措施,为get型csrf。
我们当前账号为admin,身份为小黑。先修改一下密码,在bp抓包看看。发现页面发送修改密码的信息,直接复制下来。
复制后,换个账号在Test Credentials处重新登录一下dvwa,身份切换到受害者。
这时我处于已经登录网站的状态,突然有人向我发送了一个不明链接,我自身的安全意识比较低,加上这个网站存在漏洞,我点击了这个链接,最后发现密码被修改了。
点击一下骗子的链接:
http://127.0.0.1/dvwa-master/vulnerabilities/csrf/?password_new=111&password_conf=111&Change=Change&user_token=7ee2f596f90315693358882154298794#
最后在Test Credentials处验证一下,密码确实被改成了111。
但是现在人们的安全意识逐渐增强,可能小学生看到上面那个链接都不会点击,所以我们得通过构造一个站点来达到我们的目的。
在本地完成一下这个操作,先在www目录下随便创建一个index1.php或者index1.html都可以,里面写下我们的恶意代码。
<img src="http://127.0.0.1/dvwa-master/vulnerabilities/csrf/?password_new=124&password_conf=124&Change=Change&user_token=7ee2f596f90315693358882154298794#" border="0"/ style="display:none">
<h1>401<h1>
<h2>resource not found<h2>
HTML DOM Style display 属性 | 菜鸟教程
然后让受害者点击http://127.0.0.1/index1.php就可以修改密码了,这里是在本地做实验,也可以在同一个网段下的两台电脑尝试,或者物理机和NAT模式下的kali。真实情况下可能要在服务器上面搭,这个payload不怎么行得通,因为公网不能访问到内网上,详细说明在下面。
搭在公网上试一下吧
搭建过程有劳学长帮我完成了,搭个apache和php环境就好了,后面修改配置文件退出保存失败的时候,试试强制保存
:wq!
https://cloud.tencent.com/developer/article/1498759
还要一个条件是在公网服务器上开启web服务器,通俗说就是开启网页服务,下面是命令。
python -m SimpleHTTPServer 80
然后在var/www/html目录下放置我们的恶意代码,可能有的师傅想到放置上面的恶意代码,但这是行不通的。上面放有几篇博客,我们可以知道<img src="url">是显示url所指的图像,这个操作是在用户点开不明链接时页面初始化由服务器完成的,服务器是在公网上,肯定无法访问到我们的内网,所以这个操作也就失败了。至于在同一个网段下为什么可以完成csrf攻击,怪就怪网站没有做验证,怪就怪浏览器记住了我的 cookie。
那问题来了,怎么样得到真实可行的方案呢?这就得靠我们牛逼的bp了,先以攻击者的身份在密码修改页面抓包,然后生成poc。
得到poc可以直接点击用浏览器测试,bp会自动生成一个站点,跟我们在服务器上搭建是一样的。
如果是要在服务器上搭建的话,那就要修改一下代码了,直接复制表单的内容是需要受害者自己点击发送的,不过谁会这么蠢,所以我们需要修改一下代码。
改成:
<html>
<!-- CSRF PoC - generated by Burp Suite Professional -->
<body>
<script>history.pushState('', '', '/')</script>
<form action="http://192.168.1.4/dvwa-master/vulnerabilities/csrf/" id='test'>
<input type="hidden" name="password_new" value="124" />
<input type="hidden" name="password_conf" value="124" />
<input type="hidden" name="Change" value="Change" />
<input type="submit" value="Submit request" />
</form>
</body>
<script>document.getElementById("test").submit()</script>
</html>
把这个恶意代码放在服务器/var/www/html的index.php或者index.html下,受害者访问你服务器ip的时候会自动调用这个文件,从而完成攻击。
Medium等级
先看看源码吧
这里加了一个安全验证,检查host是否在referer字段里面。
if( stripos( $_SERVER[ 'HTTP_REFERER' ] ,$_SERVER[ 'SERVER_NAME' ]) !== false )
https://www.jb51.net/article/104512.htm
我们通过在服务器上搭建恶意站点获取利用bp生成的恶意站点查看一下host和referer,发现host是不在referer字段里面的,referer字段是我们服务器的IP地址,而host是修改密码站点的地址。
那怎么办呢?上面的referer实际上是http://服务器ip/index.php,那么我们可以可以让referer等于http://服务器ip/192.168.1.4.php,从文件名上实现绕过,直接这样子构造192.168.1.4.php容易被发现,所以得进行url编码一下。
payload:
服务器ip/%31%39%32%2e%31%36%38%2e%31%2e%34%2e%70%68%70
high等级
先看看源码,加了token验证。用户每次访问改密页面时,服务器会返回一个随机的token,向服务器发起请求时,需要提交token参数,而服务器在收到请求时,会优先检查token,只有token正确,才会处理客户端的请求。
受害者点击进入这个页面,脚本会通过一个看不见框架偷偷访问修改密码的页面,获取页面中的token,并向服务器发送改密请求,以完成CSRF攻击。
这里需要分析一波
Medium和High的对比
客户端访问攻击页面->攻击页面将密码作为参数直接提交到修改密码页面
客户端访问攻击页面->攻击页面获取修改密码页面的token->将token和密码作为参数一起提交
问题在这一步上
攻击页面获取修改密码页面的token
这一步属于跨域请求,浏览器已经禁止这么做了,所以想要完整这个操作,有两个思路:
第一, 将该js上传到服务器的目录下,这样就是同一个域了,不过如果可以这样,为啥不放木马呢?
第二, 利用xss,xss可以执行代码,获取token
xss更现实一点,但是也得需要该网站存在xss,所以单纯从这个修改密码页面,无法突破High漏洞
什么是跨域?如何解决跨域问题?_飞扬_柳絮的专栏-CSDN博客_跨域问题
至于为什么impossible为什么利用不了csrf,是因为需要旧密码验证....所以直接寄了。
xss(DOM)
XSS(DOM)是一种基于DOM树的一种代码注入攻击方式,可以是反射型的,也可以是存储型的,所以它一直被划分第三种XSS
与前两种XSS相比,它最大的特点就是不与后台服务器交互,只是通过浏览器的DOM树解析产生
除了js,flash等脚本语言也有可能存在XSS漏洞
DOM—based XSS漏洞是基于文档对象模型Document Objeet Model,DOM)的一种漏洞。DOM是一个与平台、编程语言无关的接口,它允许程序或脚本动态地访问和更新文档内容、结构和样式,处理后的结果能够成为显示页面的一部分。DOM中有很多对象,其中一些是用户可以操纵的,如uRI,location,refelTer等。客户端的脚本程序可以通过DOM动态地检查和修改页面内容,它不依赖于提交数据到服务器端,而从客户端获得DOM中的数据在本地执行,如果DOM中的数据没有经过严格确认,就会产生DOM—based XSS漏洞。
可能触发DOM型XSS的属性:
document.referer属性
window.name属性
location属性
innerHTML属性
documen.write属性
low等级
先看一下源码,没有防护,直接打。
先选个English看看,发现url上方存在存在default
对这个参数进行测试,存在xss
F12看看,发现我们的脚本被添加到代码中:
Medium等级
老规矩,查看源码,过滤了<script,那我们换一种标签<img
发现<img src=1 οnerrοr=alert(11)>没有执行成功,查看F12,发现被插入到value值后,没有像low等级那样生成标签。
猜测这个<img 可能要手动闭合一下<option>和<select>标签,让它独立出来
可以成功,payload:
</option></select><img%20src=1%20onerror=alert(11)>
High等级
看一下源码,发现只能输入白名单里面的东西。
那怎么办呢?这里可以利用#来实现绕过,#后面的内容会被当成是注释。在提交表单时,被当成注释,不会被提交到服务器,但在浏览器解析时,会解析。
这是正常提交一个English
这个提交一个English#</option></select><img src=1 οnerrοr=alert(11)>,刚提交不会弹出11,刷新一下页面就好了。
分析一下impossible等级为什么绕不过,我们F12看一下其它三个等级的
再看看impossible等级的,发现了吗,在
if (document.location.href.indexOf(“default=”) >= 0) { var lang = document.location.href.substring(document.location.href.indexOf(“default=”)+8); document.write("" + (lang)+ “”); document.write("----");}
可以发现这里对我们输入的参数(lang)并没有进行URL解码,而在其他级别中是有解码过程的
XSS (Reflected)
low等级
先看一下源码吧
发现没有过滤,直接<script>alert(11)</script>试一试
可以弹窗,存在xss,我们F12看看这个代码被插入到了哪里
Medium等级
看一下源码,发现过滤了<script>,这种情况可以采取双写绕过和大小写绕过。
payload:
<scr<script>ipt>alert(11)</script>
或
<SCRIPt>alert(11)<script>
High等级
看下源码,对传入的值进行的过滤,意味着双写绕过 、大小写绕过不行了。
那就换成<img
payload:
<img src=1 onerror=alert(11)>
看看impossible等级干嘛绕不过,htmlspecialchars()函数会将输入内容转换为html实体,就是这个东西单单是一个字符而已,这样子做可以防止浏览器对恶意代码进行解析。
XSS (Stored)
low等级
看下代码,发现只是对输入内容中的一些别的字符进行转义,em...对我们的xss没有影响。
直接<script>alert(11)</script>,打开F12,ctrl+f查找一下储存在哪里
Medium等级
看一下源码,发现对message过滤很严格,还经过了htmlspecialchars编码message,根本绕不过,只能在name这里下手了。
name值这里只是简单过滤了<script>,可以采取双写绕过,大小写绕过。但是输入的时候你会发现有长度限制,F12改一下就好了。
High等级
在medium等级的基础上对name多过滤了一下,<script>的绕过形式行不通了,可以用其它的标签。
payload:
<img src=1 onerror=alert(11)>
然后impossible等级的name值加了和message一样的过滤,绕不过了。
利用xss打cookie
简单的是这样子:
<script>alert(document.cookie)</script>
<BODY ONLOAD=document.cookie>