作为开发者，最令我们头疼的可能并不是产品需求开发，而是在产品上线后出现的各种安全风险问题。

这些年，我们收到很多开发者提供的真实案例：

1. 投票功能，本来要提供公平公正的投票服务，结果因为有人雇佣水军刷赞，造成投票严重不公平；
2. 发放活动优惠券，本来是刺激用户活跃的好活动，好不容易申请了经费，结果被羊毛党用非法手段拿走了90%，变价买卖。
3. 信息发布应用，访问人数很少但是服务器压力很大，因为每天会收到几十个爬虫的千万次请求。
4. ......

这些案例一次次的发生，让我们产生了思考，到底哪个环节出问题了？

风险在哪里？

用户在使用小程序或H5应用时，业务请求从客户端发起，经过网络链路，到服务端；然后服务端根据请求处理事项并返回相应的内容，这是一个正常预期内的过程。

这里的客户端、网络链路、服务端，每一个部分都会成为被攻击的对象。我们一个个来盘点：

1.  客户端

小程序本身有代码加密插件，可以对上传的小程序代码混淆加密，并且从小程序发送的请求有明显的特征，只要服务端对应配置可以识别这些特征，攻击者破解和伪造的难度是非常高的。

但从诸多案例中我们发现，大部分攻击者不会直接从源码中破解请求体，而是使用模拟器、群控及设备农场的方式，通过外部辅助脚本或物理外挂的形式来去攻击。

比如“跳一跳”小游戏，很多玩家为了拿高分，不是去搞小游戏代码包伪造请求，而是直接搬上摄像头识别，通过距离识别，停顿秒数的计算，物理触发屏幕完成刷高分的成就。（网络搜一搜跳一跳外挂，八仙过海各显神通）

一般来说群控设备的解法要比直接破解代码包去伪造请求隐蔽的多，如果我们开发者只做了简单的 header 特征的识别，是很难抓到群控设备发出的请求的，从特征看，这些就是正常的手机直接点击完成的。

2.  网络链路

从客户端到服务端，一定是要经过本地网络和运营商网络，运营商网络直接做攻击行为的可能性很小，绝大部分的网络链路攻击都来源于本地网络。

攻击者通过对你正常的请求域名进行DNS污染，或通过代理你的网络，对客户端发出的请求做劫持和重放等，来达到TA的目的。

比如，因为开发者的逻辑失误，导致一个游戏道具的领取接口没有做校验和限制，发一个请求就领取一个道具，那么攻击者可以直接通过在链路上劫持并重放接口请求来刷道具。

除此之外还有很多很多，一半以上的攻击者目的都是为了自身，而不是去偷他人的数据，因为主观能动性，本地网络的链路劫持基本都能轻松完成。

3.  服务端

服务端是最容易被攻击的，并且大部分的攻击行为都是绕开客户端和网络链路（从客户端发来的链路），直接去搞服务端。这里列举一些常见的攻击手段：

• DDos攻击：分布式拒绝服务攻击，攻击者直接不择手段想把你的服务器打挂掉，从而影响你的正常业务。
• CC攻击：人海攻击手段，通过绑架大量肉鸡或者号召一大波人，直接把你服务端挤爆，让你无法服务正常的用户。
• BOT攻击：一般不会对你的服务器造成影响，只是通过后端接口缺陷，批量自动化获取你的业务信息，或者定时来获取你的信息，有部分是爬虫。
• 黑客攻击手段：比如SQL注入、0day漏洞、加密凭证破解、网络阻塞攻击等，这些就不是用户抢道具这种的目标行为，而是有预谋的直接攻击你的基建。

应该如何防范？

针对不同层面的攻击，我们应该有不同的防范方法，在这里我们给开发者整理了一些有效的方法：

1. 客户端

• 应用中尽量使用代码保护插件，对小程序代码进行混淆和加密，增加逆向工程的难度。
• 应用中设置合理的操作频率限制和阈值警报，比如在页面打开后不允许立刻点击按钮，按钮加上防抖和节流。
• 实现基于时间或挑战-响应的动态令牌机制，防止请求重放攻击。
• 结合多维度信息（如硬件ID、网络特征、行为模式等）生成唯一标识，识别和追踪异常设备行为。
• 接入用户行为分析监听，检测异常操作模式；比如跳一跳长时间有节奏的操作停顿，点击位置无变化，可以判定物理外挂。

2. 网络链路

• 小程序强制使用HTTPS协议，但在其他客户端也应全面采用HTTPS协议，防止中间人攻击和数据窃听；另外有条件可以采取证书固定，防止SSL劫持。
• 有能力的话，对每个请求进行签名，包含时间戳、nonce 等信息，服务端验证签名有效性。
• 有条件可以进行双向认证，服务端也要对客户端证书做认证，确保通信双方身份。
• 扩展使用 DNSSEC 或 HTTP-DNS 技术，防止DNS污染。

