Halo ITSM SQL Injection漏洞的技術分析

漏洞位置與觸發點

這個被發現的未經身份驗證 SQL Injection漏洞位於 PostNotify 控制器中，該控制器位於 NetHelpDesk.API/Controllers/NotifyController.cs 檔案內。 2 更具體來說，漏洞出現在此控制器呼叫的 PostLogMeIn 函數中。 2 值得注意的是，這個控制器缺少任何強制身份驗證的裝飾器，因此未經身份驗證的使用者也能存取。 2 此外，該控制器接受一個未強制類型的字典物件 ( Dictionary obj )。 2 在這個入口點缺乏身份驗證要求與嚴格的資料類型限制，成為促成此漏洞的關鍵因素。 2 研究發現，Halo ITSM 程式庫中其他未經身份驗證的控制器使用了更嚴格的類型限制，通常強制使用整數類型，這有效防止了類似的 SQL Injection攻擊，即使那些地方也使用了字串拼接。 2 程式庫中不同部分的安保措施不一致，凸顯了對軟體安全採取統一且嚴謹方法的重要性。

攻擊機制

要觸及漏洞程式碼，攻擊者需向 /api/Notify 端點發送一個 JSON 物件，此物件至少需包含 sessionid 和 tracking0 鍵值。 2 這些鍵值的存在會觸發 PostLogMeIn 函數的執行。 2 在 PostLogMeIn 函數內，程式碼會檢查提供的字典物件中是否存在 lastactiontime 鍵值。 2 如果該鍵值存在且其值不是 null 或空白，程式碼會繼續在呼叫 _CommonFunctions.getOneFieldInt 函數時建構一個 SQL 查詢。 2 漏洞顯現的具體程式碼行是為此函數呼叫建構 wheresql 參數的部分： "where ulogmeinid=" + obj["techid"].ToString() 。 2 getOneFieldInt 函數的第四個參數 wheresql 被設計用來包含 SQL 查詢中的 WHERE 子句。然而，漏洞源於 JSON 物件中 techid 鍵值（來自未類型化的字典）直接被轉換為字串並拼接進 wheresql 字串中，卻未經過適當的清理或類型檢查。 2 由於傳遞給控制器的初始字典物件缺乏類型強制，攻擊者可提供包含惡意 SQL 程式碼的字串作為 techid 的值。此惡意字串隨後被直接併入 SQL 查詢中並由資料庫執行。 2

概念驗證

研究人員提供了一個概念驗證的 JSON Payload ，有效展示此 SQL Injection漏洞。 2 該 Payload 在 techid 參數中注入了一個 waitfor delay 指令：

JSON

                {
                "sessionid" : "SESSION_ID_VALUE" ,
                "tracking0" : "ticket12345" ,
                "techid" : "1;waitfor delay '0:0:10'--" ,
                "pickuptime" : "2025-03-03T10:00:00" ,
                "lastactiontime" : "2025-03-03T11:30:00" ,
                "chatlog" : "assetnote are the pioneers of attack surface management"
                }
                

當這個 POST 請求被送到一個有漏洞的 Halo ITSM 實例的 /api/Notify 端點時，會讓伺服器回應延遲 10 秒。 2 這種延遲證實了資料庫成功執行了注入的 SQL 指令 waitfor delay '0:0:10'-- 。 2 這個注入指令能成功執行，直接原因是因為缺乏適當的輸入驗證，加上使用了寬鬆類型的物件進行字串拼接，讓任意的 SQL 程式碼可以被注入並執行。 2 這個簡單的例子展示了執行更複雜且具破壞性的 SQL 指令的潛力，例如用來提取或修改敏感資料的指令。

SQL Injection攻擊基礎

基本原則

