目前状况:

   游戏平台目前以开发迭代为主,安全问题考虑的较少。

目标:

 做大做强,平台安全与接口安全变的越来越重要。

存在的问题:

  1、DOS攻击无法拦截。

      DoS是Denial of Service的简称,即拒绝服务,造成DoS的攻击行为被称为DoS攻击,其目的是使计算机或网络无法提供正常的服务。最常见的DoS攻击有计算机网络宽带攻击和连通性攻击。
      说白了,DoS攻击是指故意的攻击网络协议实现的缺陷或直接通过野蛮手段残忍地耗尽被攻击对象的资源,目的是让目标计算机或网络无法提供正常的服务或资源访问,使目标系统服务系统停止响应甚至崩溃,

  而在此攻击中并不包括侵入目标服务器或目标网络设备。这些服务资源包括网络带宽,文件系统空间容量,开放的进程或者允许的连接。
     这种攻击会导致资源的匮乏,无论计算机的处理速度多快、内存容量多大、网络带宽的速度多快都无法避免这种攻击带来的后果。

2、重放攻击无法拦截。

重放攻击(Replay Attacks)又称重播攻击、回放攻击,是指攻击者发送一个目的主机已接收过的包,来达到欺骗系统的目的。
主要用于身份认证过程,破坏认证的正确性。重放攻击可以由发起者,也可以由拦截并重发该数据的敌方进行。
攻击者利用网络监听或者其他方式盗取认证凭据,之后再把它重新发给认证服务器。重放攻击在任何网络通过程中都可能发生,是计算机世界黑客常用的攻击方式之一

 

举例:入侵者从网络上截取主机A发送给主机B的报文,并把由A加密的报文发送给B,使主机B误以为入侵者就是主机A,然后主机B向伪装成A的入侵者发送应当发送给A的报文。

3、请求参数可篡改。

4、请求身份合法性不强。比如每个接口中,都有activityId,而且是Integer类型,容易被猜到,请求方很容易拿到别的活动信息,甚至不属于自己游戏的信息。

5、活动id,过于明显。

需要解决的问题:

1、拦截无效请求。

2、身份合法性验证。

3、请求唯一性验证。

4、禁止请求参数篡改。

方案:

1、DOS攻击的方案:

(1)同一个IP请求频率限制

  根据接口来源IP,限制接口访问频率。

(2)时间戳超时机制

客户端每次请求接口都带上当前时间的时间戳timestamp,服务端接收到timestamp后跟当前时间进行比对,如果时间差大于一定时间(比如:30S),则认为该请求失效。时间戳超时机制是防御DOS攻击的有效手段。

例:http://url/getInfo?id=1&timetamp=1559396263

2、重放攻击的方案:

防止重放攻击的方法是使用不重数

(1)加随机数
该方法优点是认证双方不需要时间同步,双方记住使用过的随机数,如发现请求中有以前使用过的随机数,就认为是重放攻击。缺点是需要额外保存使用过的随机数,若记录的时间段较长,则保存和查询的开销较大。

(2)加时间戳
该方法优点是不用额外保存其他信息。缺点是认证双方需要准确的时间同步,同步越好,受攻击的可能性就越小。但当系统很庞大,跨越的区域较广时,要做到精确的时间同步并不是很容易。

客户端第一次访问时,将签名sign存放到服务器的Redis中,超时时间设定为跟时间戳的超时时间一致,
二者时间一致可以保证无论在timestamp限定时间内还是外 URL都只能访问一次,如果被非法者截获,使用同一个URL再次访问,
如果发现缓存服务器中已经存在了本次签名,则拒绝服务。如果在缓存中的签名失效的情况下,有人使用同一个URL再次访问,
则会被时间戳超时机制拦截,这就是为什么要求sign的超时时间要设定为跟时间戳的超时时间一致。
拒绝重复调用机制确保URL被别人截获了也无法使用(如抓取数据)。

3、请求参数防止篡改方案:

      接口签名

4、请求唯一性验证方案:

     timestamp+nonce

5、接口重要数据加密

6、接口访问限制频率

7、前端接入防火墙

8、黑名单。 比如 IP黑名单,对恶意的IP加入黑名单。

9、白名单。 比如 对屏端的游戏,把IP加入白名单,只允许固定的屏能访问。

总方案:

(1)校验请求身份是否合法:每一款游戏为开发者分配AccessKey(开发者标识,确保唯一,作为每个接口的参数),每一个活动,分配 SecretKey(参与接口签名,不作为接口参数传参,保存在游戏前端,注意:确保不易被穷举,生成算法不易被猜测)。

(2)timestamp+nonce:nonce的一次性可以解决timestamp参数60s的问题,timestamp可以解决nonce参数“集合”越来越大的问题。防止重放攻击一般和防止请求参数被串改一起做.

接口请求中添加nonce字段,nonce指唯一的随机字符串,用来标识每个被签名的请求。通过为每个请求提供一个唯一的标识符,服务器能够防止请求被多次使用(记录所有用过的nonce以阻止它们被二次使用)。

然而,对服务器来说永久存储所有接收到的nonce的代价是非常大的。可以使用timestamp来优化nonce的存储。

假设允许客户端和服务端最多能存在1分钟的时间差,同时追踪记录在服务端的nonce集合。当有新的请求进入时,首先检查携带的timestamp是否在1分钟内,如超出时间范围,则拒绝,然后查询携带的nonce,如存在已有集合,则拒绝。否则,记录该nonce,

并删除集合内时间戳大于1分钟的nonce(可以使用redis的expire,新增nonce的同时设置它的超时失效时间为1分钟)。

(3)参数签名:客户端对传送的参数字典排序后,进行md5签名。服务器接收参数后,同理进行参数字典排序后md5签名。若客户端与服务端的签名一致,说明参数未被篡改,校验通过。

1.参数排序时,不包括sign参数
2.遇到数值拼接时,需统一转换成字符串类型。如:123 需转换成 “123”
3.为避免客户端和服务器端签名对null处理不一致,若参数值为null时,请转换成空字符串("")

4.   接口请求采用https的post方式,返回信息全部采用json格式报文。

5.   请求和返回报文双方约定采用UTF-8编码,并对请求参数做URLEncoder。

6.   签名规则(签名在URLEncoder之前做。)

服务端类似处理

 

posted on 2023-07-20 16:55  毛会懂  阅读(65)  评论(0编辑  收藏  举报