接口安全性综述

我们通过http Post或者Get方式请求开放的api接口的时候，服务器会面临着许多的安全性问题，例如：

• 请求来源(身份)是否合法？

• 请求参数被篡改？

• 请求的唯一性(不可复制)，防止请求被恶意攻击

        比如说我们客户端需要查询产品信息这个操作来进行分析，客户端点击查询按钮==》调用服务器端api进行查询==》服务器端返回查询结果。不进行验证的方式，api查询接口：http://api.XXX.com/getproduct?id=value1

        如上这种方式简单粗暴，在浏览器直接输入"http://api.XXX.com/getproduct?id=value1"，即可获取产品列表信息了，但是这样的方式会存在很严重的安全性问题，没有进行任何的验证，大家都可以通过这个方法获取到产品列表，导致产品信息泄露。

        总的来说，接口的不安全有如下隐患

 不安全的接口暴露用户隐私信息

        程序猿在做业务接口的时候往往没有保护用户隐私的意识，把用户的隐私信息暴露在外面，一旦被人利用起来会给用户带来麻烦，同时被发现会降低平台的信任度。

 数据被人滥用

        如主业务接口返回的相关业务数据被他人拿去做自己的相关的功能；这样就造成了资源的滥用和额外支出。

 请求信息被恶意修改(修改参数，COOKIE，请求头信息)

        通过修改请求中的参数来发起的请求，如：登陆接口修改用户名和用户密码，进行密码库碰撞等。修改请求参数可能会导致很多安全性问题，如：SQL注入，XSS 跨站脚本攻击等。

 发起并发请求

        通过抓包工具抓到请求后模拟并发请求，造成服务器压力，如：模拟每日签到请求，或者直接发起每日签到的并发请求。

目前，常见的接口安全设计机制有

        对于业务敏感数据，需要将用户隐私数据或敏感字段加密（脱敏处理），或者对业务有着决定性作用的字段中的部分字符串加*号，如用户的相关数据的JSON中有用户手机号，用户邮箱，支付账号，邮寄地址等隐私数据；用户请求接口时需要对其隐私参数加密：如用户登陆请求登陆接口，需要将用户密码进行加密，以免接口被恶意代理捕捉请求后获取明文密码。

        对于恶意请求，如对于恶意爬虫方面，对单位时间范围内IP请求量进行限制等各种限制IP请求的规则，如：统计记录(可以记录到mongdb中)，定时监控记录发现请求量大于限制的数量就进行IP封杀；请求头的校验，如：User-Agent 校验请求头是不是APP客服端发起，Referer 是不是有来源，来源域名是不是自己的域名地址等(这种方式只能是多一个门槛)。其他非法请求，可以在接口参数中增加一个签名参数，将参数名进行逻辑的排序组合拼接+秘钥进行MD5运算，然后服务端接受到请求的时候也用同样的逻辑得到签名，与签名参数进行对比是否相同，这样可以使参数无法被修改，修改了就提示非法请求。如：接口http://www.test.com/go/?actid=1&userid=123 我们可以加一个sign参数= MD5(actid=1&userid=123&【secret】)，其中【secret】为秘钥，由客户端或服务器定义。 服务端用一样的逻辑得到密文和sign签名进行对比是否一样，不一样就提示非法请求。

        对于客户请求信息的泄露，使用token等标识用户重要的信息字符串进行身份验证，或COOKIE中需要设置过期时间或者在加密的明文里要有创建的时间，服务端做对应的时间失效的限制，这样即使COOKIE被别人盗取，模拟请求也会随着时间而失效。