2022 SDC 议题回顾 | 从应用场景看金融安全 — 逻辑为王 - 网络安全

#2022 SDC 议题回顾 6个

在金融行业严格且特殊的安全体系下，尽管绝大多数漏洞都能被第一时间定位及修复。但”人性的弱点“使金融行业的不可控风险不再局限于钓鱼，隐蔽的逻辑漏洞正在悄无声息的成为风险“顶流”。试想如果攻击者通过一个逻辑漏洞转走钱，没有安全设备会告警，所有流量都”正常“，等到财务清账发现异常为时已晚。企业和白帽子在寻找逻辑漏洞中往往都是点对点测试，没有系统性渗透方法。导致逻辑漏洞测试不全面或没有测试思路，研发在修复时也无法理解错误逻辑本身大大增加漏洞修复难度和业务风险。

本议题站在应用场景这个宏观视角，从研发底层思维出发去探索金融安全下的逻辑漏洞测试方法论，让逻辑漏洞无所遁形。

下面就让我们来回顾【看雪第六届安全开发者峰会】上《从应用场景看金融安全 — 逻辑为王》的精彩内容。

演讲嘉宾

【蔡致远：安恒信息雷神众测-安全专家】

Poc Sir，法国大学在读，主攻金融安全研究。目前雷神众测总排名第一，微博SRC安全专家。PackerFuzzer工具主创成员、Hack Inn社区运营者。

演讲内容

以下为速记全文：

各位看雪峰会线上线下的观众朋友们，大家下午好，我是安恒信息雷神众测的蔡致远。今天为大家带来的议题是《从应用场景看金融安全逻辑为王》。我是雷神众测的安全研究员，同时也是Hack Inn安全议题分享平台的运营者，我会将国内外所有的峰会会议的议题都分享在我的Hack Inn官网上，同时我也是国内第一个深入研究各大应用小程序安全的研究员，《微信小程序渗透脉》便是我的文章之一。

接着我们来聊一聊金融安全的现状。

首先金融安全会有很多层防御，第一部分比如说我们常见的手段就是加固，当安全厂商拿到我们金融公司提供的客户端以后，他会第一时间去做一个加固的处理，加固的处理可以有效的防止一部分人对他的软件进行反调试，或者进行一些逆向分析操作。

第二部分是加密，我们的金融客户端基本上都采用了自研的或者说是依据于国密sm4或者aes\rsa等的各种加密方法，对数据的 web的传输层，包括说底层的一些用户凭证的算法都进行了一个加密，它的客户端与服务端之间都是双向加密的这么一个操作。

第三部分是安全设备，我们知道金融厂商都是特别有钱的，愿意去买各种各样的安全设备部署部署在自己的服务器中，那么这三个门槛可以抵挡住大部分的攻击者，抵挡住大部分的黑产用户，但同时也抵挡住了自己金融公司内部的，或者说是我们一些安服团队的初级\中级的一些测试人员，所以导致我们整一个金融系统，实际上有些时候是没有办法做一个全面深入的探测的。

一但这三道防线被攻破，那么后面可能就有各种各样的漏洞都存在。金融安全看似道道防护，实则可能仍非常容易被攻破。接着我们将安全设备单独来讲，安全设备它可以抵御一些异常的攻击流量，比如说我们发送一个SQL注入命令到我们的服务器，那么我们的设备可以马上的将这一个请求给阻断掉。

接着我们再来把加密这一部分拿出来再单独讲一下。如果说我们一个用户发送了正常的数据，客户端会对其进行一个加密操作，然后将加密的密文传输给服务端。

那么当一个攻击者，如果说他发送一个恶意的SQL注入命令，也会被客户端进行一个加密，加密之后传输到服务器当中，那么当这两种安全防护措施合在一起，当安全设备开始拦截异常流量，当加密门槛开始进行所有数据的加密防护的时候，我们可以看到在原本的情况下，数据是会被拦截的，但是如果说一个攻击请求进行了加密之后，一些WAF并没有办法很好的对这些数据进行一个拦截，所以导致我们一但攻破了客户端一些加密的限制的时候，我们可以进行任意的一个攻击操作，可能在WAF层面可能根本就无法触发任何的异常告警。

