之前小伙伴联系我文章里图片加载不出来，后来看了一下，原来用的图床i.imgur.com国内被墙
这真是无妄之灾，当时解决的办法有两个：1. FQ之后访问本站点；2.更换可用图床；
作为一个对非常懒的站长，还是决定换图床，为了防止又被和谐，这次直接换成了自己的站点meetsec.cn，只要站点在域名在就不会有问题。
为了感谢支持，这次吧bwapp全部教程都更新出来，不挤牙膏了，希望大家喜欢，哈哈哈~

作者：古月蓝旻

ClickJacking (Movie Tickets)--low

教学题一枚，点击劫持类漏洞主要通过iframe标签将相关网页加载到恶意攻击者站点，使用透明度或遮挡方式让用户无法肉眼识别，然后配上诱惑性话语诱导受害者点击iframe加载来的正规网页上的功能点。

我们先访问

http://192.168.248.130/bWAPP/clickjacking.php

很正常的一个电影购买站点，点击确认就花150

让我们去另外一个页面

http://192.168.248.130/evil/clickjacking.htm

嗯，翻译一下“屠龙宝刀，点击就送啊”

然而我们看下源码

既有iframe标签把第一个页面加载过来了，又通过div加载了一张大大的屠龙宝刀点击就送图

好吧我们把div删了看看，潮退了是什么

嗯，果然真实的内容被挡住了，世上没有免费的午餐

IE 8以上使用X-FRAME-OPTIONS:DENY保平安~

参考

一个比较冷门但却不容小视的漏洞——ClickJacking

Client-Side Validation (Password)--low

嗯，非常老的一个问题了，如果校验只在客户端通过js进行，那么非常容易被绕过

这道题，我们在low级别下改密码没有任何限制

但是medium/high级别下改成简单密码，就无法修改成功，告诉我们至少6位且要数字、大小写字母组合，原因我们看一下页面源码可知

页面js中定义了check_form(form)函数，在medium/high级别下，点击修改密码时，多出onsubmit进行校验

那么既然是客户端校验，就很好解决了，我们在源码中驱动onsubmit或者响应包里删除js部分可绕过限制，实现修改成简单密码形式

所以重要的校验不要只在客户端进行，永远不要相信用户输入

HTTP Parameter Pollution--low

嗯，这道题和我们上面的XSS - Reflected (HREF)界面几乎是一样的，low级别下使用xss的payload一样是有用的，但是我们这道题本身并不是让我们来xss，而是学习HPP注入的

这里先给两篇参考文章

Web应用里的HTTP参数污染（HPP）漏洞

京东某站由HTTP parameter pollution导致的XSS跨站

其实HPP也不难理解，对于HTTP协议而言，它是允许接收两个相同字段名的请求的，只是不同后端语言在字段选取的时候会有差异

这就造成了一个问题，如果我们自己构造一个相同的字段，传入我们想要污染的值，服务器会不会选择呢？当然是有可能的

比如本题，正常功能是我们先输入自己的姓名，然后给自己喜欢的电影投票，不同电影对应不同的movie字段值

可以看到，每个投票链接

href=hpp-3.php?movie=1&name=meetsec&action=vote

其中有我们可控的name字段，如果我们把name字段输入为

meetsec&movie=2

那么投票链接会怎么样？试一下就知道，会这样

href=hpp-3.php?movie=1&name=meetsec&movie=2&action=vote

一个链接中出现两个相同字段movie，对应值不同，那么服务端会选择哪一个？根据上面的表格php+apache在这种情况下，选择的是最后的值last，我们试一下，给所有电影投票

果然全部投给了2号电影，钢铁侠，污染成功

high级别同样的套路会怎样？

直接报检测到了HPP

原因如上分析php+apache下，我们的$_GET['movie']取了后面的值

当然HPP的作用也还可以用于绕过XSS过滤，SQL注入、WAF等等，因为你也不知道WAF过滤的是哪一个，如果它过滤的是正常值，服务端接受的是你的污染值就很有可能成功了

HTTP Response Splitting--low

HTTP拆分攻击，是指由于Web应用程序缺乏有效的输入验证，允许攻击者将CR和LF字符插入到应用程序响应的报头，从而将服务器的回应拆分成两个不同的HTTP消息的攻击手段。攻击者通过发送经过精心构造的HTTP请求，试图完全控制第二个响应来实现攻击

其实就是在HTTP请求中的字段插入回车换行和相关字段，使得响应头中显示该字段，影响页面的返回，配合缓存投毒效果更加，相关资料见

