błąd logiki biznesowej

Błąd logiki biznesowej (business logic vulnerability) to luka, w której aplikacja technicznie działa poprawnie, ale pozwala wykonać operacje sprzeczne z zasadami, jakie miał na myśli jej projektant. PortSwigger definiuje takie błędy jako wady projektu i implementacji aplikacji, które pozwalają atakującemu wywołać niezamierzone zachowanie ^[1]. MITRE grupuje je w kategorii CWE-840, obejmującej słabości, które zwykle pozwalają manipulować logiką biznesową aplikacji ^[2]. Przykładami są ujemna ilość towaru w koszyku, wielokrotne użycie jednorazowego kuponu albo pominięcie kroku płatności.

Jak powstaje

Błąd logiki biznesowej nie polega na wstrzyknięciu kodu. Każde pojedyncze żądanie jest poprawne składniowo, a problemem jest to, na co aplikacja w ogóle pozwala. PortSwigger wskazuje, że takie luki biorą się z błędnych założeń o zachowaniu użytkowników; programiści zakładają na przykład, że użytkownik korzysta wyłącznie z przeglądarki, i opierają się na słabej kontroli po stronie klienta ^[1]. Ryzyko rośnie w złożonych systemach, gdzie członkowie zespołu nie znają wszystkich zależności między komponentami ^[1].

Częstym wariantem jest wymuszanie kolejności kroków. MITRE opisuje w CWE-841 sytuację, w której aplikacja nie pilnuje, by użytkownik wykonał wymagane czynności we właściwej kolejności; wykonując je w innej kolejności albo pomijając kroki, atakujący może zmanipulować logikę lub wprowadzić aplikację w niedozwolony stan ^[3]. Schemat poniżej pokazuje zamówienie w sklepie, w którym serwer przyjmuje ostatni krok bez sprawdzenia poprzednich.

RYS. 1Pominięty krok w zamówieniu

Rodzaje

PortSwigger wymienia kilka typowych grup błędów logiki ^[1]. Część z nich ma odpowiedniki w katalogu CWE.

Do kategorii CWE-840 MITRE zalicza też CWE-639, czyli obejście autoryzacji przez klucz kontrolowany przez użytkownika ^[2]. To ten sam mechanizm, który opisuje hasło IDOR (Insecure Direct Object Reference). Granica między błędem logiki a brakiem kontroli uprawnień bywa więc płynna.

W WordPressie

Na stronach WordPress błędy logiki biznesowej występują przede wszystkim w sklepach WooCommerce i we wtyczkach z formularzami zamówień, rezerwacji lub kalkulatorami cen; zob. podatność we wtyczce. Typowym problemem jest rozszerzenie, które ufa cenie, rabatowi albo statusowi zamówienia przesłanemu przez przeglądarkę.

Przykładem jest luka CVE-2024-6010 we wtyczce Cost Calculator Builder PRO. Według rekordu CVE wersje do 3.2.1 włącznie pozwalały zmienić pole ceny przed przetworzeniem zamówienia w funkcji create_cc_order, więc nieuwierzytelniony atakujący mógł zmienić cenę zamówień składanych przez kalkulator ^[7]. Rekord przypisuje luce słabość CWE-472, czyli zewnętrzną kontrolę nad parametrem uznanym za niezmienny, oraz wynik CVSS 5,3 ^[7]. Był to przypadek podatności wykorzystywanej bez uwierzytelnienia, która mimo średniej oceny dotyczyła wprost kwot zamówień.

Sam WooCommerce przenosi część reguł biznesowych na serwer. Dokumentacja kuponów opisuje limit użyć kuponu dla wszystkich klientów, limit użyć na jednego klienta, opcję wyłączającą łączenie z innymi kuponami i minimalną wartość koszyka ^[6]. Wtyczki, które dodają własne rabaty, powinny egzekwować podobne ograniczenia po stronie serwera, a nie w skrypcie strony.

Zagrożenia i skutki

PortSwigger zauważa, że skutki błędów logiki są bardzo różne, od drobnych po poważne; luki w uwierzytelnianiu lub transakcjach finansowych mogą prowadzić do eskalacji uprawnień, oszustw i szkód dla firmy ^[1]. OWASP w zestawieniu API Security Top 10 z 2023 roku opisuje ryzyko nieograniczonego dostępu do wrażliwych przepływów biznesowych ^[5]. Wśród scenariuszy są wykupienie przez automaty niemal całego limitowanego towaru w celu odsprzedaży oraz automatyczne zakładanie kont, by gromadzić punkty z programu poleceń ^[5]. Takie nadużycia wykonują zwykle złośliwe boty, a w sklepach pokrewnym zjawiskiem jest testowanie kart.

OWASP Top 10 z 2021 roku podaje przykład kina, w którym atakujący z pomocą zniżki grupowej rezerwowali setki miejsc w wielu salach naraz kilkoma żądaniami, co przyniosło duże straty przychodu ^[4].

Jak się bronić

Błędów logiki zwykle nie wykryje automatyczny skaner. PortSwigger tłumaczy, że są niewidoczne przy normalnym użyciu i wymagają znajomości dziedziny biznesowej, dlatego trudno je znaleźć narzędziami ^[1]. Wykrywa je raczej ręczny test penetracyjny albo program bug bounty ^[1].

PortSwigger zaleca, by zespół rozumiał dziedzinę aplikacji, unikał niejawnych założeń o zachowaniu użytkowników i systemu, dokumentował te założenia i analizował przyczyny znalezionych błędów ^[1]. OWASP w kategorii A04:2021 zwraca uwagę, że niebezpiecznego projektu nie naprawi idealna implementacja, bo potrzebne zabezpieczenia nigdy nie powstały ^[4]. Zaleca wpisywanie wymagań bezpieczeństwa do historyjek użytkownika i testy, które sprawdzają odporność krytycznych przepływów zarówno na scenariusze użycia, jak i nadużycia ^[4]. Pomaga w tym modelowanie zagrożeń.

Dla przepływów narażonych na automaty OWASP wskazuje odcisk urządzenia, wykrywanie człowieka, na przykład przez CAPTCHA, analizę wzorców zachowania i blokowanie adresów znanych sieci proxy ^[5]. Uzupełnieniem jest rate limiting.

Historia i przykłady

Błędy logiki biznesowej bywają częścią dużych incydentów. Sekurak 5 lipca 2021 roku opisał atak na oprogramowanie Kaseya VSA, w którym według cytowanych raportów przestępcy wykorzystali błędy logiki biznesowej i SQL injection, a następnie rozprowadzili ransomware REvil ^[8]. Skutkiem był między innymi przestój około 800 sklepów szwedzkiej sieci Coop, której kasy przestały działać po ataku na dostawcę ^[8]. Incydent jest przykładem ataku na łańcuch dostaw.