在今年的黑帽大會上James Kettle 講解了《Server-Side Template Injection: RCE for the modern webapp》，從服務(wù)端模板注入的形成到檢測，再到驗證和利用都進行了詳細的介紹。本文在理解原文內(nèi)容的基礎(chǔ)上，結(jié)合更為具體的示例對服務(wù)端模板注入的原理和掃描檢測方法做一個淺析。

一、模板注入與常見Web注入

就注入類型的漏洞來說，常見 Web 注入有：SQL 注入，XSS 注入，XPATH 注入，XML 注入，代碼注入，命令注入等等。注入漏洞的實質(zhì)是服務(wù)端接受了用戶的輸入，未過濾或過濾不嚴謹執(zhí)行了拼接了用戶輸入的代碼，因此造成了各類注入。下面這段代碼足以說明這一點：

// SQL 注入
$query = "select * from sometable where id=".$_GET['id'];
mysql_query($query);------------- 華麗的分割線 -------------// 模版注入
$temp->render("Hello ".$_GET['username']);

而服務(wù)端模板注入和常見Web注入的成因一樣，也是服務(wù)端接收了用戶的輸入，將其作為 Web 應(yīng)用模板內(nèi)容的一部分，在進行目標編譯渲染的過程中，執(zhí)行了用戶插入的惡意內(nèi)容，因而可能導(dǎo)致了敏感信息泄露、代碼執(zhí)行、GetShell 等問題。其影響范圍主要取決于模版引擎的復(fù)雜性。

二、模板注入原理

模板注入涉及的是服務(wù)端Web應(yīng)用使用模板引擎渲染用戶請求的過程，這里我們使用 PHP 模版引擎 Twig 作為例子來說明模板注入產(chǎn)生的原理?？紤]下面這段代碼：

render("Hello {{name}}", array("name" => $_GET["name"]));  // 將用戶輸入作為模版變量的值
echo $output;

使用 Twig 模版引擎渲染頁面，其中模版含有 {{name}} 變量，其模版變量值來自于 GET 請求參數(shù) $_GET["name"] 。顯然這段代碼并沒有什么問題，即使你想通過 name 參數(shù)傳遞一段 JavaScript 代碼給服務(wù)端進行渲染，也許你會認為這里可以進行 XSS，但是由于模版引擎一般都默認對渲染的變量值進行編碼和轉(zhuǎn)義，所以并不會造成跨站腳本攻擊：

但是，如果渲染的模版內(nèi)容受到用戶的控制，情況就不一樣了。修改代碼為：

render("Hello {$_GET['name']}");  // 將用戶輸入作為模版內(nèi)容的一部分
echo $output;

上面這段代碼在構(gòu)建模版時，拼接了用戶輸入作為模板的內(nèi)容，現(xiàn)在如果再向服務(wù)端直接傳遞 JavaScript 代碼，用戶輸入會原樣輸出，測試結(jié)果顯而易見：

對比上面兩種情況，簡單的說服務(wù)端模板注入的形成終究還是因為服務(wù)端相信了用戶的輸出而造成的(Web安全真諦：永遠不要相信用戶的輸入!)。當然了，第二種情況下，攻擊者不僅僅能插入 JavaScript 腳本，還能針對模板框架進行進一步的攻擊，此部分只說明原理，在后面會對攻擊利用進行詳細說明和演示。

三、模板注入檢測

上面已經(jīng)講明了模板注入的形成原來，現(xiàn)在就來談?wù)剬ζ溥M行檢測和掃描的方法。如果服務(wù)端將用戶的輸入作為了模板的一部分，那么在頁面渲染時也必定會將用戶輸入的內(nèi)容進行模版編譯和解析最后輸出。

借用本文第二部分所用到的代碼：

render("Hello {$_GET['name']}");  // 將用戶輸入作為模版內(nèi)容的一部分
echo $output;

在 Twig 模板引擎里，{{ var }} 除了可以輸出傳遞的變量以外，還能執(zhí)行一些基本的表達式然后將其結(jié)果作為該模板變量的值，例如這里用戶輸入 name={{2*10}} ，則在服務(wù)端拼接的模版內(nèi)容為：

Hello {{2*10}}

Twig 模板引擎在編譯模板的過程中會計算 {{2*10}} 中的表達式 2*10 ，會將其返回值 20 作為模板變量的值輸出，如下圖：

現(xiàn)在把測試的數(shù)據(jù)改變一下，插入一些正常字符和 Twig 模板引擎默認的注釋符，構(gòu)造 Payload 為：

IsVuln{# comment #}{{2*8}}OK

實際服務(wù)端要進行編譯的模板就被構(gòu)造為：

Hello IsVuln{# comment #}{{2*8}}OK

這里簡單分析一下，由于 {# comment #} 作為 Twig 模板引擎的默認注釋形式，所以在前端輸出的時候并不會顯示，而 {{2*8}} 作為模板變量最終會返回 16 作為其值進行顯示，因此前端最終會返回內(nèi)容 Hello IsVuln16OK ，如下圖：

通過上面兩個簡單的示例，就能得到 SSTI 掃描檢測的大致流程(這里以 Twig 為例)：

同常規(guī)的 SQL 注入檢測，XSS 檢測一樣，模板注入漏洞的檢測也是向傳遞的參數(shù)中承載特定 Payload 并根據(jù)返回的內(nèi)容來進行判斷的。每一個模板引擎都有著自己的語法，Payload 的構(gòu)造需要針對各類模板引擎制定其不同的掃描規(guī)則，就如同 SQL 注入中有著不同的數(shù)據(jù)庫類型一樣。

簡單來說，就是更改請求參數(shù)使之承載含有模板引擎語法的 Payload，通過頁面渲染返回的內(nèi)容檢測承載的 Payload 是否有得到編譯解析，有解析則可以判定含有 Payload 對應(yīng)模板引擎注入，否則不存在 SSTI。

四、小結(jié)

本文簡單介紹服務(wù)端模版注入漏洞如常規(guī) Web 注入漏洞之間的關(guān)系，分析了其產(chǎn)生的原理，并以 PHP 模板引擎 Twig 為例講解了 SSTI 常規(guī)的掃描和檢測方法。雖然說 SSTI 并不廣泛存在，但如果開發(fā)人員濫用模板引擎，進行不安全的編碼，這樣 Web 應(yīng)用就可能出現(xiàn) SSTI，并且根據(jù)其模板引擎的復(fù)雜性和開發(fā)語言的特性，可能會造成非常嚴重的問題。

在后續(xù)的文章中會針對各語言流行的模板引擎做一個較為詳細的研究和分析，給出對應(yīng)的可利用點和方法。

本文題目：服務(wù)端模板注入攻擊(SSTI)的原理和掃描檢測方法
當前鏈接：http://uogjgqi.cn/article/dhpdogo.html