如何设计一个安全的对外接口?(转)

  个人觉得安全措施大体来看主要在两个方面,一方面就是如何保证数据在传输过程中的安全性,另一个方面是数据已经到达服务器端,服务器端如何识别数据,如何不被攻击;下面具体看看都有哪些安全措施。

1.数据加密

  我们知道数据在传输过程中是很容易被抓包的,如果直接传输比如通过 http 协议,那么用户传输的数据可以被任何人获取;所以必须对数据加密,常见的做法对关键字段加密比如用户密码直接通过 md5 加密;现在主流的做法是使用 https 协议,在 http 和 tcp 之间添加一层加密层(SSL 层),这一层负责数据的加密和解密;

2.数据加签

  数据加签就是由发送者产生一段无法伪造的一段数字串,来保证数据在传输过程中不被篡改;你可能会问数据如果已经通过 https 加密了,还有必要进行加签吗?数据在传输过程中经过加密,理论上就算被抓包,也无法对数据进行篡改;但是我们要知道加密的部分其实只是在外网,现在很多服务在内网中都需要经过很多服务跳转,所以这里的加签可以防止内网中数据被篡改;

3.时间戳机制

  数据是很容易被抓包的,但是经过如上的加密,加签处理,就算拿到数据也不能看到真实的数据;但是有不法者不关心真实的数据,而是直接拿到抓取的数据包进行恶意请求;这时候可以使用时间戳机制,在每次请求中加入当前的时间,服务器端会拿到当前时间和消息中的时间相减,看看是否在一个固定的时间范围内比如 5 分钟内;这样恶意请求的数据包是无法更改里面时间的,所以 5 分钟后就视为非法请求了;

4.AppId 机制

  大部分网站基本都需要用户名和密码才能登录,并不是谁来能使用我的网站,这其实也是一种安全机制;对应的对外提供的接口其实也需要这么一种机制,并不是谁都可以调用,需要使用接口的用户需要在后台开通 appid,提供给用户相关的密钥;在调用的接口中需要提供 appid+密钥,服务器端会进行相关的验证;

5.限流机制

  本来就是真实的用户,并且开通了 appid,但是出现频繁调用接口的情况;这种情况需要给相关 appid 限流处理,常用的限流算法有令牌桶和漏桶算法;

6.黑名单机制

  如果此 appid 进行过很多非法操作,或者说专门有一个中黑系统,经过分析之后直接将此 appid 列入黑名单,所有请求直接返回错误码;

7.数据合法性校验

  这个可以说是每个系统都会有的处理机制,只有在数据是合法的情况下才会进行数据处理;每个系统都有自己的验证规则,当然也可能有一些常规性的规则,比如身份证长度和组成,电话号码长度和组成等等;

如何实现

  以上大体介绍了一下常用的一些接口安全措施,当然可能还有其他我不知道的方式,希望大家补充,下面看看以上这些方法措施,具体如何实现;

1.数据加密

现在主流的加密方式有对称加密和非对称加密;

对称加密:对称密钥在加密和解密的过程中使用的密钥是相同的,常见的对称加密算法有 DES,AES;优点是计算速度快,缺点是在数据传送前,发送方和接收方必须商定好秘钥,然后使双方都能保存好秘钥,如果一方的秘钥被泄露,那么加密信息也就不安全了;

非对称加密:服务端会生成一对密钥,私钥存放在服务器端,公钥可以发布给任何人使用;优点就是比起对称加密更加安全,但是加解密的速度比对称加密慢太多了;广泛使用的是 RSA 算法;

两种方式各有优缺点,而 https 的实现方式正好是结合了两种加密方式,整合了双方的优点,在安全和性能方面都比较好;

对称加密和非对称加密代码实现,jdk 提供了相关的工具类可以直接使用,此处不过多介绍;

2.数据加签

数据签名使用比较多的是 md5 算法,将需要提交的数据通过某种方式组合和一个字符串,然后通过 md5 生成一段加密字符串,这段加密字符串就是数据包的签名,可以看一个简单的例子:

str:参数1={参数1}&参数2={参数2}&……&参数n={参数n}$key={用户密钥};MD5.encrypt(str);

注意最后的用户密钥,客户端和服务端都有一份,这样会更加安全;

3.时间戳机制

解密后的数据,经过签名认证后,我们拿到数据包中的客户端时间戳字段,然后用服务器当前时间去减客户端时间,看结果是否在一个区间内,伪代码如下:

