bWAPP（buggy web Application）是一个集成了了常见漏洞的 web 应用程序，目的是作为漏洞测试的演练场（靶机），为 web 安全爱好者和开发人员提供一个测试平台，与 webgoat、dvwa 类似。

环境搭建

bWAPP 有两种安装方式，可以单独安装，部署到 apache + php + mysql 的环境；也可以安装虚拟机版本 bee-box，区别在于虚拟机版本能够测试的漏洞更多，比如破壳漏洞，心脏滴血漏洞等在单独安装的环境下无法测试。

单独安装：

安装 wampserver ：单独安装首先需要搭建 Apache + php + mysql 的环境，使用集成环境 wampserver, 下载地址:

http://www.wampserver.com/

下载安装 bWAPP, 下载地址:

https://sourceforge.net/projects/bwapp/files/?source=navbar

解压压缩包，按照其中的 INSTALL.txt 进行安装。拷贝解压后的文件到服务区根目录，即 wampserver 安装目录下的 www 目录。编辑其中的 admin/settings.php 文件，配置数据库的地址、用户名和密码。

运行安装 wampserver，并在浏览器打开

http://127.0.0.1/bWAPPv2.2/bWAPP/install.php

其中 bWAPPv2.2/bWAPP/install.php 代表的是 www 目录下的文件路径。

点击 here 超链接，自动创建数据库。然后进入主界面：

http://127.0.0.1/bWAPPv2.2/bWAPP/login.php

用户名：bee，密码：bug，登录后即可进行相应测试。

如果需要配置成局域网电脑可访问，参考下图，打开图中所示的 httpd-vhosts.conf, 把 Require local 修改为 Require all granted，然后保存重启即可。

虚拟机安装

虚拟机安装相对简单，只需要下载虚拟机镜像 bee-box，导入虚拟机软件，开启虚拟机即可通过主机访问。

主机通过浏览器访问：

http://[IP]/bWAPP/或者http://[IP]/bWAPP/login.php

