2022应用场景看金融安全

应用场景金融安全金融安全现状加固APP/H5加固

加固厂商加固

混淆、反调试、虚拟化

× 无法直接展开测试分析加密×一次或多次加密加密×明文数据 加密数据 无法直接篡改数据内容安全设备×部署多个安全设备安全设备×WEB服务 拦截攻击流量 无法直接发送攻击请求三道门槛拦截住绝了大部分攻击者，但也拦截住了绝大部分企业渗透测试人员系统安全性得无法得到全面测试，看似安全实则脆弱金融安全现状

安全设备安全设备安全设备POST:‘1or1=1×POST:‘1or1=1×加密明文数据 一次或多次加密 加密数据加密POST:POST:1234567POST:Aj5yh…POST:‘1or1=1POST:‘1or1=1POST:Da7hd…金融安全现状

加密安全设备+ =0加密安全设备POST:‘1or1=1POST:‘1or1=1POST:Da7hd…数据无异常，放行POST:‘1or1=1POST:‘1or1=1×网络安全防护，有时并不一定是安全措施叠加越多越好标品WAF无法适应流量全加密的金融环境对它来说攻击数据和普通数据加密后没有任何区别信托保险银行信托保险银行其他金融基金证券各类供应商和客户金融系统是一个隐形的巨量开放平台渗透测试人员+金融安全现状渗透测试人员+

获取不到账户的系统

系统安全没有漏洞？那些账户的确难获取，但只要花成本还是能开户的系统：企业网银系统、IPO系统、资本引荐系统、基金机构系统、信托尊享系统和私人银行系统……往往是金融系统中的漏洞重灾区系统漏洞挖掘难度与渗透测试次数成正比，与账户权限获取难度成正比应用场景分类功能场景存款场景、取款场景、转账场景、买入场景、卖出场景功能场景单一性、模块化性、可视化性安全场景风控场景、人脸识别场景、短信验证码场景、UKEY场景安全场景应用操作周期跟随性、通用性应用场景关联金融安全传统渗透测试从漏洞类型出发传统渗透测试CSRF……命 文 信CSRF……令 件 息漏执 上 泄漏洞行 传 露洞漏 漏 漏洞 洞 洞

垂水XSSSQLXSSSQL越越注权权入漏漏漏洞洞洞应用场景关联金融安全传统渗透测试测试链路：找到应用→找到功能点→不同类型漏洞测试→产出漏洞传统渗透测试1.漏洞类型测试全面；具体功能测试全面；测试者可灵活测试。

1.测试繁琐类型多；功能点容易遗漏；缺乏整体逻辑性。基于功能点的测试功能点点动 成场景应用场景多个功能点组成一个应用场景应用场景关联金融安全基于应用场景的渗透测试测试链路：找到应用→找到场景→对应应用场景漏洞测试→产出漏洞基于应用场景的渗透测试1.针对性强，可模板化点对点展开全面测试；涵盖所有场景内的功能点不容易遗漏细节；具有整体逻辑性，排除测试人员能力因素。XX应用场景

可能存在XX信息泄露漏洞可能存在XX校验绕过漏洞可能存在XX参数篡改漏洞应用场景产生特定漏洞应用场景产生特定漏洞，为什么？要从研发底层思维逻辑解答这个问题，想研发之所想开发一个新的场景需要有不同的功能点，功能点组合的形式不同便产生了不同的漏洞开发一个新的场景需要构思代码运行步骤，步骤间逻辑的不缜密便产生了不同的漏洞应用场景的开发逻辑思考以存款证明场景为例用户：进入场景→选择冻结\非冻结类型→选择银行卡→选择开立金额→选择电子\纸质→收到证明文件开发：查询用户账户及状态→查询理财及存款金额→获取开立金额→是否冻结资产→生成电子资产证明① ② ③ ④ ⑤→判断电子\纸质类型→确认收货地址→确认证明费用→派发电子证明\派发纸质工单→流程收尾⑥ ⑦ ⑧ ⑨ ⑩功能点单独漏洞：①：越权查询他人账户信息、账户ID参数SQL注入②：越权查询他人银行卡余额、银行卡号参数SQL注入⑦：快递地址XSS漏洞、电子邮箱地址邮件内容篡改漏洞⑨：越权查看他人存款证明、工单号参数SQL注入应用场景的开发逻辑思考以存款证明场景为例开发：查询用户账户及状态→查询理财及存款金额→获取开立金额→是否冻结资产→生成电子资产证明① ② ③ ④ ⑤→判断电子\纸质类型→确认收货地址→确认证明费用→派发电子证明\派发纸质工单→流程收尾⑥ ⑦ ⑧ ⑨ ⑩多个功能点造成的逻辑漏洞：②+③+④：冻结财产金额大于可用资产金额、冻结财产金额小于开立金额②+③+⑤：电子资产证明资产金额大于可用资产金额⑥+⑦+⑧：通过电子、纸质证明金额差异信息及快递优惠信息生成低价或免费证明订单①+⑤+⑨：异常账户可顺利开具资产证明应用场景的开发逻辑思考以存款证明场景为例监管机构要求在开具存款证明前加入安全验证功能：