SQL Injection (SQLi) 是一種常見的網頁安全漏洞，讓攻擊者可以干擾應用程式對其底層資料庫發出的 SQL 查詢。 6 這種干擾能讓攻擊者看到他們通常無權存取的資料，包括其他使用者的資料或應用程式本身能存取的任何資訊。 6 很多時候，攻擊者還能修改或刪除這些資料，導致應用程式的內容或行為出現持久性的改變。 6 在更嚴重的情況下，成功的 SQL Injection攻擊甚至可能讓攻擊者危害底層伺服器或其他後端基礎設施，潛在導致系統完全被接管或拒絕服務攻擊 。 6 SQL Injection的基本原理在於透過使用者提供的輸入來操控 SQL 查詢。 6 應用程式常常透過直接將使用者提供的資料併入查詢字串中，動態建構 SQL 查詢。 6 如果這些輸入沒有被適當驗證或清理，攻擊者就能注入惡意的 SQL 程式碼，改變原始查詢的預期邏輯。 7 這種漏洞存在的一個核心原因是 SQL 內在缺乏資料層與控制層的明確區分。 11 這意味著使用者提供的資料可能被誤解並作為 SQL 指令的一部分執行，從而改變其預定功能。 11 這種情況通常發生在應用程式動態建構 SQL 查詢時，直接嵌入使用者輸入卻未採用適當的清理或參數化技術。

常見攻擊途徑與技術

SQL Injection攻擊的方法五花八門，每種都針對不同類型的漏洞和應用程式行為量身打造。 6 以下是一些最常見的攻擊途徑與技術：

• 提取隱藏資料： 攻擊者可以操控 SELECT 查詢中的 WHERE 子句，繞過預設限制，提取不該公開存取的額外資料。 6 例如，在一個根據類別顯示產品的應用程式中，攻擊者可能在類別參數中注入像 ' OR 1=1-- 的 Payload 。 -- 在 SQL 中表示註解，會註解掉原始查詢 WHERE 子句的其餘部分。 OR 1=1 條件永遠為真，讓查詢返回所有產品，包括未發布或隱藏的產品。 6
• 顛覆應用程式邏輯： 攻擊者可以打造惡意查詢，干擾應用程式的預期邏輯。 6 一個常見例子是繞過登入機制。如果應用程式使用像 SELECT * FROM users WHERE username = '"+ username + "' AND password = '"+ password + "' 的 SQL 查詢，攻擊者可能輸入像 ' OR '1'='1' -- 的使用者名稱。這會讓查詢因為 ' OR '1'='1' 條件永遠為真而始終成立，有效繞過密碼檢查，讓攻擊者無需正確認證就能登入。 6
• UNION 攻擊： 當應用程式顯示 SQL 查詢結果時，攻擊者可以利用 UNION 關鍵字，將惡意 SELECT 查詢的結果附加到原始查詢中。 6 這項技術讓他們能從其他資料庫表格中提取資料，這些表格可能包含使用者名稱、密碼或其他機密資料等敏感資訊。 6 例如，攻擊者可能注入 UNION SELECT username, password FROM admin_users-- ，從名為 admin_users 的表格中提取使用者名稱與密碼欄位，即使原始查詢是為了提取產品資訊。
• Blind SQL Injection： 在許多情況下，應用程式不會在回應中顯示 SQL 查詢結果或任何資料庫錯誤，這被稱為Blind SQL Injection漏洞。 6 儘管沒有直接輸出，攻擊者仍可利用技術根據應用程式行為推斷資訊來加以利用。 6 這些技術包括：

• 觸發條件回應： 攻擊者注入 SQL 程式碼，根據他們控制的條件真假，讓應用程式回應出現明顯差異（例如不同的訊息、頁面內容變化或特定的 HTTP 狀態碼）。 6 透過觀察這些條件回應，他們可以推斷出資料庫的資訊。
• 觸發時間延遲： 攻擊者可以使用特定的 SQL 函數（例如某些資料庫中的 WAITFOR DELAY ），在查詢執行中引入時間延遲。 6 透過監控回應時間，他們能判斷注入條件的真假。例如，攻擊者可能注入一個查詢，若資料庫名稱的第一個字母是 'a'，則延遲回應 10 秒。延遲的回應會證實這個條件。
• Out-of-Band (OAST) 技術： 這種更進階的技術涉及注入 SQL 程式碼，在執行時觸發Out-of-Band網路互動。 6 例如，攻擊者可能注入程式碼，讓資料庫伺服器向他們控制的域名發出 DNS 查詢，透過 DNS 查詢有效提取資料。 6

• 二階 SQL Injection (Second-Order SQL Injection)： 這種攻擊發生在使用者輸入最初被應用程式儲存（通常在資料庫中），隨後以不安全的方式併入 SQL 查詢時。 6 資料的初始儲存可能被安全處理，但當應用程式後續提取並在 SQL 查詢中使用這些儲存資料時，若未適當清理，就會出現漏洞。 6 例如，使用者可能輸入看似無害的字串並儲存於資料庫中。後來，應用程式的另一部分可能提取此字串並直接併入 SQL 查詢中，卻未轉義特殊字元，從而允許之前儲存的惡意 Payload 被執行。 6
• 檢查資料庫： 在成功識別 SQL Injection漏洞後，攻擊者常試圖收集資料庫本身的資訊。 6 這可能涉及查詢資料庫類型與版本、列出可用資料庫、表格與欄位，或檢查使用者權限。 6 這些資訊有助於進一步利用該漏洞。

