介紹

當您想到拒絕服務攻擊時，您會想到什么？可能是一大群機器人試圖訪問 Web 服務器的資源以使其癱瘓。好吧，這肯定是導致拒絕服務攻擊的一種方式。但是，還有一種您可能沒有聽說過的方式。它被稱為 ReDoS，是由正則表達式引起的。

正則表達式？但這怎么可能呢？那不是通過使用過濾器來匹配字符串、將字符串列入白名單和黑名單，從而使我們的工作更輕松嗎？是的，但是攻擊者也可以利用它來使應用程序（服務器）屈服。讓我們了解如何！

正則表達式是什么？

簡而言之，正則表達式是一種用于匹配（編程語言中）字符串的模式。讓我們通過一個示例來理解它吧，該示例是“用正則表達式在服務器端驗證電子郵件地址”。

letregex=newRegExp('[a-z0-9]+@[a-z]+.[a-z]{2,3}');
lettestEmails=["notanemail.com","workingexample@email.com","another_working@somethingelse.org","notworking@1.com"];
testEmails.forEach((address)=>{
console.log(regex.test(address))
});

上面是一段 JavaScript 代碼（譯者注：不會 JS 也無妨，對閱讀本文的影響不大，請繼續閱讀）。我們在這里使用的正則表達式是 [a-z0–9]+@[a-z]+.[a-z]{2,3}。我們提供了幾個電子郵件地址，然后我們需要檢查它們是否遵循電子郵件地址的一般模式。讓我們分解一下正則表達式。

• [a-z0–9]+：表示此處的字符串可以是任何小寫字母和數字。末尾的加號 (+) 表示必須至少有一個字符（無論是小寫字母還是數字）。

• @：表示此處應該有 AT（@）符。

• [a-z]+：表示此處字符串應該包含（一個或多個）小寫字母的字符

• .：表示此處應該有一個點（.）

• [a-z]{2,3}：表示此處字符串是由小寫字母組成的，但其長度只能是 2 或 3。

讓我們將其與我們選擇的電子郵件 ID 進行比較。讓電子郵件 ID 為 yourremail12@yahooemail.com。

• youremail12@ 對應于 [a-z0-9]+@
• yahooemail 對應于 [a-z]+
• .com 對應于 .[a-z]{2,3}

這通常是正則表達式的工作方式。但這不是會按預期工作嗎？這如何能導致拒絕服務攻擊呢？讓我們了解一下。

正則表達式由正則表達式運算器處理。在 ReDoS 攻擊期間，攻擊者通過提供輸入字符串強制正則表達式運算器陷入循環。當它處于循環中時，正則表達式運算器可能會花費大量時間，并消耗大量資源。這會導致其他合法客戶端無法使用資源，并可能導致 Web 服務器和應用程序無響應并最終崩潰。

另一種情況可能是設計不良的正則表達式模式，這可能導致輸入驗證失敗，在正則表達式運算器解析時會消耗大量時間等。

有害正則表達式（Evil Regex）

有害正則表達式模式是攻擊者可以利用的正則表達式。根據 Wikipedia，這些是有害正則表達式模式的特征。

• 正則表達式將重復（+、*）應用于復雜的子表達式。
• 對于重復的子表達式，存在一個匹配，同時該匹配也是另一個有效匹配的后綴。

這說明了如果已經有一個復雜的子表達式，并且應用一些像 + 或 * 這樣的貪婪運算符，可能會導致一個有害的正則表達式。

例如，

我們考慮以下正則表達式：^(a+)+$

^ 和 $ 定義了字符串必須分別以 a 開頭和結尾。

如果我們提供 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa，正則表達式運算器將在幾毫秒內處理它并返回 True。

如果我提供 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa!，你覺得會發生什么！

如果您運行它，則對于所提供的正則表達式，（在返回 False 之前）需要花費大約 2 秒的時間來處理。只是通過添加一個額外的感嘆號會導致這么長的時間嗎？

讓我們從正則表達式運算器的角度來看看它是如何工作的。正則表達式運算器直到達到感嘆號之前將會正常工作。由于我們沒有指定查找 (!) 標記，因此它會回溯到前面的字母，并查看是否有另一種方法來解析先前的字符，以便可以驗證整個字符串。在它最終發現絕不會返回 True 之前，這樣的回溯將會一直持續下去。

如您所知，回溯會導致大量時間消耗。攻擊者可以使用它來利用有害正則表達式模式。

譯者注

看完上述內容后，有些讀者可能仍對剛才的示例（回溯）表示不解。為了讓讀者能夠更加清晰地了解其原理，我將上例中正則表達式運算器可能將執行的步驟進行了分解演示。

下列演示的過程只是存在的一種可能（實際情況取決于正則表達式引擎的實現）

從上面的表格可以看出，正則引擎可能會做出 （近 20 億）種解析結果。

也就是，對于示例給出的有害正則表達式和惡意字符串。如果按照我們的演示進行，設有效最長子串的長度為 ，那么回溯的時間復雜度為（證明過程略，感興趣的讀者可去探究帕斯卡三角形）。該時間復雜度是指數級別，多么可怕的時間復雜度級別啊！

對于 30 個 a，僅多出一個感嘆號，執行時間竟然多出約 20 億倍。當然了，這里僅是一種可能的演示，在作者示例中的時間僅多了千倍左右。這可以從很多方面解釋，例如正則引擎的某些優化，或比例受某些較長固定執行時間的支配等。

譯者注結束

可利用性

開發人員和我們一樣都是人類，因此都會出錯。他們創建的許多應用程序可能會包含可利用的正則表達式模式。對于有經驗的黑客或安全專家來說，正則表達式模式很容易被猜到，而在有些情況下，源代碼是可以在線獲得的。攻擊者可以利用這一點來謀取利益，并可能降低被攻擊者的利益。

糟糕的正則表達式模式也可能會導致繞過許多安全控制，無論是在 Web 應用程序還是網絡防火墻上。

因此，始終建議在將應用程序部署到生產環境之前正確測試正則表達式模式。

緩解措施

• 緩解這種情況的最佳方法是根本不去使用它。尤其當你是新手時。

• 如有必要，請使用安全的正則表達式。這樣只需尋找另一種替換方法來完成相同的輸出。

• 在使用正則表達式之前，請在 regex101.com 或其他在線資源等網站上測試它們。

• 安全掃描用戶輸入永遠不會過時。

• 現在存在著很多正則表達式運算器。我建議您使用更高效的正則表達式引擎。你可以看看 https://github.com/google/re2。

• 測試您是否正在使用易受攻擊的正則表達式引擎或運算器。例如，url-regex 是一個用于測試匹配 URL 的正則表達式的包。

結論

我們忽視的諸如此類的小事可能會給安全增加了很大的風險。在這篇文章中，我們了解了可能由有害正則表達式模式引起的 DoS 攻擊、主要原因、以及我們應如何緩解它們。有必要緩解這種情況，因為它們會影響網站的可用性，并且可能會花費您很多資金。