“二維碼支付”安全么？
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