授權與合規(guī)聲明本文全部操作對象均為自建隔離靶場本機容器或隔離虛擬機涉及安全測試的環(huán)節(jié)必須以取得合法授權為前提。未經(jīng)授權的滲透測試違反《中華人民共和國網(wǎng)絡安全法》與《刑法》相關條款須承擔相應法律責任。本文只講環(huán)境配置、版本對照與靶場隔離不含任何攻擊步驟、利用載荷與繞過手法請勿將文中環(huán)境指向任何非自有系統(tǒng)。一、先看現(xiàn)象同一條正則短輸入秒回、長輸入不動1.1 轉圈的那幾十秒日志里什么都沒留下一個再普通不過的字段校驗。用戶提交一段「備注」后端先過一條正則確認文本的構成符合約定。這條正則寫在validate()里一行注釋只有四個字只允許字母。上線前你自己試過空串、一個字母、帶數(shù)字的、帶中文的全部一次通過耗時看不出差別。然后某個工作日的下午接口開始轉圈。不是所有請求都慢是偶發(fā)的一兩個。用戶并沒有做什么特別的操作他只是把一份文檔里的一大段說明文字粘進了備注框——不是為了攻擊你是真的想提交這段備注。請求發(fā)出去前端一直等網(wǎng)關在預定的時間點把連接掐斷應用日志里有「請求開始」沒有「請求結束」機器上那條 CPU 曲線在那幾十秒里有一個很尖的峰隨后落回去。重啟之后一切恢復正常你拿同樣的賬號、同樣的瀏覽器再提交一次怎么都復現(xiàn)不出來。1.2 把「感覺慢」換成一張表復現(xiàn)不出來的原因是觸發(fā)條件不在「請求」這一層而在「輸入」這一層它要同時滿足兩個條件——足夠長并且以一個讓匹配失敗的方式結束。你手工重試時粘的是能通過的那段走的全是快路徑自然看不出問題。要判斷這類問題不用讀引擎源碼只要把長度當成唯一變量。固定模式、固定機器、固定輸入的字符構成只改長度每一檔跑多輪取中位數(shù)。下面這張表是 2026-10-25 在本機跑出來的結果模式是一條用于校驗「整段只由同一種字符組成」的表達式輸入是本地合成的字符串末尾多加一個不屬于該類字符的符號使它必然匹配失敗。連續(xù)字符個數(shù) n平均耗時毫秒相對上一檔140.38—161.49×3.9185.83×3.92021.80×3.72282.94×3.8上表為本機實測CPython 3.13 macOS輸入全部是本地合成的字符串不指向任何在線服務數(shù)值隨機器變化倍數(shù)關系不變。讀這張表別讀毫秒讀最后一列。四檔的比值都落在 3.7 到 3.9 之間非常穩(wěn)定每加 2 個字符耗時乘 4。也就是說每加 1 個字符耗時大約乘 2。下面這段是把測法固化成腳本的骨架模式和輸入都從腳本外部給。表里那五個數(shù)值就是照這套邏輯跑出來的腳本本身沒有再逐字復跑所以按規(guī)矩標了待驗證。??代碼待驗證importos,re,time,statistics PATTERNre.compile(os.environ[RE_PATTERN])# 待測的那一條從本地配置讀INPUTS[l.rstrip(\n)forlinopen(os.environ[RE_INPUTS])]defmeasure(text,rounds9):samples[]for_inrange(rounds):t0time.perf_counter()PATTERN.search(text)samples.append((time.perf_counter()-t0)*1000)returnstatistics.median(samples)fortextinINPUTS:print(flen{len(text):3}median{measure(text):9.3f}ms)1.3 該記住的不是毫秒是倍數(shù)毫秒數(shù)最不可遷移。同一段代碼在同事的筆記本上可能快五倍在容器里可能慢三倍——CPU 型號、主頻、是否有別的進程在搶全都在動。拿本文的 82.94 毫秒去和別人對賬沒有意義。有意義的是那個比值。它描述的是「耗時會怎么隨輸入長度變化」這是一個形態(tài)不是一次測量。形態(tài)由寫法決定不由機器決定。所以你在自己機器上測一遍只要看到「每加兩個字符乘 4」這個節(jié)奏就已經(jīng)能判定這條寫法有問題了不需要任何人的數(shù)值來背書。也正因為它是形態(tài)它才值得警惕從 n14 到 n22只多了 8 個字符耗時從 0.38 毫秒變成 82.94 毫秒差了約 218 倍。這不是「慢了一點」是兩種不同的東西。本章可以帶走的一句一條正則慢不慢不看它在短輸入上多快看它的耗時怎么隨長度變。二、回溯是什么匹配失敗之后引擎還得回頭2.1 匹配不是看一眼是一路做選擇正則引擎讀你的模式從左到右一個字符一個字符地對。凡是遇到量詞它就要做一個決定這一個「重復」我到底重復幾次把它想成走迷宮。你站在入口前面每個岔口都要選一條路。選對了繼續(xù)往前選錯了走到底發(fā)現(xiàn)是死胡同就得退回到最近的那個岔口換另一條路再走一次。這個「退回去、換條路」的動作就是回溯。關鍵在于引擎在走的時候并不知道哪條路是對的它只能靠試。所以「重復幾次」這個決定不是一次定下來的而是邊走邊改。??代碼待驗證模式允許把一段字符切成若干段每段至少一個 切法一 → 走到底 → 不通 → 退回 切法二 → 走到底 → 不通 → 退回 切法三 → …… 一次「退回」 一次回溯 走法有多少種退回就可能有多少次2.2 失敗的時候引擎要把做過的選擇全部重走一遍這就解釋了一件很多人沒想通的事為什么最慢的情況恰恰是「這條輸入不該被通過」的時候。如果輸入能匹配引擎走到某個位置發(fā)現(xiàn)「成了」就可以收工。但如果輸入注定不匹配引擎必須把所有可能的路都走完才敢下結論說「不匹配」?；厮菪鸵嬖谶@里的代價是它要把已經(jīng)做過的選擇重新走一遍而這些失敗路徑的數(shù)量可以隨輸入長度指數(shù)增長。Python 的re、Perl、PCRE、Java 的java.util.regex都屬于這一類。這句話的分量在于這是回溯的本質代價不是 bug升級依賴、換小版本、加編譯緩存都不會改變它。2.3 指數(shù)是從「有多少種走法」里長出來的指數(shù)不是玄學它可以數(shù)出來。假設輸入是 n 個一模一樣的字符而你的模式允許「把這一段切成若干段、每段至少一個」那么切法有多少種連續(xù)字符個數(shù) n所有可能的分段方式數(shù)量相對上一檔48—105126414819216181310721622209715216每一檔加 4 個字符數(shù)量乘 16——也就是每加 1 個字符乘 2每加 2 個字符乘 4。這和第一章那張計時表最后一列的 3.7 到 3.9是同一件事的兩種說法一邊是「有多少種走法」一邊是「要花多少時間」。引擎不會把每一種走法都完整走完它剪掉一部分明顯重復的分支所以真實耗時不會精確等于上表的行數(shù)但量級關系對得上。本章可以帶走的一句慢的不是匹配是匹配失敗之后那趟回頭路。三、三種放大器什么樣的寫法會把回頭路變多3.1 嵌套量詞同一段字符被反復重新切分第一種形態(tài)是量詞套著量詞。具體說一個分組本身用「一個或多個」修飾這個分組整體外面又套了一層「一個或多個」。寫成抽象的形態(tài)就是這樣??代碼待驗證( X )這里必須說清楚上面這行只是形態(tài)示意不作為可直接使用的模式。它想表達的只有一件事——外層每選一種分法內(nèi)層就得把同一段字符重新切一遍同一批字符被數(shù)了很多次。你自己代碼里真正長什么樣要看你的分組和字符集本文不給任何可以直接拿去用的完整寫法。識別方法很簡單在正則里找「右括號后緊跟量詞、而括號內(nèi)部本身也以量詞結尾」的位置。看到這種結構先假設它有問題再去測。3.2 相鄰的重疊分支兩條路通向同一個地方第二種形態(tài)是分支之間能匹配同一段字符。(A|B)這樣的選擇結構里如果 A 和 B 能吃掉同一批字符——比如一個是另一個的前綴或者兩者的字符范圍有交集——那么對同一段輸入引擎就有兩條路可走。匹配失敗的時候兩條路都得試如果這個分支后面還跟著量詞那么每一條路的每種長度組合都要各試一遍。這種形態(tài)更隱蔽因為它看起來「很正?！拐l寫校驗規(guī)則沒寫過幾個備選分支呢問題不在有分支而在分支之間有重疊且分支后面還有量詞在放大它。判斷方法把每個分支能接受的字符集合寫出來看有沒有交集。有交集且分支之后還跟著量詞就歸到這一類。3.3 無錨點全掃每個起點都當一次開頭第三種形態(tài)跟模式本身無關跟你怎么調用有關。如果一條用于「整段校驗」的正則沒有寫起點錨定而調用時用的又是「在字符串里找一處匹配」的接口那么引擎會把每一個字符位置都當成一次新的開頭各試一遍。輸入長 n就等于把前面的代價乘上 n。這一條的放大倍數(shù)最溫和——只是線性的一倍——但它最容易和前面兩種疊在一起。一個沒有錨定的、帶嵌套量詞的校驗代價是「每個起點 × 每條回頭路」兩者相乘。形態(tài)在代碼里怎么認描述不給可用寫法放大的是什么一句話識別嵌套量詞分組內(nèi)部以量詞結尾右括號外又跟一個量詞同一段字符的切分次數(shù)重復的重復重疊分支兩個分支的字符集有交集分支后還跟著量詞每個位置的可選路徑數(shù)兩條路走同一段無錨點全掃做整段校驗卻沒有起點錨定且用「找一處」的接口起點數(shù)量每個位置都當開頭本章可以帶走的一句三種形態(tài)單獨看都只是「倍數(shù)」疊在一起才是指數(shù)。四、為什么換個語言就沒事兩條不同的技術路線4.1 走回頭路和不走回頭路正則的實現(xiàn)有兩條路線。一條是回溯型引擎維護一個「選擇?！棺卟煌ň蛷棗Ｖ卦?。Perl、PCRE、Python 的re、Java 的java.util.regex都是這一路。它的優(yōu)點是表達能力強、貼著人的直覺走代價就是上一章講的回頭路。另一條是自動機型把模式編譯成一個狀態(tài)機一次掃過去不保留「回頭重選」的機制。RE2 就屬于這一路。RE2 官方對自己的定位是把自己放在「backtracking regular expression engines like those used in PCRE, Perl, and Python」的對立面——它明確承認自己說的是另一條路線不是同一件事的更快版本。4.2 Go 那句線性承諾值得逐字讀Go 的regexp包文檔里有一句很硬的話The regexp implementation provided by this package is guaranteed to run in time linear in the size of the input.逐字摳一下guaranteed——是保證不是「通?！筶inear——線性in the size of the input——相對于輸入規(guī)模。合起來的意思是輸入翻倍耗時最多翻個常數(shù)倍不會出現(xiàn)第一章那種「每加兩個字符乘 4」。注意它沒承諾什么。它沒承諾更快也沒承諾所有模式都能寫。它承諾的是可預測。這個區(qū)別很重要如果你正在排查的是一個偶發(fā)的、無法復現(xiàn)的超時你要的恰恰是可預測而不是平均快 30%。??代碼待驗證python3-cimport re,sys; print(sys.version); print(re.__file__)# 看 Python 這一側go version# 看 Go 這一側go doc regexp|head-n20# 線性承諾那句就在這份文檔里實現(xiàn)路線復雜度形態(tài)本文依據(jù)Pythonre回溯型失敗路徑可隨長度指數(shù)增長RE-03Perl / PCRE回溯型同上RE-03、RE-05Javajava.util.regex回溯型同上RE-03Goregexp自動機型RE2 系線性承諾RE-04、RE-05JavaScript 引擎本文不展開各引擎實現(xiàn)與版本差異需自行核對RE-11待驗證4.3 換語言看起來解決了其實只是換了個位置有人會想那我用 Go 寫這個服務不就行了?？梢缘銚Q的不是一行代碼是整條技術棧。更常見的情況是同一個校驗規(guī)則Python 的老服務里有一份Go 的新網(wǎng)關里有一份兩邊行為不一樣出問題的時候你在 Go 那邊怎么都復現(xiàn)不出來因為問題在 Python 那邊。所以「換引擎」是架構決策不是寫法技巧。本章可以帶走的一句線性引擎買到的是可預測不是更快換引擎是改架構不是改寫法。五、怎么在自己機器上判定一張長度與耗時的表5.1 測法只改長度別的都不動這套測法只有四條紀律。固定模式一次只測一條別把好幾條拼在一個腳本里跑。固定輸入的字符構成——第三章講過形態(tài)是由「字符怎么重復」決定的所以除長度外每檔輸入應當完全同構。每檔跑多輪取中位數(shù)時鐘精度、垃圾回收、調度抖動都會給你離群值。最后不要在共享機器上測更不要在線上服務上測你要的是這條正則的形態(tài)不是這臺機器此刻的負載。把第一章那段腳本的輸入長度依次取 10、20、40、80別的都不動你會拿到四行數(shù)字。接下來是判讀。5.2 判讀看第二次翻倍的倍數(shù)有沒有繼續(xù)變大長度翻倍后的耗時倍數(shù)大致形態(tài)要不要管約 ×2線性通常不用管約 ×4且再翻一倍仍是 ×4平方要管長輸入會明顯拖慢倍數(shù)本身還在隨長度變大指數(shù)形態(tài)必須先限長再改寫忽高忽低、沒有規(guī)律測法有問題或被別的負載干擾先修測法別下結論平方和指數(shù)的區(qū)別就在第二列和第三列之間平方的倍數(shù)是個常數(shù)翻一倍總是 ×4指數(shù)的倍數(shù)是「越翻越大」。區(qū)分它們的辦法很簡單——多做一次翻倍。只翻一次兩者看起來一模一樣翻兩次答案就出來了。還有一個容易誤判的點如果四行數(shù)字都很快也別急著下結論?？赡苣氵x的輸入沒有讓匹配失敗全程走的是快路徑。校驗類正則的問題幾乎都藏在「不通過」的那一側。5.3 三個會讓你白忙一場的坑一是輸入沒構造對。同一段文本結尾多一個字符和少一個字符走的可能是完全不同的路徑。二是只測一次。單次測量里混著進程啟動、模塊導入、緩存預熱你測到的是環(huán)境不是正則。三是用了帶結果緩存的框架去測第二次調用直接命中緩存你會得到一條漂亮但虛假的直線。這三條避開你得到的形態(tài)結論才有意義。本章可以帶走的一句你不需要讀引擎源碼只需要一張長度與耗時的表。完整版對照資料本文把「長度與耗時」的測法、判讀表、三種形態(tài)的識別要點整理成了一頁速查和本章這套判定流程是同一份東西的濃縮版。放在資料包里掃碼即可獲取六、改法每一條都有代價沒有免費的6.1 最便宜的兩步限長然后加錨點第一步是限長。這件事必須在正則之前做先判斷長度超了直接拒根本不讓它進正則。如果順序反了你連「這段輸入有多長」這件事都要花在匹配里限長就白限了。第二步是加錨點。做整段校驗的正則就該用「整段匹配」的語義而不是「在字符串里找一處」。錨點讓起點唯一第三章里那個「每個位置都當一次開頭」的放大器就直接沒了。兩件事都有代價。限長要你定一個業(yè)務上限——備注到底是 500 字還是 5000 字這是產(chǎn)品決策技術側替不了你。加錨點會改變語義原來「文本里包含一段符合規(guī)則的內(nèi)容」就通過現(xiàn)在變成「整段都符合才通過」上線前必須把正例、反例、邊界值全部重跑一遍。下面是一個把順序擺對的寫法長度檢查在前正則在后??代碼待驗證MAX_LEN500defvalidate_note(text:str)-bool:iftextisNone:returnFalseiflen(text)MAX_LEN:# 先卡長度最便宜的一道returnFalseifnottext.isascii():# 再做字符集層面的粗篩returnFalsereturnPATTERN.fullmatch(text)isnotNone# 最后才是結構性校驗6.2 拆平嵌套改掉重疊分支嵌套量詞的改法是把「重復的重復」拍平成「一次重復 明確的字符集」。原來靠分組表達的結構改成用字符類和定長結構表達讓同一段字符只有一種切分方式。重疊分支的改法有兩種一是把分支改成互斥的調整字符范圍讓兩者不可能同時匹配同一段二是調整分支順序并配合錨定讓引擎盡早排除掉不可能的路。前者更徹底后者改動更小。代價是等價性。任何改寫都會引入「原來能過、現(xiàn)在過不了」或者反過來的風險。所以改寫之后必須做一件事把這條規(guī)則曾經(jīng)拒絕過的真實樣本脫敏后的、曾經(jīng)通過的真實樣本各挑一批重跑。沒有這批樣本你不知道自己改的是性能還是語義。6.3 換引擎、上原子組、加超時各自代價不同占有量詞和原子組是 PCRE 系提供的能力它告訴引擎「這一段一旦匹配上就別再回頭改主意了」。這直接把回頭路砍掉但語義也變了——原本靠回溯才能匹配到的輸入改寫后可能匹配不上而且不是每種語言都有這個語法跨語言遷移時要注意。換線性引擎是最徹底的一條代價也最大模式語法是另一個集合要逐條核對而且第四章說過你換的是技術棧不是一行代碼。加超時最容易做也最容易騙自己。它只是止損超時之后請求會失敗業(yè)務側必須能處理這種失敗否則你只是把「一直轉圈」換成了「轉一會兒就失敗」它不是修復。另外一件事必須標清楚各語言引擎回溯上限的默認值屬于本文的待驗證項RE-11本文不引用任何具體數(shù)值。要在自己的環(huán)境里確認只能按你所用的那個實現(xiàn)的文檔核對別照抄別人的數(shù)字。手段改什么代價什么時候不該用限長在正則之前卡長度要定業(yè)務上限輸入本身必須完整保留時加錨點把「找一處」改成「整段」語義變化要重跑用例業(yè)務確實是「包含即通過」拆平嵌套改變分組與量詞結構等價性風險缺真實樣本可回歸時原子組 / 占有量詞禁止回溯語義變化且非所有語言支持需要跨語言復用同一條模式換線性引擎換實現(xiàn)語法子集不同遷移成本高只是給老服務打補丁時加超時加一層時限只止損不修復把它當成最終方案時本章可以帶走的一句所有改法都是拿語義或架構上的讓步換一份可預測的耗時。七、把它放進校驗流程的哪一步7.1 四道閘的順序不能亂一條輸入從進來到被使用按理要過四道閘順序是有講究的長度與體積上限——用最便宜的方式擋掉大部分異常輸入編碼與字符集粗篩——只允許該字段該有的字符類別結構與格式校驗——也就是正則該待的地方業(yè)務規(guī)則——唯一性、頻率、狀態(tài)合法性。第一章那個場景的問題本質上是把第 3 道閘放在了第 1 道前面正則成了第一個接觸原始輸入的東西于是一段很長的、注定不通過的文本把全部算力都花在了「證明它不通過」上。還有一個常被忽略的點入口不止表單。JSON 請求體里的字段、上傳文件的文件名、請求頭里的自定義字段、日志解析、批量導入的每一行、消息隊列里的消息體——每一個都是原始輸入的入口。你只在表單那一處加了限長別的入口照樣能把長輸入送進來。7.2 給每條正則留一份可審的記錄正則寫在一行里看不出成本所以它需要一份額外記錄至少六欄模式、用途、允許的輸入上限、有沒有錨定、有沒有嵌套量詞或重疊分支、最近一次復測的結論與日期。這份記錄的價值不在當下而在半年后有人要改這條規(guī)則的時候——他能看見「這條測過當時是平方形態(tài)靠限長兜住的」而不是只看到一行注釋然后照著感覺改。7.3 邊界這套方法管什么、不管什么它管的是寫法層面的耗時形態(tài)怎么測、怎么讀表、怎么改、改在哪一步全部在你自己的機器和你自己的代碼上完成。它不管「怎么去驗證某個具體服務扛不扛得住」這類問題本文所有計時都在本機用合成字符串完成不給針對具體服務的驗證方法也不給可以直接拿去用的完整模式與配套輸入。這類驗證只要換一個目標性質就完全不同了。本章可以帶走的一句正則不該是第一個接觸原始輸入的東西。完整版對照資料本文第七章這套「四道閘 一條正則一份記錄」的落地清單已經(jīng)整理成可直接照著填的表格和本章的順序設計一一對應。放在資料包里掃碼即可獲取附表 A本文引用事實與官方出處對照表序號事實出處核驗日期本文位置1計時環(huán)境為 CPython 3.13 macOS本機實測RE-012026-10-25第一章 1.22n14/16/18/20/22 對應 0.38 / 1.49 / 5.83 / 21.80 / 82.94 毫秒RE-012026-10-25第一章 1.23相鄰兩檔的相對倍數(shù)落在 3.7 至 3.9 之間RE-012026-10-25第一章 1.24每加 2 個字符約乘 4即每加 1 個字符約乘 2RE-012026-10-25第一章 1.2、1.35計時輸入為本地合成字符串不指向任何在線服務RE-012026-10-25第一章 1.26計時反映復雜度形態(tài)而非絕對速度換機器數(shù)值會變、倍數(shù)關系不變RE-022026-10-25第一章 1.37回溯型引擎包括 Perl、PCRE、Pythonre、Javajava.util.regexRE-032026-10-25第二章 2.2、第四章 4.18匹配失敗時引擎需把已做過的選擇重新走一遍RE-032026-10-25第二章 2.29失敗路徑數(shù)量可隨輸入長度指數(shù)增長RE-032026-10-25第二章 2.210上述代價是回溯的本質不是 bugRE-032026-10-25第二章 2.211放大器之一量詞套量詞內(nèi)層重復被外層再重復一遍RE-062026-10-25第三章 3.112放大器之二兩個分支能匹配同一段字符失敗時任一條路都要試RE-062026-10-25第三章 3.213放大器之三沒有起點錨定每個位置都要試一遍RE-062026-10-25第三章 3.314Goregexp文檔承諾運行時間相對輸入規(guī)模線性RE-042026-10-25第四章 4.215該線性來自自動機路線不做回溯RE-042026-10-25第四章 4.216RE2 把自己定位為與 PCRE、Perl、Python 那類回溯引擎相對的另一條路線RE-052026-10-25第四章 4.117判定閾值輸入長度翻倍時耗時是否接近翻 4 倍或更多RE-072026-10-25第五章 5.218緩解手段加錨點、拆平嵌套、限長、把校驗挪到長度檢查之后RE-082026-10-25第六章 6.1、6.219緩解手段占有量詞 / 原子組PCRE 系RE-082026-10-25第六章 6.320緩解手段換線性引擎RE2 系實現(xiàn)RE-082026-10-25第六章 6.321各語言引擎回溯上限的默認值待驗證本文不引用具體數(shù)值RE-112026-10-25第六章 6.3附表 B術語速查表術語一句話解釋回溯引擎走不通時退回上一個選擇點、換一條路重試的動作回溯型引擎靠維護選擇棧來匹配的實現(xiàn)失敗時要走完所有失敗路徑自動機引擎把模式編譯成狀態(tài)機、一次掃過、不回頭重選的實現(xiàn)嵌套量詞分組內(nèi)部以量詞結尾、分組外又套一個量詞的結構重疊分支兩個分支能匹配同一段字符因而對同一輸入存在多條路徑錨點聲明匹配只能從字符串開頭或結尾開始的符號原子組 / 占有量詞告訴引擎這一段匹配后不再回頭改主意的語法PCRE 系提供線性時間耗時與輸入規(guī)模成正比翻倍只帶來常數(shù)倍增長中位數(shù)多輪測量里排在中間的那個值比平均值更抗離群點待驗證項本批未取得官方原文、因而在正文中只標注不引用具體數(shù)值的條目寫在最后這篇用到的資料寫這篇文章時我把同一段計時反復跑了幾遍確認真正穩(wěn)定的不是毫秒數(shù)而是最后一列的倍數(shù)順手把測法和判讀表做成了一張能直接填的紙也整理了幾份配套的東西靶場環(huán)境對照表DVWA、upload-labs 在 Windows / macOS / Linux 三平臺的可行性與推薦路徑Web 安全學習路線圖從基礎打牢到安全管理四個階段各學什么常用靶場清單每個靶場練什么、適合哪個階段資料是我自己整理的放在下面這個碼上掃碼即可獲取添加時備注「靶場」優(yōu)先通過。拿到之后建議先看環(huán)境對照表那一份先把「自己的正則跑在哪條引擎路線上」這件事確認下來再回頭改寫法。