“二维码支付”安全么？
1 引言
随时支付宝和微信的线下不断推广，目前使用手机进行二维码支付已经逐渐成为一种时尚了。
但是大家有没有思考过：这种便捷的支付方式到底安不安全呢？今天我们就针对这个话题来进行一些探讨吧。
2 二维码简介
先来简单说说二维码：二维码是用一定规则排布的点阵的图像来编码信息的方式。与二维码对应的是传统的“条码”（一维码）。
和“条码”一样，二维码具有如下特点：
- 容易生成
- 容易被机器识别
但是“二维码”具有更多的优点：
- 高容错性
- 搞污损能力
- 高密度的信息承载能力
二维码曾被腾讯公司总裁 马化腾 誉为：连接线上和线下的通道。
随着支付宝，微信，微博等厂商的大力支持和推广，二维码的应用已经逐渐成为生活中随处可见的应用图案了。
当然，大家最熟悉的使用场景肯定是：移动支付。也是本期重点讨论的领域。
3 支付场景
- 身份二维码
- 收款二维码
- 付款二维码
大家可以使用第三方应用扫描微信或者支付宝提供的二维码，可以获取其中代表的含义。比如：两种应用互扫二维码。
3.1 身份二维码
微信 身份二维码：
http://weixin.qq.com/r/L-rg_G-EbIITrZub0097
支付宝 身份二维码：
https://qr.alipay.com/apa2uu7j3tpjyxlr00
不难看出，身份二维码实际上有用的信息就是指定的URL后面的一个串号。这个串号具有如下特点：
- 一直固定不变
- 无法通过此串号获取用户信息
- 仅能被自己的app识别其深层含义（自家app查询自家数据库），客户app扫码后，将弹出相应的显示详细身份或者加好友的界面
这样很好地兼顾了 隐私性 和 开放性 。
3.2 收款二维码
使用UC来扫微信和支付宝的收款二维码。
微信：
https://wx.tenpay.com/f2f?t=AQAAAEBfhXKNRIQUrs6fy4XO8p879
支付宝：
https://d.alipay.com/i/index.htm?b=RECEIVE_AC&u=mGnPJ/rNBfKKKKKDcQlNGn1mthWAVDa7vw00ow5sM4o=
明显看出，换了一个API，同时后面带上一串和用户账号无关串号。此串号具有如下特点：
- 一直固定不变
- 无法通过此串号获取用户信息
- 仅能被自己的app识别其深层含义（自家app查询自家数据库），被客户app扫描后，客户app直接调出向对方账号付款的界面
3.3 付款二维码
在付款二维码上，微信 和 支付宝 是差不多的，都是一串每分钟就会变一次的一串数字：
284308793673642130
此二维码信息具有如下特点：
- 是一串不带API的纯数字串
- 每分钟变一次
- 通过指定的SDK以此数字为参数进行接口调用可以完成扣款
其实上本质上就是一个付款账号。然后扫码时自动输入这个串号，通过第三方客户端调用支付平台SDK即可以完成扣款。
此扣款场景及规则如下：支付平台默认只要用户主动出具了二维码，就表明进行了授权扣款，这有点类似于在校园卡在食堂的作用一样，小额交易免除了繁琐的授权流程了。
关于付款二维码和之前的二维码的区别如下：
- 永久不变 和 每分钟必变
- API+参数 和 纯参数
关于第一点的解释，笔者在此插播一个现实生活中的小故事：
在某早餐店， 笔者问店主：为何不做个二维码放墙上？ 店主说：那玩意经常变，我们就不知道怎么弄了。 笔者笑：你说的是付款二维码，那东西如果不变，传播出去后，你的钱会被人随便扣，但是你的收款二维码，你是不是还会担心别人随便给你转钱呢？ 店主立刻明白了，笑：当然不会，别人不断给我汇款，我高兴都还来不及呢。
所以，用户只是担心自己的钱可能被不知情的情况下被划走，但是肯定是不会担心别人给自己汇款的，这就很好的解释了 “不变” 和 “变” 的区别了。
关于第二点的解释：
- app上的扫码所对应的场景众多，必须要做一定的区分，所以带上API名称
- 条码枪对应的场景单一，仅仅只是扣款，所以二维码只需要对参数进行编码即可
4 本节小结
通过本文的实验和介绍，大家应该对自己手机中的支付app的二维码是怎么回事有大致的了解了吧，后面一节将从安全性上对它们进行分析，敬请期待。。。
5 概述
前面的章节我们讲了支付宝和微信的二维码的主要信息载体，本部分则开始讨论其安全风险问题。
6 安全风险
关于二维码的风险问题主要从如下几个方面来说：
- 隐私问题
-
是否出现用户的私有信息随着二维码的传播而被泄露，给用户千万困扰的问题
-
- 越权问题
-
是否出现违反用户意途的越权操作问题
-
7 隐私问题
在前面对二维码承载的信息的分析如此可以看出，用户私有的一些信息：
- 真实姓名
- 账号明文
- 手机号码
都并没有体现在相应的参数当中，黑客很难根据那一串无意义的数据获悉二维码背后的真实的用户信息。当然，除非黑客攻陷了微信或者支付宝的数据库了，这基本上不太可能。通过这些串号获取到的用户昵称和头像也仅仅限制在当前app中。
8 越权问题
身份二维码。这个因为单方面加了好友后，是需要二维码身份主人进行验证，所以不存在越权问题。
收款二维码。正如上一文中提到的，如果有人未经当事人同意“越权”给当事人转账，你会有意见么？
付款二维码。有过在超市支付宝付款经历的人肯定知道，掏出手机，亮出二维码，收银员条码枪一过，一秒过后，钱就被扣走了。如果要说有直接的金钱损失，可能就是这个地方了吧。下面我们来细说此场景。
9 越权扣款
在前面的文章中提到，付款二维码具有如下特点：
- 一分钟强制变一次
- 能且只能被使用一次
设想这样的场景：
超市里面，收银员A在零售系统中核算出商品价格，顾客B亮出付款二维码，A拿起条码枪扫码，完成扣款，钱从B的账号进入到A所属的公司中。
那么这里面是否存在 越权扣款 的漏洞？
我的回答是：有，但是这需要我们大开脑洞才能想到。
由于二维码是一种通过光线视觉来传递信息的方式，而且二维码出示的时候，并不会指定要扣款给谁，所以在顾客B出示二维码到被收银员A扫码之间的空档里面，可能会被别人截获。
当然，我们现在都不考虑一些网络通路被攻破，数据通讯被劫持和篡改的情况，就按照正常的流程来走。顾客B出示了二维码，然后由C通过设备直接提前识别了二维码，并完成了扣款。
这个C有如下可能：
- 隐藏在旁边某人衣帽里面的针孔摄像头
- 附近大厅上方的某个已经“叛变”的监控摄像头
- 旁边某个玩手机的路人甲乙丙丁
- 带着眼镜的斯文四眼仔
他们的共同特点就是：
- 快速识别二维码。通过光学识别设备（即摄像头）即可。
- 拥有扣款的资格，黑客有各种办法使用冒牌身分获取到此资格。
- 能快速完成识别和扣款。目前的机器视觉和后续的自动化扣款程序可以实现。
假如我们这个脑洞成真了，那么就是这样的场景了：
- 顾客B掏出手机展示付款码
- 在收营员A扫码前B已经被扣款
- 环顾周边的购物的人山人海，并没发现可疑的人
- 找相关机构报案，数额太少，浪费自己的时间不划算
- 如果自己时间不值钱，坚持报案，数额不少，不予以立案
- 顾客B不相信社会了，再也不用这种付款方式了
10 小结
本节的脑洞开得有点大了。但是到底是不是耸人听闻了，还真不一定。虽然这两家公司的开发人员和产品人员也并不是吃白饭的，但是黑客和黑产从业人员也更不是吃白饭的。
11 概述-3
在上一章节里面，我们提到过，其实支付厂商和技术人员和黑产从业人员技术孰高孰低，还真不好说。但是我们目前还是尽力相信暂时正方是占据上风的吧，那么支付服务厂商到底做了哪些措施来保证这个安全呢？我们可以来分析一下。当然，本文的定位还是给技术小白的简谱吧，技术大牛面前还是属于献丑了。
12 风险控制
虽然确实存在以上漏洞，但是其实细心的用户可能注意到了，微信和支付宝尽力地做了相应的措施：
- 对申请扣款资格主体身份进行严格审核，虽然说不能百分百，但是还是可以极大增加假冒门槛。当然厉害的黑客还是有办法过。
- 设立资金保险。当然，估计并没有多少人去投保了。
- 限额。将这种扣款方式进行限定，将其局限在小额场景。但是每次被扣除个几百块，也还是有点心疼的吧。
直接出示付款码，让对方扫码扣款，这种方式确实是自己目前体会到的最便捷的支付方式了。但是这种方式存也确实存在一定的安全风险，所以用户在使用时，请养成良好的习惯，让二维码暴露在公众视野下的时间尽量短，看到的人尽量少。否则，稍微的疏忽就成了黑客们线下薅羊毛发家致富的场景了。
13 方案建议
关于此“安全漏洞”，在技术流程上的解决方案是：
在扫码之后，加入“用户确认”环节， 要求用户在自己的app上做一个简单的交互，表示自己 知晓 并 认可 当前的扣款行为。
当然，这个“简单” 最后加一道确认环节，关于这个环节，我们可以头脑风暴一下，我先说下自己的“脑洞”：
- 加一个类似苹果开机的滑动解锁确认
- 指纹确认（对于有指纹模块的手机来说不错）
- 做一个按钮图标，需要用户长按2s确认
- 要求用户摇一摇把钱甩出去（扫码后，做个图片：钱一半在口袋外面了）
- 要求用户对着手机吹一口气把钱吹出去（吹气后，加个钱被吹走的动画）
大家有看到这几个构想的，如果觉得比较好，请转达给微信或者支付宝的产品经理，如果被采用了，请给我发个红包哦（手动龇牙表情）。
14 结论
虽然本文有点脑洞大开，只是希望大家能明白：我们享受到了新型的便捷的付款方式的同时，其实是牺牲了一定的安全性的。在商场使用刷卡支付，刷卡后输入密码，虽然麻烦，但是却有一个重要的“用户确认环节”，还是能避免掉意外扣款。当然这也是产品的权衡了，看这个风险出现的概率是否值得提供商牺牲掉好的付款体验了。
现在还没有出现那种被机器视觉薅羊毛的扣款事件吧，也不知道今后会不会有，希望是我杞人忧天了吧。
转自：https://www.cnblogs.com/beer/p/6918180.html
制作)
...)
