brak weryfikacji pochodzenia żądania

Brak weryfikacji pochodzenia żądania to luka bezpieczeństwa dopuszczająca przetworzenie zapytań z niezaufanych źródeł.

Na czym polega brak weryfikacji pochodzenia żądania

Brak weryfikacji pochodzenia żądania oznacza, że aplikacja przyjmuje i przetwarza żądania bez sprawdzenia, z jakiego kontekstu przeglądarki lub systemu zostały wysłane. Sam fakt dotarcia zapytania do serwera nie potwierdza, że pochodzi ono z właściwej strony internetowej, zaufanego komponentu programu ani od użytkownika, który świadomie wykonał daną czynność. Taka luka może wystąpić w aplikacji webowej, panelu administracyjnym, interfejsie API albo lokalnym programie komunikującym się z usługą sieciową.

Najczęściej problem wiąże się z atakiem CSRF, czyli Cross-Site Request Forgery. Jeżeli użytkownik jest zalogowany w jednej witrynie, a jego przeglądarka automatycznie dołącza ciasteczko sesyjne do żądania, inna strona może próbować skłonić przeglądarkę do wysłania żądania do tej witryny. Jeżeli serwer nie wymaga dodatkowego dowodu, że żądanie pochodzi z prawidłowego formularza lub aplikacji, może wykonać operację w kontekście zalogowanego użytkownika.

Źródła informacji o pochodzeniu w protokołach HTTP

Przeglądarka może przekazywać serwerowi nagłówek Origin, zawierający schemat, nazwę hosta i port źródłowej strony, na przykład https://panel.example. Przy niektórych nawigacjach dostępny bywa również nagłówek Referer, wskazujący adres strony, z której rozpoczęto żądanie. Nagłówki te są pomocne przy kontroli pochodzenia, ale nie powinny być jedynym zabezpieczeniem każdej operacji. Nie wszystkie rodzaje żądań mają identyczny zestaw nagłówków, a część klientów innych niż przeglądarki może wysyłać żądania bez typowych informacji przeglądarkowych.

Mechanizm CORS, czyli Cross-Origin Resource Sharing, określa, czy przeglądarka może udostępnić skryptowi odpowiedź z innego pochodzenia. CORS nie zastępuje kontroli dostępu po stronie serwera i nie chroni automatycznie przed każdym żądaniem zmieniającym dane. Serwer powinien niezależnie sprawdzać uwierzytelnienie, uprawnienia oraz poprawność parametrów. Ważne jest także rozróżnienie pochodzenia od samej nazwy domeny: różny schemat, host lub port oznacza inne origin, nawet gdy pozostała część adresu wygląda podobnie.

Skutki przyjęcia żądania z niezaufanego kontekstu

Skutki zależą od tego, jakie operacje udostępnia podatny endpoint. Jeżeli żądanie tylko pobiera publiczne dane, konsekwencje mogą być ograniczone. Jeżeli jednak endpoint zmienia hasło, adres e-mail, ustawienia konta, dane konfiguracji, zawartość koszyka albo status zamówienia, brak kontroli pochodzenia może prowadzić do wykonania niezamierzonej czynności. Szczególnie istotne są żądania metod POST, PUT, PATCH i DELETE, choć sama metoda HTTP nie stanowi zabezpieczenia.

Nie należy utożsamiać tej luki z brakiem logowania. Użytkownik może być prawidłowo uwierzytelniony, a aplikacja może nadal nie rozpoznawać, czy konkretne żądanie zostało wywołane przez właściwy interfejs. Nieprawidłowa kontrola może też wynikać z akceptowania dowolnej wartości Origin, automatycznego odbijania jej w nagłówku Access-Control-Allow-Origin albo zezwalania na poświadczenia dla zbyt szerokiego zestawu domen. Oceniając problem, trzeba prześledzić konkretny endpoint, sposób obsługi sesji i zakres operacji, które może wykonać zalogowany użytkownik.

Metody ograniczenia ryzyka w aplikacji

Typową ochroną przed CSRF jest token synchronizowany z sesją. Serwer generuje wartość trudną do odgadnięcia, umieszcza ją w formularzu lub przekazuje aplikacji, a następnie wymaga jej w żądaniu zmieniającym stan. Token powinien być sprawdzany po stronie serwera i powiązany z właściwą sesją. W aplikacjach korzystających z nagłówka Origin można dodatkowo stosować ścisłą listę dozwolonych źródeł, zamiast akceptować dowolną wartość przekazaną przez klienta. Ciasteczka sesyjne powinny mieć odpowiednio dobrane atrybuty Secure, HttpOnly i SameSite; SameSite ogranicza wysyłanie ciasteczka w kontekście żądań między witrynami, ale jego działanie trzeba ocenić względem rzeczywistego przepływu aplikacji.

Podczas diagnostyki należy sprawdzić logi serwera, żądania w narzędziach deweloperskich przeglądarki, konfigurację ciasteczek, reguły CORS oraz kod obsługujący endpointy. Test powinien obejmować zarówno prawidłowe żądanie z aplikacji, jak i próbę wysłania tego samego żądania z innego pochodzenia lub bez wymaganego tokenu. Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów i komputerów PC, w tym diagnostyką problemów z oprogramowaniem oraz konfiguracją urządzeń użytkowanych w domu lub biurze.