Wyjaśnienie ReDoS: Czym jest DoS oparty na wyrażeniach regularnych i jak mu zapobiegać

Regular Expression DoS (ReDoS) to rosnące ryzyko w nowoczesne bezpieczeństwo aplikacjiPonieważ coraz więcej zespołów polega na walidacji danych wejściowych i dopasowywaniu wzorców, źle zaprojektowane wyrażenie regularne może wprowadzić luki w wydajności, które atakujący mogą wykorzystać do spowolnienia usług lub spowodowania przerw w działaniu. W rzeczywistości, OWASP opisuje ReDoS jako atak typu „odmowa usługi”, który wykorzystuje fakt, że wiele implementacji wyrażeń regularnych może stać się niezwykle powolnych, a czas wykonania czasami rośnie wykładniczo wraz z rozmiarem danych wejściowych.

Jednocześnie ataki ReDoS są szczególnie niebezpieczne w środowiskach chmurowych i CI/CDśrodowiskach sterowanych przez ReDoS, w których pojedyncze podatne wyrażenie regularne w interfejsie API, bramce lub przepływie uwierzytelniania może wpłynąć na dostępność na dużą skalę. Z tego powodu zespoły powinny traktować ReDoS jako realne zagrożenie dla dostępności, a nie tylko niszowy przypadek brzegowy.

Co ważniejsze, te luki często pozostają niewykryte podczas tworzenia oprogramowania, ponieważ tradycyjne podejścia koncentrują się na składni, a nie na sposobie wykonywania. W rezultacie nieefektywne wzorce wyrażeń regularnych mogą łatwo dotrzeć do środowiska produkcyjnego bez generowania alertów.

W tym miejscu z pomocą przychodzą nowoczesne platformy AppSec, takie jak Xygeni. Dzięki integracji kontroli bezpieczeństwa bezpośrednio z procesami rozwoju oprogramowania, pomagają one szybciej wykrywać problemy i priorytetyzować zagrożenia, które są rzeczywiście osiągalne i mają wpływ na środowisko, zamiast po prostu generować dodatkowy szum.

Czym jest ReDoS (Regular Expression DoS)?

ReDoS (Regular Expression Denial of Service) to luka w zabezpieczeniach, która występuje, gdy wzorzec wyrażenia regularnego powoduje nadmierne cofanie się, co skutkuje wykładniczym wydłużeniem czasu wykonywania.

Mówiąc prościej, złośliwe dane wejściowe mogą zmusić Twoją aplikację do poświęcenia bardzo dużej ilości czasu na ocenę wyrażenia regularnego, blokując system i pogarszając wydajność.

Na przykład wzorce z zagnieżdżonymi kwantyfikatorami, takie jak:

				
					(a+)+

może okazać się wysoce nieefektywny podczas przetwarzania niektórych danych wejściowych, zwłaszcza gdy został celowo stworzony przez atakującego.

Choć może się to wydawać skrajnym przypadkiem, zaskakująco często zdarza się w rzeczywistych zastosowaniach, szczególnie w logice walidacji, wprowadzaniu danych do formularzy i obsłudze żądań API.

Jak działają ataki ReDoS

Atak ReDoS nie wymaga zaawansowanej eksploatacji. Zamiast tego wykorzystuje przewidywalne zachowanie silnika wyrażeń regularnych.

Katastrofalne cofanie się

Atakujący atakuje wyrażenie regularne, które może przyjmować wiele pasujących ścieżek. Następnie dostarcza dane wejściowe, które zmuszają silnik do zbadania większości lub wszystkich ścieżek.

Dane wejściowe opracowane przez atakujących

Napastnicy zazwyczaj wysyłają:

Długie ciągi znaków zawierające powtarzające się znaki.
Dane wejściowe, które prawie pasują, na końcu nie działają.
Ładunki skupiające się na najbardziej niejednoznacznej części wzoru.

Obniżenie wydajności

Ponieważ każde żądanie może wyczerpać zasoby procesora, efekt szybko się kumuluje:

Większe opóźnienie między punktami końcowymi.
Wyczerpanie puli wątków.
Pętla zdarzeń zatrzymuje się w środowiskach jednowątkowych.

Te ataki nie wymagają skomplikowanych exploitów. Zamiast tego wykorzystują nieefektywne dopasowywanie wzorców, co utrudnia ich wykrycie, jeśli narzędzia sprawdzają jedynie składnię lub znane luki w zabezpieczeniach (CVE).

Wpływ luk w zabezpieczeniach ReDoS na rzeczywisty świat