SQL Injection漏洞可能出現在 SQL 查詢的各個部分，不僅限於 WHERE 子句。它們也可能出現在 UPDATE 語句（在更新的值或 WHERE 子句中）、 INSERT 語句（在插入的值中），甚至在表格或欄位名稱或 SELECT 語句的 ORDER BY 子句中。 6

成功 SQL Injection的影響

成功的 SQL Injection攻擊可能對受影響的應用程式及其依賴的組織造成嚴重後果。 6 潛在影響包括：

• 未授權存取敏感資料： 攻擊者可以存取資料庫中儲存的敏感資訊，例如密碼、信用卡資料、個人使用者資訊、商業機密與智慧財產。 6 這可能導致身份盜竊、金融詐欺、聲譽損害與法律後果。
• 資料修改或刪除： 攻擊者可以更改或刪除資料庫中的關鍵資料。 6 這可能擾亂業務運作，導致資料遺失並危害資料完整性。在某些情況下，攻擊者可能在合法網頁中插入惡意內容。
• 身份驗證繞過與權限提升： 攻擊者可以繞過登入機制，並可能在應用程式內獲得管理權限。 7 這讓他們能執行通常僅限授權使用者執行的動作，潛在導致完全控制應用程式及其資料。
• 遠端指令執行： 在某些資料庫設定中，攻擊者可能能在資料庫伺服器上執行作業系統指令。 8 這可能導致伺服器完全被危害，允許攻擊者安裝惡意軟體、存取網路上的其他系統或執行其他惡意活動。
• 資料完整性與可用性受損： SQL Injection攻擊可能危害資料庫中儲存資料的完整性，使其變得不可靠。 8 它們也可能透過過載(Overloading)資料庫伺服器或損壞關鍵資料，導致拒絕服務狀況，使應用程式無法供合法使用者使用。 6
• 建立持久後門： 攻擊者可利用 SQL Injection在易受攻擊的系統中建立持久後門，即使初始漏洞可能已被更新，他們仍能重新獲得存取權。 7 這些後門可能長期未被發現，允許長期危害。

寬鬆類型處理引發的漏洞

寬鬆類型的概念

在程式語言領域，強類型語言與弱類型（也稱寬鬆類型）語言之間有明顯的區別。 5 強類型語言（如 Go、C# 和 Java）對變數實施嚴格的類型規則，這意味著變數的類型通常在編譯時定義，且未經明確轉換無法輕易更改。 5 這有助於防止不同變數類型在無明確指令的情況下混用。 5 相反，弱類型或寬鬆類型的程式語言（如 JavaScript、PHP 和 Ruby）對變數沒有這麼嚴格的類型規則。 5 在這些語言中，變數的類型通常在運行時決定並可更新，這一概念稱為 dynamic typing。 17 這提供了更大的靈活性，因為單一變數可能在某個時間點持有整數值，而在程式執行後期持有字串值。 5

寬鬆類型的安全影響

雖然寬鬆類型提供的靈活性有時能加速開發並讓程式碼更簡潔，但若未小心處理，也可能帶來顯著的安全影響。與寬鬆類型相關的主要安全風險之一是類型混淆漏洞 (type confusion vulnerabilities)。 5 類型混淆發生在應用程式預期變數為某種資料類型但收到另一種時，導致意外行為或安全繞過。 17 Halo ITSM 漏洞就是一個顯著例子。程式碼預期 techid 參數為整數，這從函數名稱 getOneFieldInt 及查詢資料庫記錄 ID 的情境可推測。 2 然而，由於底層框架或開發者選擇的寬鬆類型特性，接受此輸入的字典物件 ( obj ) 未經類型化，攻擊者得以傳送包含惡意 SQL 程式碼的字串作為 techid 的值。 2 此字串隨後被直接拼接進 SQL 查詢中，導致成功的 SQL Injection。若 techid 參數被嚴格類型化為整數，試圖注入包含 SQL 程式碼的字串可能在早期階段失敗，從而防止漏洞。 2

