1、接口幂等性设计

说明：保证数据的唯一性，不允许有重复的数据

  • 什么是接口的幂等性

接口幂等性就是用户对于同一操作发起的一次请求或者多次请求的结果是一致的,不会因为多次点击而产生了副作用。

  • 为什么要实现幂等性

在接口调用时一般情况下都能正常返回信息不会重复提交，不过在遇见以下情况时可以就会出现问题，如：

  • 前端重复提交表单： 在填写一些表格时候，用户填写完成提交，很多时候会因网络波动没有及时对用户做出提交成功响应，致使用户认为没有成功提交，然后一直点提交按钮，这时就会发生重复提交表单请求。
  • 用户恶意进行刷单： 例如在实现用户投票这种功能时，如果用户针对一个用户进行重复提交投票，这样会导致接口接收到用户重复提交的投票信息，这样会使投票结果与事实严重不符。
  • 接口超时重复提交： 很多时候 HTTP 客户端工具都默认开启超时重试的机制，尤其是第三方调用接口时候，为了防止网络波动超时等造成的请求失败，都会添加重试机制，导致一个请求提交多次。
  • 消息进行重复消费： 当使用 MQ 消息中间件时候，如果发生消息中间件出现错误未及时提交消费信息，导致发生重复消费。

使用幂等性最大的优势在于使接口保证任何幂等性操作，免去因重试等造成系统产生的未知的问题。

  • 怎么设计接口的幂等性
    • 解决restflu接口的幂等性
      • 数据库主键唯一
        • 使用唯一主键可以避免脏数据的添加，当插入重复数据时数据库会抛异常，保证了数据的唯一性。
      • 数据库乐观锁

这里的乐观锁指的是用乐观锁的原理去实现，为数据字段增加一个version字段，当数据需要更新时，先去数据库里获取此时的version版本号

  1. select version from tablename where xxx

更新数据时首先和版本号作对比，如果不相等说明已经有其他的请求去更新数据了，提示更新失败。

  1. update tablename set count=count+1,version=version+1 where version=#{version}
  1.   - **数据库悲观锁**

乐观锁可以实现的往往用悲观锁也能实现，在获取数据时进行加锁，当同时有多个重复请求时其他请求都无法进行操作

  1.   - **分布式锁**

幂等的本质是分布式锁的问题，分布式锁正常可以通过redis或zookeeper实现；在分布式环境下，锁定全局唯一资源，使请求串行化，实际表现为互斥锁，防止重复，解决幂等。

  1.   - **token机制**

token机制的核心思想是为每一次操作生成一个唯一性的凭证，也就是token。一个token在操作的每一个阶段只有一次执行权，一旦执行成功则保存执行结果。对重复的请求，返回同一个结果。token机制的应用十分广泛。
image.png
image.png

2、防参数篡改

说明： API参数篡改就是恶意人通过抓包的方式获取到请求的接口的参数，通过修改相关的参数，达到欺骗服务器的目的，常用的防止篡改的方式是用签名以及加密的方式。

防御方式：

  • 使用https传输
  • 对参数以某种方式进行加密

3、防重发攻击

说明： 就是把之前窃听到的数据原封不动的被重发或多次重发。

防御方式：
防止重发攻击必须要保证请求仅一次有效
需要通过在请求体中携带当前请求的唯一标识，并且进行签名防止被篡改。
所以防止重发攻击需要建立在防止签名被串改的基础之上

实例：基于timestamp和nonce

微信支付的接口就是这样做的

timestamp的作用
每次HTTP请求，都需要加上timestamp参数，然后把timestamp和其他参数一起进行数字签名。HTTP请求从发出到达服务器一般都不会超过60s，所以服务器收到HTTP请求之后，首先判断时间戳参数与当前时间相比较，是否超过了60s，如果超过了则认为是非法的请求。

一般情况下,从抓包重放请求耗时远远超过了60s，所以此时请求中的timestamp参数已经失效了,如果修改timestamp参数为当前的时间戳，则signature参数对应的数字签名就会失效，因为不知道签名秘钥，没有办法生成新的数字签名。

但这种方式的漏洞也是显而易见的，如果在60s之后进行重放攻击，那就没办法了，所以这种方式不能保证请求仅一次有效

nonce的作用
nonce的意思是仅一次有效的随机字符串，要求每次请求时，该参数要保证不同。我们将每次请求的nonce参数存储到一个“集合”中，每次处理HTTP请求时，首先判断该请求的nonce参数是否在该“集合”中，如果存在则认为是非法请求。

nonce参数在首次请求时，已经被存储到了服务器上的“集合”中，再次发送请求会被识别并拒绝。

nonce参数作为数字签名的一部分，是无法篡改的，因为不知道签名秘钥，没有办法生成新的数字签名。

这种方式也有很大的问题，那就是存储nonce参数的“集合”会越来越大。

nonce的一次性可以解决timestamp参数60s(防止重放攻击)的问题，timestamp可以解决nonce参数“集合”越来越大的问题。

4、防数据信息泄漏

说明： 案例：截获用户登录请求，截获到账号、密码等

防御方式： 参数进行加密传输
如果为了保证更加的安全，可以加上RSA,RSA2，AES等等加密方式，保证了数据的更加的安全，但是唯一的缺点是加密与解密比较耗费CPU的资源.

5、防SQL注入

说明： SQL注入是比较常见的网络攻击方式之一，它不是利用操作系统的BUG来实现攻击，而是针对程序员编程时的疏忽，通过SQL语句，实现无帐号登录，甚至篡改数据库。

  1. public interface UserMapper {
  3.     @Select(" SELECT  * FROM user_info where userName=#{userName} and password=${password}")
  4.     public UserEntity login(UserEntity userEntity);
  6. }

假设password=“1; drop table user_info”，那就会删掉表了。

防御方式：

  • 普通用户与系统管理员用户的权限要有严格的区分。
  • 使用正则表达式过滤传入的参数。
  • 必要的情况下使用专业的漏洞扫描工具来寻找可能被攻击的点。
  • 使用PreparedStatement来代替Statement来执行SQL语句。
  • MyBatis的映射语句时，尽量采用“#{xxx}”这样的格式。若不得不使用“${xxx}”这样的参数，要手工地做好过滤工作，来防止SQL注入攻击。

MyBatis框架作为一款半自动化的持久层框架，其SQL语句都要我们自己手动编写，这个时候当然需要防止SQL注入。其实，MyBatis的SQL是一个具有“输入+输出”的功能，类似于函数的结构，参考上面的两个例子。其中，parameterType表示了输入的参数类型，resultType表示了输出的参数类型。回应上文，如果我们想防止SQL注入，理所当然地要在输入参数上下功夫。上面代码中使用#的即输入参数在SQL中拼接的部分，传入参数后，打印出执行的SQL语句，会看到SQL是这样的：select id, username, password, role from user where username=? and password=?
不管输入什么参数，打印出的SQL都是这样的。这是因为MyBatis启用了预编译功能，在SQL执行前，会先将上面的SQL发送给数据库进行编译；执行时，直接使用编译好的SQL，替换占位符“?”就可以了。因为SQL注入只能对编译过程起作用，所以这样的方式就很好地避免了SQL注入的问题。