其中 IP 为对应 bee-box 虚拟机的 ip 地址。(一定要自己动手尝试才清楚，一开始我还以为虚拟机比较复杂，后面发现如此简单）

漏洞练习

测试漏洞是在虚拟机环境下进行测试的。

1.HTML 注入—反射型 GET

漏洞类型：注入

影响范围：主站

URL：http://localhost/bWAPP/htmli_get.php

描述：HTML 注入漏洞是指在用户输入的地方，输入 HTML 文本，被当作 GET 参数传到服务器，服务器以原始格式存储，未采用 HTML 编码，导致 HTML 的特性被浏览器解析执行。这种编码必须在服务器端存储参数的时候进行。

威胁程度：严重

POC：

1、在浏览器界面登录进去，然后选择 HTML INJECTION - REFLECTED GET。

2、在 First name 和 Last name 的文本框内输入 HTML 代码：

<marquee><h2>You just got hacked!!</h2></marquee> and <img src="hacked.jpg">

3、点击 Go，会得到如下效果。前提是 hacked.jpg 放在服务器端 /var/www/bWAPP 目录下。

4、结果显示 HTML 文本被嵌入到页面底部。

解决方案：

1、查看服务端响应处理表格参数的脚本如下 ( htmli_get.php )：

2、在服务端对表格参数进行检查并进行编码然后输出

3、设置安全等级为 high 后，在此测试，可以发现漏洞不复存在。

2.跨站脚本攻击（ XSS ）—— IFRAME 注入

影响范围：主站

URL：http://localhost/bWAPP/iframei.php?ParamUrl=robots.txt&ParamWidth=250&ParamHeight=250

描述：网页中包含 IFRAME 标签，并且暴露了 URL 中 IFRAME 的参数，导致网页中存在该漏洞。这使得攻击者可以利用 XSS 在流行网站中注入恶意网站连接。注入的内容可以从低危的广告到高危的键盘记录和恶意下载站点。

威胁程度：中危到高危

POC：

1、访问 URL：http://localhost/bWAPP/iframei.php?ParamUrl=robots.txt&ParamWidth=250&ParamHeight=250

2、IFRAME 源 URL 是 robots.txt，并且作为参数暴露在 URL 中。

3、用其他链接替换掉地址栏中的 ParamUrl，就会展现其他地址的页面。比如访问

http://192.168.211.131/bWAPP/iframei.php?ParamUrl=http://www.baidu.com&ParamWidth=1000&ParamHeight=250

解决方案：

1、查看服务端响应处理表格参数的脚本如下 ( iframei.php )：

2、通过抓包可以发现 IFRAME 标签中的 URL 被当作新的 http 请求头发起请求，通过如下的 header 函数发送 http 请求头：

3、在 IFRAME 标签中作如下图所示的修改就能避免该问题，直接指定参数为固定值，不会接收用户的输入作为参数，并且注销掉 header 函数那段代码，这就直接避免了这一问题。

3.系统命令注入

漏洞类型：注入

影响范围：主站

URL：http://192.168.102.134/bWAPP/commandi.php

描述：漏洞产生的原因是 shell 命令能够通过 ';'、'|'、'&&' 这些符号串联起来执行，操作系统本身就支持这种操作。这种漏洞导致恶意 shell 命令可以被执行，比如后台监听某端口或者导致系统崩溃的 fork 炸弹。

威胁程度：高危

POC：

1、访问网址：http://192.168.102.134/bWAPP/commandi.php

2、发起正常的 DNS 请求，返回的结果如下：

3、在输入框中输入 'www.baidu.com;cat /eta/passwd'，得到如下内容：

4、从中可以看出返回了 shell 命令被执行，并且返回了相应的结果。从开发者的角度，明显不希望这样的 shell 命令被执行。

解决方案：

1、查看服务器端响应的脚本 ( commandi.php )：

2、进一步能够发现服务器在送去执行前未对接收到的输入内容进行检测:

3、修复这个漏洞，通过 escapeshellcmd 函数对特殊字符进行转义，把输入当作一个字符串直接导入 shell 函数，并且只当作单个安全的命令。该函数用来转义来自用户输入的针对 shell 函数的单个参数，shell 函数包括 exec()、system() 和反引号操作符。或者直接去掉输入中的 ';'、'|'、'&&'。

4.代码注入（ PHP 代码注入）

漏洞类型：代码注入

影响范围：主站

URL:http://192.168.211.131/bWAPP/phpi.php

描述：代码注入是一种常见的攻击类型，主要是让应用程序识别为代码并执行。这类漏洞主要是由于未对不可信的输入输出数据进行检查所致。如果攻击者能够将代码注入应用程序并得到执行，那就仅仅是被PHP代码的能力限制，而未被应用程序限制。此例中，可以添加PHP代码在对URL的请求上，并得到执行。

威胁程度：严重

POC：

1、访问 URL：http://192.168.211.131/bWAPP/phpi.php

2、请求 URL 的页面允许添加参数，称为 message，这里未进行适当的检查，就可以被利用。

3、此例中，设置 message 参数为 message=a;$fp = fopen("/etc/ucf.conf","r");$result = fread($fp,1024); echo $result。

这将列出 /etc/ucf.conf 文件的内容。（根据实际情况来选择文件，有的文件为空，什么都没有，就会导致没有列出任何内容，避免踩坑）

解决方案：

1、查看后台服务器响应的脚本 ( phpi.php )。

2、message 参数通过 eval 函数的时候未对其内容进行任何检查，并且 eval 函数可以执行任意 PHP 代码。

3、为避免执行 message 中的内容，可以利用 htmlspecialchars 函数复写可能被当作代码执行的参数，并且移除 eval 函数，因为 eval 函数非常危险，能够执行任意代码。

4、最终，攻击者注入的代码不会被执行，这就修复了该漏洞。

5.SQL注入——GET/SEARCH AND GET/SELECT

漏洞类型：SQL 注入

影响范围：主站

描述：SQL 注入 ( SQLi ) 是一种注入攻击，恶意攻击者可以执行 SQL 语句以控制 web 应用的数据服务器。许多 SQL 语句可以用来测试是否修复了非预期的结果。

威胁程度：严重

POC：

1、访问 URL：http://192.168.211.131/bWAPP/sqli_1.php。

2、以下列出了几种 sql 注入的命令，可以获得非常有趣的结果。

解决方案：

1、查看后台响应脚本 ( sqli_1.php )。

2、漏洞产生的原因是在输入数据送入 mysql 查询之前没有进行检查。以下代码反应了没有做任何检查。

3、修复该漏洞需要对可解析的字符进行检测，比如引号、反斜杠等，避免这些字符被解析执行。PHP 中的 mysqli_real_escape_string 函数对特殊字符进行转义，利用该函数能够安全地进行 sql 查询。该函数预先考虑一下反斜杠字符：\x00 , \n , \r , \ ,' , " 和 \x1a。

4、升级到安全代码之后，可以发现不再存在 sql 注入漏洞，因此修复了该漏洞。

6. XML/XPATH注入——登录表单

漏洞类型：注入

影响范围：主站

URL：http://192.168.211.131/bWAPP/xmli_1.php

描述：XPath 注入是利用了应用支持用户输入，构建相应的语句查询或者访问 XML 文档。XPath 的语法和 sql 查询语法比较相似，构造类似 sql 查询语句能够实现 XML 文档的查询。此处漏洞产生在用户名和密码输入的地方，可以同时设置为 1' or '1' = '1，来获得进一步的信息。

威胁程度：严重

POC：

1、访问 URL：http://192.168.211.131/bWAPP/xmli_1.php。

2、设置用户名和密码为1' or '1' = '1。

3、获得了账户的权限。

解决方案：

1、查看服务器端响应的脚本文件 ( xmli_1.php )。

2、数据在送入 xpath 函数之前未经任何检验。假设只有字母和数字才是正确的用户名密码格式，通过检测输入数据是否存在非字母数字的字符来正确避免这一问题。代码中采用了简单的 preg_match 函数对字符串进行检查。对任意刻意的字符串都返回空字符串，因此不会查询任何数据。

3、这样一来，网页就能安全地避免了 xpath 注入攻击。结果如下所示：

7.无效认证——不安全的登录表单

影响范围：主站

URL：http://192.168.211.131/bWAPP/ba_insecure_login_1.php

描述：用户名和密码出现在HTML的源文件中，企图通过设置字体为白色来隐藏，但是这样无效。

威胁程度：低危(极低水平的开发人员才会出现这种情况)

POC：

1、访问网址：http://192.168.211.131/bWAPP/ba_insecure_login_1.php。

2、查看 HTML 源代码文件。

3、利用该用户名和密码能够成功登录。

解决方案：

1、查看服务器端的脚本文件 ( ba_insecure_login_1.php )。

2、从源文件中移除用户名和密码的标签，就能修复该问题。

8.会话管理——管理门户

影响范围：主站

URL：http://192.168.211.131/bWAPP/smgmt_admin_portal.php?admin=0

描述：管理门户默认是被锁着的，但是仅仅简单地修改URL请求中的一个参数(admin的值设为1)，就能进入管理门户。在GET请求中发送重要参数，这是严重的缺陷。

威胁程度：低(极低水平的开发人员才会出现这种情况)

POC:

1、访问地址：http://192.168.211.131/bWAPP/smgmt_admin_portal.php?admin=0。

2、设置 admin 参数为 1, 并且发送请求，就能发现页面解除锁定。

解决方案：

1、查看服务器端的脚本文件 ( smgmt_admin_portal.php )。

2、改变通过 GET 接收参数的方式，采用 POST 或者 cookie 的方式才足够安全。会话参数需要完全在服务端的掌控之下。

3、admin 参数不在暴露出来并且能够任意改变，服务端会在确认用户登录前检验用户的状态。

9.跨站脚本攻击（XSS）——反射型GET

影响范围：主站

URL：http://192.168.211.131/bWAPP/xss_get.php

描述：XSS 的危害在于允许攻击者注入代码到 web 站点中，加载网页时就会在受害者浏览器上得到执行。用户输入参数从客户端上传至服务器，由于缺乏对用户输入参数的检查，导致可以植入 javascript 代码，并在服务器下次返回网页结果至客户端的时候触发执行。

威胁程度：高危

POC：

1、访问网址：http://192.168.211.131/bWAPP/xss_get.php

2、在 firstname 和 lastname 的文本框内输入如下语句：<script>alert(document.cookie)</script> 和 You just got hacked！

3、javascript 代码被执行，在当前页面返回了 cookie 的值，更进一步能够轻易发送 cookie 的值给攻击者。

解决方案：

1、查看服务器端处理响应的脚本文件 ( xss_get.php )。

2、对用户输入的内容通过 htmlentities 函数转换，把程序可解释执行的字符串转换成不可执行的。

3、漏洞被修复。

10.跨站脚本——反射型JSON

影响范围：主站

URL：http://192.168.211.131/bWAPP/xss_json.php

描述：在搜索电影的文本框中输入的值被提交到服务器，服务器不检查输入的内容，这就导致当服务器返回 json 对象到客户端的时候产生严重的问题，为了解析 json 内容并适当展示，就会执行 javascript 代码，如果原始内容中本身就包含 javascript 代码,那就很有可能得到执行。

威胁程度：高危

POC：

1、访问 URL：http://192.168.211.131/bWAPP/xss_json.php

2、查看源代码，发现从服务器返回的文本框内容是通过 javascript 解析的 json 对象。

3、json 字符串可以通过在电影名称后面添加 ‘'}]}’ 来闭合，然后再添加 javascript 代码，最后添加 // 字符。输入内容如下：

watchmen"}]}' ;prompt("Enter password to continue:"); alert("Password received with thanks");//

4、通过提交上面的输入内容，导致额外的 javascript 代码被执行。

5、比如可以在用户不知情的情况下偷取用户信息。( 自己在火狐和 chrome 上没有实验成功，感觉是被浏览器处理了 )

解决方案：

1、查看服务器端处理响应的脚本 ( xss_json.php )。

2、用户端提交的电影名称在未做任何检查的情况下被存储，这就带来了所见到的不安性。

3、修复这个漏洞，需要过滤掉可以被浏览器解析的特殊字符，因此利用 htmlspecialchars 函数对特殊字符进行转换，比如单引号、双引号等。

4、修改服务端脚本后，提交同样的请求，返回的不再是特殊字符，而是转换成了 html 格式输出，因此漏洞被修复。

11.不安全的直接对象引用——改变密码

影响范围：主站

URL：http://192.168.211.131/bWAPP/insecure_direct_object_ref_1.php

描述：不安全的直接对象引用发生于应用提供对用户相关的对象的直接接入。漏洞导致攻击者可以绕过认证并直接接触到系统资源，比如数据库记录或者文件。此例中，用户提供的login ID被用来在后台直接接入和更新数据库，没有检查当前会话的login ID是否匹配。

威胁程度：高危

POC：

1、访问 URL：http://192.168.211.131/bWAPP/insecure_direct_object_ref_1.php

2、利用 burpsuite 拦截客户端和服务器交互的信息。拦截信息后，修改 POST 信息的 body 部分，修改 login ID 为其他内容，比如 “ned”。

3、尽管消息显示成功，但是该用户不会意识到自身的密码被修改。

解决方案：

1、查看服务器端处理响应的脚本文件 ( insecure_direct_object_ref_1.php )。

2、脚本文件接收用户输入的 login ID，但是并没有检查这是否是目前登陆的用户(会话变量中的登陆的用户)。

3、修复这个漏洞，需要检查用户提供的 login ID 和会话存储的 login ID。只有它们匹配了才进一步提供查询数据库操作。

4、现在如果攻击者采用上面的方式修改密码，服务器就会返回如下的错误信息。

5、注意这种方式并不能阻止密码被修改，在实施这种措施之前，需要实施应对重放攻击的机制。

12.敏感数据泄露——base64编码密码

影响范围：主站

需要解决的程度：高

URL：http://192.168.102.134/bWAPP/insecure_crypt_storage_3.php

描述：编码或者加密的cookie存储在客户端浏览器上，并不足够健壮以应对解码或者解密。SHA1和base64算法比较容易破解。

威胁程度：中危(并不常见)

POC：

1、访问 URL：http://192.168.102.134/bWAPP/insecure_crypt_storage_3.php。

2、取出网站的 cookie，火狐浏览器上通过：F12 —— 存储 —— cookie 查看。

3、对低安全性下的 base64 编码和高安全性下的 sha1 加密的字符串进行解密，可以获得解密后的字符串 “sdf”。因此 cookie 可以被破解。

解决方案：

1、查看服务器处理响应的脚本 ( insecure_crypt_storage_3.php )。

2、使用更安全的加密算法,比如 "sha512”。

3、最终加密出来的 cookie 就更难破解:

50fde99373b04363727473d00ae938a4f4debfd0afb1d428337d81905f6863b3cc303bb331ffb3361085c3a6a2ef4589ff9cd2014c90ce90010cd3805fa5fbc6。

13.缺少访问功能控制——目录遍历之目录

影响范围：主站

URL：http://192.168.102.134/bWAPP/directory_traversal_2.php?directory=documents

描述：目标用户才能接触的文件列表作为 GET 请求的参数传递，如果未对文件名进行检查，攻击者可以修改文件名从而接触到其他文件。

威胁程度：中危

POC：

1、访问 URL：http://192.168.102.134/bWAPP/directory_traversal_2.php?directory=documents

2、改名目录参数 ”document” 为 ‘.’ ，列出当前目录下的文件。

3、同时也可以用相对路径的方式获取更多目录信息，了解目录架构能够让恶意攻击者获取非常多的信息，比如 directory=../../../../ 能够直接查看服务器根目录的信息。

解决方案：

1、查看服务器端处理响应的脚本 ( directory_traversal_2.php )。

2、可以看出目录作为用户输入的参数，在经过 show_directory 函数前没有检查其合法性，导致相对路径的请求也会通过，从而使得攻击者可以遍历整个目录。

3、修复这个漏洞，必须对输入进行检查，确保 "../” 这样的字符串无论如何不会出现在目录字符串中。使用 directory_traversal_check_2 函数对输入进行检查，过滤掉特殊字符串。

3、这就修复了该漏洞，当前目录之前的目录不能被遍历，

14.缺少访问功能控制——目录遍历之文件

影响范围：主站

URL：http://192.168.102.134/bWAPP/directory_traversal_1.php?page=message.txt

描述：提供给用户接入的参数作为GET请求的参数，攻击者可以修改该参数为当前目录下其他的文件。因为没有检查相对路径，因此攻击者可以接入隐藏的和受保护的文件。

威胁等级：高危

POC：

1、访问 URL：http://192.168.102.134/bWAPP/directory_traversal_1.php?page=message.txt

2、网页参数暴露在外，攻击者通过简单的测试即可发现没有对相对路径进行校验。

3、修改参数 “message.txt” 为 page=../../../etc/passwd，目录路径可以通过实验获取错误信息来找到，比如通过递归方式遍历目录路径。这样就可以直接分析目录结构(比如利用某些目录下的遍历漏洞)，找到需要的文件的相对路径。一旦找到这样的目录，就能直接利用相应的路径打印出文件的内容。

解决方案：

1、查看服务器端处理响应的脚本 ( directory_traversal_1.php )。

2、任何用户提交的 file 参数在通过 show_file 函数之前都没有进行检查,没有判断其是否是相对路径的格式，因此到来了该漏洞。

3、修复这个漏洞，必须在进入 show_file 函数之前对 $file 变量进行检查，通过 directory_traversal_check_1 函数对输入的参数进行检查,过滤掉相对路径的格式，如下：

4、更新后，重新在浏览器上测试，就可发现不存在该漏洞了。

15.跨站请求伪造(转移财产)

影响范围：主站

URL：http://192.168.102.134/bWAPP/csrf_2.php

描述：跨站请求伪造(CSRF)就是当一个恶意站点、邮件、博客、紧急信息或者程序导致用户的浏览器利用用户现在的凭证在另外一个受信任的站点做了非期望的操作。

威胁等级：严重

POC：

1、访问 URL：http://192.168.102.134/bWAPP/csrf_2.php

2、在基金转移的接口，通过 URL 传递参数是很糟糕的一种做法，在这种情况下容易犯相同的错误。链接可以被修改为攻击者的银行账号,并且转移的金额也可以被修改。

3、可修改指向攻击者账户的链接为：

csrf_2.php?account=Nagaraj_Account&amount=1000&action=transfer

可以嵌入该链接到图像中或者通过其他社会工程学手段让某个人点击该连接。点击该连接将导致相应金额被转移。比如下面的图片，包含上面的超链接，用户粗心地点击了该图片。

解决方案：

1、查看服务器端处理响应的脚本( csrf_2.php )。

2、第一步就是改版提交方式为 POST，确保该 url 不能独自被用来转移资产,无法嵌入一个 post 请求在之前的对象中。

3、下图展示的是需要要修改的原始代码：

4、参照如下图片修改后，就无法嵌入 url 进行 csrf 攻击。

5、最终完成了漏洞修复。