由一張小票引起的聯想

事情是這樣的，日前逛煎蛋網，看到站長抱怨他買的東西，小票上的電子發票竟然沒有二維碼，而是一個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原創獎勵計劃，未經許可禁止轉載

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