ReDoS trafia w punkt „A” w triadzie CIA: dostępność. Dopóki nie połączymy faktów, może to wyglądać na problem ze stabilnością, a nie incydent bezpieczeństwa.

Spowolnienie API

Pojedynczy punkt końcowy, który wykorzystuje podatne wyrażenie regularne, może spowodować wzrost obciążenia procesora podczas sprawdzania poprawności danych wejściowych, kierowania żądaniami lub sprawdzania uwierzytelniania.

Przerwa w świadczeniu usług

Pod obciążeniem punkt dostępowy ReDoS może spowodować ponowne uruchomienie kontenerów, pogorszenie automatycznego skalowania i wywołanie kaskadowych awarii.

Wyczerpanie zasobów

ReDoS może zużywać:

Procesor na węzłach aplikacji.
Pamięć spowodowana cofaniem się stanu.
Wątki robocze blokujące inne żądania.

Ponieważ ReDoS koncentruje się na wydajności, a nie na ujawnianiu danych, wiele zespołów nie docenia jego wpływu. Jednak dostępność jest kluczowym elementem bezpieczeństwa aplikacji, a zakłócenia mogą szybko przełożyć się na ryzyko biznesowe.

Zmiany stanowią prawdziwy problem zaufania

Kiedy programiści mówią, że nie ufają funkcji autofix, często mają na myśli jedną konkretną rzecz: nie ufają jej, że czegoś nie zepsuje.

Problem z zaufaniem jest najbardziej widoczny w przypadku naprawiania zależności.

Pakiet z luką w zabezpieczeniach może mieć dostępną wersję z poprawkami, ale to nie oznacza, że aktualizacja jest bezpieczna. Wersja z poprawkami może usunąć metodę używaną przez aplikację. Może zmienić nazwę API. Może zaostrzyć kontrakt typu. Może zmodyfikować zachowanie w sposób, który przejdzie testy jednostkowe, ale spowoduje regresję w środowisku produkcyjnym. W wielu zespołach rzeczywisty koszt naprawy nie polega na zastosowaniu poprawki, ale na zbadaniu promienia rażenia.

Rozważmy prosty przykład w Javie. Baza kodu jest zależna od biblioteki, w której wspólna metoda istnieje w wersji 1.x, ale została usunięta w wersji 2.x.

Ataki ReDoS i incydenty bezpieczeństwa w świecie rzeczywistym

ReDoS to nie tylko teoretyczna luka w zabezpieczeniach. Została ona wykorzystana w rzeczywistych aplikacjach, wpływając na powszechnie używane biblioteki i systemy produkcyjne.

Oto kilka znaczących przykładów, które podkreślają wpływ nieefektywnych wzorców wyrażeń regularnych:

Luka w zabezpieczeniach Moment.js ReDoS

Jedna z najbardziej znanych luk ReDoS, na którą narażeni są użytkownicy Moment.js, powszechnie używana biblioteka dat JavaScript.

Źle zaprojektowany wzorzec wyrażenia regularnego spowodował nadmierne cofanie się
Atakujący mogą wywołać wysokie obciążenie procesora za pomocą zmodyfikowanych danych wejściowych
Aplikacje wykorzystujące Moment.js stały się podatne na warunki odmowy usługi

Ten problem pokazał, jak nawet zaufane biblioteki mogą wprowadzać luki w zabezpieczeniach związane z wydajnością do tysięcy aplikacji.

Biblioteka walidatorów Node.js (validator.js)

Inny przykład dotyczył walidator.js, powszechnie stosowane do walidacji danych wejściowych.

Niektóre funkcje walidacyjne opierają się na nieefektywnym wyrażeniu regularnym
Złośliwe dane wejściowe mogą znacznie opóźnić wykonanie
Dotyczyło to interfejsów API i usług zaplecza, które opierają się na walidacji danych wprowadzanych przez użytkownika

Ze względu na szerokie zastosowanie validator.js jego wpływ rozciągnął się na wiele aplikacji i usług.

Awaria Cloudflare (awaria oparta na wyrażeniach regularnych)

Doszło do głośnego incydentu Cloudflare, gdzie błędny wzorzec wyrażenia regularnego spowodował poważną awarię.

Wyrażenie regularne wdrożone w środowisku produkcyjnym spowodowało nadmierne użycie procesora
Systemy na całym świecie przestały reagować
Duże części Internetu zostały tymczasowo zablokowane

Mimo że nie był to atak złośliwy, incydent ten wyraźnie pokazuje, jak nieefektywne stosowanie wyrażeń regularnych może mieć realne konsekwencje na dużą skalę.

Dlaczego tradycyjne narzędzia bezpieczeństwa nie sprawdzają się w przypadku ReDoS

