1、短信验证码泄露(任意手机号抢占+任意手机号重置密码)
http://common.api.inwatch.cc/sms/checkcode
“/sms/checkcode”接口请求服务端,服务端会返回明文短信验证码。
无论注册手机号,改绑手机号、重置密码等需要用到短信验证码的功能都用到这个接口,高危。


下面是重置某用户密码成功截图:

2、验证不严谨+重放攻击(任何时候重置任意手机号密码)
找回密码功能,输入要重置密码的手机号,输入任意短信验证码,提交请求,服务端返回错误数据,拦截该返回数据并修改其中false为true,放行给客户端,客户端欺骗绕过短信验证码验证。



来到重置顺利来到重置密码界面:

输入新密码,改密码完成:

PS:值得一提的是,服务端没有及时失效上述该密码修改请求数据↑,导致重放攻击,任何时候恶意攻击者只需要提交该请求即可重置该手机用户的账户密码。
3、未限制用户批量发送数据(短信轰炸)
未限制用户批量发送数据,发送短信接口可通过脚本或工具批量提交,导致目标手机遭短信验证码短信的骚扰。

4、验证不严前端欺骗登录(任意用户登录+劫持任意用户手机绑定号)
其实和第3点是一样的性质。
客户端登录界面随意输入账号密码,按登录发起请求。
服务端返回错误消息,不存在的用户或者是密码错误。
拦截服务端返回消息,并修改其中user_id为任意用户ID,这里以ID为1的用户来做例子。
将修改后的返回数据放行给客户端,客户端被欺骗,通过认证,成功进入ID为1的账户。



接下来就是利用客户端发起对ID为1的用户的操作(让客户端算sign),如存储用户基本资料。

修改ID为1的用户的头像,用户名等等信息。

修改成功:


接下来还可以改绑用户手机号,以ID为52509的用户为例子。

改绑用户手机号成功,完全夺取该账户的使用权(最终用13777777779又改绑了一次)。


检测匆忙,没有尽全,手上没有实体智能手表,无法深挖其他与手表手环相关的接口。