如何執行 SQL 注入攻擊
根據使用者輸入執行 SQL 查詢的應用程式可能容易受到 SQL 注入攻擊。 例如，網頁應用程式可以使用 SQL 查詢來實現身份驗證過程。 用戶提供他們的用戶名，應用程式使用該用戶名來查找該用戶帳戶的密碼雜湊。 如果使用者提供的密碼的雜湊符合此密碼雜湊，則使用者成功驗證並獲得對其帳戶的存取權限。
如果網路應用程式在將使用者名稱包含在 SQL 查詢中之前不對使用者名稱執行驗證，則程式可能會誤解故意格式錯誤的使用者名稱。 例如，SQL 查詢通常使用單引號 (') 或雙引號 (「) 來表示命令中的資料。 例如，用於根據使用者名稱使用者名稱查找客戶記錄的命令可能是 從客戶中選擇 *，其中使用者名稱 =「用戶」。
針對其命令執行 SQL 插入攻擊的攻擊者可能會在輸入中包含雙引號字元，以使其某些資料被解釋為程式碼。 例如，考慮使用者名稱 用戶」或「1」=」1。
插入到 SQL 查詢時，查詢會變成 從用戶名 =「用戶」或「1」=「1」的客戶中選擇 *。此查詢不會尋找使用者名稱與使用者提供的值相符的記錄，而是傳回符合兩個條件之一的記錄。 第一個是預期的測試 用戶名 =」用戶」，這將返回用戶的記錄。
第二個條件是測試 「一」=」1」。由於這始終是真的，因此它將返回數據庫中的所有記錄。 這可能允許攻擊者擷取其他使用者的敏感資訊，或可能允許攻擊者繞過驗證或以其他使用者身分驗證。
SQL 注入的類型
SQLi 攻擊可用於實現不同的目的，並且可以通過各種方式進行。 SQLi 的三種主要類型包括：
- 頻內 SQLi： 頻段內 SQLi 攻擊使用相同的媒介，例如 HTTP 請求，來執行攻擊並收集結果。 內部 SQLi 攻擊的兩種常見形式是以錯誤為基礎的 SQLi 攻擊，這些攻擊會嘗試產生錯誤訊息，以提供目標資料庫的資訊以供用於攻擊，以及使用 SQL UNION 運算子合併 SQL SELECT 陳述式的聯盟型 SQL。
- 盲方形數據: 在盲目 SQLi 攻擊中，攻擊者不會根據其要求從伺服器接收資料。 相反，攻擊者會根據伺服器行為修改其攻擊。 例如，不同的輸入可能會導致作業成功或失敗，或影響作業執行所需的時間。
- 頻外 SQLi： 頻外 SQLi 攻擊會對一種媒介進行攻擊，並在另一種媒體上收集數據。 此攻擊取決於資料庫伺服器上某些功能的可用性。 例如，攻擊者可以根據攻擊者是否強制資料庫伺服器產生 HTTP 或 DNS 要求給攻擊者控制的伺服器來衡量 SQLi 攻擊的成功。
如何預防 SQLI
使用不受信任的資料進行 SQL 命令時，SQLi 攻擊會利用輸入驗證不良的利用。 許多 SQLi 攻擊涉及在用戶輸入中使用意外的字符，例如單引號或雙引號。
在 SQL 查詢中包含使用者提供的資料之前執行輸入驗證，可協助減少 SQLi 攻擊的威脅。 例如，應用程式可以將使用者輸入限制為特定的字元集，例如僅允許字母數字使用者名，或阻止某些字元包含在使用者輸入中。 但是，輸入驗證雖然很重要，但並不足以防止 SQL 插入攻擊。 攻擊者可以透過使用意外的字元組合來避開封鎖，繞過允許清單或封鎖清單。
因此，公司也應該部署 網路應用程式防火牆 （WAF）或理想情況下， 網路應用程式和 API 保護 (WAAP) 位於執行 SQL 查詢的網路應用程式和應用程式開發介面之前。 這些解決方案可以幫助識別和阻止試圖利用 SQLi 的惡意請求以及針對網路應用程式和應用程式開發介面的其他攻擊。
使用Check Point預防 SQLi
SQLi 攻擊是許多對組織構成威脅的攻擊之一 應用程式資安 (應用程式管理系統)。 組織需要能夠保護其面向互聯網的本地和雲端應用程式和資料庫的安全解決方案。
Check Point CloudGuard AppSec 提供自動化 WAAP 功能，可了解應用程式的工作原理並防止非法和惡意請求到達易受攻擊的應用程式。 要了解有關 CloudGuard AppSec 及其防範 SQLi 和其他攻擊的能力的更多信息，請查看此 電子書. You’re also welcome to 報名參加免費示範 親自了解 CloudGuard AppSec 的功能。
反映意見