寬鬆類型處理導致漏洞的類似案例

Halo ITSM 漏洞並非孤立事件，還有其他記錄案例顯示寬鬆類型處理導致重大安全缺陷：

• GLPI 未經身份驗證 SQL Injection： 在 GLPI 的 Inventory 功能中發現了一個未經身份驗證的 SQL Injection漏洞。 19 此漏洞因 SimpleXMLElement 物件（用於處理 XML 請求）能繞過清理使用者輸入的 dbEscapeRecursive 函數而產生。這一繞過源於系統處理輸入類型的方式，允許注入惡意 SQL 查詢，導致未授權存取敏感資料庫資訊。 19
• PHP 密碼比較問題： 在 PHP 中，可被解釋為數字的字串在某些比較中被視為數字。此行為導致一個身份驗證繞過漏洞，hashed 密碼（通常為隨機字母數字字串）可被 PHP 解釋為與另一字串（例如帶指數符號的 "0e123"）在數字上相等的不同字串所繞過。 5 這顯示了 PHP 比較運算子中的寬鬆類型可能導致意外且不安全的結果。
• Node.js 模板引擎漏洞： 在 Node.js 模板引擎中發現了一個類型混淆錯誤，當預期字串時提供陣列作為輸入，導致清理邏輯被繞過，產生跨站腳本 (XSS) 漏洞 。 17 includes 函數對字串與陣列的行為不同，且缺乏嚴格類型檢查，使攻擊者能提供包含惡意 JavaScript 的陣列，隨後在使用者瀏覽器中顯示。 17

這些例子與 Halo ITSM 漏洞一起，凸顯了在未實施強大且明確的類型檢查與資料驗證的情況下依賴寬鬆類型的潛在危險。動態類型的靈活性若開發者對資料類型做出未被程式語言或應用程式邏輯一致強制的假設，可能成為重大安全負債。

表格 1：因寬鬆類型處理導致的漏洞範例

Software/Technology	Vulnerability Type	Cause	Reference
Halo ITSM	SQL Injection	Untyped dictionary allowing string injection where integer was expected	2
GLPI	SQL Injection	SimpleXMLElement bypassing sanitization due to type handling	19
PHP	Authentication Bypass	Numeric string comparison leading to incorrect equality evaluation	5
Node.js	Cross-Site Scripting	Type confusion in templating engine leading to sanitization bypass	17

未經身份驗證 SQL Injection的原因與緩解策略

常見原因

多種因素可能導致未經身份驗證 SQL Injection漏洞的出現。 10 其中一個最常見的原因是對使用者提供資料的 輸入驗證與清理不足 。 7 當應用程式未能在將使用者輸入用於 SQL 查詢前適當驗證與清理時，攻擊者就能注入惡意 SQL 程式碼。另一個重要原因是 基於使用者輸入動態生成 SQL 查詢卻未採取適當防護 。 10 如 Halo ITSM 案例所示，直接將使用者輸入拼接進 SQL 查詢字串，為攻擊者創造了操控查詢結構的機會。忽略基本的 安全最佳實踐(Security best practices) ，例如始終使用參數化查詢(Parameterized queries)或 Prepared statement，也使應用程式易受攻擊。 7 應用程式不同部分的安保措施執行不一致（某些區域可能有更嚴格的輸入處理），如 Halo ITSM 程式庫中所見，也可能導致漏洞。 2 最後，在直接與資料庫互動的關鍵程式碼路徑中接受未類型化的資料，如 Halo ITSM 的 PostNotify 控制器中的未類型化字典物件，大幅增加了 SQL Injection的風險。 2

防禦機制

