业务安全测试方法总结

0x01 登录认证

用户枚举

在验证用户身份的时候，或判断用户是否已注册时，若验证码处理不当、或错误提醒明确，都可能存在用户枚举。

案例：

任意密码重置

短信验证码回传

通过手机找回密码，发送验证码的响应包中包含了短信验证码。

案例：

当点击发送按钮后，拦截返回包，短信验证码包含在返回包中，导致可重置账户密码。

用户凭证修改任意账户密码

通过手机找回密码是一般需要短信验证码验证（这里可以尝试爆破或绕过），当我们输入正确的手机号和正确的短信验证码，然后进入重置密码的最后一步，也就是输入新的密码，输入密码后提交到服务端的post数据包需要包含当前用户的身份信息，而一般网站是通过用户名或用户ID来标识用户身份的，如果这个用户名或用户ID没有和当前手机号、短信验证码进行绑定，也就是说服务端只验证用户名、ID是否存在，而不去验证用户和当前手机号是否匹配，那么我们就可以通过修改用户名、ID去修改其他用户的密码了。当然可以修改的地方不限于找回密码的数据包，比如修改资料的地方也可能存在这样的漏洞。

案例：

以某网站修改任意用户资料导致修改任意账号密码为例，截取的数据包为：

POST /user/info_do HTTP/1.1
Host: www.XXX.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:59.0) Gecko/20100101 Firefox/59.0
Accept: */*
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
Referer: http://www.XXX.com/user/info_view
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
Content-Length: 211
Cookie: yunsuo_session_verify=9341a54b945886e9485ff54a17650468; PHPSESSID=sgbibaqe7f8f6okerps8jip916; sdrcUserlockcount=1; sdrcUseruserid=14943
Connection: keep-alive

password=A123456&email=1%40qq.com&address=1&postcode=1&mobile=13888888888&sex=man&birthday=0000-00-00&degree=collegeLT&testsite=1&post=1&__hash__=b0b15b067dea00bd34fd39421b7ef684_efc2399e5c4b2071f261e75fe3362d4fa

经分析与尝试，发现数据包中的sdrcUseruserid的值是用来标识当前用户身份的，那么我们就想到这个id可否任意修改呢？答案是肯定的，我们修改id的值为14942、14941都是可以成功的，截图如下：

修改响应包重置任意账户密码

通过手机找回密码一般需要短信验证码验证，服务端需要告诉客户端，输入的验证码是否正确，如果客户端收到true的信息，那么就会向带着true的信息向服务端请求进入下一步，而服务端收到true的信息，就会允许客户端进入下一步，反之，如果是false的信息，服务端就不会允许客户端进入下一步。也就是说我们进入下一步的关键是让服务端收到客户端的true信息，而借助burpsuite，我们可以修改服务端返回到客户端的信息，这样一来，我们就可以输入任意短信验证码，然后将服务端返回的false信息改为true就可以绕过短信验证码的验证了。

案例：下面是找回密码的一个流程，输入正确的用户名，跳到第二步，这时需要输入短信验证码，这里我们随意输入一个短信验证码：123456，然后抓取服务端返回的信息如下所示。

把回包中false改为true后，即可绕过短信验证码验证，结果如下图所示。

乌云案例：https://m.hundan.org/2015-0137432

跳过验证步骤重置任意账户密码

找回密码流程一般需要四个步骤：1、验证用户名；2、验证短信验证码；3、输入新密码；4、重置成功。这四个步骤应该紧紧相连，互相相关，只有通过了第一个步骤验证才可以进入下一个步骤，如果每个步骤之间没有进行关联性验证，就可能导致跳过关键验证步骤，从而导致重置任意账号密码。

案例：某网站找回密码有四个步骤，第一步输入正确的用户名，第二步输入手机号和正确的验证码，截取服务端返回的数据包为：

<html>
<head><title>object moved</title></head>
<body>
<h2>object moved to <a href="/Personal/sys/getpasswordreset">here</a>.</h2>
</body>
</html>

上述数据包是用来跳转到输入密码的界面，我们猜想能否输入任意验证码，然后直接访问输入密码界面，结果是可以的，而且重置密码成功了。经分析，此处成功的关键是页面跳转到输入密码界面，当我们输入新的密码后，提交到服务端，服务端并没有对当前用户身份进行二次验证，只是简单的获取到用户名或ID以及新密码，从而导致跳过短信验证码验证重置任意账号密码。

重置密码链接中token值未验证或不失效导致任意账号密码重置

使用邮箱重置密码时，服务端向邮箱发送一个重置密码的链接，链接中包含当前用户的身份信息（如用户名或用户ID）和一个随机生成的token信息，如果未对token值进行验证或是验证后不失效，我们就可以通过修改用户名或用户ID来重置任意账号密码。

案例：某网站使用邮箱找回密码时，服务端向邮箱发送的链接为：

http://www.xxx.com/GetPwd.aspx?q=0x0531387a5a6c1227e4d6ba0ce16dc72e&r=3244166

经尝试，此处未对随机生成的q值进行验证或是验证了但是验证之后未失效，导致可以重复使用，最终只需要修改r为其他用户ID，即可重置其他用户密码。

找回密码的短信验证码可被爆破导致任意账号密码重置

找回密码时使用位数较少的短信验证码，或者验证码没有设置有效时间限制，导致攻击者借助自动化工具在一定时间范围内爆破获得短信验证码，从而导致重置任意账号密码。

案例：某网站找回密码时使用短信验证码的一个数据包为：

Code=5000&u=13888888888&Check=dc5b94101cb4f23a9ce6ae71197fc5de&a=5

此处可以对Code进行爆破，如下图所示：

服务端未对身份做校验

验证身份时，未对答案进行校验，输入任意答案即可进入下一步

案例：忘记密码处，第二步中，选择其他方式找回，通过密保找回，未对密保答案进行验证，随便输入答案，即可跳转到设置密码处

验证码置空绕过验证

短信验证码处，随便输入其他，验证码错误，而置空却不校验，则可以通过置空绕过

案例：我的==>登陆==>短信验证码登陆登陆时抓包把code（验证码字段）值置为空，即可登陆任意账户

短信轰炸

对发送短信验证码时间未做限制，导致可无限重发短信导致短信轰炸

案例：

邮箱轰炸

同短信轰炸原理一样，未对验证发送机制时间进行限制，可无限重发

案例：

0x02 业务风控

刷优惠券

程序逻辑设计错误，优惠券参数可控，攻击者修改参数导致重复获取优惠券或重新生成大数额优惠券

乌云案例：

https://wooyun.x10sec.org/static/bugs/wooyun-2015-0109007.html

https://wooyun.x10sec.org/static/bugs/wooyun-2016-0168071.html

恶意套现

网站验证机制或人工验证机制不完善，导致可恶意套现

乌云案例：https://wooyun.x10sec.org/static/bugs/wooyun-2015-099622.html

0x04 会话访问

会话固定攻击

尝试登录多个账户，sessionid不变，可通过遍历用户名，登录已存在用户

乌云案例: https://wooyun.x10sec.org/static/bugs/wooyun-2013-025427.html

COOKIE仿冒

服务器为鉴别客户端浏览器会话及身份信息，会将用户身份信息存储在 Cookie中，并发送至客户端存储。攻击者通过尝试修改Cookie中的身份标识，从而达到仿冒其他用户身份的目的，并拥有相关用户的所有权限。

乌云案例：https://wooyun.x10sec.org/static/bugs/wooyun-2014-051424.html

0x05 授权访问

未授权访问

用户没有通过认证授权的情况下可直接访问需要通过认证才能访问到的页面或文本信息。

乌云案例：https://wooyun.x10sec.org/static/bugs/wooyun-2016-0203819.html

越权访问

垂直越权

A用户权限高于B用户，B用户越权操作A用户的权限的情况称为垂直越权

登录普通用户pikachu 密码000000 只有查看权限

登录超级用户 admin 密码为123456 拥有修改用户信息和添加用户的权限

用admin用户添加一个新用户并用burp进行抓包可以看到PHPSESSID

打开另一个浏览器登录普通用户pikachu后尝试直接复制admin用户的添加用户网址来进行添加用户（未授权访问）

发现会回到登录界面

但是用admin用户查看的时候 test2用户已经被添加成功(admin用户需要在登陆状态)

用burp实现重新用管理员账号添加用户用burp进行抓包

将抓到的请求发送到repeater中

登陆普通用户抓取普通用户的cookie值

普通用户登陆成功后将这个cookie值修改到发送到repeater中的请求中重放这个数据包

刷新页面查看发现有了两个test3 一个为admin添加的一个是重放admin的数据包添加的

乌云案例：https://wooyun.x10sec.org/static/bugs/wooyun-2016-0189507.html

水平越权

A用户和B用户属于同一级别用户，但各自不能操作对方个人信息。A用户如果越权操作B用户个人信息的情况称为水行越权操作

案例：

三个用户 lucy/lili/kobe 密码都为123456

随便登录其中一个用户lucy 可以看到地址栏里 “url为op1_mem.php?username=lucy&submit=点击查看个人信息

退出lucy登录其他用户可以看到地址只有username不同

不退出lili账号直接在地址栏中将username改成lucy 也可以直接访问lucy的信息

乌云案例：https://wooyun.x10sec.org/static/bugs/wooyun-2016-0196371.html

0x06 支付逻辑

用户ID篡改

遍历用户ID，是否可查看其他用户信息

乌云案例：https://wooyun.x10sec.org/static/bugs/wooyun-2015-0111617.html

修改支付价格

抓包修改金额等字段，例如在支付页面抓取请求中商品的金额字段，修改成任意数额的金额并提交，查看能否以修改后的金额数据完成业务流程。

乌云案例：https://wooyun.x10sec.org/static/bugs/wooyun-2015-0117083.html

修改支付状态

没有对支付状态的值跟实际订单支付状态进行校验，导致点击支付时抓包修改决定支付或未支付的参数为支付状态的值从而达到支付成功。

乌云案例：https://wooyun.x10sec.org/static/bugs/wooyun-2015-0102292.html

修改商品数量

抓包修改商品数量等字段，将请求中的商品数量修改成任意数额，查看能否以修改后的数量完成

乌云案例：https://wooyun.x10sec.org/static/bugs/wooyun-2015-0120863.html

越权支付

生成订单，修改用户ID，实现跨用户付款

乌云案例：https://wooyun.x10sec.org/static/bugs/wooyun-2016-0174748.html

多线程并发引起的支付漏洞

例：
某游戏平台存在首充礼包，一个账户只能开通一次首充，这时会产生2重不同思路漏洞。
1.选择1元首充—-选择支付宝扫码支付—-弹出支付宝的付款码
这时，不要扫码付款，用此方法重放获取多个1元首充礼包支付宝支付界面。如果逻辑校验出错时，创建新订单时上一订单不会失效，依次同时付款，就会发现首充礼包不断到账。从而产生支付漏洞。
2.还有一种思路就是，某游戏平台的首充礼包里有1元6元两个挡位供用户选择，此时同时创建1元礼包和6元礼包2个付款码同时支付，如存在逻辑问题，两份礼包都会到账。