本文主要是介绍网络攻防丨人机识别与应用安全的血泪发展史！，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
说到人机识别， 大家首先联想到的 可能是人工智能。
但是，今天我们要聊的 不是人工智能， 也不是机器学习，而是人机识别在应用安全中的应用（有点绕）
首先我们说说啥是人机识别……
What is 人机识别？
黑客，在大多数人心中是一种神秘的存在。你们想象中的他们可能是这样的：
（敲什么不重要，重要的是背景很黑，看起来就很厉害……）
或者是这样的：
（编剧对CTF和电子竞技游戏的关系可能有某种误解……）
看得人心潮澎湃，有没有？
心想我要有这技术就好了，是不是？
但真实的情况并不是这样。
现实中的黑客在攻击前一般需要先收集目标信息并对目标进行系统分析；而收集信息和发起攻击都离不开机器或工具。
根据Distil Networks发布的报告显示，机器流量约占全网流量的40%，其中恶意机器流量约占20%。
既然黑客攻击离不开工具，那么我们就有识别工具的必要性。
多选题：人机识别就是用来识别：
A. 真实客户端(比如浏览器)还是机器(比如工具)
B. 是一类进行问答式身份验证的安全措施
C. 区别发起请求的是真实用户还是不怀好意的攻击者
答案：ABC
Why we need 人机识别？
在网络安全领域中，爬虫、扫描、暴力破解、DDoS等多种攻击行为，都是通过工具发起的。
操纵者预设指令，由工具去自动执行任务。
在进行全局分析时，我们可以认为这些操作都是恶意的且应被阻断的；然而单独来看，每一个操作又是合理正常且没有任何攻击特征的。但是，没有攻击特征不代表无法识别。
这些针对业务发起的定制攻击，绝大多数来自于自动化工具，或者说机器人。
如何区分一个请求的发起者是人还是机器？这就是人机识别的重要意义。
How to 人机识别？
对于机器发起的请求，除了直接拦截之外，还可以返回机器不理解的信息，让机器无法进行下一步，从而达到防御的目的。
我们不妨先对比下机器的特点，大多数情况下，机器只能按照预设的指定执行，不能处理预设以外的交互信息。
比如小区管理，正常情况下业主刷卡就能进；但如果小偷捡到卡了也可以进入小区。
但如果某一天，保安要求说出房号姓名电话号码时，只凭卡就进不去了。
再比如某一天，物业对每个业主都设置了某种标记，如果不知道这个标记，当然也不能进入。
基于以上说到的这些特点，接下来我们聊聊识别机器的方法有哪些。
方法一：验证码
最常见也最传统的方法就是图形化验证码识别
早期的时候，这个方法确实很有效。一般的工具不理解，也不会主动输入验证码进行校验；
虽然它仍然是目前被普遍使用的验证方法但随着打码平台的出现，这种简单的验证码识别其适用的范围变得越来越小。
另一种是创新的交互优化型验证码，它充分利用了人机之间知识的差异性通过人类可以解答而机器难以解答的问题进行人机判断。
比如12306的验证码
近年来还出现了无知识型验证码，其最大的特点是不再基于知识进行人机判断，而是基于人类固有的生物特征以及操作的环境信息进行综合判断。
例如Google的新版ReCaptcha
方法二：动态令牌
除了验证码识别，动态令牌也可以应用于人机识别。动态令牌可用于身份验证，有的工具在收到令牌后不会再带着令牌访问从而被识别出来；
同时令牌可有效防止请求重放等非法操作；请求会根据上一个操作，动态生成每个请求唯一的令牌；
一旦令牌为空、重复使用或者被篡改就会被视为无效请求而被拦截。
方法三：混淆、封装（加密）、动态验证
Web应用存在较多敏感信息，如页面内容、JS源代码、后续链接、表单信息等。
它们构成了一个应用的运行逻辑。只要能够判断这种逻辑，应用行为就是可以预测的，这也是爬虫、扫描器等工具运作的基本原理。
对应用页面的源代码进行混淆或加密，工具并不能正常解析混淆后的内容，很大程度上能使工具失去作用。
对于具备JS解析能力的机器行为，还可以采用动态验证的方式来识别。
动态验证会校验JS的实际运行环境，获取设备指纹，采集客户端行为，例如是否有键盘鼠标操作以及在页面停留时间等。
通过多维度数据分析，区分操作的是人还是机器。
这一步本身不是用于识别工具行为，却可以有效防御借助工具进行的中间人攻击等行为。
方法四：风险控制
-检测到您本次操作存在风险，操作被拒绝
当我们的业务越来越大，并且面向的用户越来越复杂的时候，上面我们提到的这些简单的规则很难应付业务或用户的复杂多变。
这时候就需要通过数据分析的方式，来动态的、实时的调整我们的规则和处理方式，以及提供风险分析、预测等功能。这时候我们可能需要有一个独立的风控服务。
做过支付业务的小伙伴可能会接触的比较多，支付风控十分繁杂，防控规则策略可达上千条，甚至上万条。
那我们看到上面有看到，针对不同的模板的场景来确定风险等级，然后来做不同的操作，这块其实就涉及到风控相关了。只是比较初级，比如风险等级如何确定？每个风险等级需要做什么样的事情？如何进行动态的配置等等。
举个栗子：
- 我们可以收集用户的行为轨迹（注册时间、登录次数、页面访问情况等）来分析一个用户，确定用户的风险等级，再决定他可以执行那些操作。
- 根据模板的历史趋势，来自动判断相应短信模板的合理范围，如果达到上限，则认为存在风险操作，可以做对应的处理。
- 配置相应的规则，如果某个设备在单位时间内重复N次发送请求操作，并都无反馈结果，则认为存在风险。
- 等等
这样的风控还适用于发送短信验证的风险识别，包括注册、登录、支付操作等等。毕竟发送短信验证码是需要一定费用的，这和产品利益直接挂钩，一个好的风控系统十分必要。当然，这也不是一蹴而就的，需要长时间的积累和建设。
比如上面说到的用户行为轨迹和模板趋势，都需要有全面的埋点和数据平台作为支撑。还有如果业务要求比较高，还需要开发适合自己业务的规则引擎。但是当风控系统建设起来之后，效果也是明显的！
当然，风控服务并非无可参考，国内就有公司一直致力于支付风控服务研究，对于风控业务颇为熟悉。再经过长时间试验，推出了短信风控服务——短信风控防火墙。
总结一下
以上几种方法都有其使用的场景，但也有自身的局限性。我们可以根据业务情况以及风险程度来选择使用，已达到更好的识别和防护效果。
安全无大小，防护需谨慎。
>> 相关阅读
《风控防火墙使用教程》
这篇关于网络攻防丨人机识别与应用安全的血泪发展史！的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
