0x00 命令注入

payload:

127.0.0.1 | ipconfig

13||ipconfig

127.0.0.1&ipconfig

127.0.0.1&&ipconfig

上面的方式主要是通過管道符讓系統執行了命令。‘

以下是常用的管道符：

0x01 windows系列支援的管道符

| 直接執行後面的語句

|| 如果前面執行的語句出錯，則執行後面的語句，前面的語句只能為假

& 如果前面的語句為假則直接執行後面的語句，前面的語句可假可真

&& 如果前面的語句為假則直接出錯，也不執行後面的語句，前面的語句只能為真

0x02 linux支援的管道符：

; 執行完前面的語句再執行後面的語句

| 顯示後面語句執行的結果

|| 當前面的語句執行出錯時，執行後面的語句

& 如果前面的語句為假則直接執行後面的語句，前面的語句可假可真

&& 如果前面的語句為假則直接出錯，也不執行後面的，前面的語句只能為真

0x01php程式碼注入

0x01 挑戰1

由下圖可以看出，頁面直接輸出了url中的引數data的值，

檢測是否會造成程式碼執行，

可以看到，這裡存在命令注入漏洞

0x02 挑戰2

頁面將data引數的值轉換為大寫輸出到了頁面

再次測試，是否存在命令執行

payload：http://127.0.0.1/btslab/vulnerability/phpinjection/challenge2.php?data=phpinfo()

可以看到，伺服器並沒有解析執行，

再次嘗試：http://127.0.0.1/btslab/vulnerability/phpinjection/challenge2.php?data=<?php phpinfo();?>，發現頁面沒有輸出，說明伺服器存在過濾

payload：http://127.0.0.1/btslab/vulnerability/phpinjection/challenge2.php?data=${phpinfo()}

程式碼注入成功執行。

我們看看原始碼

其中最關鍵的就是preg_replace()函式。

其實最關鍵的還是正則表示式中的/e引數，正是由於該引數，preg_replace

其實就是一句話，當正則表示式中存在/e引數時，preg_replace函式中的第二個引數replacement就會被當做是eval函式的引數來執行，這就是造成程式碼執行的原因所在。正是由於這個原因，所以在php版本的更新中可以看到，這個函式已經用 preg_replace_callback() 代替。

但是這裡還有一個問題，如果有留意就會發現：

http://127.0.0.1/btslab/vulnerability/phpinjection/challenge2.php?data=phpinfo()沒有程式碼執行；

http://127.0.0.1/btslab/vulnerability/phpinjection/challenge2.php?data=${phpinfo()}則會造成程式碼執行。

why???

兩個請求的差別就在於${}，還是不明，why???

我們先看看，去掉e，正則匹配到的結果是啥，我們將之打印出來

可以從上圖清楚的看到，正則匹配的結果是strtoupper("${phpinfo()}")，即在e匹配模式下，傳遞到eval()函式中的引數是strtoupper("${phpinfo()}")，所以最終的結果就是eval(strtoupper("${phpinfo()}"))這條語句執行的結果，

所以，這就是preg_replace函式會造成程式碼執行的根本原因。

為了對比，我們看看http://127.0.0.1/btslab/vulnerability/phpinjection/challenge2.php?data=phpinfo()，

正則匹配結果：strtoupper("phpinfo()")

執行結果eval(strtoupper("phpinfo()"))，函式phpinfo()並沒有並解析執行