long interval=5*60*1000;//超时时间long clientTime=request.getparameter("clientTime");long serverTime=System.currentTimeMillis();if(serverTime-clientTime>interval){    return new Response("超过处理时长")}

4.AppId 机制

生成一个唯一的 AppId 即可,密钥使用字母、数字等特殊字符随机生成即可;生成唯一 AppId 根据实际情况看是否需要全局唯一;但是不管是否全局唯一最好让生成的 Id 有如下属性:

  • 趋势递增:这样在保存数据库的时候,使用索引性能更好;
  • 信息安全:尽量不要连续的,容易发现规律;
  • 关于全局唯一 Id 生成的方式常见的有类 snowflake 方式等;

5.限流机制

常用的限流算法包括:令牌桶限流漏桶限流计数器限流

  1.令牌桶限流: 令牌桶算法的原理是系统以一定速率向桶中放入令牌,填满了就丢弃令牌;请求来时会先从桶中取出令牌,如果能取到令牌,则可以继续完成请求,否则等待或者拒绝服务;令牌桶允许一定程度突发流量,只要有令牌就可以处理,支持一次拿多个令牌;

  2.漏桶限流: 漏桶算法的原理是按照固定常量速率流出请求,流入请求速率任意,当请求数超过桶的容量时,新的请求等待或者拒绝服务;可以看出漏桶算法可以强制限制数据的传输速度;

  3.计数器限流: 计数器是一种比较简单粗暴的算法,主要用来限制总并发数,比如数据库连接池、线程池、秒杀的并发数;计数器限流只要一定时间内的总请求数超过设定的阀值则进行限流;

具体基于以上算法如何实现,Guava 提供了 RateLimiter 工具类基于基于令牌桶算法:

RateLimiter rateLimiter = RateLimiter.create(5);

以上代码表示一秒钟只允许处理五个并发请求,以上方式只能用在单应用的请求限流,不能进行全局限流;这个时候就需要分布式限流,可以基于 redis+lua 来实现;

6.黑名单机制

如何为什么中黑我们这边不讨论,我们可以给每个用户设置一个状态比如包括:初始化状态,正常状态,中黑状态,关闭状态等等;或者我们直接通过分布式配置中心,直接保存黑名单列表,每次检查是否在列表中即可;

7.数据合法性校验

合法性校验包括:常规性校验以及业务校验;

常规性校验:包括签名校验,必填校验,长度校验,类型校验,格式校验等;

业务校验:根据实际业务而定,比如订单金额不能小于 0 等;

原文地址:https://www.cnblogs.com/myseries/p/12050459.html

时间: 2024-11-06 07:36:50

如何设计一个安全的对外接口?(转)的相关文章

如何设计一个安全的对外接口

作者:ksfzhaohui my.oschina.net/OutOfMemory/blog/3131916 前言 最近有个项目需要对外提供一个接口,提供公网域名进行访问,而且接口和交易订单有关,所以安全性很重要:这里整理了一下常用的一些安全措施以及具体如何去实现. 安全措施 个人觉得安全措施大体来看主要在两个方面,一方面就是如何保证数据在传输过程中的安全性,另一个方面是数据已经到达服务器端,服务器端如何识别数据,如何不被攻击:下面具体看看都有哪些安全措施. 1.数据加密 我们知道数据在传输过程中

如何设计一个异步Web服务——接口部分

需求比较简单,提供一个异步Web服务供使用者调用.比如说,某应用程序需要批量地给图片加lomo效果.由于加lomo效果这个操作非常消耗CPU资源,所以我们需要把这个加lomo效果的程序逻辑放到一台单独的服务器上去运行,以免影响应用本身所在服务器的性能. 这篇先讲讲服务的接口部分,侧重于理清应用和服务之间的调用关系,有时间的话,后面再写一篇关于服务内部任务分派资源调度的随笔. 根据这个需求,我们可以很快设计出一套流程: Application通过向service的addTask接口post任务相关

如何设计一个优雅的RESTFUL的接口

