10.2 逻辑错误漏洞

• 提交订单；
• 付款。
  ③ 拦截HTTP/HTTPS请求，分析其参数项的含义；
  ④ 修改参数值，尝试触发逻辑漏洞；
  ⑤ 返回第②步骤，对其他功能继续测试；

简单地说，黑客挖掘逻辑漏洞有两个重点，就是业务流程和HTTP/HTTPS 请求篡改。下面将详细介绍常见的逻辑漏洞。

10.2.2 绕过授权验证

授权在网络上的意思是指，对特定资源的读写权限。通俗地讲，就是你的权限能让你做什么事情。而验证则表示你是否真的可以对这些资源进行读写。这就好比朋友在网上向你借钱，在转账时，你要求用电话确认一下，是否真的是朋友找你借钱，这就是验证。

授权问题是指访问了没有授权的资源或信息，也叫作越权。顾名思义，越权就是超越原本的权限。越权又可以分为两种：水平越权与垂直越权。接下来，将深入分析水平越权与垂直越权。

1.水平越权

例如，http://www.secbug.org 提供了用户修改资料的功能，当访问URL：

http://www.secbug.org/userinfo.action?id=2

时，将会显示自己的信息，并且可以编辑，UserInfo.java 源代码如下：

public String execute() {int id = this.user.getUserId();this.user = new UserProxy.findUserById(id);return SUCCESS;
}

这段代码并没有对ID 做任何验证，直接接收用户的ID，然后根据ID来查询用户信息。

当提交URL 为：

http://www.wecbug.org/userinfo.action?id=3

时，程序就会按部就班地执行，返回ID 为3的User 信息到页面中，这就是水平越权。

总的来说，水平越权就是相同级别(权限)的用户或者同一-角色的不同用户之间，可以越权访问、修改或者删除的非法操作。如果出现此类漏洞，那么将可能会造成大批量数据泄露，严重的甚至会造成用户信息被恶意篡改。

2.垂直越权

水平越权是相同级别的用户之间的越权操作，而垂直越权则恰恰相反，是不同级别之间或不同角色之间的越权。

垂直越权又被分为向上越权与向下越权。比如，某些网站，像发布文章、删除文章等操作是属于管理员做的事情，假设一个匿名用户也可以做相同的事情，这就叫作向上越权。

向下越权与向上越权恰恰相反，向下越权是一个高级别用户可以访问一个低级别的用户信息。这样做似乎没错，而且很多网站都是这么做的，包括低级别密码也可以被高级别用户掌控，但这样做可以说是完全错误！因为即使权限再低的用户都有他自己的隐私，可能用户为了更方便，会将自己的银行卡号与密码记录在网站中，这些信息都属于用户的隐私。

3.水平越权示例

越权漏洞中水平越权访问是最常见的，当然水平越权也包括越权删除、越权修改、越权增加等逻辑漏洞。

以任意密码的修改为例，UpDataUser.java 源码如下:

public String execute() {int id = Integer.parseInt(request.getParameter("userId"));String password = request.getParameter("password");String password2 = request.getParameter("password2");if(!("".equals(password)||"".equals(password2))){return ERROR;}if(!password.equals(password2)) {return ERROR;}User u = new UserBiz().findUserById(id);  //根据ID 来获取User具体对象u.setPassword(password);boolean flag = new UserBiz().saveOrUpate(u);  //更新对象if(flag){return SUCCESS;}else{return ERROR;}
}

这段代码看起来没有任何错误，而且具有较高的通用性，只要是修改密码操作，均可以使用此方法。

首先，程序将接收用户ID 以及新密码，然后根据ID 查询出用户的全部信息，再设置新密码，最后更新对象。

但这里隐含了一个非常大的逻辑漏洞，那就是任意密码的修改，现在假设有两个用户，一个用户是Admin 用户，UserID 为1。另一个用户是Guest，UserID 为2。Guest 进行密码修改时，拦截HTTP请求，HTTP请求如下:

