.svg)
Wyobraź sobie ten scenariusz: jest spokojne popołudnie, wprowadzasz drobną poprawkę do kodu, wdrażasz ją na produkcję. Chwilę później na firmowym Slacku zaczyna się burza. Płoną alerty, kluczowe systemy padają jeden po drugim, a nikt nie wie, co się dzieje. Brzmi jak koszmar każdego programisty, prawda? A teraz wyobraź sobie, że to nie Ty, a inżynierowie z Cloudflare, jednego z filarów współczesnego internetu.
Właśnie to im się niedawno przydarzyło. I co najciekawsze – sami sobie zafundowali ten kryzys. To historia o tym, jak potężna firma niechcący przeprowadziła atak DDoS na własną infrastrukturę za pomocą... błędu w użyciu komponentu React.
Atak panelu administracyjnego
W wielkim skrócie: panel administracyjny Cloudflare, z którego korzystają miliony użytkowników do zarządzania swoimi usługami, zaczął zachowywać się jak wściekły botnet. Każda otwarta w przeglądarce sesja panelu zaczęła generować niekończącą się lawinę zapytań do jednego z wewnętrznych, krytycznych systemów API. Ten system, przytłoczony gigantyczną falą ruchu od własnych klientów, po prostu się poddał. A ponieważ był on kluczowy dla autoryzacji, pociągnął za sobą inne usługi, powodując efekt domina. W efekcie panel i API przestały działać.
Problematyczna implementacja
Dla nas, programistów, to jest sedno całej tej historii. Przyczyną chaosu był jeden z najbardziej znanych, ale i zdradliwych hooków w React.
Jak wiemy, useEffect pozwala na wykonanie kodu po renderowaniu komponentu, a jego ponowne uruchomienie jest kontrolowane przez tzw. tablicę zależności (dependency matrix). Jeśli coś w tej tablicy się zmieni, efekt odpala się na nowo. W tym właśnie był problem. Błąd w kodzie Cloudflare polegał na tym, że do tej tablicy zależności przekazano obiekt, który był tworzony od nowa przy każdym renderze komponentu. Ponieważ JavaScript porównuje obiekty przez referencję (miejsce w pamięci), a nie przez wartość (zawartość), dla Reacta ten obiekt był zawsze nowy.
Jak wygląda atak?
- Komponent się renderuje.
- Tworzy nowy obiekt i przekazuje do tablicy zależności useEffect.
- React porównuje "nowy" obiekt ze "starym" i stwierdza zmianę.
- Uruchamia kod w useEffect, który wysyła zapytanie do API.
- Odpowiedź z API powoduje aktualizację stanu, co... ponownie renderuje komponent.
- Wracamy do punktu 1.
Tak powstała samonapędzająca się pętla, która z przeglądarki każdego użytkownika wysyłała niekończące się zapytania do serwerów Cloudflare.
Separacja systemów powstrzymała większe szkody
Na szczęście architektura Cloudflare zdała egzamin w najważniejszym miejscu. Awaria dotyczyła wyłącznie "płaszczyzny zarządzania" (panel i API). Cały ruch internetowy ich klientów, ochrona stron i działanie DNS pozostały nietknięte. To kluczowe rozróżnienie pokazuje, jak ważna jest separacja systemów.
Oczywiście, zespół Cloudflare szybko namierzył i naprawił błąd, ale mleko się rozlało.
Moje 3 wnioski
Pokora, pokora i jeszcze raz pokora. To może się zdarzyć każdemu. Nawet w firmie, która dosłownie napisała podręcznik o ochronie przed atakami DDoS, jeden mały błąd programisty może wywołać kryzys.
Front-end to nie zabawa. Ta historia przypomina, że błąd w kodzie front-endowym może mieć równie katastrofalne skutki, co dziura w zabezpieczeniach serwera. Aplikacja kliencka to potężne narzędzie, które może stać się bronią hakerów.
Zrozum swoje narzędzia. Frameworki takie jak React dają nam ogromną moc, ale z wielką mocą wiąże się wielka odpowiedzialność. Musimy dogłębnie rozumieć, jak działają ich mechanizmy, a nie tylko kopiować i wklejać kod ze Stack Overflow. Porównywanie obiektów przez referencję w tablicy zależności useEffect to klasyk, o którym nie myśli już wielu z nas.
Historia Cloudflare to świetne przypomnienie, że w świecie inżynierii oprogramowania granica między drobną poprawką a globalnym kryzysem potrafi być zaskakująco cienka. Warto więc nie tylko pisać kod, ale i uważnie myśleć o jego konsekwencjach — bo czasem największe „ataki” na nasze systemy nie przychodzą z zewnątrz, lecz rodzą się w naszych własnych edytorach.
