保障接口安全的11个方法

保障接口安全的11个方法_第1张图片

一、参数校验

  • 校验参数是否为空,有些接口中可能会包含多个参数,有些参数允许为空,有些参数不允许为空,需要对这些参数做校验,防止接口底层出现异常。
  • 校验参数类型,比如:age 是 int 类型的,用户传入了一个字符串:“123abc”,这种情况参数不合法,需要被拦截
  • 校验参数的长度,特别是对于新增或者修改数据接口,必须要做参数长度的校验,否则超长了数据库会报异常。比如:数据库 username 字段长度是 30,新用户注册时,输入了超过 30 个字符的名称,需要提示用户名称超长了。虽说前端会校验字段长度,但接口对参数长度的校验也必不可少。
  • 校验枚举值,有些接口参数是枚举,比如:status,数据库中设计的该字段只有1、2、3三个值。如果用户传入了4,则需要提示用户参数错误。
  • 校验数据范围,对于有些金额参数,需要校验数据范围,比如:单笔交易的 money 必须大于 0,小于 10000。

可以自己写代码,对每个接口的请求参数一一做校验,也可以使用一些第三方的校验框架。
Hiberate 的 Validator 框架,它里面包含了 @Null、@NotEmpty、@Size、@Max、@Min 等注解,有些日期字段和枚举字段,可能需要通过自定义注解的方式实现参数校验。

二、统一封装返回值

写的某个接口底层的 SQL,在某种条件下有语法问题。某个用户请求接口之后,在访问数据库时,直接报了 SQL 语法错误,将数据库名、表名、字段名、相关 SQL 语句都打印出来了。
接口将这些异常信息直接返回给外网的用户,有些黑客拿着这些信息,将参数做一些调整,拼接一些注入 SQL,可以对数据库发起攻击。
因此,非常有必要对接口的返回值做统一的封装。


{
    "code":0,
    "message":null,
    "data":[{"id":123,"name":"abc"}]
}

code:表示响应码,0-成功,1-参数为空,2-参数错误,3-签名错误 4-请求超时 5-服务器内部错误等。
message:表示提示信息,如果请求成功,则返回空。如果请求失败,则返回我们专门在代码中处理过,让用户能看懂的错误信息。
data:表示具体的数据,返回的是一个 JSON 字段。

对返回值这样封装之后,即使在接口的底层出现了数据库的异常,也不会直接提示用户,给用户提示的是服务器内部错误。
对返回值统一封装的工作,没有必要在业务代码中做,完全可以在放到API网关。
业务系统在出现异常时,抛出业务异常的 RuntimeException,其中有个 message 字段定义异常信息。
所有的 API 接口都必须经过 API网关,API 网关捕获该业务异常,然后转换成统一的异常结构返回,这样能统一返回值结构。

三、做转义

在用户自定义输入框,用户可以输入任意内容。
有些地方需要用 html 的格式显示用户输入的内容,比如文章详情页或者合同详情页,用户可以自定义文案和样式。

这些地方如果我们不做处理,可能会遭受 XSS(Cross Site Scripting)攻击,也就是跨站脚本攻击。

攻击者可以在输入的内容中,增加脚本,比如:,这样在访问合同详情页时,会弹出一个不需要的窗口,攻击者甚至可以引导用户访问一些恶意的链接。
由此,我们需要对用户输入内容中的一些特殊标签做转义。

下面这张图中列出了需要转义的常见字符和转义后的字符:
保障接口安全的11个方法_第2张图片
可以自定义一个转义注解,打上该注解的字段,表示需要转义
有个专门的 AOP 拦截器,将用户的原始内容,转换成转义后的内容。
保存到数据库中是转义之后的内容。
除此之外,为了防止 SQL 注入的情况,也需要将用户输入的参数做 SQL 语句方面的转义。

四、做权限控制

①、校验是否登录

对于用些公共数据,比如:外部分类,所有人都能够看到,不用登录也能看到。
而对于有些查看内部分类的接口,需要用户登录之后,才能访问。

可以从当前用户上下文中获取用户信息,校验用户是否登录。
如果用户登录了,当前用户上下文中该用户的信息不为空。