可能说你一个网站已经被黑完了，或者说别人已经拿到你OA客户端破解完了以后，在里面进行了一大堆数据库操作以后，你WAF层面一点流量感知都没有，你可能最后需要通过一些数据库审计的产品才能发现这些异常请求。

随后我们再来聊一聊金融数据安全，金融行业它可能会有各种各样的数据接入接出，比如说银行，它需要对接人行，对接一些政策性银行，或者对接国际的一些比如说像Swift的一些支付系统，但他可能也要对接一些地方行，对接一些高端用户私人银行的一些客户权益系统，对接来对接去，它本身是一个非常大量的隐形的开放平台, 他的数据在各个层面进行一个交互，可能你银行本身没有漏洞，但是你把这个数据开放给了你的供应商，你的供应商没有防护，导致你整一条安全措施都是白做。

我们接着讲一讲渗透测试人员再加上一个获取不到账户的系统，是不是等于没有漏洞？肯定不是。但是在我们一些传统的渗透测试过程中，如果说我们没有获取到账号，没有办法对这个系统进行一个深入的测试，那么我们只能给出一个无漏洞的这么一个渗透测试报告，但是实际情况往往是比如说像一些企业网银系统，IPO系统一些私募系统这种系统，我们的确很难拿到账号，但是比如说像企业网银系统，我们自己注册一个空壳公司，那么我们再去进行一个柜台的交易开户，我们还是有可能拿到这些账户的一些权限账号，然后接着我们再去测，这些系统往往都是漏洞，所以说系统漏洞的挖掘难度与测试的次数成正比，也与账户权限获取的难度成正比。账户获取的难度越难，它隐藏的漏洞可能就更深更多。

我们聊完安全现状，我们再回归到主题，我们来聊一聊什么是应用场景。说到应用场景，我先给应用场景做一个简单的分类，第一类叫功能场景，功能场景它有单一性、模块化性和可视化性，比如说像我们的存款、取款、买入、买出，这些都是一个用户在操作时期的功能场景。

还有一类是安全场景，安全场景与功能场景不同的，它有可能是不可见的，你比如说风控场景，但是它有一个叫应用操作周期跟随性，它是用户打开了APP以后，安全场景一直是跟随用户的，比如它的风控参数，它会一直跟随用户，比如说用户做一个转账操作，它里面就会触发短信验证码或者说是人脸识别的这些安全场景。

那么接着我们来聊一聊传统安全测试，我们可以看到传统安全测试它是从漏洞类型出发的，比如说我今天要对一个网站进行一个渗透，或者我要对一个金融客户端进行一些渗透，我会做什么，我会去找他有没有SQL注入，不知道他有没有XSS漏洞，有没有信息泄露，有没有一些常见的按漏洞类型去挖掘这些漏洞，传统漏洞它的测试链路是这样子的，先找应用，再找对应的功能点，再找不同类型的漏洞去进行一个测试。

如果说我找到一个功能点，我先测SQL注入，测出来有注入，那么我再换另外一个漏洞类型测试，我继续去测试，这样优点是有的，它可以测得非常全面，我可以漏洞类型一个个的去测过去，但是我只是在一个具体的功能点上去测试，我虽然这个功能点可以测得很全面，我也可以是测得很灵活，但是我们应用里功能点有非常多，我们很容易遗漏掉一个或者多个在应用场景下的这些功能点，我们功能点可能测不全，而且我们因为要一个个漏洞类型去测过去，我们其实工作量是非常大的，我们需要测很多的漏洞类型，同时我们缺乏一个整体的测试逻辑性，我们只能站在单一的一个功能点去测试这些漏洞，那么接着思考，一个个功能点在一起，功能点多了，它就变成了一个应用场景。

所以如果说我们以应用场景的方向去测试，那么它的测试链路就会改变，它并不是在按照漏洞类型去做一个测试。

首先我们先找到应用，然后再找到对应应用中的场景，比如说支付场景，找到支付场景以后，我们去按对应应用场景的漏洞进行测试，对应的漏洞，我们可以看到最下面这一行字，应用场场景产生特定漏洞，比如说我们来到支付场景，它可能会存在比如说越权多取别人的钱的这一些只在这个场景下出现的这些漏洞，然后我们去测试这些漏洞是否存在，我们去找到对应的漏洞产出，这样做的优点有什么？

首先它针对性强，可以模块化的展开一些详细的测试，并且涵盖所有场景内的功能点，它不遗不容易遗漏一些细节。