3. 服务端

• 使用专业的DDoS防护服务器，实现流量清洗和智能负载均衡；另外应用层面要基于IP或者用户openid做访问频率限制。
• 使用验证码或其他人机交互验证来辅助判断，比如关键接口滑动验证，或使用短信验证码确认。
• API层面要做细粒度的接口权限控制，对敏感接口应该有更严格的认证和授权机制。
• 引入一些BOT检测机制，通过特征标记来识别和阻止自动化脚本；配合动态黑名单系统，自动封禁异常IP。
• 部署WAF，防御常见的Web攻击，如SQL注入、XSS等；另外对服务器和后端服务软件的安全更新和补丁要及时处理。
• 使用API网关，集中管理和监控API调用，将多个服务受攻击面缩减到一个，集中精力防护。

通过实现上述手段，我们能阻止绝大部分的安全攻击，但也对各位开发者提出了更高的要求；如果因为自身理解或者配置不当，很有可能会遗漏一些重要的点，造成防护失效，对业务服务造成损失。

那么有没有什么方法，能够让开发者简单操作就能实现上述所有防护手段，从而高效的处理的自己的业务开发呢？

微信做了什么？

微信官方团队，在去年就推出了集API网关、网络加速、请求加密、安全防护、流量管控于一体的「安全网关」，有一套完整的端到端的防护体系。从客户端到服务端，全面覆盖业务服务过程，为开发者提供简单、高效的保护和治理。

「安全网关」的防护能力分链路层面、客户端层面、服务端层面，我们分别来看下几个层面的防护特点。

在链路层面上，实现了三层防护

1. 第一层：请求进入网关的微信私有协议时，可以精准识别协议外挂、爬虫特征、模拟器攻击、黑灰产IP、DDos和CC攻击等各种异常请求，并及时拦截。
2. 第二层：经过第一层的初步清洗，在这一层会对伪造、篡改协议的请求进行清洗；同时结合用户请求频率、权限校验等风控能力拦截掉非法请求、越权请求、高频请求等；前两层的清洗已经拦截90%的异常流量，将剩余正常流量转发给业务源站。
3. 第三层：为了防止漏网之鱼，开发者可以选择接入第三层，网关会结合请求特征、设备信息、账号信息形成多维智能分析模型，对请求进行风险的判别，并将判别结果一同提交给业务源站，开发者可以参照或结合自己的数据，综合判断请求的合法性。开发者也可以授权网关直接对高风险的请求直接拦截，不转发给业务源站。

在客户端层面，请求加密和风险识别

「安全网关」提供微信私有协议，二次封装，100%加密数据和接口，全程无明文数据传输，极大的提高外部抓包破解门槛。

并且「安全网关」支持在小程序、WEB、H5、APP等多端场景接入。尤其在微信小程序中，平台能在 wx.request 中直接转发请求到网关安全链路，无需开发者改代码；支持一键断连，恢复为普通请求链路。

风险识别上，「安全网关」在微信小程序中推出「安全检测插件」，插件会根据设备环境、网络环境、用户行为、账号风险等多维度综合判断当前运行环境的可信情况，给出判断结果；开发者接入后可以在敏感业务前调用检测，检测通过才进行业务请求。

该扩展插件可以帮助开发者拦截群控、模拟器、设备农场等端场景的攻击行为，极大降低了游戏刷高分，集赞水军，自动羊毛党对正常业务的影响。

服务端层面提供信任参考

「安全网关」之所以称之为网关，是因为TA代理了所有客户端发送的请求，集中转发到开发者业务服务器中。在这个集中处理的过程中，实现了加密、加速、安全防护等多个效果。

作为服务端的开发者，我们在接入「安全网关」后，可以充分利用网关转发请求的附加信息，比如请求来源小程序appid、用户openid、用户unionid、用户风险标识等等，根据这些网关标记结合自身业务需求予以处理。

你可以在服务端对「安全网关」转发流量以外的其他流量设置限制访问，只接受「安全网关」的IP发过来的请求，将自己服务器隐藏在安全网关后面，更加安全；也可以设置其他更丰富化的防护策略，一切自由决定。

如何接入安全网关？

目前网关控制台（请在 PC 端访问：https://dev.weixin.qq.com/console/gateway ）已支持自助接入。

我们针对微信小程序提供一键接入方式，你可以无需任何代码改动和版本发布就可以体验。支持全量、URL灰度、用户灰度等策略，体验出现问题也支持一键断连。

针对其他客户端，如WEB、H5、PC端场景，也提供手动接入方案。

我们还推出了系列视频课程，全面讲解「安全网关」的各方面使用细节，让开发者上手更容易：微信网关系列课程

如果你有企业级版本（预期 >1000 QPS）的接入需求，请邮件联系我们专业对接：donut@tencent.com