資訊採集系統看似簡單，不就是收集用戶填寫的資料嗎？但當我看到那張「E生活」App的註冊頁面截圖，姓名、手機號、驗證碼、銀行卡號一應俱全，心裡不禁打了個冷顫——這些資料如果被竊取，後果可不是鬧著玩的。我自己就遇過一次，某個叫「xx生活」的App，註冊完沒兩天就收到詐騙簡訊，報警後才知道那系統根本沒做基本的安全防護。所以今天想聊的，不只是技術層面的「安全防護」，更是一種對用戶資料的責任感。
表單提交背後的風險，遠比你想像的大
很多開發者為了趕進度，直接把前端傳來的資料存進資料庫，連最基本的 SQL 注入防護都省略。你想想，一個看似普通的註冊頁面，如果「姓名」欄位沒經過參數化查詢處理，攻擊者只要輸入 ' OR 1=1 --，就能把整張用戶表拉出來。這不是危言聳聽，2022年台灣某知名外送平台就因為類似漏洞，導致數十萬筆訂單資料外洩，包含地址、電話、信用卡末四碼。所以第一個防護動作，就是對所有輸入做嚴格驗證——不管是客戶端 JavaScript 驗證（那個很基本，但容易被繞過），還是伺服器端過濾，兩者缺一不可。
連線加密與資料儲存，不能只做表面功夫
我發現很多小型專案只在前端用 HTTPS，以為這樣就安全了。錯了！HTTPS 只是保護傳輸過程，資料到伺服器之後，如果後端沒做好存取控制，或者資料庫明文儲存密碼、銀行卡號，那跟把鑰匙放在門口有什麼兩樣？根據 OWASP（開放網路應用安全專案）的報告，超過60%的資料外洩事件來自於「未加密敏感資料」。以圖片中的「銀行卡號」欄位為例，正規做法是使用 AES-256 加密後再儲存，而且加密金鑰要獨立存放，不能寫死在程式碼裡。另外，驗證碼的過期時間也很重要，如果驗證碼沒有時效性，攻擊者就能用暴力破解或重放攻擊繞過認證。
別忘了後台管理的安全死角
資訊採集系統通常會搭配後台管理介面，用來查看或匯出用戶資料。偏偏很多開發者為了方便，把後台路徑設成 /admin 或 /manage，密碼還用預設的 admin/123456。這等於直接把資料庫拱手讓人。我建議後台要加上雙因子驗證，並且限制存取 IP，甚至可以設定「操作日誌」，記錄誰在什麼時間看了哪些資料。還有一點常被忽略：資料匯出功能。如果匯出 CSV 或 Excel 時沒做權限檢查，低權限管理員也能把全體用戶的銀行卡資料打包帶走——這在真實案例中時有所聞。
實例警示：一個沒做安全防護的代價
去年我有個朋友接了類似的「生活服務」App 專案，客戶為了省錢，堅持不額外做安全測試。結果上線三個月後，駭客利用簡單的 XSS 漏洞注入惡意腳本，竊取了管理員 Cookie，直接登入後台，把幾萬筆用戶資料全部下載。最後賠償金加罰款，總共燒掉將近兩百萬新台幣。早知道這些錢拿來做滲透測試和資安加固，不是更好嗎？
資訊採集系統的防護，不是買個 SSL 憑證就能交差的。它需要從前端輸入過濾、傳輸加密、儲存加密、後台管控到日誌審計，層層把關。尤其是像「銀行卡號」這種高敏感性字段，更該用最高標準處理。你覺得呢？如果你正在開發類似的系統，不妨從 OWASP Top 10 開始檢視，至少先把最常見的漏洞補上。畢竟，用戶把資料交給我們，靠的是信任——這份信任，值得用嚴謹的資安態度來守護。
評論（15）
真的假的啊，注册完就收到诈骗简讯也太可怕了吧
那个SQL注入的例子，OR 1=1 这种老招还能中哦🤔
银行帐号加密跟密钥分开存这招学到了，实用
朋友那案子烧两百万，早做测试不就结了
后台上/admin加双因子验证，这个好，之前我公司就因为这个被搞过
感觉讲来说去都是OWASP那些老问题，但就有人不修
有没有推荐的小团队资安检测工具啊？不想花钱请人测
明文存密码真的一堆中小企业还在干，吓死人
外送平台那事有印象，地址电话全流出去超夸张
验证码时效性这点我常漏，每次做完都忘记设过期
汇出CSV没权限检查，这坑我踩过，还好只是测试环境
路人吃瓜，资安这东西听起来好复杂
其实用户哪管那么多，资料外泄才来哭已经来不及了
HTTPS只保护一半这句话真中肯，一堆人以为这样就够
那如果后端用ORM框架是不是就自动防注入啊