短信验证码场景

（加入安全场景）开发：查询用户账户及状态→查询理财及存款金额→获取开立金额→是否冻结资产→生成电子资产证明① ② ③ ④ ⑤→判断电子\纸质类型→确认收货地址→确认证明费用→短信验证码校验→派发证明工单→流程收尾⑥ ⑦ ⑧ ⑨ ⑩ ⑪短信验证码场景正确验证码放行短信验证码场景正确验证码错误验证码严格校验验证码正确性，无漏洞错误验证码拦截应用场景的开发逻辑思考以存款证明场景为例开发：查询用户账户及状态→查询理财及存款金额→获取开立金额→是否冻结资产→生成电子资产证明① ② ③ ④ ⑤⑧⑨⑩直接跳过验证码功能，进入原有开发逻辑⑧⑨⑩直接跳过验证码功能，进入原有开发逻辑⑥ ⑦ ⑪单独看⑨的确没有问题，但在整个应用场景中却存在漏洞研发在原有的开发逻辑上加入短信验证码校验却没有修改⑩原有的逻辑，没有加入是否已经校验短信验证码的判断上下步骤的逻辑校验在金融系统中很重要每一次对应用场景的改动都需要重新校验真实案例脱敏详解操作功能

应用操作周期跟随性安全场景

放行 进行后续操功能暂时禁拦截安全场景是为阻止恶意操作者攻击系统功能保障用户信息、财产不受侵犯而设置的“路障”测试逻辑：一切为了绕过“路障”真实案例脱敏详解——风控场景不给风控参数，等于没有风控POST/mbank/tran-019.do?_locale=ZH_CN&version=7.7&riskflag=XXXXX

POST/mbank/tran-019.do?_locale=ZH_CN&version=7.7&riskflag=真实案例脱敏详解——风控场景固定风控参数，等于一片祥和编写JS脚本，替换不固定的风控参数内容，永远传入一个常量值“riskdoc”为AES加密之后的风控数据“prdToken”在每次API请求后都会由服务端返回的新值真实案例脱敏详解——风控场景触发风控，焉知非福密码校验失败（“checkstatus”状态值），但还是返回了对应用户的全部信息真实案例脱敏详解——人脸识别场景客户端降维打击某人脸识别SDK活体校验模块真实案例脱敏详解——人脸识别场景客户端降维打击发现Class:com.xxx.sdk.live.verify.EyeClose EyeClose请眨眨眼真实案例脱敏详解——人脸识别场景服务端降维打击使用本人真实人脸识别捕获人脸识别请求数据真实案例脱敏详解——人脸识别场景服务端降维打击我们发现在向“FaceChecking.action”API发送人脸识别数据时，请求数据包内有两个重要参数值其中第一个参数是“photo”，经过分析为用户无动作时的正脸照片经过Base64编码之后的数据我们将其替换为从被攻击者身份证上截取的本人照片Base64编码之后的数据真实案例脱敏详解——人脸识别场景服务端降维打击第二个参数是“faceData”，也为Base64编码之后的数据我们解码之后简化如下：眼时的照片经过Base64编码之后的数据,用户眨眼时的脸部特征值 用户微笑时的照片经过Base64编码之后的数据,用户微笑时的脸部特征值其中涉及到两张图片：用户眨眼时的照片和用户微笑时的照片我们继续将这两张图片替换为攻击者身份证上截取的本人照片Base64编码之后的数据，然后进行人脸识别操作：真实案例脱敏详解——人脸识别场景系统会把当前用户上传的身份证照片头像当做用户人脸数据，后续人脸识别将以此作为人脸比对数据特殊的人脸识别系统会把当前用户上传的身份证照片头像当做用户人脸数据，后续人脸识别将以此作为人脸比对数据真实案例脱敏详解——UKEY场景

