brak ograniczenia pochodzenia (origin)

Brak ograniczenia pochodzenia (origin) to luka bezpieczeństwa dopuszczająca żądania z dowolnej domeny bez weryfikacji ich źródła.

Brak ograniczenia pochodzenia (origin) – czym jest ten problem

Brak ograniczenia pochodzenia (origin) oznacza sytuację, w której aplikacja internetowa przyjmuje żądania wysyłane z dowolnej domeny, bez sprawdzenia, czy wskazane źródło powinno mieć dostęp do określonych zasobów. W praktyce najczęściej odnosi się to do błędnej konfiguracji mechanizmu CORS, czyli zasad kontrolujących komunikację pomiędzy stronami internetowymi działającymi w różnych źródłach. Każda witryna ma własne pochodzenie określane przez schemat połączenia, nazwę hosta i port. Jeżeli aplikacja nie ogranicza listy dozwolonych źródeł, obca strona może próbować odczytywać odpowiedzi serwera albo nakłaniać przeglądarkę do wysyłania żądań w imieniu zalogowanej osoby.

Samo pojawienie się nagłówka Access-Control-Allow-Origin: * nie zawsze oznacza pełną podatność. Znaczenie ma cały sposób obsługi sesji, ciasteczek, tokenów, metod HTTP, nagłówków oraz odpowiedzi zwracanych przez serwer. Ryzyko rośnie wtedy, gdy szerokie zezwolenie łączy się z uwierzytelnianiem opartym na ciasteczkach lub innym mechanizmem automatycznie dołączającym dane sesyjne. W takim układzie strona kontrolowana przez osobę atakującą może stać się pośrednikiem pomiędzy przeglądarką użytkownika a aplikacją.

Warto odróżnić kontrolę pochodzenia od kontroli dostępu po stronie serwera. CORS jest przede wszystkim mechanizmem przeglądarkowym. Nie zastępuje uwierzytelniania, autoryzacji, ochrony przed fałszowaniem żądań ani poprawnej walidacji danych. Błąd może nie ujawniać się podczas zwykłego odwiedzania witryny, ponieważ użytkownik widzi poprawnie działający interfejs. Problem ujawnia się dopiero przy analizie odpowiedzi, zachowania przeglądarki i możliwości wykonania operacji z obcej domeny.

Brak ograniczenia origin w kontekście CORS i polityki same-origin

Polityka same-origin jest jednym z podstawowych zabezpieczeń przeglądarek. Ogranicza możliwość swobodnego odczytywania danych pomiędzy różnymi źródłami. Dwie strony mogą być uznane za odrębne, gdy różni je domena, protokół albo port, nawet jeśli należą do tej samej organizacji. CORS stanowi kontrolowany wyjątek od tej zasady. Serwer informuje w nim przeglądarkę, jakie źródła mogą odczytywać odpowiedzi oraz w jakich warunkach.

Najczęstszy błąd polega na ustawieniu gwiazdki jako wartości dozwolonego pochodzenia bez sprawdzenia, czy dane zwracane przez punkt końcowy mają charakter publiczny. Dla publicznych zasobów, takich jak ogólne pliki lub informacje przeznaczone dla każdego odwiedzającego, taka konfiguracja może być zamierzona. Inaczej należy traktować profil użytkownika, historię operacji, dane formularzy, dokumenty, ustawienia konta i odpowiedzi zawierające informacje zależne od sesji.

Niebezpieczny wariant może pojawić się także wtedy, gdy serwer odsyła wartość nagłówka Origin bez sprawdzenia jej względem zamkniętej listy zaufanych adresów. Należy zwrócić uwagę na różnice między domeną główną a subdomenami, użycie protokołu HTTP lub HTTPS, końcowe kropki w nazwie hosta, wielkość liter, przekierowania oraz nietypowe porty. Pozornie drobna różnica w porównywaniu tekstu może doprowadzić do zaakceptowania źródła, którego nie przewidziano w projekcie.

Osobnego sprawdzenia wymaga opcja przekazywania poświadczeń. Jeżeli przeglądarka ma wysyłać ciasteczka lub inne dane sesyjne, nie powinno się łączyć tego z bezwarunkowym zezwoleniem dla wszystkich źródeł. Właściwa konfiguracja wymaga jawnego wskazania dozwolonego pochodzenia oraz oceny, czy dana metoda i dany punkt końcowy rzeczywiście muszą być dostępne między źródłami. Preflight, czyli żądanie wstępne, nie jest gwarancją bezpieczeństwa, jeżeli właściwe żądanie nadal pozostaje źle zabezpieczone.

Brak ograniczenia pochodzenia (origin) a typowe skutki

Skutki błędnej konfiguracji zależą od rodzaju danych i sposobu działania aplikacji. W najłagodniejszym przypadku dochodzi do udostępnienia informacji, które i tak miały być publiczne. W poważniejszym wariancie może dojść do odczytu danych przypisanych do zalogowanego użytkownika, jeżeli przeglądarka dołącza jego sesję, a serwer akceptuje obce pochodzenie. Odczytana odpowiedź może zawierać dane kontaktowe, ustawienia konta, historię zgłoszeń, szczegóły zamówień albo informacje techniczne.