②、接口功能权限控制

对于有些重要的接口,比如订单审核接口,只有拥有订单审核权限的运营账号,才有权限访问该接口。

可以自定义一个权限注解,在注解上可以添加权限点。在网关层有个拦截器,会根据当前请求的用户的权限,去跟请求的接口的权限做匹配,只有匹配上次允许访问该接口。

③、接口数据权限控制

对于有些订单查询接口,普通运营只能查看普通用户的数据。
而运营经理可以查看普通用户和 VIP 用户的数据
不同的角色,能够查看的数据范围不同,可以在查询数据时,在 SQL 语句中动态拼接过滤数据权限的 SQL。

五、加验证码

对于一些非常重要的接口,在做接口设计的时候,要考虑恶意用户刷接口的情况。
最早的用户注册接口,是需要用图形验证码校验的,比如下面这样的:
保障接口安全的11个方法_第3张图片
仅靠图形验证码,防止用户注册接口被刷,难道太大了。又出现了一种移动滑块形式的图形验证方式,安全性更高。

保障接口安全的11个方法_第4张图片
此外,使用验证码比较多的地方是发手机短信的功能。
发手机短信的功能,一般是购买的云服务厂商的短信服务,按次收费,比如:发一条短信 0.1 元。
如果发送短信的接口,不做限制,被用户恶意调用,可能会产生非常昂贵的费用。

六、限流

从页面上的验证码,只能限制当前页面的不能重复发短信,但如果用户刷新了页面,也可以重新发短信。
因此非常有必要在服务端,即:发送短信接口做限制。

增加一张短信发送表,该表包含:id、短信类型、短信内容、手机号、发送时间等字段。
保障接口安全的11个方法_第5张图片
有用户发送短信请求过来时:

  • 先查询该手机号最近一次发送短信的记录
  • 如果没有发送过,则发送短信
  • 如果该手机号已经发送过短信,但发送时间跟当前时间比超过了 60 秒,则重新发送一条新的短信
  • 如果发送时间跟当前时间比没超过 60 秒,则直接提示用户操作太频繁,请稍后重试

这样就能非常有效的防止恶意用户刷短信的行为。

漏洞:
用户知道在 60 秒以内,是没法重复发短信的。他有个程序,刚好每隔 60 秒发一条短信。
这样1个手机号在一天内可以发:60*24 = 1440 条短信。
如果他有 100 个手机号,那么一天也可以刷你很多条短信。
由此,还需要限制每天同一个手机号可以发的短信次数。

其实可以用 Redis 来做:
用户发短信之后,在 Redis 中保存一条记录,key 是手机号,value 是发短信的次数,过期时间是 24 小时。
这样在发送短信之前,要先查询一下,当天发送短信的次数是否超过10次(假设同一个手机号一天最多允许发 10 条短信)
如果超过 10 次,则直接提示用户操作太频繁,请稍后重试。如果没超过 10 次,则发送短信,并且把 Redis 中该手机号对应的 value 值加 1。
保障接口安全的11个方法_第6张图片

七、加ip白名单

比如:会员系统的开通会员接口,业务系统可能会调用该接口开通会员。
这个 IP 白名单前期可以做成一个 Apollo 配置,可以动态生效。

如果后期 IP 数量多了的话,可以直接保存到数据库。
只有ip在白名单中的那些服务器,才允许调用开通会员接口。
这样即使开通会员接口地址和请求参数被泄露了,调用者的 IP 不在白名单上,请求开通会员接口会直接失败。

除非调用者登录到了某一个白名单 IP 的对应的服务器,这种情况极少,因为一般运维会设置对访问器访问的防火墙。

当然如果用了 Fegin 这种走内部域名的方式访问接口,可以不用设置 IP 白名单,内部域名只有在公司的内部服务器之间访问,外面的用户根本访问不了。
但对于一些第三方平台的接口,他们更多的是通过设置ip白名单的方式保证接口的安全性。

八、校验敏感词

对于某些用户可以自定义内容的接口,还需要对用户输入的内容做敏感词校验。
比如:在创建商品页面,用户输入了:傻逼商品,结果直接显示到了商城的商品列表页面,这种情况肯定是不被允许的。

