API安全设计
2017-10-12 18:10
260 查看
一、简述
安全是恒久的话题,如果不注意防范,会带来很严重的后果。比如:1.接口被大规模调用消耗系统资源,影响系统的正常访问,甚至系统瘫痪
2.数据泄露
3.伪造(篡改)数据,制造垃圾数据
4.App被仿制…
那么我们设计API时,就要保证RESTful API的安全性,主要包括三大方面:
a) 对受限资源的登录授权
b) 对请求做身份认证,并且防止篡改,重放攻击
c) 对敏感的数据做加密
二、受限资源的登录授权
此流程不是本文重点,不赘述,基本流程如下:1. 客户端提交账号信息(用户名+密码)到服务端
2. 服务端验证成功,返回AccessToken给客户端存储
3.访问受限资源时,客户端带入AccessToken就可访问。
三、请求认证
如果不对请求进行签名认证,那么可以简单的通过fiddler等工具轻易抓包拿到数据,并进行篡改,提交,大规模批量调用,则会使系统产生大量垃圾数据,系统资源被大量消耗,甚至无法正常使用(另说,当然可以通过GateWay进行限流),因而我们需要对请求进行签名认证。URL格式
URL:schema://domain/path?query&imei×tamp&sign
参数说明
签名方法
sign=signature(path?query&imei×tamp&SIGN_KEY)
验证过程
认证逻辑
1、初始时,服务端存有各App版本的SIGN_KEY,客户端存有对应版本的SIGN_KEY
2、当要发送请求之前,通过签名方法加密,得到一个sign
3、发送请求的时候,连同sign一起发送给服务器端
4、服务器端首先验证时间戳timestamp是否有效,比如是服务器时间戳5分钟之前的请求视为无效;
5、然后取对应版本的SIGN_KEY验证sign是否合法
6、为了防止重放攻击,需要检查sign是否在redis中存储,如不存在则存入redis(缓存5分钟)
如何防止数据篡改
这里通过签名参数中包含原有请求的所有参数,改动任意参数,sign值都会不同,因此无法篡改。
如何防止重放攻击
由于签名算法中还有imei(设备唯一Id)、timestamp参数,且签名算法为不可逆算法(如md5或sha1),因而对于正常的每个请求sign值不会重复。此时服务端可以存储5分钟的sign值,来做重放攻击时的验证过滤,超过5分钟的请求则直接被timestamp校验过滤。
总结
如此便实现了请求认证,防止数据篡改,重放攻击,但是需要确保App密钥(SIGN_KEY)的安全保存,其优点是容易理解与实现,缺点是需要承担安全保存密钥和定期更新密钥的负担。
四、敏感据加密
1)、部署SSL基础设施(即HTTPS),敏感数据的传输全部基于SSL。2)、仅对部分敏感数据做加密(例如账号+密码),并加入某种随机数作为加密盐,以防范数据被篡改。
说说API的防重放机制
我们在设计接口的时候,最怕一个接口被用户截取用于重放攻击。重放攻击是什么呢?就是把你的请求原封不动地再发送一次,两次...n次,一般正常的请求都会通过验证进入到正常逻辑中,如果这个正常逻辑是插入数据库操作,那么一旦插入数据库的语句写的不好,就有可能出现多条重复的数据。一旦是比较慢的查询操作,就可能导致数据库堵住等情况。这里就有一种防重放的机制来做请求验证。
timestamp+nonce
我们常用的防止重放的机制是使用timestamp和nonce来做的重放机制。timestamp用来表示请求的当前时间戳,这个时间戳当然要和服务器时间戳进行校正过的。我们预期正常请求带的timestamp参数会是不同的(预期是正常的人每秒至多只会做一个操作)。每个请求带的时间戳不能和当前时间超过一定规定的时间。比如60s。这样,这个请求即使被截取了,你也只能在60s内进行重放攻击。过期失效。
但是这样也是不够的,还有给攻击者60s的时间。所以我们就需要使用一个nonce,随机数。
nonce是由客户端根据足够随机的情况生成的,比如 md5(timestamp+rand(0, 1000)); 它就有一个要求,正常情况下,在短时间内(比如60s)连续生成两个相同nonce的情况几乎为0。
服务端
服务端第一次在接收到这个nonce的时候做下面行为:1 去redis中查找是否有key为nonce:{nonce}的string
2 如果没有,则创建这个key,把这个key失效的时间和验证timestamp失效的时间一致,比如是60s。
3 如果有,说明这个key在60s内已经被使用了,那么这个请求就可以判断为重放请求。
示例
那么比如,下面这个请求:http://a.com?uid=123×tamp=1480556543&nonce=43f34f33&sign=80b886d71449cb33355d017893720666
这个请求中国的uid是我们真正需要传递的有意义的参数
timestamp,nonce,sign都是为了签名和防重放使用。
timestamp是发送接口的时间,nonce是随机串,sign是对uid,timestamp,nonce(对于一些rest风格的api,我建议也把url放入sign签名)。签名的方法可以是md5({秘要}key1=val1&key2=val2&key3=val3...)
服务端接到这个请求:
1 先验证sign签名是否合理,证明请求参数没有被中途篡改
2 再验证timestamp是否过期,证明请求是在最近60s被发出的
3 最后验证nonce是否已经有了,证明这个请求不是60s内的重放请求
相关文章推荐
- 设计安全的接口api
- API接口安全加强设计方法
- 开放接口/RESTful/Api服务的设计和安全方案
- REST API安全设计指南
- REST API 安全设计指南
- OAuth 2和JWT - 如何设计安全的API?
- **15.app后端怎么设计用户登录方案(API权限安全)
- OAuth 2和JWT - 如何设计安全的API?
- 如何写出安全的API接口?接口参数加密签名设计思路
- REST API 安全设计指南
- 途牛原创|浅谈API安全设计
- HTTP API接口安全设计
- 移动API设计与安全存储
- 如何写出安全的API接口?接口参数加密签名设计思路
- REST API 安全设计指南
- 用产品思维设计API(五)—— 安全,就只能用HTTPS?
- RESTFUL API 安全设计指南
- 如何写出安全的API接口?接口参数加密签名设计思路
- 如何写出安全的API接口?接口参数加密签名设计思路
- REST API 安全设计指南