其次它因为是基于场景出发，它不是一个点去测它有一个整体的逻辑性，可以排除因为渗透测试人员能力的干扰所带来的测试结果不同，可以有效的保证一个测试效果，而且他的经验都是可以一代一代的流传下去的，可以总结成一个模板。

那么有可能有人会问说为什么应用场景会产生特定的漏洞，为什么呢？从要探讨这个问题，我们需要从底层的逻辑思维来想，想研发之所想，开发一个新的场景，有不同的功能点，功能点的组合形式不同，便产生了不同的漏洞。要开发一个新的场景，需要构思代码的运行步骤，步骤间逻辑的不缜密，便产生了不同的漏洞。

那么我们现在以存款场景为例，我们来详细的展开讲一讲，以应用场景的开发逻辑进行思考。

首先在存款证明这个场景下，用户的操作流程是这样的，首先它需要进入这个场景，然后选择要开冻结或者非冻结证明的存款证明，然后选择要开具的银行卡，然后选择要开立的金额，然后选择需要纸质凭证或者说是要电子凭证，最后收到存款证明文件。

但是在开发的这一个过程中就非常的复杂了，它首先需要查询用户的状态，用户银行的账户是否异常，是否被冻结，以及他也买了哪些理财产品，理财产品里有多少钱，然后他的银行卡的可用余额是多少，然后获取用户的开立金额，接着他要查询用户是要冻结资产的开立，还是需要不冻结资产的开立，然后再生成一个电子的资产证明，最后判断用户最终是想要电子，还是说想要纸质的一个证明，然后再去确认用户的邮箱，或者说是他的实际的收件地址，然后最后再结算这个邮件的费用，包括说开立证明的费用，最后再将用户证明发送给用户。

那么如果说我们以功能点进行测试，我们单看每一个功能点，我们可以看到第一个功能点，它可能存在越权查询他人账户信息，账户ID或者说存在一个SQL注入，如果我们单看第二个功能点，它可能存在越权查询他人银行卡余额，银行卡卡号参数进行一个SQL注入的这么一个漏洞。

然后我们再来看第七点，它可能会比如说存在快递地址的这么一个XSS漏洞，然后再看第九点，第九点它可以比如说越权查询别人的存款证明，查看别人的存款地址这样一些漏洞存在。

但是如果说我们以多个功能点相结合，我们可以看到一些全新的逻辑漏洞在里面，比如说将第二个功能点第加第三个功能点，再加第四个功能点，我们可以看到可能会存在，比如说冻结财产金额大于可用资金金额或者冻结财产金额，小于可用开立金额的这么一些逻辑漏洞，将第二个功能点加第三个功能点再加第五个功能点，我们可能会产生一些比如说像电子资产证明金额大于可用账户金额的这么一个漏洞。

如果说我们将第六个第七个第八个功能点加在一起，我们可能会产生通过电子纸质证明的金额差异，来达到开立金额的这么一个异常金额的信息，我们可以非常低价或者说是0元钱的方式，将原来比如说要收取15块快递费的这么一个开立流程。直接变成免费开率的这么一个逻辑漏洞的存在。

如果说我们将第五个第九个功能点结合在一起，我们可以使用异常账户进行一个开立金额，比如说一个账户已经被银行冻结了，但是我绕过了这几个点，我还照样可以开出一个资产证明来用。

那么还有一种特殊情况，比如说监管机构需要你在开立的这么一个流程中加入一个验证，安全验证的场景，那么很多时候我们会选择加入一个短信验证码场景，在其中作为一个安全的校验，那么它的整一个开发流程就变了，它在第九部多加了一个短信验证码校验的场景，那么在这种情况下会产生什么漏洞，我们可以看到短信验证码场景前提它是没有漏洞的，如果你输入正确的验证码，它会给你放行，如果你输入错误的验证码，它就给你返回一个报错值，后面的步骤就不再继续运行下去了。

但是如果说我是一个黑客，我会怎么测试？我会尝试去跳过第九个步骤，那么当我成功跳过了第九个步骤，这一个被新加入的验证流程就不存在意义了，我可以直接跳过验证码，来实现一个达到直接开立存款证明的一个目的。那么这为什么会产生这样一个漏洞？我们可以看到单独看第九个场景的确是没有问题的，在原有的场景中却又存在了漏洞，这是因为原研发在原有的开发逻辑上直接加入了这个短信验证码校验的逻辑，但却没有修改第十处的这么一个逻辑去判断，是否已经通过第九个步骤的这一个验证码的判断，它只是单单的将验证码作为一个安全场景，安全功能加入到了其中，所以说我们在上下步骤中的每一步的逻辑校验都是非常关键的。

