現在的WEB程序基本都有對SQL注入的全局過濾，像PHP開啟了GPC或者在全局文件common.php上使用addslashes()函數對接收的參數進行過濾，尤其是單引號。同上一篇，我們需要找一些編碼解碼的函數來繞過全局防護，本篇介紹base64decode()的情況。
原文出處：http://www.cnbraid.com/2016/sql2.html
－－－－－－－－－－－－－－－－－－－
如果你認同支持我們每日分享的文章的話，請幫我們按個讚並且點擊追蹤「搶先看」，這樣就可以快速獲得最新消息囉！
您的分享及點讚，是我們最大的動力來源。
https://www.facebook.com/LonelyPoPo/
波波觀點：Base64Decode 繞過提醒我們要追資料流
Base64Decode 繞過常見於系統把參數包成編碼資料後再進行業務處理。若安全檢查只看編碼前或編碼後其中一層，就可能漏掉真正進入 SQL 的內容。代碼審計時，重點不是看到 base64_decode 就判定有漏洞，而是追蹤資料如何被解碼、拼接、查詢與輸出。
審計清單
- 找出 base64_decode、json_decode、unserialize、UrlDecode 等資料轉換點。
- 確認每次轉換後是否重新進行型別驗證、長度限制與白名單檢查。
- 檢查 SQL 組字串位置是否仍使用參數化查詢，而非手寫拼接。
- 加入測試案例覆蓋正常、編碼、雙重編碼與非法輸入。
防禦與系列整理
編碼不是安全邊界。系統若需要傳遞編碼資料，仍必須在資料進入危險操作前完成驗證與授權檢查。對 SQL 查詢來說，最穩定的防線仍是參數化查詢、白名單欄位與最小權限資料庫帳號。
建議後續把 UrlDecode、Base64Decode 與全局防護繞過整理成一個系列頁，讓讀者能按資料流與防禦策略理解 SQL 注入，而不是只記個別 payload。
