RESTful Api鉴别真伪请求

参与公司的登录系统几个月了, 也发现了一点问题,记录一下.

顺便也说几个问题,如果有朋友懂的,也麻烦指点下在下.

 

以前网站上集成的api服务很简单.

比如很常用的一个用户登录的API, 只需要传入登录账号和密码, 处理后如果返回0就表示成功,返回1表示密码错误,2表示用户不存在等等.

这样就给刷账号的人留下了漏洞, 他就可以拿着手机号码(从11111111111-19999999999)一个个试,看server的db里有哪些手机账户.

这样的刷账号方法很简单,而且他是不需要密码的, 他只想拿到账户的手机号码而已,然后就可以拿去卖钱了.

这个属于非恶意的盗号攻击而已, 应该还不算非常严重的漏洞.

 

另外一种就是碰密码方式的刷账户行为方式,密码可以随意的取人们常用的那些的密码.

或者甚至是从其他网站盗号后,匹配手机账号后的密码.

这样的刷号方式,不仅是可以知道有哪些手机号码,而且能看到用户的个人资料,如果用户账号涉及到了钱,那么就非常危险了.

 

上面说的两种情况仅仅是指登陆功能, 其实其他的API一样也有类似的漏洞问题.

 

对于上面说的这种在互联网上裸奔的API的漏洞问题,一般的解决方式就是让访问任何API的时候,都需要在输入参数里, 附带提供一个access token.

这个token倒不是OAuth里的那个token,而是你自己定义的, 简单点说, 就是一个结合了server/client以及调用方认证用户的信息的一个加密串.

然后再顺带说一下OAuth, 它是国际标准, 而且安全性也较高, 但个人却觉得对于RESTful的API不太合适, 只是觉得它使用起来绕来绕去, 觉得很麻烦.

 

再回到token, 说到加密, 方式就非常多了,这里就不细谈了. 这里有个问题,不知道是否有朋友能指点一二.

经过服务器加密后的token, 返回给用户后, 接下来用户发送该token给服务器验证, 通过后再调用其他API, 那么服务器怎么确定这个token是真实用户发送的,而不是被人劫持了.

打个很简单的比方, 以前火车票上市没有身份证和姓名的, 如果你捡到或者偷到一张别人的火车票, 那么你就可以那这张车票去坐火车了.

但现在火车票上有了身份证号码和姓名, 那么这种劫持别人火车票想免费坐车就不行了.