数据安全:后台接口中一些看似多余的参数

【IT老五】数据安全:后台接口中一些看似多余的参数

后台接口开发与前端开发有不少不同,在并发、性能、容错、安全等方面都需要有一定的考虑……而且由于后台接口往往是直接或者间接的对数据库进行操作,所以在提供一个接口时,往往要考虑数据库数据是否有可能被人通过该接口恶意拷贝、修改甚至删除……

接口

我这里就最近碰到的一种现象来吐槽下:GetReportById(int reportId);看上去,这个接口很简单,功能也很明确,通过报告id查找报告,貌似没什么问题…

问题

但是,如果为该接口加上一些前提呢?首先该报告是与用户绑定的,其次该报告查看功能是不需登录的……此时,再来看看该接口:仅需一个报告id即可以获取到报告内容,一般情况下,这个报告id是主键,而且是自增的,那么,我导出数据库所有的报告只需要从1开始不断地改变入参reportId即可,显然,这是非常不安全的…(当然,可能有人觉得可以依托于其他方式来防止该问题,如IP调用限制、数据加密、入参id加密等)

【IT老五】数据安全:后台接口中一些看似多余的参数

解决

先来说说当我们没有使用数据加密时,有什么办法来防止数据通过接口循环导出?

1. 数据校验

想想,我们上面说的前提,报告是属于用户的,那么我们简单的修改下接口,改成GetReportById(int reportId, it userId),在通过报告id获取报告时校验下是否属于该用户,则可以防止数据被简单的循环导出了。

2. 入参加密

另外,更深一个层次,我们队入参id进行加密,使入参不再单纯的是自增id,而是一种无规律的字符串,那么,就对数据的保护是不是就更强了?

比如我们定一个id的加密方法(这里只是一个简单的示例):

id为: reportId = 1;
定义一个随机值: code = new Random().nextInt(100);
加密后的id为: encryptId = (reportId + code) * 5;
解密获取原id: reportId = encryptId / 5 - code;

此时,我们的接口应该是GetReportById(encryptId, int code, it userId),当然,userId也可以进行加密,这里只是作为示例就不考虑这么多了…

3. 出参加密

即对数据出参进行加密,此时一般都会用到时间戳之类的作为加解密因子,所以接口可能会变为GetReportById(int encryptId, int code, long timestamp, it userId)

【IT老五】数据安全:后台接口中一些看似多余的参数

总结

相对于最初的GetReportById(int reportId)而言,后面的三个操作都带入了基础业务上不需要的参数,这些参数看上去确实是多余的。

因为我只需要报告,通过id查找报告,很简单的一个实现,而最后却加了一堆不解释看不懂的参数,可能会让人感觉莫名其妙。然而,这些参数却能解决数据安全问题,可谓“冗余并不一定是坏的”。

简书:ThinkinLiu 博客: IT老五

ps: 最近这段时间该webapi经常看到一些GetReportById(int reportId)类型的接口,所以就写了这篇文章,谈谈自己的看法,解除后台开发不久,如写得有问题,或者由于我知识面浅薄,有其他方式或在其他层面已经解决了该问题(不再需要考虑这种安全性问题),欢迎指教…


IT老五(it-lao5):关注公众号,一起源创,一起学习!


发表评论

必填项已用*标注