要有效防禦未經身份驗證 SQL Injection漏洞，需採取多層次的防禦機制。 10 輸入驗證與清理 是關鍵的第一步，確保使用者輸入符合預期格式，且任何潛在惡意字元被轉義或拒絕。 7 然而，單靠輸入驗證通常不夠。防禦 SQL Injection最有效的方法是使用 Prepared statements 與參數化查詢 。 7 此技術涉及先定義 SQL 查詢結構，再將使用者提供的資料作為獨立參數傳遞。這確保資料庫將輸入嚴格視為資料而非可執行程式碼，防止任何注入的 SQL 被執行。 10 網頁應用程式防火牆 (WAFs) 也能提供額外的防禦層，透過過濾惡意流量並在到達應用程式前阻擋已知的 SQL Injection模式。 10 遵循 最小權限原則 為資料庫帳戶設定權限是另一重要的緩解策略。透過限制應用程式用於連接到資料庫的資料庫使用者權限，可將成功 SQL Injection攻擊的潛在損害降至最低。 10 定期進行 安全審計與滲透測試 對於主動識別漏洞至關重要，以免被攻擊者利用。 10 在開發生命週期早期實施 威脅建模與漏洞評估 有助於識別潛在攻擊途徑與安全漏洞，允許及時緩解。 10 監控使用者行為以發現資料庫互動中的異常也能幫助檢測正在進行的 SQL Injection攻擊。 10 限制資料庫查詢返回的記錄數量並實施分頁可減少攻擊者在成功注入時能提取的資料量。 10 最後，保持所有軟體（包括作業系統、網頁伺服器、應用程式框架與資料庫管理系統）更新至最新的安全更新程式至關重要。 10

防止 SQL Injection與類型相關問題的安全開發實踐

防止 SQL Injection的最佳實踐

要有效防止 SQL Injection漏洞，開發者應在整個軟體開發生命週期中採納一系列安全編碼實踐。 20 最關鍵的實踐是 始終使用 Prepared statements 或參數化查詢 進行資料庫互動。 20 這確保使用者提供的資料被視為資料而非可執行 SQL 程式碼。開發者還應 在伺服器端實施適當的輸入驗證 ，盡可能靠近資料來源。 7 在可能的情況下， 針對輸入驗證使用白名單 ，特別是對於不可參數化的輸入（如表格或欄位名稱），以將接受的值限制在預定義的安全選項集。 11 對資料庫帳戶 應用最小權限原則 也至關重要，僅授予應用程式運作所需的必要權限。 20 開發者應 避免使用字串拼接動態建構 SQL 查詢 ，因為這是 SQL Injection漏洞的主要來源。 7 應定期進行程式碼審查與安全審計，以識別並解決潛在的 SQL Injection缺陷。 10 考慮使用 物件關係映射器 (ORMs) 也可能有益，因為它們通常以安全方式處理查詢建構，抽象化直接與 SQL 的互動。 11 最後，建議在生產環境中 禁用詳細的資料庫錯誤訊息 ，因為這些訊息有時可能為攻擊者提供有關資料庫結構的寶貴資訊。 7

穩健類型處理與資料驗證策略

為減輕與寬鬆類型處理相關的安全問題，開發者應採用特定的穩健類型處理與資料驗證策略。 5 在 強類型語言 中，開發者應利用類型系統本身強制資料類型，確保變數與參數為預期類型。 5 在 寬鬆類型語言 中，類型強制較不嚴格，開發者必須在將資料用於安全敏感操作（如建構 SQL 查詢）前執行明確的類型檢查與轉換。 5 為輸入參數定義並強制執行資料架構也有助於確保應用程式接收到預期的類型與格式的資料。使用資料驗證庫可進一步協助驗證輸入是否符合所需類型與格式，並清理資料以防止意外行為。開發者在使用未類型化的資料結構（如字典或映射）時應格外小心，特別是當這些結構包含使用者控制的輸入並將在資料庫互動中使用時。 2 在適當的情況下，考慮使用像 TypeScript 這樣的類型安全語言（它為 JavaScript 添加了靜態類型），可以在開發階段捕捉類型相關錯誤，避免它們在生產環境中被利用。 17

安全編碼指南、程式碼審查與靜態分析工具的重要性

建立並遵循專門針對 SQL Injection與類型處理的安全編碼指南，對防止這類漏洞至關重要。這些指南應提供明確的指示與安全實踐範例，例如強制使用參數化查詢與正確處理資料類型。進行徹底的程式碼審查，特別專注於識別潛在安全漏洞，是另一關鍵步驟。程式碼審查者應接受專門培訓，以尋找常見的 SQL Injection模式與寬鬆類型處理可能引入風險的情況。使用靜態分析安全測試 (SAST) 工具能顯著提升識別潛在漏洞的過程。這些工具可自動掃描程式庫，找出已知的 SQL Injection模式與類型相關問題，為開發者提供早期警告，讓他們在應用程式部署前解決這些缺陷。 22 將這些工具整合到開發流程中，有助於確保在整個軟體開發生命週期中都考慮到安全性。