每一次对应用场景的一个改动都需要重新校验整一个场景中所有的关联逻辑，才能确保你不会有任何逻辑漏洞的产生。不然如果说你单独直接强硬地，加一个功能进去或者加一个场景进去，很容易造成一些逻辑漏洞的突破。

接着我们分享一些真实案例给大家。首先给大家举一些安全场景的应用案例，在安全场景中我们可以看到它整体的这样一个逻辑是这样的，用户操作了某一个功能在一个场景中，然后它会触发这样一个安全场景，因为它有应用操作周期供给性，所以说会触发这样一个操作，那么当用户通过了安全校验之后，客户端程序会进行一个放行，然后让用户进行后续的操作步骤，如果说用户没有通过安全场景校验，那么这个功能就会被暂时应禁用。

安全场景是为阻止恶意操作者攻击用户，攻击系统产品功能，保障用户信息财产不受到侵犯的这么一个路障。那么我们针对这一类类型的安全场景的测试，我们需要做的是什么？它的测试逻辑其实非常简单，一切都是为了绕过路障，我们只要把安全场景给干掉了，我们不管怎么样干掉，都算是成功突破了这一个限制。

那么首先我们来到第一个真实案例的一个讲解，我们来到的是一个风控场景，在风控场景中我们可以看到大家非常熟悉，不过如果说你在进行一个银行的异常交易，或者说你的设备已经root过了或者一些hook过了，或者说你的设备存在一些其他不稳定的因素，比如说涉及一些洗钱或者一些其他的信息，你的账户在转账的时候可能就会被风控拦截，风控不让你把这一笔钱给转出去。

我们抓一下它的数据包，我们可以非常清楚的看到，它的数据包里面，post的里面有一个叫riskflag的这么一个参数，那么我们想到如果把riskflag的参数值，我们给他清空，我们重新进行一个发包，我们会发现成功的通过了这一个风控校验，这就是第一个点，不给风控参数，等于没有风控，它就默认不会触发一个风控机制。

我们再来看第二个案例，在第二个案例中，我们可以看到里面有一个叫riskdoc的参数值，经过分析，我们发现是程序客户端经过AES加密之后生成的一个风控数据，我们将数据解压还原以后，我们发现他有一个叫prdToken，还有一些设备的device id、device info的这么一些信息，那么prdToken这一个值是每一次进行一个API请求以后，API服务器会返回的这么一个token值，它是会一直变的，它会根据用户的风险等级返回不同的值，然后根据token再去判断用户是否处在一个被风控或者需要风控的这么一个流程中。

那么之后我们针对这一套风控体系编写一个脚本，我们购买了一部新的手机新的设备，然后用一个全新注册的银行账户，我们固定给他，我们将其中的risk token给它提取出来，然后通过一个脚本一直生成这样一个固定的token值，然后进行给我们的攻击设备进行使用，然后全程，我们在整一个测试的流程中都没有触发过任何的风控，没有固定风控参数等于一片祥和。

这时我们来讲另外一个场景，大家可以看到在这个场景下它触发了风控场景，它需要进行一个身份验证，它需要你输入当前资金的这么一个密码，对于黑产来说这是一件坏事，但是对于我们来说，实际上这是一个好事。

为什么这样说？因为如果说我们触发了这么一个新的功能，我们就可以多测一个漏洞点，我们有可能就会发现新的漏洞。那么事实的确是如此，我们在输入了当前的账户密码一个假的密码之后，不论这个密码是否成功，它都会返回当前账户的这么一个完整信息，它存在一个信息泄露的这么一个漏洞，我们就成功发现了这么一个新的漏洞存在。

接着我们来讲一讲人脸识别场景，人脸识别场景分为客户端和服务端，我们先来讲客户端的这么一个降维打击。在客户端大家可以看到这是一个人脸识别，这是我自己的照片。然后我们进行一个hook，我们发现当前的activity是一个某人脸识别厂商提供的这么一个SDK，然后我们再去分析 Sdk。我忘了讲一点，上面有行字叫请眨眨眼，他让你进行一个眨眼的这么一个活体校验操作。

