ASP 門檻低、見效快,新手能在短時間構建功能完整的動態網站。但「能跑」不代表「安全」。介面友好度、執行效能、資安防護是區分新手與資深工程師的三大分水嶺。SQL 注入正是新手最易忽視、危害最大的漏洞類型。
正常請求: https://site/show.asp?ID=444
後端 SQL: SELECT * FROM News WHERE ID = 444
測試請求: https://site/show.asp?ID=444 AND USER>0
後端 SQL: SELECT * FROM News WHERE ID = 444 AND USER>0
-- 強制型別轉換錯誤,洩露資料庫版本、連接帳號(如 sonybb)
攻擊請求: https://site/show.asp?ID=444 AND (SELECT PassWord FROM Login WHERE User_Name='admin')>0
錯誤訊息: [SQL Server] 將 varchar 值 '!@#*&admin' 轉換為 int 失敗
-- 紅框部分即為管理員密碼!
攻擊者利用型別轉換錯誤回顯(Error-based Injection),將查詢結果強制轉為數值型別觸發錯誤,將資料「偷渡」在錯誤訊息中。
手動注入需數小時甚至數天,但 NBSI (Network Base SQL Injection) 2.0 等自動化工具可在數分鐘內完成:
許多「腳本小子」不懂 ASP/SQL,僅靠工具一天癱瘓十餘站點,僅留「善意警告」與署名,惡性不容小覷。
IIS 設定:將 500;100 錯誤頁從 500-100.asp 改為靜態 500.htm。所有 ASP 錯誤統一回傳 HTTP 500,攻擊者無法獲得資料庫結構、帳號等偵察資訊。
代價:開發除錯不便,但生產環境應優先安全。可建立測試環境供開發使用詳細錯誤。
xp_cmdshell 可奪取作業系統控制權)在每個接收參數的頁面 ,攔截含 exec, insert, select, delete, update, count, *, xp_cmdshell, -- 等關鍵字的請求並終止執行。
' 錯誤寫法
sql = "SELECT * FROM Users WHERE Name = '" & Request("name") & "'"
' 正確寫法:Command 物件參數化
Set cmd = Server.CreateObject("ADODB.Command")
cmd.ActiveConnection = conn
cmd.CommandText = "SELECT * FROM Users WHERE Name = ?"
cmd.Parameters.Append cmd.CreateParameter("@name", 200, 1, 50, Request("name"))
Set rs = cmd.Execute
參數化查詢將資料與程式碼徹底分離,資料庫引擎將參數視為字面值而非可執行碼,從根本上消除注入可能。
SQL 注入之所以橫行,核心在於「資料與程式碼未分離」。參數化查詢是銀彈,輸入驗證是護盾,統一錯誤頁是迷彩,最小權限是護城河。開發者應建立「所有外部輸入皆不可信」的防禦思維,將安全內建於開發生命週期每個環節,而非事後補丁。