To jest sekcja poświęcona konwersji, ponieważ wyjaśnia lukę, którą odczuwa większość zespołów: skanery działają, dashboards wypełnienie, a ReDoS i tak się prześlizguje.

Narzędzia statyczne skupiają się na składni

Wiele skanerów potrafi oznaczyć „niebezpieczne wzorce wyrażeń regularnych”, ale często nie mają pewności, czy dany wzorzec rzeczywiście nadaje się do wykorzystania w danym kontekście.

Brak kontekstu wykonania

ReDoS dotyczy zachowania w czasie wykonywania. OWASP zauważa, że wiele implementacji wyrażeń regularnych może osiągnąć ekstremalne wyniki i działać bardzo wolno, czasami wykładniczo zależnie od rozmiaru danych wejściowych.
Jeśli narzędzie nigdy nie analizuje kształtu danych wejściowych, nie dopasowuje warunków błędu ani ścieżek wykonania, nie wychwyci ryzyka lub utonie w fałszywie pozytywnych wynikach.

Brak analizy podatności na wykorzystanie

Wyrażenie regularne może być „teoretycznie ryzykowne”, ale w praktyce nieosiągalne. Z drugiej strony, „mały” walidator w publicznym punkcie końcowym może być prawdziwym incydentem. Bez kontekstu zespoły albo ignorują alerty, albo nadmiernie poprawiają błędy.

Tradycyjne skanery często nie wykrywają ReDoS, ponieważ nie oceniają zachowania wyrażeń regularnych w czasie wykonywania lub w przypadku złośliwych warunków wejściowych. Właśnie w tym miejscu platformy takie jak Xygeni robią różnicę, łącząc analizę z… ocena ryzyka kontekstowegopomagając zespołom zrozumieć, czy dana słabość jest rzeczywiście osiągalna i ma wpływ.

Jak wykryć luki w zabezpieczeniach ReDoS

Ataki ReDoS można wykryć, łącząc dyscyplinę projektową z testowaniem. Ponadto, kontrole powinny być przeprowadzane w sposób ciągły, a nie tylko podczas przeglądu bezpieczeństwa.

Bezpieczny projekt wyrażeń regularnych

Zacznij od wzorców, które minimalizują niejednoznaczność. Unikaj zagnieżdżonych kwantyfikatorów i nakładających się alternatyw.

Testowanie i testowanie

Przetestuj wzorce wyrażeń regularnych za pomocą:

Bardzo długie dane wejściowe.
Niemal błędne dane wejściowe, które zawodzą na późnym etapie.
Powtarzające się tokeny mające na celu wywołanie cofania się.

Analiza statyczna

Użyj analizy, która sygnalizuje znane ryzykowne konstrukcje i wzorce zgodne z CWE-1333.

Walidacja w czasie wykonywania

W miarę możliwości stosuj ograniczenia długości danych wejściowych i limity czasu dotyczące oceny wyrażeń regularnych. Wytyczne OWASP dotyczące walidacji danych wejściowyche wyraźnie ostrzega przed ReDoS i podkreśla znaczenie zdefiniowania minimalnej i maksymalnej długości danych wejściowych.

Zaawansowane rozwiązania AppSec, takie jak Xygeni, wykraczają poza wykrywanie wzorców, analizowanie kodu w kontekście przepływu pracy i pomaganie zespołom w skupianiu się na problemach, które mają największe znaczenie w rzeczywistych scenariuszach, co zmniejsza liczbę fałszywych alarmów i przyspiesza rozwiązywanie problemów.

Jak zapobiegać atakom ReDoS

Zapobieganie polega na połączeniu bezpieczniejszych wzorców, bezpieczniejszych danych wejściowych i bezpieczniejszych wyborów w czasie wykonywania.

Unikaj zagnieżdżonych kwantyfikatorów

Zagnieżdżone powtórzenia często powodują najgorsze efekty cofania się.

Ogranicz rozmiar wejściowy

To najprostsze i najskuteczniejsze rozwiązanie. Ustaw maksymalne limity długości dla danych wejściowych, które przechodzą walidację wyrażeń regularnych. OWASP podkreśla limity długości jako kluczowy element bezpiecznej walidacji danych wejściowych.

W miarę możliwości używaj bezpiecznych silników wyrażeń regularnych

Jeśli masz możliwość wyboru silnika, wybieraj taki, który zapobiega katastrofalnym w skutkach cofaniu się. RE2 firmy Google jest pozycjonowany jako bezpieczna alternatywa dla silników wyrażeń regularnych wykorzystujących backtracking.

Weryfikuj dane wejściowe za pomocą kontroli warstwowych