那么我们继续去找这个里面的class，我们发现有一个class特别的神奇，它叫Eye close，那么Eye close马上就关联到了，请眨眨眼，然后我们继续去分析，它的确是里面有很多的功能在判断你是否眨眼，判断你Eye close是否通过验证还有一些对比的这么一个方法，那么很简单我们直接上frida，我们将所有的这些方法的返回值，我们要么干成100，要么我们给它返回一个q的值，然后我们进行一个操作，我们直接使用一张电脑上静态的照片，直接绕过了人脸识别的活体校验，通过了整一个人脸识别的流程。

我们再来聊一聊服务端的这么一个漏洞。首先同样是人脸识别场景，然后这一次不一样，这一次我们用本人的人脸识别进行一个正常的人脸识别操作，他让我们眨眼我们就眨眼，他让我们点头，我们就去点头，然后我们去抓取服务器端的这么一个请求数据。我们可以看到数据中有两个值，一个是photo，一个是facedata，然后我们继续去分析，我们发现在 API中有这么两个值，photo值是base64编码之后的一个人脸的正脸比对正脸数据，然后我们可以将受害者的身份证上的照片我们截一个图，然后我们base64编码传输过去。

那么关于第二个参数叫facedata参数，facedata参数也是一段base64编码之后的数据，我们将它解码之后，我们发现它分为4个部分，第一个部分是用户眨眼时的照片，再加上眨眼时的脸部特征，然后还再加上用户微笑时的照片和用户微笑时的脸部合成参数。

那么很简单，我们将这两张照片直接都替换成用户动态的用户静态的这么一个正常的正脸的照片，我们进行一个测试。我们发现成功过了服务端的这么一个活体校验，我们可以使用三张完全一样的照片来进行一个人脸识别的操作。

其实我们来讲一个特殊的人脸识别，在一些特殊的场景下，比如说用户第一次开户，或者说用户可能要更新自己的存留身份的照片，所以导致一些金融系统不以用户储存到他们数据库的用户正脸的数据，或者说是公安的人脸识别仿照的这么一个结果，作为一个人脸对比的数据进行判断。

它的数据人脸判断从哪里来？他会默认从自己用户所上传的用户身份证照片而来，在他的心里，他可能觉得用户上传的身份证照片肯定是安全的，哪会有人去ps自己的身份证照片，所以说他会将这个照片上的人脸提取出来和用户的这么一个人脸进行对比，那么此时我们上传一张我们修改过之后的特殊照片，再加上对应照片的人脸进行一个对比，我们可以成功过掉人脸识别的校验。

我们来到一个UKEY场景，UKEY场景大家肯定不陌生，在一些比如说个人 PC端的网银的操作大额转账，或者说是在企业网银的一些登录的时候可能都会用到一个UKEY，我们前一段时间分析了一个UKEY，在UKEY的驱动进行启动之后，我们发现他在本地成功起了一个外部服务，一个非常高位的随机的外部服务，然后所有的我企业银行的交互都是通过外部服务来跟UKEY进行一个交互的。

然后我们去看一下它的这一个交互的这个APM，发现是一个JSONP的格式，说到JSONP，我们就想到CSRF漏洞。CSRF漏洞是通过referer这个参数来校验的，他判断你的referer是否在一个合法的值，如果不在一个合法的值，它应该返回一个错误的或者空内容的请求。

但是我们看到网银的UKEY的这么一个驱动，它并没有降于Free的来源的合法性。我们在本地取了一个Python的简易服务，我们去进行一个API的请求，我们发现照样可以调用操作来操作一个UKEY，那么这一个UKEY驱动的漏洞就秒变成了一个JSONP的漏洞，那么最后我们可以自己写一个脚本，然后利用csrf的基础，我们就可以直接调用UKEY驱动来实现跟UKEY进行所有的交互。

我们再来看到另外一块，功能场景下的漏洞，功能场景下有什么漏洞？首先我们可以看到比如说用户需要这些某个操作，它就会进入用户功能场景，然后在约束条件内它完成对应的操作。那么根据功能场景的不同，因为它灵活多样，所以说它的逻辑漏洞并没有限制，我们需要在对应的场景下去创造不同的漏洞，创造不同的漏洞组合。测试的逻辑也非常简单，我们需要突破系统约束的上限或者下限。