一 .引入 设计接口是我们开发人员的日常操作.当我们把接口交给前端人员时,是否有种拔剑出鞘的错觉.毕竟交付接口,我们的开发工作就阶段性完成了.不过,如果我们没有一个接口设计规范的时候,结果会怎样呢?我们来张图感受一下. 二.REST 2000年,一个年轻小伙子(Roy Thomas Fielding)在他的博士论文提出了 REST.REST 是一种万维网软件架构风格.为什么说是风格不是标准呢?个人理解可能说标准就有点过分了.小伙子做不到.随后这种风格被推广开来,漂洋过海,被大众熟知.在 REST

如何正确合理的设计一个接口项目

时间:2013-10-08 11:43 来源:wangpeng047 作者:wangpeng047 首先,我这里说明接口,不是代码里的接口,而是接口项目,如果想错了就不用往下看了. 在手机广泛流行的今天,手机应用也随之越来越多,而且成长的速度也非常快.手机应用软件开发实现方式同普通PC软件一样,也分为BS和CS方式.而采用CS方式,在服务器端大多采用接口的形式提供数据交互(主流数据交互方式有:Json.WebService等),今天要说的就是如何设计接口. 接口作为连通客户端与数据库进行数据流通

如何设计一个良好的接口

在设计接口时,有很多因素要考虑,如接口的业务定位,接口的安全性,接口的可扩展性.接口的稳定性.接口的跨域性.接口的协议规则.接口的路径规则.接口单一原则. 接口过滤和接口组合等诸多因素,本篇文章将简要分析这些因素. 一 规范性建议 1.职责原则 在设计接口时,必须明确接口的职责,即接口类型,接口应解决什么业务问题等 2.单一性原则 在明确接口职责的条件下,尽量做到接口单一,即一个接口只做一件事,而非两件以上.很多非资深接口设计者,在设计接口时, 总认为接口所做的事越多,越牛叉,这是非常严重的错误

探讨一下常见支付系统的对外接口

本文作者为我的朋友 Terry Gao,某互联网架构师,首发于其个人公众号[PHP架构] 经授权允许本账号转载. 看了之后,感觉写的非常到位,对于测试人员也很有帮助,故原文直接发布. 如果有朋友想了解支付相关测试,请点击-->互联网产品支付功能如何测试? 点击尾部 阅读原文,进入对方公众号. 原文如下 作为一个具备用户交易能力的网站,丰富它的支付渠道对于获客和提高日活都 有不可估量的积极作用.算起来,我接触过的支付系统也有几十个了,在这里总结一下我所接触过的支付系统对外接口的设计方案. 1. 支

设计一个 iOS 控件

代码的等级:可编译.可运行.可测试.可读.可维护.可复用 前言 一个控件从外在特征来说,主要是封装这几点: 交互方式 显示样式 数据使用 对外在特征的封装,能让我们在多种环境下达到 PM 对产品的要求,并且提到代码复用率,使维护工作保持在一个相对较小的范围内:而一个好的控件除了有对外一致的体验之外,还有其内在特征: 灵活性 低耦合 易拓展 易维护 通常特征之间需要做一些取舍,比如灵活性与耦合度,有时候接口越多越能适应各种环境,但是接口越少对外产生的依赖就越少,维护起来也更容易.通常一些前期看起来

如何设计一个可伸缩的计数系统

很多应用程序都有通知或系统消息的功能模块,如果有新消息会以红点或消息条数在某个显眼位置展示给用户,这是计数系统使用场景之一.应用内部,比如微博,每个用户有自己发送微博数量,微博评价数等需要计数的需求,这也是计数系统常见的使用场景.将普遍需要的计数功能独立出一个单独的模块或系统,有利用系统的扩展,所以本文将讨论下如何构建一个可伸缩的计数系统. 1. 先对上述计数常见使用场景简要分析.第一种情况,如果有新消息,应用会显示消息条数或直接显示红点,比如CSDN通知栏的做法,这种场景需要的是消息的增量信息

设计一个中间件的访问日志组件

对任何一个系统,一个强大的日志记录功能是相当重要且必要的,根据日志的记录可以及时掌握系统运行时的健康状态及故障定位.然而作为web容器存在另外一种日志--访问日志.访问日志一般会记录客户端的访问相关信息,包括客户端ip.请求时间.请求协议.请求方法.请求字节数.响应码.会话id.处理时间等等.通过访问日志可以统计访问用户的数量.访问时间分布等规律及个人爱好等等,而这些数据可以帮助公司在运营策略上做出抉择. 如果让你来设计一个访问日志组件你会如何来设计?你应该很快就会想到访问日志的核心功能就是将信