软件安全性测试（连载18）
2.13逻辑漏洞
逻辑漏洞往往与业务相关，除了水平/垂直越权外其他都没有通用性，读者需要结合业务场景有效挖掘逻辑漏洞。这里除了介绍水平/垂直越权，还介绍了其他四个逻辑漏洞。
1. 水平越权
水平越权是指具有相同权限的用户的越权行为。
1）案例
案例4-5 水平越权
电子商务系统，A用户删除自己配货地址的URL为http://www.mydomain.com/delete_address?address_id=123，B用户获取了这段URL。用自己的账户登录，在浏览器中输入获取的URL将A的配货地址。
2）测试方法
获取另一个用户的可能存在水平越权的URL，以自己的身份登录，在浏览器URL中输入获取的URL，验证是否真正存在水平越权。
3）防护方法
在程序中做好水平越权控制，见如下代码。
if not util.check_User_By_Address(request,username,address_id):
returnrender(request,"error.html",{"error":"你试图删除不属于你的地址信息！"})
else:
…
#删除这个地址信息
Address.objects.filter(id=address_id).delete()方法util.check_User_By_Address(request,username,address_id)中参数username为当前登录的用户名，address_id为待删除地址的地址编号。这几段代码的含义是检查待删除地址是不是属于当前登录的用户，如果不是，这提示错误信息，否则删除。
2. 垂直越权
垂直越权是指低权限的用户执行高权限用户的操作行为。
1）案例
案例4-6 垂直越权
BBS系统，审核员审稿的URL为
http://www.ibbs.com/review_paper/。普通用户获取了这段URL，用自己的账户登录，在浏览器中输入获取的URL，就可以选择待审搞进行审稿操作了。
2）测试方法
获取高级权限用户的可能存在垂直越权的URL，以自己的身份登录，在浏览器URL中输入获取的URL，验证是否真正存在垂直越权。
3）防护方法
在程序中做好垂直越权控制，见如下代码。
username =util.check_user(request)
#如果没有登录，跳转到首页
if username=="":
uf = LoginForm()
returnrender(request,"index.html",{'uf':uf,"error":"请登录后再进入！"})
else:
#进入正式业务页面通过函数check_user()判断用户有没有登录，如果没有登录转到登录页，然后提示错误信息，否则进行正式的业务操作。函数check_user()具体实现如下。
def check_user(self,request):
#从cookies中取出username
username = str(request.session.get('username',''))
#判断数据库中是否尊在
user = User.objects.filter(username =username)
#如果不存在，返回空串
if (user is None):
return ""
#否则返回username
else:
return username首先从session中获取用户名，然后判断这个用户名是否在数据库中注册过，如果注册过返回用户名，否则返回空。
3. 支付漏洞
某个商品单价为30元，现在仓库库存20件。某人余额为100元，她选择数量为1，买了这个商品。购买后库存变为20-1=19件，余额为100-1×30=70元。这时候她在数量输入框中输入-3，由于程序在前后端都没有对数量输入进行校验，这样就产生了支付漏洞，此时库存变为19-(-3)=22件，余额为70-(-3×30)=160元。显而易见，解决支付漏洞的关键在于控制数量输入框必须为大于0的整数。
4. 用户封锁
许多系统为了防止DDoS攻击或者暴力破解，限制登录次数。比如一个登录系统，如果一天内某个账号连续3次登录失败，只能到第二天才可以重新登录。3次失败登录到第二天账户处于封锁状态。对于安全而言，这样的做法是有一定好处的。但是如果你的账户被其他人获取，他/她可以连续3次用你的账号输入错误的密码，就可以让你今天登录不了系统了。由此可见你不但要保护好你的密码，对于你的用户名同样需要得到很好的保护。
5. 密码找回
现在密码无处不在，为了保护自己的密码，一个人手头可能具有多个密码，所以找回密码成为大部分网站提供的功能。通过注册手机找回密码的流程如34所示。
34 通过注册手机找回密码流程
首先选择通过注册手机找回，然后在注册手机中输入“13687698766”和验证码2145。系统发送到后端，验证输入的手机是不是当前用户注册的手机，验证通过给手机13687698766发送PIN码，然后进入第3个页面，在第3个页面，点击重新发送链接，黑客通过截包工具截获，把13687698766修改为自己的手机号。由于原先的手机号13687698766在第3个页面中以隐藏表单的形式存在，粗心的程序员这么也没想到这个请求包中途被拦截，所以没有在后端进行再一次认证就把PIN码发给黑客的手机中去了。黑客利用获取的PIN码在第3个页面中，最后就可以通过第四个页面修改密码了。所以解决这个问题的关键在于只要发送PIN码，都要验证这个手机号是否为当前用户注册的。在邮箱找回中同样适合这条规则。
6. 并发操作
一个博客系统流程如35所示。
35 博客系统
这个博客系统具有以下角色及对应的权限。
l 角色：博文作者。权限：书写、修改、删除博文。
l 角色：审核员。权限：审核博文。
l 角色：普通和用户。权限：浏览被审核通过的博文。
情形1：审核员A与审核员B同时登录系统，审核同一篇博文。审核员A先通过了审核，标记为审核通过（审核未通过），审核员B后提交审核，审核意见与审核员A相反，为审核未通过（审核通过）。审核员A后来发现自己审核通过（审核未通过）变成了审核未通过（审核通过）。
情形2：审核员在审核一篇博文，作者在审核期间删除了这篇博文，审核员在审核决策后页面上出现了数据库不存在这条信息的信息，且里面包含着一些数据库的日志信息。
情形3：审核员在审核一篇博文，作者在审核期间修改了这篇博文的内容，审核员在审核决策后发现博文中的内容与审核期间不一致。
对于如上三种情况可以采取如下措施。
情形1：审核员在审核完毕前都要检查这篇博文的状态是否依旧为“待审核”，如果不是则弹出类似“该博文已经被XXX审核（没）通过，请与他（她）联系…，本次审核失效”。或者加入一个博文 “审核中”的状态，如果审核员A领取了这篇博文，将博文状态由“待审核”变为“审核中”。
情形2和情形3：处理情形1中加入博文 “审核中”的状态，作者不允许修改或者删除外。还可以在审核员审核决定后提示“该博文已经被作者XXX修改（删除），请与他（她）联系…，本次审核失效”。
加入博文“审核中”的状态好像比较理性，但是要注意在审核过程中，审核员的浏览器（或客户端）挂起或者机器重新启动，这样处理不当，这篇博文就容易永远处于“审核中”的状态了。