如何设计一个安全的对外接口 - ksfzhaohui的个人页面 - OSCHINA

标签: | 发表时间:2019-11-20 23:00 | 作者:
出处:https://my.oschina.net


前言

最近有个项目需要对外提供一个接口,提供公网域名进行访问,而且接口和交易订单有关,所以安全性很重要;这里整理了一下常用的一些安全措施以及具体如何去实现。

安全措施

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

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提供了相关的工具类可以直接使用,此处不过多介绍;
关于https如何配置使用相对来说复杂一些,可以参考本人的之前的文章 HTTPS分析与实战

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等;

总结

本文大致列举了几种常见的安全措施机制包括:数据加密、数据加签、时间戳机制、AppId机制、限流机制、黑名单机制以及数据合法性校验;当然肯定有其他方式,欢迎补充。

相关 [设计 安全 接口] 推荐:

如何设计一个安全的对外接口 - ksfzhaohui的个人页面 - OSCHINA

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

API 接口应该如何设计?如何保证安全?如何签名?如何防重?

- - DockOne.io
说明:在实际的业务中,难免会跟第三方系统进行数据的交互与传递,那么如何保证数据在传输过程中的安全呢(防窃取). 除了https的协议之外,能不能加上通用的一套算法以及规范来保证传输的安全性呢. 下面我们就来讨论下常用的一些API设计的安全方法,可能不一定是最好的,有更牛逼的实现方式,但是这篇是我自己的经验分享.

API 接口设计规范

- - 掘金后端
这篇文章分享 API 接口设计规范,目的是提供给研发人员做参考. 规范是死的,人是活的,希望自己定的规范,不要被打脸. url?后面的参数,存放请求接口的参数数据. 请求头,存放公共参数、requestId、token、加密字段等. Body 体,存放请求接口的参数数据. 调用方需向服务方申请 appKey(请求时使用) 和 secretKey(加密时使用).

接口安全调用该怎么做?签名?证书?服务安全?

- - 企业架构 - ITeye博客
在这个以“数据为生命”的时代,每一个开发商都尽可能的收集客户的数据建立自己的BI库,各系统、各平台间数据的传输和调用变得非常普遍且非常重要;那么作为开发人员,我们不但要防止系统被攻击被入侵,我们还要确保数据的安全和完整. 在内网传输和外网传输的数据对安全的要求一般是不同的,因为内网数据的传输得到了网络防火墙的保护,起到了隔绝外部攻击的作用,但也并非一定安全;相比之下,对外部开放的接口则需要做的更多更好.

API设计新思维:用流畅接口构造内部DSL

- 风子 - 酷壳 - CoolShell.cn
感谢@weidagang (Todd)向酷壳投递本文. 程序设计语言的抽象机制包含了两个最基本的方面:一是语言关注的基本元素/语义;另一个是从基本元素/语义到复合元素/语义的构造规则. 在C、C++、Java、C#、Python等通用语言中,语言的基本元素/语义往往离问题域较远,通过API库的形式进行层层抽象是降低问题难度最常用的方法.

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

- - CSDN博客架构设计推荐文章
首先,我这里说明接口,不是代码里的接口,而是接口项目,如果想错了就不用往下看了. 在手机广泛流行的今天,手机应用也随之越来越多,而且成长的速度也非常快. 手机应用软件开发实现方式同普通PC软件一样,也分为BS和CS方式. 而采用CS方式,在服务器端大多采用接口的形式提供数据交互(主流数据交互方式有:Json、WebService等),今天要说的就是如何设计接口.

[原]增量接口的设计及实现

- - 高爽|Coder
在应用开发过程中,我们总会碰到这样的场景:某系统需要同步我们系统的数据去做一些业务逻辑,当数据量较小的时候,可以全量的提供,但当数据量很大时,全量提供就显得很笨重,不仅耗时而且做了很多无用功,这时我们需要一种提供增量数据的机制,只告诉对方变化的数据. 提供增量数据大致可分为两种方式:MQ和接口提供,MQ的优点是及时,缺点是丢失、重复、回溯复杂等等问题(依赖于具体MQ实现),这里不过多赘述;接口提供不限于RPC或HTTP等方式,接口提供的优缺点正好和MQ反过来,及时性取决于调用周期.

从 Feign 使用注意点到 RESTFUL 接口设计规范 - ImportNew

- -
最近项目中大量使用了Spring Cloud Feign来对接http接口,踩了不少坑,也产生了一些对RESTFUL接口设计的想法,特此一篇记录下. SpringMVC的请求参数绑定机制. 了解Feign历史的朋友会知道,Feign本身是Netflix的产品,Spring Cloud Feign是在原生Feign的基础上进行了封装,引入了大量的SpringMVC注解支持,这一方面使得其更容易被广大的Spring使用者开箱即用,但也产生了不小的混淆作用.

云服务器安全设计

- - WooYun知识库
目前越来越多的初创企业把自己的业务系统架设在公有云上,包含:阿里云、Ucloud、青云、华为云和AWS. 在云上的安全怎么保证,是目前摆在我们面前的最大问题,因为,互联网公司业务系统在不断迭代,迭代周期最少的有3天,而且架构也不断在改变. 在这种频繁改变的过程中,云安全应该怎么保证. ,云主机安全服务平台(Cloud security as a service),为多租户提供云主机安全服务的产品,减少用户业务系统攻击面,防止恶意的定向攻击(APT).

如何优雅设计 API 接口,实现统一格式返回?

- - DockOne.io
【编者的话】在移动互联网,分布式、微服务盛行的今天,现在项目绝大部分都采用的微服务框架,前后端分离方式. 题外话:前后端的工作职责越来越明确,现在的前端都称之为大前端,技术栈以及生态圈都已经非常成熟;以前后端人员瞧不起前端人员,那现在后端人员要重新认识一下前端,前端已经很成体系了. 一般系统的大致整体架构图如下:.