我们来举第一个例子，数字人民币场景，数字人民币是最近两年新兴的这么一个场景，它的业务构造也非常特殊，首先上接人民银行，它有数字人民币APP，下接十二大商业银行，这些十二大商业银行都有开设数字人民币钱包的这么一个权限，并且在它对应的客户端中有非常完整的数字人民币的一个操作功能。然后其他的一些地方性或者说一些其他商业银行，会接入这十二大行的数字人民币服务，对接其中的一家或者两家的数字人民币钱包，然后进行一些基础的功能，比如说提入银行卡、绑定银行卡，钱转入转出的这么一些基础功能。

那么说到这个数字人民币，我们就免不了说到它其中的一个概念叫钱包编号，它跟银行卡一样，它每一个数字人民币中都有一个钱包编号。那么钱包编号，它既然是ID值，它可能就会有越权漏洞存在。那么最简单的就是挖它这么一个越权漏洞。

接着我们再来看下一个案例，它在数字人民币中也会同样存在对公钱包或者对私钱包的这么一个案例。在对公钱包中我们遇到了这样一个场景，对公钱包它有一套自己的账户体系，你在绑定这个钱包之前需要进行一个不依赖于企业网银的客户端账户体系的一个单独的注册体系，我们需要进行一个注册，那么在注册的时候，我们可以将这个钱包的预留手机号篡改为我们自己的手机号，然后进行一个注册，这时候系统会判断你是否注册，我当时是用frida直接hook，然后我们成功强制重新注册上了这个数字人民币钱包的权限。

最后因为绑定的手机也是我们自己的，我们就直接进行转账操作就可以，我们成功管控了对公钱包，并成功将钱包里的钱转出来了。

我们再来聊对私钱包的这么一个案例，在对私钱包中我们首先是做一个基础的查询，然后我们获取到对应钱包的信息，然后它里面有一个支付密码的重置模块，我们发现特别有意思，但是这个重置密码它有一个钱包注册手机号，我发现是对应用户的这么一个手机号，我们将手机号篡改为我们自己的手机号，我们发现成功接收到了验证码，最后成功控制掉了手机，然后包括它人脸识别也是通过传入身份证进行一个人脸识别的，我传自己的身份证，我也成功通过了识别，然后成功获取了账户的权限。

之后我们再来讲一下在存款场景下会有哪些漏洞。如果说是存定期存款时间不变，那么我们就想要利率变高，如果说它的利率不变的前提下，我们就想要它的存款时间更短，更少的时间获得更多的利息。

那么我们就可以修改，比如说尝试修改它的利率，我们将它原来三个月月化的利率1.9，修改成77.7，然后我们进行发包，我们发现成功生成存款请求，我们生成了一个只要存三个月就有77.7利息的这么一个存单。

我们再来看登录场景。在登陆场景下，比如说用户是在一些情况下，首次登陆会有一个初始化场景，很多测试人员他可能测不到这个初始化场景，因为他拿到一个账户他已经初始化好了，但我们可以通过一些测试逻辑，修改一些参数，我们进入到这一个首次登录的场景，然后我们发现它首次登录需要修改密码，而修改密码的时候传入的是手机号和你生成的对应性密码，那么我们直接将网银客户端的密码给重置掉了，我们成功登录了对应用户的网银客户端。

我们再来讲，用户在一些新设备登录的时候会有一个新设备校验，它可能需要你进行一个人脸或者短信验证码的一些安全校验操作。

那么在这些安全操作中我们可以看到，比如说登上去了，如果说它有一个set-cookie，它返回了类似于登录成功的这么一个请求值，一个用户的token，但是他还是这样提示说需要一个新设备绑定，那么我们可以去尝试去寻找它是不是进行了一个本地的校验，比如说我们去找一下数据包里面返回包里面的内容，比如它有一个phonechangetag，我们将它修改成零会怎么样？

我们修改成0，然后发现成功登录了对应的网银客户端，它就是一个本地的安全校验。

那么还有一种场景就是数据交叉的利用，比如说在登陆场景中，它可能同时支持手势登录或者人脸登录或者密码登录或者短信验证码登录，那么我们在人脸识别登录的时候，我们传入自己的被攻击者的一个手机号，我们查看返回包，我们发现返回了一个叫CCuserID这么一个值， use ID的话，肯定不简单，肯定有用。

