服務器端模板注入攻擊(SSTI) 是指威脅行為者利用模板的本機語法并將惡意負載注入模板。然后在服務器端執行受損模板。模板引擎通過將固定模板與易變數據相結合來生成網頁。
攻擊者使用服務器端模板注入技術將用戶輸入直接插入模板，允許他們引入任意指令來改變模板引擎的行為。它可以讓威脅行為者獲得對目標服務器的完全控制。
服務器端模板注入有什么影響？
服務器端模板注入漏洞可能會使網站遭受各種攻擊，具體取決于模板引擎的類型及其與應用程序的工作方式。在極少數情況下，這些漏洞不會構成真正的安全風險。然而，在大多數情況下，SSTI 攻擊的影響是嚴重的。
在最嚴重的情況下，攻擊者可以遠程執行代碼并完全接管后端服務器。然后他們可以使用這些服務器對內部基礎設施發起額外的攻擊。即使攻擊者無法遠程執行代碼，他們也可能能夠讀取存儲在服務器上的敏感數據或文件。具有讀取權限的攻擊者仍然可以使用 SSTI 作為許多其他攻擊的基礎。
如何檢測 SSTI 漏洞
純文本與基于代碼的 SSTI 檢測
SSTI 漏洞可能出現在需要不同檢測技術的兩種情況下。
純文本 SSTI 檢測
測試人員可以通過使用模板表達式作為不同模板引擎使用的有效載荷來檢測純文本上下文中的 SSTI 漏洞。然后，引擎可以在錯誤消息中查看服務器的 HTTP 響應。
常見模板表達式的一些示例包括：
通用模板表達式
基于代碼的 SSTI 檢測
測試人員可以通過構建有效負載來檢索錯誤或空白服務器響應，從而在代碼上下文中測試 SSTI 漏洞。
例如，測試人員可以使用模板語句中的personal_greeting變量在 HTTP 請求中插入 GET 參數。負載服務器將以空白的“Hello”響應：
personal_greeting=用戶名 用戶 01 您好
接下來，測試人員可以在使用以下有效負載后注入 HTML 標記以中斷語句：
personal_greeting=用戶名}<tag> 你好 user01 <標簽>
當測試人員識別出注入點后，就可以根據相關的模板表達式來識別模板引擎。
輸入中使用的惡意或格式錯誤的有效負載決定了測試人員是否會識別SSTI?。服務器可能會顯示錯誤消息或標記異常。
例如，測試人員可以通過在用戶輸入參數中注入以下有效負載來檢測漏洞：
POST /some-endpoint HTTP/1.1
主機：victim-website.com
參數=${{<%[%'"}}%\.
如果存在漏洞，服務器將響應一個反映模板引擎的錯誤消息。
識別模板引擎
一旦測試人員檢測到模板注入，他們必須確定使用了哪個模板引擎。此步驟可能很簡單，測試人員提交無效語法，使模板引擎在生成的錯誤消息中識別自己。在某些情況下，這種技術是不夠的，因為某些東西會抑制錯誤消息。它也不適合自動化。
或者，測試人員可以使用 Burp Suite 中的決策樹自動執行識別步驟。該樹可以映射特定于語言的有效載荷，紅色和綠色箭頭代表失敗和成功的響應。有時，單個負載可能有多個成功響應，例如 {{7*'7'}} 探測在 Jinja2 中產生 7777777，在 Twig 中產生 49。
利用漏洞
識別模板注入和底層模板引擎后，測試人員必須嘗試閱讀文檔。此步驟對于識別零日攻擊和驗證攻擊者是否可以利用 SSTI 漏洞?很重要。
主要興趣點是：
- “對于模板作者”部分——本部分介紹基本語法。
- “安全注意事項”部分——應用程序的開發人員可能跳過了這部分，這可能會提供有用的安全見解。
- 內置功能列表——這應該包括內置函數、方法、變量和過濾器。
- 擴展和插件列表——這可能包括默認啟用的外部功能。
如果在這個階段沒有明顯的漏洞利用，那么測試人員應該檢查環境的可訪問性范圍。此步驟可能會揭示模板引擎提供的默認對象和開發人員傳遞給模板的特定于應用程序的對象。一些模板系統可能公開一個名稱空間或“自我”對象，允許開發人員列出對象的方法和屬性。
開發人員提供的對象更有可能包含敏感數據，并且在應用程序中的多個模板之間可能會有所不同。因此，測試人員應將此過程分別應用于每個模板。
到目前為止，測試人員應該清楚地了解可用的攻擊面。最后一步是應用傳統的安全審計方法來審查每個功能并識別攻擊者可能利用的漏洞。測試人員應將此步驟作為整體應用程序安全的一部分。某些功能可能允許攻擊者利用特定于應用程序的功能。
服務器端模板注入攻擊防護
從服務器上完全刪除模板引擎通常是不可接受的，因為它支持應用程序更改而不會中斷正在進行的操作。因此，學習如何在防止 SSTI 的同時安全地使用模板非常重要。
限制“編輯”訪問
對所有人開放的模板很容易成為黑客的目標。因此，最好通過對模板文件應用訪問規則來限制訪問。防止模板被開發人員和管理員以外的任何人修改是至關重要的。此外，生產中使用的模板只能由負責服務器或應用程序的特定管理員訪問，而不應由開發人員訪問。這可以降低供應鏈攻擊和內部威脅的風險。
清理輸入
滅菌可以顯著降低 SSTI 攻擊的風險。模板應檢查所有預期輸入是否存在破壞性元素。如果可能，該模板應使用白名單方法來僅允許用戶期望的輸入，并拒絕其他所有內容。一種常見的方法是使用正則表達式來創建允許的輸入模式列表。雖然輸入清理很重要，但它是有限的，攻擊者有許多創造性的方法來規避它并創建符合允許模式的惡意輸入。因此，該解決方案不能保證完全保護。
沙盒
沙盒是一種比清理更安全的方法。這是一種預防措施，可為用戶創建安全、隔離的環境。在這個環境中，沒有危險的功能或模塊，并且對其他數據的訪問受到限制。這意味著如果發現漏洞或用戶嘗試攻擊，損害是有限的。對模板進行沙箱處理是一種非常有效的措施，但實施起來卻很困難。此外，攻擊者可以利用錯誤配置或嘗試提升權限以突破沙盒環境，從而避開沙盒。
無邏輯模板
也許最安全的方法是使用無邏輯模板。這些是將代碼解釋與視覺表示完全分開的模板。無邏輯模板引擎的一個例子是 Mustache。無邏輯模板使用控制流語句來確保控件在默認情況下是數據驅動的，從而實現與應用程序邏輯的集成。在此設置中，遠程代碼執行的可能性變得非常小。