webgoat-HTTP Splitting(HTTP拆分攻击)

这道题提示了“Try to get the new line detected warning...”
，嗯尝试获得该警告就算过了，所以并不会实际受我们的攻击影响，我们测试一下，原URL参数后增加%0D%0ALocation: https://www.baidu.com

果然出现了警告，说明拆分成功被检测到

源码看一下

low级别下header中直接取url的值，因此url一旦被插入其它字段，header头里会直接在响应中出现

HTTP Verb Tampering--low

嗯，HVT，http动作窜改漏洞，其实还是比较常见的，http verb这个有点陌生，但是一提http method你肯定就熟悉了：get,post,trace,put,move,delete等

又是你可以尝试改一个我们请求的方法，这个漏洞说的就是这个情况，我们本题也是如此，当你在low级别下，提交修改密码请求，实际上是一个POST请求

我们可以尝试改成GET，然后把内容放到url中，看看行不行

可以修改成功，为什么呢？我们看下源码

low级别下使用$_REQUEST[]方式接受字段值，也就是说GET和POST都是可以的，这才导致了问题

那么有人问，这个有啥用啊？

其实有些时候，通过改变不同方法可以用来过waf

或者csrf中构造poc，如果存在本漏洞，可以直接在url中提交参数，点击即中招

Information Disclosure - Favicon--low

信息泄漏，本题是指有时候页面图标会泄漏web框架信息，比如本题

无论是图标还是源码都表明web 框架是drupal

所以本题启发我们，要么不用图标，要么换个别的干扰视线

Information Disclosure - Headers--low

这题告诉我们，响应包里会泄漏服务器的相关信息，攻击者可能利用相关信息找到对应漏洞针对性攻击

要么屏蔽banner信息，要么混淆

Information Disclosure - PHP version--low

让我们留意站点里的phpinfo()，别轻易泄漏，造成信息泄漏，使用的模块和脚本信息也在其中，攻击者很可能利用其中的配置缺陷针对性攻击

Information Disclosure - Robots File--low

前面有提到，robots.txt会泄漏网站敏感路径信息

Insecure iFrame (Login Form)--low

看源码可知，登录框其实是通过iframe标签嵌入本页面的

当我们发送登录请求时，其实发送到了其它网站

这个主要还是由于攻击者可操控目标站点的页面所致

Unrestricted File Upload--low

终于在收尾的地方来了一道文件上传题，哈哈哈

首先正常上传图片，上传成功，路径为http://192.168.248.130/bWAPP/images/6.jpg点击可显示

好的，我们改一下请求包，一处是文件名，另外改内容是phpinfo

上传成功，尝试访问一下

非常完美

我们看下low级别下，文件上传完全没有校验任何内容

同样的方法在medium下就不行了，为什么呢，源码说使用了file_upload_check_1方法先检查了一遍（function_external.php中）

嗯，其实是个后缀名黑名单，把php加入了，怎么办呢？其实很简单

我们知道

php还有其它后缀能被当成php执行，如php3,php5等

上传成功，能否解析呢？

所以黑名单过滤大法并不好，很容易绕过

同样的方法在high级别下并不好用

因为在medium的基础上又加了一层限制

$file_error = file_upload_check_2($_FILES["file"], array("jpg","png"));

可以说是白名单限制了

试验了一下php 5.3.4以下版本的00截断，发现然并卵

high级别下使用file_upload_check_2方法获取后缀名

比如上传1.php3x00.jgp，是可以生效，变成1.php3，但是白名单过滤在此时生效，不是jpg和png都过不了

除非配合文件解析漏洞或者.htaccess可以由我们操控，否则过不去

不过也并非真的没有办法，如果此时站点有远程/本地文件包含漏洞RFI/LFI，我们可以将内容为phpinfo的png包含过来执行，比如我们的bwapp就有这个漏洞，思路还是要广一点

File Upload Exploitation in bWAPP (Bypass All Security)

关于文件上传漏洞总结见

文件上传漏洞的一些总结

完结撒花！

结语

历时约3个礼拜终于把bwapp所有题目写完，这个教程总计8w+字也创下本人教程字数新高，在学习的过程中，收获了很多新的知识和技巧，特别是一些全网无解题能磕出来也是很艰难又开心，也感谢bwapp团队给出这么好的一套环境

受限于时间和精力，很多题目没法更细一步展开，有些medium和high级别的绕过也没时间一试，代码审计也主要偏向low级别。愿以此篇教程打下web安全的基础，在将来走得更远！