然后我们再来到这个短信验证码登录，我们输入一个假的短信验证码发包，然后我们将返回包里的ccuserid改成我们前一步获取到的ccuserid，然后我们可以看到，虽然他提示说您输入的动态密码不正确，但是我们最后成功绕过了短信验证码进入到网银客户端之中。

之后我们再来聊一聊支付场景下的漏洞。首先我们来聊一个非常基础的叫最低逻辑值的漏洞，大家肯定不陌生，就是将钱改的越少越好，我原本需要800块购买，那么我们现在将amount改成0元，尝试进行一个发包，我们发现成功兑换了权益，这就是一个0元购的漏洞，这个漏洞大家肯定很常见，我们再来讲一讲不同的案例。

首先第一个叫加法逻辑，在加法逻辑之中，我们想购买一个微波炉，微波炉要540元，那么然后我们去查看一下他购买的数据包，我们发现有150多个参数，涉及到订单金额的参数就有16个，那么我们只能去一个个找。我大概那个时候从晚上7点试到了凌晨2点，试了好多种组合生成了疑似用的词，订单分了好几十个账号，最后我发现有一个参数特别神奇，叫商家让利价参数。我将这个参数修改为530，然后我自己实付款的金额修改为10元，他只要这两个值的金额总数等于他微波炉总数540元，我就可以成功生成订单，然后最后成功购买微波炉。

我们再来聊另外一个逻辑叫减法逻辑。在减法逻辑中，比如说我们来到一个商城，物品我们需要10元去购买它，然后我们点进去以后发现它支持两种付款方式，你可以同时用银行卡支付，也可以同时使用像商城里面的钱包进行一个支付，然后我们提取一下它的数据包，我发现数据包里面的确由这两个参数承担，一个是余额pay，一个卡的pay，然后这两个一个是零一个10，它等于商品的总额10元。

然后我们就想那么既然它有这么两个参数值，我肯定不能往大了改对吧？不能一个改成5，一个改成10，我一个改成-5，一个改成15，我觉得应该尝试，我发现成功生成了订单，我可以用余额支付付5块钱，我用自己的银行卡支付15块钱，当然我银行卡的确也扣了15块钱，我不是多花了5块钱买了一个原本只要花10块钱才能购买的东西对吧？

然后我们首先来看一下他的账户，我们发现15块钱是以充值的方式入账的，然后最后在钱包内扣了10块钱，剩下的5块钱冲到自己的钱包去了。

我听到这个消息马上开心，找回了5元的损失，测个漏洞都不容易，我马上把这个钱提出来以后，我发现既然没漏洞，还有一个申请退款，马上申请退款，一分钱也不花，我点击申请退款，照道理来说我们应该会有10元的这么一个到账，因为商品是10元退款应该就退10元，但是我们发现退款到账了15元，原来他只要银行卡你交易的时候用了多少钱，他退你的时候他退的不是你的商品总额，而是你银行卡支付的钱，我们就发现了新的漏洞，我们赚取的钱就等于说我们充值的金额减去我们商品的价格，这就是一个减法逻辑。

那么我的案例也讲完了，我接下来说一些总结。使用基于应用场景的渗透测试和传统渗透测试相结合，可以让这两种方法测试的更加全面，也可以让测试得到更好更快的一个结果。接着如果说我们将过往的漏洞以应用场景的方式进行一个总结，其实有利于我们未来更加深入的研究或者发现一些漏洞或者防御一些漏洞。

接着说一些部分的应用场景，我们可以看到比如说像人脸识别手势登录或者一些风控场景，其实并非都是用户完全自研的，可能用的都是一些其他的供应商公司的，如果说供应商存在漏洞，那么整一条银行金融的供应链都会存在漏洞，它的人脸识别场景全部都会有这么一个漏洞，其实是非常可怕的。

如果还有一个就是像DevSecOps在对员工进行一个安全培训的时候，应该更注重于应用场景中上下逻辑之间的这么一个校验，确保一些逻辑漏洞不再发生，要培训开发者的逻辑思考性和逻辑安全性。最后从业务角度出发，用了越难获取到用户权限的系统，往往越应该强化安全测试，只要存在应用场景，就会存在未知的漏洞，谢谢大家。