這次 Code-Breaking Puzzles 中我出了一道看似很簡單的題目pcrewaf，將其代碼簡化如下：

<?php 
function is_php($data){   
    return preg_match('/<\?.*[(`;?>].*/is', $data);   
} 
 
if(!is_php($input)) { 
    // fwrite($f, $input); ... 
} 

大意是判斷一下用戶輸入的內(nèi)容有沒有 PHP 代碼，如果沒有，則寫入文件。這種時候，如何繞過 is_php() 函數(shù)來寫入 webshell 呢?

這道題看似簡單，深究其原理，還是值得寫一篇文章的。

一、正則表達式是什么

正則表達式是一個可以被「有限狀態(tài)自動機」接受的語言類。

「有限狀態(tài)自動機」，其擁有有限數(shù)量的狀態(tài)，每個狀態(tài)可以遷移到零個或多個狀態(tài)，輸入字串決定執(zhí)行哪個狀態(tài)的遷移。

而常見的正則引擎，又被細分為 DFA(確定性有限狀態(tài)自動機)與 NFA(非確定性有限狀態(tài)自動機)。他們匹配輸入的過程分別是：

• DFA：從起始狀態(tài)開始，一個字符一個字符地讀取輸入串，并根據(jù)正則來一步步確定至下一個轉(zhuǎn)移狀態(tài)，直到匹配不上或走完整個輸入
• NFA：從起始狀態(tài)開始，一個字符一個字符地讀取輸入串，并與正則表達式進行匹配，如果匹配不上，則進行回溯，嘗試其他狀態(tài)

由于 NFA 的執(zhí)行過程存在回溯，所以其性能會劣于 DFA，但它支持更多功能。大多數(shù)程序語言都使用了 NFA 作為正則引擎，其中也包括 PHP 使用的 PCRE 庫。

二、回溯的過程是怎樣的

所以，我們題目中的正則 <\?.*[(`;?>].*，假設(shè)匹配的輸入是

見上圖，可見第 4 步的時候，因為第一個 .* 可以匹配任何字符，所以最終匹配到了輸入串的結(jié)尾，也就是 //aaaaa。但此時顯然是不對的，因為正則顯示.*后面還應(yīng)該有一個字符 [(`;?>]。

所以 NFA 就開始回溯，先吐出一個 a，輸入變成第 5 步顯示的 //aaaa，但仍然匹配不上正則，繼續(xù)吐出 a，變成 //aaa，仍然匹配不上……

最終直到吐出;，輸入變成第 12 步顯示的 ] ，這個結(jié)果滿足正則表達式的要求，于是不再回溯。13 步開始向后匹配;，14 步匹配.*，第二個.*匹配到了字符串末尾，最后結(jié)束匹配。

在調(diào)試正則表達式的時候，我們可以查看當前回溯的次數(shù)：

這里回溯了 8 次。

三、PHP 的 pcre.backtrack_limit 限制利用

PHP 為了防止正則表達式的拒絕服務(wù)攻擊(reDOS)，給 pcre 設(shè)定了一個回溯次數(shù)上限 pcre.backtrack_limit。我們可以通過 var_dump(ini_get(‘pcre.backtrack_limit’));的方式查看當前環(huán)境下的上限：

這里有個有趣的事情，就是 PHP 文檔中，中英文版本的數(shù)值是不一樣的：

我們應(yīng)該以英文版為參考。

可見，回溯次數(shù)上限默認是 100 萬。那么，假設(shè)我們的回溯次數(shù)超過了 100 萬，會出現(xiàn)什么現(xiàn)象呢?比如：

可見，preg_match 返回的非 1 和 0，而是 false。

preg_match 函數(shù)返回 false 表示此次執(zhí)行失敗了，我們可以調(diào)用 var_dump(preg_last_error() === PREG_BACKTRACK_LIMIT_ERROR);，發(fā)現(xiàn)失敗的原因的確是回溯次數(shù)超出了限制：

所以，這道題的答案就呼之欲出了。我們通過發(fā)送超長字符串的方式，使正則執(zhí)行失敗，最后繞過目標對 PHP 語言的限制。

對應(yīng)的 POC 如下：

import requests 
from io import BytesIO 
 
files = { 
  'file': BytesIO(b'aaa<?php eval($_POST[txt]);//' + b'a' * 1000000) 
} 
 
res = requests.post('http://51.158.75.42:8088/index.php', filesfiles=files, allow_redirects=False) 
print(res.headers) 

四、PCRE 另一種錯誤的用法

延伸一下，很多基于 PHP 的 WAF，如：

<?php 
if(preg_match('/SELECT.+FROM.+/is', $input)) { 
    die('SQL Injection'); 
} 

均存在上述問題，通過大量回溯可以進行繞過。

另外，我遇到更常見的一種 WAF 是：

<?php 
if(preg_match('/UNION.+?SELECT/is', $input)) { 
    die('SQL Injection'); 
} 

這里涉及到了正則表達式的「非貪婪模式」。在 NFA 中，如果我輸入 UNION/*aaaaa*/SELECT，這個正則表達式執(zhí)行流程如下：

• .+? 匹配到/
• 因為非貪婪模式，所以.+? 停止匹配，而由 S 匹配*
• S 匹配*失敗，回溯，再由.+? 匹配*
• 因為非貪婪模式，所以.+? 停止匹配，而由 S 匹配 a
• S 匹配 a 失敗，回溯，再由.+? 匹配 a
• …

回溯次數(shù)隨著 a 的數(shù)量增加而增加。所以，我們?nèi)匀豢梢酝ㄟ^發(fā)送大量 a，來使回溯次數(shù)超出 pcre.backtrack_limit 限制，進而繞過 WAF：

五、修復(fù)方法

那么，如何修復(fù)這個問題呢?

其實如果我們仔細觀察 PHP 文檔，是可以看到 preg_match 函數(shù)下面的警告的：

如果用 preg_match 對字符串進行匹配，一定要使用===全等號來判斷返回值，如：

<?php 
function is_php($data){   
    return preg_match('/<\?.*[(`;?>].*/is', $data);   
} 
 
if(is_php($input) === 0) { 
    // fwrite($f, $input); ... 
} 

這樣，即使正則執(zhí)行失敗返回 false，也不會進入 if 語句。