Monthly Archives: June 2018

抽奖活动中的黑灰产对抗

有羊毛的地方,必有薅羊毛者。近日破站为了预热 98E 手办,推出了个抽奖活动,需要通过用户互赞达成抽奖条件,并且以先到先得,无限抽奖的方式清空奖池。

显然这种活动很容易被羊毛党攻击,可利用点有:

  • 将养好羊毛号拿出来批量相互点赞
  • 即将开始抽奖时,控制羊毛号批量无限抽奖

攻击者只需要写个简单脚本就能完成上述攻击,攻击成本低。这时候防御方则需要考虑如何用尽量低的成本进行防护,而且若稍有不慎,服务还可能被攻击者打挂,下面将从四个方面介绍攻防对抗手段:

  1. 增加参与门槛
  2. 应用层的防御
  3. 业务风险控制模型
  4. 切断利益链

Continue reading

微服务架构的认证与鉴权

微服务很酷,但流量在各服务间欢快穿梭的背后可能隐藏着重大安全隐患,黑客也许只需要通过一个点,就能将整个体系击溃。

相比单体应用,在微服务架构的身份认证和鉴权需要考虑的点要多许多。在单体应用中的只有两个对象,即用户与整体的系统,相对简单。

在微服务架构中,对象可能有用户、API 网关、身份认证鉴权服务和其他服务。系统由多个服务组成,并且为了更好的伸缩性,每个服务都应该是无状态的,而服务的对外网络也许并不是完全隔离的,服务间是不可信的,服务间也需要认证和鉴权。

为了保持微服务的简洁轻量,可以将身份认证和鉴权可以单独的拆分出来作为一个或两个独立的服务,由这些服务负责授权,其他服务可以根据用户携带的令牌进行认证。当然,若是能做到完全隔离,并且服务间完全可信,也可以在 API 网关统一解决认证和鉴权,能减少各服务的关注点,把注意力集中在业务本身。服务间通信有一定的成本,如果每个请求过来,除了 API 网关以外,请求涉及到服务都调用一次鉴权服务,这会大大增加鉴权服务的压力,可能会成为系统瓶颈并带来隐患,下面为了平衡安全性和性能来进一步分析选型。

Continue reading