以前因为业务须要,涉及到一些爬虫方面的工做, 发现一部分小众产品在数据接口中存在安全性问题, 接口能够被任意调用甚至能够修改一部分数据(没有一点安全措施啊)。为了避免被‘祭天’。 因此就后台接口安全结合本人工做中对其的理解进行记录。后端
尤为如今大部分项目都是先后端分离, 后台接口安全更是重中之重。毕竟数据就是钱啊缓存
Token验证是我在最开始作移动接口项目的时候用到的方式。安全
所谓Token验证就是 当用户使用帐号和密码进行登陆操做后, 服务端给客户端返回登陆后的Token, 并将Token和登陆用户在缓存服务器中进行关联(Redis
)并对其设置时限(通常为30分钟), 随后客服端每次访问都须要将Token传到服务器端, 后台对Token进行验证, Token正确即经过验证bash
关键代码服务器
//验证token
String token = request.getHeader("Token");
if(!jedisPoolService.exists(token))
throw new TokenException("token is invalid");
复制代码
可是上述方式只能判断当前Token是否存在, 可是若是存在的Token在作一些事情,就无法控制。(经过代码长时间调用该接口)app
因此在Token验证的基础上加上了非法ip的判断:前后端分离
IP黑名单:若是当前访问的ip在一段时间内(1分钟)访问次数超过咱们限定的次数, 说明这个ip对应的访问存在问题, 那么禁止当前ip访问并将该ip添加到黑名单中post
在访问接口以前, 判断ip是否ip黑名单中,若是在, 就禁止该ip访问ui
关键代码加密
//判断ip
String ip = GlobalUtil.getIpAddr(request); //获取当前IP
if(jedisPoolService.sismember(IP_BLOCK, ip)) {
throw new NoParamException("黑名单禁止访问");
}
//判断当前ip是否超过访问次数
String key = IP_KEY.replace("{key}", ip);
int count = StringUtil.toInteger(jedisPoolService.get(key) != null ? jedisPoolService.get(key) : 0);
if(count > MAX_COUNT) {
jedisPoolService.putSet(IP_BLOCK, ip);
throw new NoParamException("超过访问次数");
}
jedisPoolService.incrAtTime(key, MAX_COUNT);
复制代码
在接触到不少第三方支付后,就尝试将本身的接口项目进行升级
在Token验证的基础上, 加上timestamp时间戳和sign签名。 约定timestamp时间戳和当前时间超过规定的范围(如:1分钟) 即判断当前访问的接口有误。
关于sign签名操做
关键代码
//时间戳
Object o = objectMap.get("timestamp");
if(o == null)
throw new NoParamException("参数timestamp为空");
Long timestamp = StringUtil.toLong(o);
if (LocalDateUtils.nowTime().getTime() - timestamp >= 1 * 60 * 1000)
throw new NoParamException("timestamp已过时");
//sign
private String getSign2Map(Map<String, Object> map) {
StringBuffer sb = new StringBuffer();
ArrayList<String> list = new ArrayList<String>(map.keySet());
Collections.sort(list);
for (String key : list) {
Object value = map.get(key);
if (!key.equalsIgnoreCase("sign"))
sb.append(key).append("=").append(map.get(key)).append("&");
}
sb.deleteCharAt(sb.length() - 1);
return DigestUtil.getInstance().md5(sb.toString());
}
复制代码
HTTPS: 基于HTTP协议,经过SSL或TLS提供加密处理数据、验证对方身份以及数据完整性保护
Https的成本略高, SSL证书须要购买申请,功能越强大的证书费用越高
上述方式能很大程度的保证接口安全,可是也不是必定安全 (无聊的人呢仍是不少的)。-_-~~
理论不等于实战,实际开发中仍是有不少细节的东西须要完善。 下一节来具体实现下上述的方式