當前位置:
首頁 > 新聞 > 由一張小票引起的聯想

由一張小票引起的聯想

事情是這樣的,日前逛煎蛋網,看到站長抱怨他買的東西,小票上的電子發票竟然沒有二維碼,而是一個URL明文:



這個很明顯是二維碼沒有正確列印嘛。且慢,看起來金額、日期等參數很眼熟啊……


頓時有點興趣了。日期、金額好像都是明文,沒有任何加密,而且看起來沒有什麼校驗。姑且嘗試一下:

http://fapiao.lppz.com/eleInvoice/index.jhtml?ive=6640|66401|2019/01/29|00055102|139.21

生成一個二維碼試試看(此處使用的是草料二維碼生成器):



接下來用微信掃碼試試,彈出提示,讓我們下載發票(這個鏈接已經被使用,所以提示可以下載該發票):



順手下載下來看一眼發票內容:



看起來都是零食,肯定有個貪吃的GF。請承受來自碼農的怒火吧。


那麼,既然這個鏈接的參數都是明文,那麼能不能自己修改一下,然後生成二維碼呢?試試:

http://fapiao.lppz.com/eleInvoice/index.jhtml?ive=6640|66401|2019/02/30|00055109|0.01

6640和66401,看起來應該是店鋪id,暫不修改;日期隨手改了個2月30日;0005510x可能是流水號,改了一個數字;最後是金額,寫0.01。


再生成一個二維碼試試看:


使用微信掃碼試試:



這都是什麼情況…………………………難道可以自行填寫了嗎?


ps:看起來已經自動把2月30日改為3月2日了;程序員贊一個……



竟然真的可以提交申請。如果沒有人工審核,或者後台沒有校驗真實數據,也許這個票就真的開出來了。


聯想起N久以前肯德基的電子發票,也是這個模式,微信掃二維碼自行填報信息開具。可惜手賤,鄙人已經把那個二維碼扔了。所以在某不存在的搜所引擎找一下,看看有沒有「好心人」貼圖:



該二維碼同樣可以正常被識別,內容如下:


可以看出,很多重要參數都是明文的,如果系統後台審核不嚴格,訪客可以隨意構建url,生成二維碼後使用微信開票,企業將面臨

巨額

損失。


由於實測風險過大,就不親身嘗試了。不過根據筆者多年的經驗來看,這類系統存在漏洞的可能性極大。


由此,產生了一些想法:



1.必須進行身份核驗,而且必須是開票的微信才能下載pdf,且限定下載次數;


2.其他人的微信,不可以瀏覽開票詳情,不可以下載該pdf文件;


3.嚴格檢查傳參,並和後台的流水號、金額,需要一一對應


4.必須要一票一密,增加校驗碼;


5.參數要加密;

6.對於異常訂單,要自動審查,進行人工核驗;


7.參數一定要檢查,務必要檢查,必須要檢查,謹防注入。


*本文原創作者:delectate,本文屬於FreeBuf原創獎勵計劃,未經許可禁止轉載


喜歡這篇文章嗎?立刻分享出去讓更多人知道吧!

本站內容充實豐富,博大精深,小編精選每日熱門資訊,隨時更新,點擊「搶先收到最新資訊」瀏覽吧!


請您繼續閱讀更多來自 FreeBuf 的精彩文章:

從Linux到Windows的PowerShell遠程處理

TAG:FreeBuf |