背景：
產品有個通過正則表達式驗證用戶輸入電話號碼是否合法的功能（沒有約束輸入號碼的長度），研發人員寫的正在表達式（java代碼）：regexp="^[+]?(\\d+)((-?|\\s?)\\d+)*$"，被別人測出來存在正則表達式回溯的漏洞，即輸入很長一段字符，觸發正則回溯后，導致CPU占用達到200%。搜了下相關資料，梳理下這個漏洞的發生原因如下。
1. 正則表達式引擎
說起回溯陷阱，要先從正則表達式的引擎說起。正則引擎主要可以分為基本不同的兩大類：一種是DFA（確定型有窮自動機），另一種是NFA（不確定型有窮自動機）。簡單來講，NFA 對應的是正則表達式主導的匹配，而 DFA 對應的是文本主導的匹配。
DFA從匹配文本入手，從左到右，每個字符不會匹配兩次，它的時間復雜度是多項式的，所以通常情況下，它的速度更快，但支持的特性很少，不支持捕獲組、各種引用等等；而NFA則是從正則表達式入手，不斷讀入字符，嘗試是否匹配當前正則，不匹配則吐出字符重新嘗試，通常它的速度比較慢，最優時間復雜度為多項式的，最差情況為指數級的。但NFA支持更多的特性，因而絕大多數編程場景下（包括java，js），我們面對的是NFA。以下面的表達式和文本為例，
- text ＝ ‘after tonight’ regex ＝ ‘to(nite|nighta|night)’
在NFA匹配時候，是根據正則表達式來匹配文本的，從t開始匹配a，失敗，繼續，直到文本里面的第一個t，接着比較o和e，失敗，正則回退到 t，繼續，直到文本里面的第二個t，然后 o和文本里面的o也匹配，繼續，正則表達式后面有三個可選條件，依次匹配，第一個失敗，接着二、三，直到匹配。
而在DFA匹配時候，采用的是用文本來匹配正則表達式的方式，從a開始匹配t，直到第一個t跟正則的t匹配，但e跟o匹配失敗，繼續，直到文本里面的第二個 t 匹配正則的t，接着o與o匹配，n的時候發現正則里面有三個可選匹配，開始並行匹配，直到文本中的g使得第一個可選條件不匹配，繼續，直到最后匹配。
可以看到，DFA匹配過程中文本中的字符每一個只比較了一次，沒有吐出的操作，應該是快於NFA的。另外，不管正則表達式怎么寫，對於DFA而言，文本的匹配過程是一致的，都是對文本的字符依次從左到右進行匹配，所以，DFA在匹配過程中是跟正則表達式無關的，而 NFA 對於不同但效果相同的正則表達式，匹配過程是完全不同的。
2. 回溯
說完了引擎，我們來看看什么是回溯。先來看個例子：
Round 1
假設有正則表達式 /^(a*)b$/ 和字符串 aaaaab。如果用該正則匹配這個字符串會得到什么呢？
答案很簡單。兩者匹配，且捕獲組捕獲到字符串 aaaaa。
Round 2
這次讓我們把正則改寫成 /^(a*)ab$/。再次和字符串 aaaaab 匹配。結果如何呢？
兩者依然匹配，但捕獲組捕獲到字符串 aaaa。因為捕獲組后續的表達式占用了 1 個 a 字符。但是你有沒有考慮過這個看似簡單結果是經過何種過程得到的呢？
讓我們一步一步來看：
- 匹配開始
(a*)捕獲盡可能多的字符a。 (a*)一直捕獲，直到遇到字符b。這時(a*)已經捕獲了aaaaa。- 正則表達式繼續執行
(a*)之后的ab匹配。但此時由於字符串僅剩一個b字符。導致無法完成匹配。 (a*)從已捕獲的字符串中“吐”出一個字符a。這時捕獲結果為aaaa，剩余字符串為ab。- 重新執行正則中
ab的匹配。發現正好與剩余字符串匹配。整個匹配過程結束。返回捕獲結果aaaa。
從第3，4步可以看到，暫時的無法匹配並不會立即導致整體匹配失敗。而是會從捕獲組中“吐出”字符以嘗試。這個“吐出”的過程就叫回溯。
回溯並不僅執行一次，而是會一直回溯到另一個極端。對於 * 符號而言，就是匹配 0 次的情況。
Round 3
這次我們把正則改為 /^(a*)aaaab$/。字符串依然為 aaaaab。根據前邊的介紹很容易直到。此次要回溯 4 次才可以完成匹配。具體執行過程不再贅述。
悲觀回溯
了解了回溯的工作原理，再來看悲觀回溯就很容易理解了。
Round 4
這次我們的正則改為 /^(a*)b$/。但是把要匹配的字符串改為 aaaaa。去掉了結尾的字符 b。
讓我們看看此時的執行流程：
(a*)首先匹配了所有aaaaa。- 嘗試匹配
b。但是匹配失敗。 - 回溯 1 個字符。此時剩余字符串為
a。依然無法匹配字符b。 - 回溯一直進行。直到匹配 0 次的情況。此時剩余字符串為
aaaaa。依然無法匹配b。 - 所有的可能性均已嘗試過，依然無法匹配。最終導致整體匹配失敗。
可以看到，雖然我們可以一眼看出二者無法匹配。但正則表達式在執行時還要“傻傻的”逐一回溯所有可能性，才能確定最終結果。這個“傻傻的”回溯過程就叫悲觀回溯。
3. 貪婪、懶惰與獨占
我們再來看一下究竟什么是貪婪模式。
下面的幾個特殊字符相信大家都知道它們的用法：
i. ?: 告訴引擎匹配前導字符0次或一次。事實上是表示前導字符是可選的。
ii. +: 告訴引擎匹配前導字符1次或多次。
iii. *: 告訴引擎匹配前導字符0次或多次。
iv. {min, max}: 告訴引擎匹配前導字符min次到max次。min和max都是非負整數。如果有逗號而max被省略了，則表示max沒有限制；如果逗號和max都被省略了，則表示重復min次。
默認情況下，這個幾個特殊字符都是貪婪的，也就是說，它會根據前導字符去匹配盡可能多的內容。這也就解釋了為什么在第3部分的例子中，第3步以后的事情會發生了。
在以上字符后加上一個問號（？）則可以開啟懶惰模式，在該模式下，正則引擎盡可能少的重復匹配字符，匹配成功之后它會繼續匹配剩余的字符串。在上例中，如果將正則換為
- ab{1,3}?c
則匹配過程變成了下面這樣（橙色為匹配，黃色為不匹配），
由此可見，在非貪婪模式下，第2步正則中的b{1,3}?與文本b匹配之后，接着去用c與文本中的c進行匹配，而未發生回溯。
如果在以上四種表達式后加上一個加號（+），則會開啟獨占模式。同貪婪模式一樣，獨占模式一樣會匹配最長。不過在獨占模式下，正則表達式盡可能長地去匹配字符串，一旦匹配不成功就會結束匹配而不會回溯。我們以下面的表達式為例，
- ab{1,3}+bc
如果我們用文本"abbc"去匹配上面的表達式，匹配的過程如下圖所示（橙色為匹配，黃色為不匹配），
可以發現，在第2和第3步，b{1,3}+會將文本中的2個字母b都匹配上，結果文本中只剩下一個字母c。那么在第4步時，正則中的b和文本中的c進行匹配，當無法匹配時，並不進行回溯，這時候整個文本就無法和正則表達式發生匹配。如果將正則表達式中的加號（+）去掉，那么這個文本整體就是匹配的了。
把以上三種模式的表達式列出如下，
| 貪婪 |
懶惰 |
獨占 |
| X? |
X?? |
X?+ |
| X* |
X*? |
X*+ |
| X+ |
X+? |
X++ |
| X{n} |
X{n}? |
X{n}+ |
| X{n,} |
X{n,}? |
X{n,}+ |
| X{n,m} |
X{n,m}? |
X{n,m}+ |
4. 總結
現在再回過頭看看研發人員寫的那個電話號碼的正則表達式
- regexp="^[+]?(\\d+)((-?|\\s?)\\d+)*$"
如果這里我們輸入很長的一串字符“123123123123123123123……………………89a”，先匹配^[+]與第一個數字1，沒有匹配到，在匹配（\d+）與第一個數字1，因為貪婪匹配，一直要匹配到最后的字母a，\d+不在匹配上。
第一次回溯：
這時候就要把這時候把a前面的數字“9”吐出來，前面的所有數字“123123123123123123123……………………8”匹配了正則表達式的前半部分"^[+]?(\\d+)”，剩下的就是“9a”與“((-?|\\s?)\\d+)”進行匹配，“9”可以與后面的“\d+”匹配，剩下"a"又沒有匹配。
第二次回溯：
把8也吐出來，同樣前面的所有數字“123123123123123123123……………………”匹配了正則表達式的前半部分"^[+]?(\\d+)”，剩下的就是"89a"與正則表達式的后半部分就行匹配，“\d+”貪婪匹配，匹配到“89”，剩余“a”，沒有匹配到。這時候需要注意啦，后半部分的正則也要進行回溯啦。也就是“89”要做一次回溯，“8”與“((-?|\\s?)\\d+)”的“\d+”匹配，剩余"9a"沒法匹配，所以其實第二次回溯進行了2次。
以此類推，
第三次回溯：
實際回溯了3次
以此類推……
一共回溯了（1+N）*N/2，當N=500的時候，一共回溯了12萬5千多次。所以一旦發生回溯，計算量將是巨大的，所以導致CUP占用超過200%。
因此，在自己寫正則表達式的時候，一定不能大意，在實現功能的情況下，還要仔細考慮是否會帶來性能隱患。