POST /user/UpDateUser.action HTTP/1.1
Host: www.xxser.com
Accept: text/html, application/ xhtml+xml, application/xml;q=0.9, */*;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.17 (KHTML, like Gecko)
Referer: http:/ /www . xxser . com/user/userinfo. action
Accept-Encoding: gzip, deflate, sdch
Accept- Language: zh-CN, zh;q=0.8
Accept-Charset: GBK, utf-8;q=0.7, *;q=0.3id=2&password-myuser123&password2=myuser123

此时，ID 为2，密码为myuser123，当Guest 把用户的ID 修改为1时，Admin 用户的密码就会被修改为myuser123。程序会根据ID 查询出Admin 用户的所有信息，然后修改Admin 用户的密码。

此段代码中最大的BUG 在于程序中并没有进行二次密码验证，也就是原密码验证，如果对密码进行二次验证，则不会存在任意密码修改漏洞。

如果你希望不输入原始密码就使用该功能，可以通过Session 来实现，当用户登录成功后，就将用户信息放到Session中，当进行修改密码的操作时，将用户信息从Session 中取出即可，虽然这样可以不输入旧密码就能修改密码，但不建议这样做，因为无法确定修改密码的用户一定是本人。

4.垂直越权示例

垂直越权的漏洞也不少见，下面将以向上越权为例，分析垂直越权。

后台管理页面一般只允许管理员访问，如果普通用户可以访问，就存在向上越权漏洞。

解决向上越权是比较容易处理的事情，如果管理员表与普通用户表是同一张数据库表，就必须要存在权限验证字段，权限验证字段用来区分是否为管理员。

以Java 为例，做一个Filter即可，当用户登录后，就把此用户的信息放到Session 中，当访问设定路径时，过滤器就会判断是否是管理员。

如果不是一张表，更容易操作，在过滤器中直接取出管理员信息即可。当访问admin 路径下的资源时，将自动调用过滤器。

10.2.3 密码找回逻辑漏洞

为了防止用户遗忘密码，大多数网站都提供了找回密码功能。常见的找回密码方式有：邮箱找回密码、根据密码保护问题找回密码、根据手机号码找回密码等。虽然这些方式都可以找回密码，但实现方式各不相同。无论是哪种密码找回方式，在找回密码时，除了自己的用户密码，如果还能找回其他用户的密码，就存在密码找回漏洞。

密码找回漏洞在逻辑漏洞中占了较大的比例。测试密码找回漏洞与其他逻辑漏洞的方法相同，其中必经的两个步骤是：熟悉业务流程(密码找回过程)与对流程中的HTTP请求分析。

下面将介绍一个简单的密码找回漏洞。

http://www.xxser.com 提供了密码找回的功能，根据网页提示，可以发现业务流程为：输入注册邮箱地址→提交→收取邮件→更改密码。看起来这些步骤并没有漏洞，但有些“东西"隐藏在背后，只有抓包才能看到。在收取邮件重置链接步骤看到有一个重新发送的超链接，对此使用BurpSuite进行抓包。
此时可以猜想，网站是否根据此邮箱发送的重置密码链接。尝试修改参数为另一个邮箱(xxser@xxser.com)，然后发送，发现果然发来了密码重置邮件。

这样一个任意修改密码漏洞就出现了，如果知道其他用户的邮箱，就可以更改他的密码。这个案例中最大的错误就是“重新发送”功能使用了客户端的邮箱，而程序开发人员根本没有想到，“用户”会修改隐藏在HTML中的邮箱。

10.2.4 支付逻辑漏洞

不同的功能分别对应不同的逻辑漏洞，例如，密码找回功能就对应任意修改密码的问题，查询功能可能存在越权的问题，但查询功能最多是让你看到了不该看到的资源，却不会造成一些其他的漏洞，如删除某些资源，也就是说，只与查询有关的漏洞。而支付逻辑漏洞与钱有关，那么对应的则是“刷钱”、“免费购买”等漏洞。

同样，测试支付逻辑漏洞的重点是对HTTP 请求及业务流程的分析。在前面简单介绍了支付的业务流程，接下来将详细介绍支付逻辑漏洞。

在测试支付逻辑漏洞时，也有几个侧重点，就是由用户提交的参数，如：购买数量、商品价格、折扣、运费、商品信息的中转页面、跳转到支付接口时等参数。接下来介绍几种常见的逻辑支付漏洞场景。

1.商品数量为负数

商品数量为负数的情况多数出现在有站内货币(虚拟币)的网站上，当购买一个产品时，算法一般为“购买数量X商品单价=支付金额”，但如果购买数量为负数，比如-5，那么支付金额将会为负数。下面我们来看逻辑步骤：

• ① 从Session 中取得User 对象，也就是当前用户信息。
• ② 根据User 的ID，在数据库中查询当前用户的最新信息。
• ③ 取得商品的ID，根据商品ID 查询出商品的详细信息，包括价格、总数量。
• ④ 对商品数量进行判断，如果用户购买数量大于库存数量，则跳转页面，结束购物。
• ⑤ 根据数量计算出总价格。
• ⑥ 判断用户的Money 是否大于总价格，如Moeny 不够，则跳转页面，结束购物。
• ⑦ 将用户的Money 与商品数量重置，然后保存，如果都成功，则进行下一步，否则页面跳转，结束购物。
• ⑧ 将最新的用户信息与商品信息放入Session 中。

这段代码是一个比较常见的购买流程，但却存在安全隐患，那就是用户可以“刷钱”。现在假设用户的Money 为100元，商品价格为30元，商品数量为20个。用户购买1个商品后，那么Money 就变为70元，商品数量也剩下19个，这属于正规流程。下面来看不正规的流程，也就是最常见的支付逻辑漏洞之一。

将购买数量修改为-3，然后购买，当这段Servlet 在计算价格时，并没有对负数进行验证，而是直接进行运算: 30*(-3)=-90，现在的商品价格为-90元。接下来判断用户的金额是否大于-90，这里显然是大于的，所以通过验证，进入下一环节。

有趣的事情出现了，u.setMoney(u.getMoney()-allprice)的意思是将用户的Money 进行重置，我们来算算，100-( -90)= 190，我们账户中的钱不但没有减少，反增加了90元，如果购买的商品数量越多，那么你刷的“钱”也就越多。

再来看商品的数量comm.setNumber(comm.getNumber)-number)，这句代码的意思是重置商品的数量，也就是原来的商品数量减去购买的数量，为：20-(-3)=23，商品也是一样，不但没有减少，反而增加了。

2.0元购买商品

0元也能购买商品？对，你没听错。下面将介绍一种比较常见的0元商品的逻辑漏洞。

至今，大多数脚本语言都会支持异常处理机制，而异常处理机制有哪些好处呢？比如，我们的程序正在读取数据库，这时突然断网了，程序无法控制网络是否畅通，如果没有正确处理，则会产生致命的错误，可能程序都会因此而崩溃，而有了异常处理机制后，程序员可以将关键性的代码、可能会出现异常的代码块使用异常处理机制处理，即使这块代码真的出了问题，程序也不会因此问题而使整个软件崩溃，这就是异常处理。

一个存在BUG 的Main，java源码如下:

public static void main(String[] args) {Scanner sc = new Scanner (System.in) ;System.out.print ("请输入一个整数: ");String str = sC.nextLine() ;  //接收键盘记录int num = Integer.parseInt (str) ;  //将字符串转换为整数System.out.println("您输入的是: "+num) ;
}

当程序运行后，会提示用户输入一个整数，这时输入5，程序将会告诉你“您输入的是5”，程序看起来没有什么错误，但如果某个不规矩的用户不输入整数，而是输入“Hello”，那么程序又会怎样呢？毫无疑问，程序会崩溃，因为在Java 中尝试将一个不是数字的字 符串转为整型时，将会抛出一个致命的错误，java.lang.NumberFormatException 类型转换异常，相信这个关键字大家并不陌生，在Java 语言的SQL 注射时可能会经常遇到这个关键字。

为了避免这样的错误，可使用Java 异常处理机制，改善后的代码如下：

public static void main(String[] args) { Scanner sc = new Scanner (System.in) ;System.out.print ("请输入一个整数: ");String str = sc.nextLine();  //接收键盘记录int num = 0;try {num = Integer.parseInt (str) ;  //将字符串转换为整数} catch (Exception e) {System. out.println("类型转换异常!");}System.out.println("您输入的是: " + num) ;
}

这样即使程序再出错，也不会直接崩溃。

可能有人会说：使用异常处理是比较合理的做法，怎么可能造成0元购买商品漏洞呢？请读者注意，程序的执行流程最后显示的是“您输入的是0”，程序虽然没有退出，但这个0可能会影响之后的代码执行结果。

有些支付页面会做一些这样的异常处理措施，但如果没有正确地使用异常处理，则可能会隐藏安全隐患。

逻辑漏洞的例子数不胜数，这里关键是看程序员的思维，很多程序都是闭源的，我们看不到其源码，只能“盲目”地修改HTPP请求参数测试，也就是Fuzz Testing。

常见的支付逻辑漏洞场景还有商品价格修改、物流运费修改等。

10.2.5 指定账户恶意攻击

逻辑漏洞也能恶意攻击指定账户？没错。

在一些安全性较高的网站经常会遇到以下场景：在输入密码时，不小心输入错误，系统提示“失败三次后，将锁定账户”、“您还有三次输入机会”等。

一般情况下，普通用户输入密码错误次数不会超过三次，如果超过三次，就有可能是攻击者正在尝试破解你的密码。

有人可能会说：这不正是一个很好的方案吗?可以有效地防止攻击者破解密码。但反过来想想，如果攻击者不是想入侵你的账户，而仅仅是“封锁”你的账户呢？

例如，某银行系统安全体系较高，限制用户登录，当密码输入错误次数大于5次后，则封锁账户一天，一天之内此账户无法登录。这就意味着你的银行卡号千万不要随便让别人知道。

如果碰到有心的“攻击者”每天在凌晨时刻就开始输入错误的密码，进行另类攻击，那么最终结果就是你的卡号无法使用。

在上述例子中这种“有心的”攻击者可能很少见，但如果换一个场景呢？如:商城拍卖系统，当密码连续输入错误时，就会封锁一天，那么你的竞争对手在得知你的账户之后，每天都会多次输入错误的密码，这样的结局可想而知。如果安全体系较高，必须要提供“封锁”账户的功能，那么应该怎么办呢？针对这种逻辑漏洞场景，最好的办法就是不要暴露登录账户，而对外仅仅暴露NikeName(昵称)。就像人与人交流一样，交流的时候只说名字就可以，不需要用身份证号码。