如何做网站的逻辑结构图,如何快速做一个网站,58同城推广效果怎么样,个人外贸网站在电商行业#xff0c;线上的营销活动特别多。在移动互联网时代#xff0c;一般为了活动的快速上线和内容的即时更新#xff0c;大部分的业务场景仍然通过 Web 页面来承载。但由于 Web 页面天生“环境透明”#xff0c;相较于移动客户端页面在安全性上存在更大的挑战。本文… 在电商行业线上的营销活动特别多。在移动互联网时代一般为了活动的快速上线和内容的即时更新大部分的业务场景仍然通过 Web 页面来承载。但由于 Web 页面天生“环境透明”相较于移动客户端页面在安全性上存在更大的挑战。本文主要以移动端 Web 页面为基础来讲述如何提升页面安全性。 活动 Web 页面的安全挑战 对于营销活动类的 Web 页面领券、领红包、抽奖等活动方式很常见。此类活动对于普通用户来说大多数时候就是“拼手气”而对于非正常用户来说可以通过直接刷活动 API 接口的“作弊”方式来提升“手气”。这样的话对普通用户来说就变得很不公平。 对于活动运营的主办方来说如果风控措施做的不好这类刷接口的“拼手气”方式可能会对企业造成较大的损失。如本来计划按 7 天发放的红包在上线 1 天就被刷光了活动的营销成本就会被意外提升。主办方想发放给用户的满减券、红包却大部分被黄牛使用自动脚本刷走而真正想参与活动的用却无法享受活动优惠。 终端用户到底是人还是机器网络请求是否为真实用户发起是否存在安全漏洞并且已被“羊毛党”恶意利用等等这些都是运营主办方要担心的问题。 安全防范的基本流程 为了提升活动 Web 页面的安全性通常会引入专业的风控服务。引入风控服务后安全防护的流程大致如图所示。 Web 前端用户通过 Web 页面来参与活动同时 Web 前端也会收集用于人机识别验证的用户交互行为数据。由于不同终端移动端 H5 页面和 PC 端页面交互形式不同收集用户交互行为数据的侧重点也会有所不同。风控服务一般大公司都会有专业的风控团队来提供风控服务在美团内部有智能反爬系统来基于地理位置、IP地址等大数据来提供频次限制、黑白名单限制等常规的基础风控拦截服务。甚至还有依托于海量的全业务场景的用户大数据使用贝叶斯模型、神经网络等来构建专业度较深的服务。风控服务可以为 Web 前端提供通用的独立验证 SDK验证码、滑块验证等区分人机的“图灵验证”也可以为服务端提供 Web API 接口的验证等。后端业务服务负责处理活动业务逻辑如给用户发券、发红包处理用户抽奖等。请求需要经过风控服务的验证确保其安全性然后再来处理实际业务逻辑通常在处理完实际业务逻辑时还会有针对业务本身的风控防范。对于活动 Web 页面来说加入的风控服务主要为了做人机识别验证。在人机识别验证的专业领域上我们可以先看看业界巨头 Google 是怎么做的。 Google 如何处理人机验证 Google 使用的人机验证服务是著名的 reCAPTCHACompletely Automated Public Turing Test To Tell Computers and Humans Apart区分人机的全自动图灵测试系统也是应用最广的验证码系统。早年的 reCAPTCHA 验证码是这样的 如今的 reCAPTCHA 已经不再需要人工输入难以识别的字符它会检测用户的终端环境追踪用户的鼠标轨迹只需用户点击“我不是机器人”就能进行人机验证reCAPTCHA骗用户进行数据标注而进行AI训练的验证另说。 reCAPTCHA 的验证方式从早先的输入字符到现在的轻点按钮在用户体验上有了较大的提升。 而在活动场景中引入人机识别验证如果只是简单粗暴地增加验证码或者只是像 reCAPTCHA 那样增加点击“我不是机器人”的验证都会牺牲用户体验降低用户参加活动的积极性。 Google 的普通 Web 页面的浏览和有强交互的活动 Web 页面虽是不同的业务场景但对于活动 Web 页面来说强交互恰好为人机识别验证提供了用户交互行为数据收集的契机。 人机识别验证的技术挑战 理想的方案是在用户无感知的情况下做人机识别验证这样既确保了安全又对用户体验无损伤。 从实际的业务场景出发再结合 Web 本身的环境如果想实现理想的方案可能会面临如下的技术挑战 1需要根据用户的使用场景来定制人机识别验证的算法Web 前端负责收集、上报用户交互行为数据风控服务端校验上报的数据是否符合正常的用户行为逻辑。2确保 Web 前端和风控服务端之间通信和数据传输的安全性。3确保上述两大挑战中提到的逻辑和算法不会被代码反编译来破解。在上述的三个挑战中1已经实现了人机识别验证的功能而2和3都是为了确保人机识别验证不被破解而做的安全防范。接下来本文会分别针对这三个技术挑战来说明如何设计技术方案。 挑战一根据用户使用场景来定制人机识别验证算法 先来分析一下用户的使用场景正常用户参与活动的步骤是用户进入活动页面后会有短暂的停留然后点击按钮参与活动。这里所说的“参与活动”最终都会在活动页面发起一个接口的请求。如果是非正常用户可以直接跳过以上的实际动作而去直接请求参与活动的接口。 那么区别于正常用户和非正常用户就是那些被跳过的动作对实际动作进一步归纳如下 进入页面。短暂的停留。滚动页面。点击按钮。以上的动作又可以分为必需的操作和可选的操作。对这一连串动作产生的日志数据进行收集在请求参与活动的接口时将这些数据提交至后端验证其合法性。这就是一个简单的人机识别验证。 在验证动作的合法性时需要考虑到这些动作数据是不是能被轻易模拟。另外动作的发生应该有一条时间线可以给每个动作都增加一个时间戳比如点击按钮肯定是在进入页面之后发生的。 一些特定的动作的日志数据也会有合理的区间进入页面的动作如果以 JS 资源加载的时间为基准那么加载时间可能大于 100 毫秒小于 5 秒。而对于移动端的按钮点击点击时记录的坐标值也会有对应的合理区间这些合理的区间会根据实际的环境和情况来进行设置。 除此之外设备环境的数据也可以进行收集包括用户参与活动时使用的终端类型、浏览器的类型、浏览器是否为客户端的容器等如果使用了客户端客户端是否会携带特殊的标识等。 最后还可以收集一些“无效”的数据这些数据用于障人耳目验证算法会将其忽略。尽管收集数据的动作是透明的但是验证数据合法性不是透明的攻击者无法知道验证的算法中怎么区分哪些是有效、哪些是无效。这已经有点“蜜罐数据”的意思了。 挑战二确保通信的安全性 收集的敏感数据要发送给风控服务端进而确保通信过程的安全。 Web API 接口不能被中途拦截和篡改通信协议使用 HTTPS 是最基本的要求同时还要让服务端生成唯一的 Token在通信过程中都要携带该 Token。接口携带的敏感数据不能是明文的敏感数据要进行加密这样攻击者无法通过网络抓包来详细了解敏感数据的内容。Token 的设计 Token 是一个简短的字符串主要为了确保通信的安全。用户进入活动 Web 页面后请求参与活动的接口之前会从服务端获取 Token。该 Token 的生成算法要确保 Token 的唯一性通过接口或 Cookie 传递给前端然后前端在真正请求参与活动的接口时需要带上该 Token风控服务端需要验证 Token 的合法性。也就是说Token 由服务端生成传给前端前端再原封不动的回传给服务端。一旦加入了 Token 的步骤攻击者就不能直接去请求参与活动的接口了。 Token 由风控服务端基于用户的身份根据一定的算法来生成无法伪造为了提升安全等级Token 需要具有时效性比如 10 分钟。可以使用 Redis 这类缓存服务来存储 Token使用用户身份标识和 Token 建立 KV 映射表并设置过期时间为 10 分钟。 虽然前端在 Cookie 中可以获取到 Token但是前端不能对 Token 做持久化的缓存。一旦在 Cookie 中获取到了 Token那么前端可以立即从 Cookie 中删除该 Token这样能尽量确保 Token 的安全性和时效性。Token 存储在 Redis 中也不会因为用户在参与活动时频繁的切换页面请求而对服务造成太大的压力。 另外Token 还可以有更多的用处 标识参与活动用户的有效性。敏感数据对称加密时生成动态密钥。API 接口的数字签名。敏感数据加密 通信时传递的敏感数据可以使用常见的对称加密算法进行加密。 为了提升加密的安全等级加密时的密钥可以动态生成前端和风控服务端约定好动态密钥的生成规则即可。加密的算法和密钥也要确保不被暴露。 通过对敏感数据加密攻击者在不了解敏感数据内容的前提下就更别提模拟构造请求内容了。 挑战三化解纸老虎的尴尬 有经验的 Web 开发者看到这里可能已经开始质疑了在透明的前端环境中折腾安全不是白折腾吗这就好比费了很大的劲却只是造了一个“纸老虎”质疑是有道理的但是且慢通过一些安全机制的加强是可以让“纸老虎”尽可能的逼真。 本文一再提及的 Web 环境的透明性是因为在实际的生产环境中的问题前端的代码在压缩后通过使用浏览器自带的格式化工具和断点工具仍然具备一定的可读性花点时间仍然可以理解代码的逻辑这就给攻击者提供了大好的代码反编译机会。 如果要化解“纸老虎”的尴尬就要对前端的代码进行混淆。 前端代码混淆 前端的 JS 代码压缩工具基本都是对变量、函数名称等进行缩短压缩对于混淆的作用是比较弱。除了对代码进行压缩还需要进行专门的混淆。 对代码进行混淆可以降低可读性混淆工具有条件的话最好自研开源的工具要慎用。或者基于 Uglify.js 来自定义混淆的规则混淆程度越高可读性就越低。 代码混淆也需要把握一个度太复杂的混淆可能会让代码无法运行也有可能会影响本身的执行效率。同时还需要兼顾混淆后的代码体积混淆前后的体积不能有太大的差距合理的混淆程度很重要。 断点工具的防范会更麻烦些。在使用断点工具时通常都会导致代码延迟执行而正常的业务逻辑都会立即执行这是一个可以利用的点可以考虑在代码执行间隔上来防范断点工具。 通过代码混淆和对代码进行特殊的处理可以让格式化工具和断点工具变得没有用武之地。唯一有些小遗憾就是处理后的代码也不能正常使用 Source Map 的功能了。 有了代码混淆反编译的成本会非常高这样“纸老虎”已经变得很逼真了。 技术方案设计 在讲解完如何解决关键的技术挑战后就可以把相应的方案串起来然后设计成一套可以实施的技术方案了。相对理想的技术方案架构图如下 下面会按步骤来讲解技术方案的处理流程 Step 0 基础风控拦截 基础风控拦截是上面提到的频次、名单等的拦截限制在 Nginx 层就能直接实施拦截。如果发现是恶意请求直接将请求过滤返回 403这是初步的拦截用户在请求 Web 页面的时候就开始起作用了。 Step 1 风控服务端生成 Token 后传给前端 Step 0 可能还没进入到活动 Web 页面进入活动 Web 页面后才真正开始人机识别验证的流程前端会先开始获取 Token。 Step 2 前端生成敏感数据 敏感数据应包含用户交互行为数据、设备环境数据、活动业务逻辑数据以及无效数据。 Step 3 使用 HTTPS 的签名接口发送数据 Token 可以作为 Authorization 的值添加到 Header 中数据接口的签名可以有效防止 CSRF 的攻击。 Step 4 数据接口的校验 风控服务端收到请求后会先验证数据接口签名中的 Token 是否有效。验证完 Token才会对敏感数据进行解密。数据解密成功再进一步对人机识别的数据合法性进行校验。 Step 5 业务逻辑的处理 前面的步骤为了做人机识别验证这些验证不涉及到业务逻辑。在所有这些验证都通过后后端业务服务才会开始处理实际的活动业务逻辑。处理完活动业务逻辑最终才会返回用户参与活动的结果。 总结 为了提升活动 Web 页面的安全性使用了各种各样的技术方案我们将这些技术方案组合起来才能发挥安全防范的作用如果其中某个环节处理不当都可能会被当作漏洞来利用从而导致整个验证方案被攻破。 为了验证技术方案的有效性可以持续观察活动 API 接口的请求成功率。从请求成功率的数据中进一步分析“误伤”和“拦截”的数据以进一步确定是否要对方案进行调优。 通过上述的人机识别验证的组合方案可以大幅提升活动 Web 页面的安全性。在活动 Web 页面应作为一个标准化的安全防范流程除了美团像淘宝和天猫也有类似的流程。由于活动运营的环节和方法多且复杂仅仅提升了 Web 页面也不敢保证就是铁板一块安全需要关注的环节还很多安全攻防是一项长期的“拉锯升级战”安全防范措施也需要持续地优化升级。 参考资料 https://www.google.com/recaptcha/intro/v3.htmlhttps://segmentfault.com/a/1190000006226236https://www.freebuf.com/articles/web/102269.html作者简介 益国美团点评 Web 前端开发工程师。2015年加入美团曾先后负责过风控前端SDK和活动运营平台的研发现负责大数据平台的研发工作。