当然你也可以做一个审核功能,对用户创建的商品信息做人工审核,如果商品数量太多,这样会浪费很多人力。
当然你也可以做一个审核功能,对用户创建的商品信息做人工审核,如果商品数量太多,这样会浪费很多人力。

可以调用第三方平台的接口,也可以自己实现一个敏感词校验接口。
可以在 GitHub 上下载一个开源的敏感词库,将那些敏感词导入到数据库中。
然后使用 hanlp 对用户输入的内容,进行分词。对分好的词,去匹配敏感词库中的那些敏感词。

如果匹配上了,则说明是敏感词,则验证不通过。
如果没有匹配上,则说明非敏感词,则验证通过。

不可能在每个业务接口中都调用敏感词校验接口,我们可以自定义注解,在AOP拦截器中调用敏感词校验接口。
在调用业务接口之前,先触发拦截器,校验打了敏感词校验注解的那些字段,将他们里面包含的内容,作为入参传入敏感词校验接口做校验。
当然有时候 hanlp 分词器会把句子分错词,还需要添加一个敏感词的白名单,白名单中的词不是敏感词。

九、使用https协议

HTTP(HyperText Transport Protocol,即超文本传输协议)协议

  1. 使用明文通讯,内容容易被窃听。
  2. 不验证通讯方的真实身份,容易遭到伪装。
  3. 无法证明报文的完整性,报文很容易被篡改。

HTTPS 协议是在 HTTP 协议的基础上,添加了加密机制:

  • SSL:它是Secure Socket Layer的缩写, 表示安全套接层。
  • TLS:它是Transport Layer Security的缩写,表示传输层安全。

HTTPS = HTTP + 加密 + 认证 + 完整性保护。
HTTPS 协议需要申请证书,有些额外的费用

十、数据加密

有些信息是用户的核心信息,比如:手机号、邮箱、密码、身份证、银行卡号等,不能别泄露出去。
在保存到数据库时,我们要将这些字段,做加密处理。

这种情况可以使用AES对称加密的方式,因为后面系统的有些业务场景,需要把加密的数据解密出来。

为了安全性考虑,我们需要设置一个用于加密的密钥,这个密钥可以稍微复杂一点,包含一些数字、字母和特殊字符
同样可以通过自定义注解的方式,给需要加密的字段添加该注解,在 Mybatis 拦截器中实现加解密的功能。

对于查询操作,需要将加了该注解的字段的数据做解密处理。
对于写入操作,要将加了该注解的字段的数据做加密处理。

有些页面显示的地方,手机号一般不会显示完整的手机号,中间有一部分用代替,比如:182**3457。

十一、做风险控制

有些特殊的接口,比如用户登录接口,我们需要对该接口做风险控制,尽可能减小被盗号的风险。

用户登录失败之后,需要有地方,比如:Redis,记录用户登录失败的次数。
如果用户第一次输入账号密码登录时,出现的是一个稍微简单的验证码。

如果用户把账号或密码连续输错 3 次之后,出现了更复杂的验证码。
或者改成使用手机短信验证。

如果用户在一天之内,把账号或密码连续输错 10 次,则直接锁定该账号。
这样处理是为了防止有人用一些软件,暴力破解账号和密码。

在用户登录成功之后,需要有一张表记录用户的 IP、所在城市和登录的设备id。
如果你的账号被盗了。
在盗号者在页面输入账号密码登录,会调用登录接口,此时登录接口中可以根据用户的ip和设备id,做一些风险控制。
接口判断如果用户当前登录的 IP、所在城市和设备 IP,跟上一次登录成功时记录的相差非常大。

比如:1 小时之前,用的 IP 是 100.101.101.101,城市是北京,设备 id 是 1001,而 1 小时之后,用的 IP 是200.202.202.101,城市是广州,设备 id 是 2002。
这种情况用户的账号极有可能被盗了。登录接口做安全性升级,需要校验用户手机验证码才能登录成功。
由于盗号者只有你的账号和密码,没有手机验证码,所以即使被盗号了,也没办法登录成功。

你可能感兴趣的:(安全)