Nie opieraj się na jednym wyrażeniu regularnym do wszystkich walidacji. Połącz:

listy dozwolonych postaci,
rygorystyczne kontrole długości,
i prostsze wzory na pole.

Zapobieganie atakom ReDoS wymaga stosowania bezpiecznych praktyk kodowania i ciągła walidacja w całym cyklu życia rozwoju, zwłaszcza gdy aplikacje stają się coraz większe, a zależności rosną.

Jak Xygeni pomaga wykrywać i zapobiegać atakom ReDoS

Xygeni pomaga zespołom DevSecOps wykrywać i zapobiegać lukom w zabezpieczeniach ReDoS poprzez łączenie wielu warstw analizy.

Kluczowe możliwości obejmują:

Wykrywanie podatnych na ataki wzorców wyrażeń regularnych podczas rozwoju
Analiza przepływów danych i ścieżek wykonania
Identyfikacja podatności możliwych do wykorzystania, a nie tylko teoretycznych
Integracja z CI/CD pipelines do ciągłego skanowania
Praktyczne wskazówki dotyczące naprawy dla deweloperów

Zamiast przytłaczać zespoły alertami, Xygeni priorytetyzuje podatności, do których faktycznie można dotrzeć i wywierające wpływ.

Dzięki temu zespołom można szybciej rozwiązywać rzeczywiste problemy, nie spowalniając przy tym prac nad projektem.

Najlepsze praktyki dla zespołów DevSecOps

Bezpieczeństwo przesunięcia w lewo

Niech kontrole ReDoS będą częścią tej samej procedury, co przegląd kodu i testy jednostkowe.

Zautomatyzuj skanowanie

Przeprowadź kontrole każdego pull request więc ryzyko wyrażeń regularnych nie czeka na okresowe przeglądy.

Monitoruj zależności

Luki w zabezpieczeniach wyrażeń regularnych pojawiają się również w bibliotekach zależności i przetwarzania danych wejściowych, dlatego należy dbać o higienę zależności.

Ciągła weryfikacja danych wejściowych

Zastosuj limity długości i reguły wejściowe na krawędziach, a następnie przeprowadź ponowną walidację w obrębie krytycznych usług.

Dzięki integracji zabezpieczeń bezpośrednio z procesami tworzenia oprogramowania zespoły mogą zapobiegać zagrożeniom wydajnościowym, takim jak ReDoS, zanim oprogramowanie dotrze do środowiska produkcyjnego.

Zapobieganie atakom ReDoS zaczyna się od widoczności bez cienia

Atak ReDoS jest często pomijany, a może mieć znaczący wpływ na wydajność i dostępność aplikacji. OWASP postrzega ReDoS jako ryzyko odmowy usługi (DoS) wynikające z ekstremalnego zachowania środowiska wykonawczego wyrażeń regularnych.
Oznacza to, że potrzebujesz czegoś więcej niż tylko podstawowego skanowania. Potrzebujesz kontekstu, priorytetyzacji i automatyzacji.

Jeśli traktujesz wyrażenia regularne jak kod, który może zawieść po wprowadzeniu danych przez atakującego, szybciej wykryjesz ReDoS i dostarczysz bezpieczniejsze systemy. Dzięki Xygeni zespoły mogą ograniczyć szum, priorytetyzować rzeczywiste ryzyko i wzmocnić wewnętrzne mechanizmy bezpieczeństwa aplikacji. CI/CD przepływy pracy.

Wniosek

Luki w zabezpieczeniach ReDoS łatwo wprowadzić, ale trudno je wykryć bez odpowiedniego kontekstu.

Podczas gdy tradycyjne narzędzia koncentrują się na identyfikowaniu problemów, nowoczesne AppSec wymaga zrozumienia, które luki są rzeczywiście istotne.

Aby więc utrzymać przewagę, zespoły potrzebują przejrzystości, ustalania priorytetów i automatyzacji, które muszą ze sobą współdziałać w całym cyklu rozwoju.

Właśnie w tym miejscu Xygeni robi różnicę. Koncentrując się na zagrożeniach, które można wykorzystać, pomaga zespołom wykrywać problemy na wcześniejszym etapie, redukować szumy informacyjne i zabezpieczać aplikacje od etapu rozwoju do wdrożenia.

Podsumowując, tworzenie bezpiecznego oprogramowania oznacza dziś wyjście poza skanowanie i przyjęcie kontekstowego podejścia do kwestii bezpieczeństwa w czasie rzeczywistym.

Zacznij tworzyć bezpieczne i odporne aplikacje dzięki wykrywanie w czasie rzeczywistym i bezpieczeństwo kontekstowe.