Odrębnym zagrożeniem jest możliwość wykonywania operacji zmieniających stan aplikacji. Sam CORS nie tworzy automatycznie dowolnej możliwości wykonania takiej operacji, jednak błędna konfiguracja może ułatwić połączenie kilku słabości: braku tokena antyfałszerstwa, niewłaściwej ochrony ciasteczek, zbyt szerokich uprawnień sesji i braku dodatkowej weryfikacji po stronie serwera. W efekcie użytkownik może nieświadomie zatwierdzić zmianę ustawień, dodanie adresu odbiorczego albo inną czynność dostępną w jego koncie.

W raportach bezpieczeństwa spotyka się również sytuacje, w których nieprawidłowo działający serwer ujawnia zbyt dużo informacji w nagłówkach odpowiedzi. Dotyczy to między innymi listy dozwolonych metod, nietypowych nagłówków, sposobu obsługi błędów i różnic pomiędzy środowiskiem testowym a produkcyjnym. Nie każda obserwacja oznacza podatność możliwą do wykorzystania, dlatego ocena powinna uwzględniać realną dostępność danych, obecność uwierzytelnienia oraz zakres uprawnień użytkownika.

Ryzyko bywa większe przy aplikacjach korzystających z wielu niezależnych interfejsów. Jeden punkt końcowy może być poprawnie zabezpieczony, a inny może mieć odziedziczoną, szeroką konfigurację. Problem może dotyczyć także serwera pośredniczącego, bramy API albo pamięci podręcznej, która nie rozróżnia odpowiedzi zależnych od nagłówka Origin. Wtedy nieprawidłowo utworzona odpowiedź może zostać przekazana kolejnym klientom.

Brak ograniczenia origin – praktyczne wskazówki diagnostyczne

Analizę warto rozpocząć od sporządzenia listy punktów końcowych, które mają działać z innych źródeł. Dla każdego z nich powinno się określić, czy odpowiedź jest publiczna, czy wymaga zalogowania, jakie metody są potrzebne i czy konieczne jest przekazywanie poświadczeń. Dopiero na tej podstawie można ustalić wąski zestaw dozwolonych źródeł. Lista powinna być jawna, kontrolowana i utrzymywana razem z dokumentacją aplikacji.

Podczas testów należy sprawdzać odpowiedzi dla źródeł prawidłowych, nieznanych, podobnych wizualnie oraz różniących się protokołem lub portem. Warto zweryfikować zachowanie przy żądaniu prostym i przy żądaniu preflight. Należy też sprawdzić, czy odpowiedź zawiera właściwy nagłówek Vary: Origin, gdy treść odpowiedzi zmienia się zależnie od źródła. Bez tego pośrednia pamięć podręczna może potraktować odpowiedź dla jednego źródła jako odpowiednią dla innego.

Konfiguracja nie powinna opierać się na luźnych dopasowaniach tekstowych. Bezpieczniej jest porównywać znormalizowane źródło z dokładnie zdefiniowanym zbiorem wartości, a następnie generować nagłówki tylko po pozytywnym dopasowaniu. Nie należy dopuszczać dowolnych końcówek domeny wyłącznie na podstawie fragmentu nazwy. Jeżeli potrzebne są subdomeny, ich zakres powinien być ograniczony i regularnie przeglądany.

Przydatne jest prowadzenie testów regresji po każdej zmianie konfiguracji serwera, biblioteki, bramy API lub systemu uwierzytelniania. Sprawdzeniu powinny podlegać także ustawienia ciasteczek, w tym ich zakres, wymóg bezpiecznego połączenia i zasady wysyłania między witrynami. W razie wątpliwości można zlecić przegląd konfiguracji oraz test działania aplikacji; w Warszawskim Pogotowiu Komputerowym 24/7 diagnoza laptopa jest wykonywana bez opłat.

Kiedy zgłosić brak ograniczenia pochodzenia (origin) do sprawdzenia

Zgłoszenie jest uzasadnione, gdy w narzędziach deweloperskich pojawiają się niespójne nagłówki CORS, serwer akceptuje nieznane źródła albo aplikacja zachowuje się inaczej po otwarciu z obcej domeny. Szczególnej uwagi wymagają odpowiedzi zawierające informacje użytkownika, komunikaty z danymi wewnętrznymi oraz operacje dostępne po zalogowaniu. Nie należy zakładać, że brak widocznego błędu w interfejsie oznacza prawidłową ochronę.

Warto zgłosić problem również po zmianie domeny, migracji aplikacji, dodaniu subdomeny, wdrożeniu nowego modułu logowania lub zmianie serwera pośredniczącego. Takie modyfikacje często powodują niezamierzone rozszerzenie zaufania. Przed przekazaniem sprawy dobrze jest zapisać adres badanego punktu końcowego, metodę żądania, obserwowane nagłówki oraz informację, czy użytkownik był zalogowany. Nie powinno się przekazywać haseł ani pełnych tokenów sesyjnych.

Ocena powinna zakończyć się jasnym rozróżnieniem pomiędzy zamierzonym dostępem do publicznego zasobu a rzeczywistym ujawnieniem danych chronionych. W razie potwierdzenia problemu zaleca się zawężenie listy źródeł, ograniczenie poświadczeń, przegląd uprawnień, testy po wdrożeniu poprawki i obserwację logów. Brak ograniczenia pochodzenia (origin) nie jest wyłącznie kwestią jednego nagłówka; bezpieczeństwo zależy od połączenia polityki przeglądarki, konfiguracji serwera, sesji użytkownika i kontroli dostępu.