UKEY驱动在本地建立Web服务与企业端网银进行全部交互操作真实案例脱敏详解——UKEY场景UKEY驱动数据交互实现方法为JSONP UKEY驱动漏洞秒变JSONP跨域漏洞成功实现操作UKEY驱动任意功能真实案例脱敏详解需进行某操作

单一性、模块化性功能场景

在约束条件内

完成对应操作功能场景灵活多样，交互逻辑各异，不同场景下并没有固定的漏洞挖掘逻辑不必局限于传统测试思路，要从找漏洞变成“创造”漏洞or下线真实案例脱敏详解——数字人民币场景其他商业银行接入真实案例脱敏详解——数字人民币场景真实案例脱敏详解——数字人民币场景对公钱包来到注册处输入钱包ID此时返回钱包预留的法人信息及手机号全部篡改成自己的数据接着系统会判断钱包是否注册篡改返回包内容成未注册状态按照流程创建支付密码强制重新注册钱包信息真实案例脱敏详解——数字人民币场景对公钱包

⽀付密码就能够以把钱转⾛真实案例脱敏详解——数字人民币场景对私钱包接收验证码码时将接收⼿机号篡改为⾃⼰的⼿机号真实案例脱敏详解——数字人民币场景对私钱包⽤⾃⼰的⼈脸去识别 重置完密码后拥有钱包全部权限真实案例脱敏详解——存款场景时长不变:利率变高利率不变:时长变短"depositRate":"1.9""depositRate":"77.7"篡改参数后重新发包成功以高利率购买存款产品真实案例脱敏详解——登录场景首次登录情况特殊会有一些列初始化设置很多人都是初始化完成之后才开始测试很难进入到该逻辑中成功重置任意网银账户密码并使用新密码登录真实案例脱敏详解——登录场景验证码校验

新设备登录手机网银时需要身份验证绑定手机双因子校验

人脸识别校验真实案例脱敏详解——登录场景密码登录之后发现还要短信验证码二次校验

发现登录之后的返回包内含有疑似用户凭证Cookie内容猜测二次校验可被饶过

找到疑似校验参数"bindDeviceFlag""bindDeviceFlag":true↓"bindDeviceFlag":false成功绕过二次校验登录系统真实案例脱敏详解——登录场景登录返回包内有Token值本地安全设备校验找到判断参数，直接篡改数据交叉利⽤

来到人脸识别登录模块点击进行人脸识别并查看对应返回包获取到userId参数内容真实案例脱敏详解——登录场景数据交叉利⽤将⼈脸识别登录流程中获取到的值给验证码登录流程使⽤，成功登录真实案例脱敏详解——支付场景最低值逻辑POST/mapp/orderPay.do?prodId=xxxxx&amount=800&count=1

POST/mapp/orderPay.do?prodId=xxxxx&ount=0&count=1真实案例脱敏详解——支付场景加法逻辑查看数据包一共150个参数 涉订单金额的参数有16个真实案例脱敏详解——支付场景加法逻辑商品原价540元(totalfee)实际付款10元(payment)商家让利价530元(yieldProfits)530+10=540真实案例脱敏详解——支付场景减法逻辑

⼩程序在付款界⾯同可以使⽤账户余额⽀真实案例脱敏详解——支付场景减法逻辑POST/miniapp/action/paymyorder?id=xxx&yuePay=0&cardPay=10HTTP/1.1Host:Connection:closeContent-Length:0Sec-Fetch-Dest:emptyUser-Agent:Mozilla/5.0(WindowsNT6.3;WOW64)AppleWebKit/537.36(KHTML,likeGecko)Chrome/47.0.2526.106Safari/537.36Content-Type:application/x-www-form-urlencodedAccept:*/*Origin:/Sec-Fetch-Site:same-originSec-Fetch-Mode:corsAccept-Encoding:gzip,deflate两者值必须等于订单金额10元，否则会报错真实案例脱敏详解——支付场景减法逻辑15–5=10POST/miniapp/action/paymyorder?id=xxx&yuePay=0&cardPay