Co to jest Mass Assignment?
Autor: Redakcja Domeny.ForSale Opublikowano
W skrócie: Mass Assignment to automatyczne przypisywanie danych z żądania HTTP do pól wewnętrznego obiektu lub modelu bazy danych. Staje się luką bezpieczeństwa, gdy aplikacja pozwala w ten sposób zmieniać również pola, nad którymi użytkownik nie powinien mieć kontroli — na przykład rolę administratora. Ochrona polega przede wszystkim na jawnym wskazaniu dozwolonych pól i sprawdzaniu uprawnień po stronie serwera.
Jak działa automatyczne przypisywanie pól
Aplikacja webowa odbiera dane przesyłane przez przeglądarkę, na przykład podczas zapisywania profilu. Żądanie HTTP, czyli komunikat wysyłany do serwera, może zawierać nazwę użytkownika, adres e-mail i inne wartości. Serwer musi następnie przypisać je do odpowiednich pól w swoim kodzie.
Mass Assignment pozwala zrobić to zbiorczo, bez ręcznego przypisywania każdej wartości. Mechanizm dopasowuje nazwy otrzymanych pól do właściwości obiektu. Jeśli dane zawierają pole nazwa, jego wartość może trafić do właściwości nazwa w obiekcie użytkownika.
Takie mapowanie bywa nazywane również autobinding. W kontekście tej podatności spotyka się też określenie object injection, choć w innych kontekstach bezpieczeństwa może ono oznaczać odmienne mechanizmy. Samo automatyczne mapowanie nie jest błędem: problem zaczyna się wtedy, gdy serwer przyjmuje więcej pól, niż powinien.
Prosty przykład: edycja profilu i zmiana roli
Załóżmy, że formularz edycji profilu pozwala zmienić wyłącznie nazwę wyświetlaną i adres e-mail. Prawidłowe dane wysyłane do serwera wyglądają tak:
{
"nazwa": "Anna",
"email": "anna (at) example.com"
}
W bazie danych konto ma jednak więcej właściwości. Oprócz nazwy i adresu przechowuje również pole rola, które określa uprawnienia użytkownika. Formularz go nie pokazuje, bo zwykły użytkownik nie powinien móc go zmieniać.
Osoba atakująca nie musi jednak korzystać z formularza. Może zmodyfikować wysyłane żądanie i dopisać dodatkowe pole:
{
"nazwa": "Anna",
"email": "anna (at) example.com",
"rola": "administrator"
}
Jeżeli serwer bez ograniczeń skopiuje wszystkie otrzymane właściwości do konta, może zapisać również nową rolę. Gdy system uprawnień korzysta z tego pola, skutkiem może być uzyskanie dostępu administracyjnego.
Brak pola w formularzu nie jest zabezpieczeniem. O tym, co można zmienić, musi decydować serwer, a nie wygląd strony czy kod JavaScript działający w przeglądarce.
Jakie dane są szczególnie narażone
Mass Assignment nie dotyczy wyłącznie kont użytkowników. Ryzyko pojawia się wszędzie tam, gdzie dane z zewnątrz trafiają automatycznie do obiektów zawierających także właściwości wewnętrzne.
Przykładowe pola wymagające szczególnej kontroli to:
wlasciciel_id— może określać, do kogo należy dokument lub zamówienie;cena— może wpływać na kwotę naliczaną za zakup;status_platnosci— może wskazywać, czy zamówienie zostało opłacone;email_potwierdzony— może decydować o pominięciu potwierdzania adresu.
Przykładowo klient sklepu powinien przesłać identyfikator produktu i wybraną liczbę sztuk. Cenę serwer powinien ustalić na podstawie swojej oferty, zamiast bezwarunkowo przyjmować wartość podaną w żądaniu.
Nie każde dodatkowe pole doprowadzi do ataku. Musi zostać zaakceptowane, przypisane i wykorzystane w sposób mający znaczenie dla działania aplikacji. Dlatego podczas analizy trzeba sprawdzić cały przepływ danych, a nie tylko zawartość formularza.
Jak skutecznie ograniczyć Mass Assignment
Podstawową ochroną jest lista dozwolonych pól: serwer przyjmuje do danej operacji wyłącznie właściwości wskazane przez programistę. Dla zwykłej edycji profilu mogą to być nazwa i email, ale nie rola.
Schemat postępowania może wyglądać tak:
dozwolone_pola = ["nazwa", "email"]
dane_profilu = wybierz_pola(dane_zadania, dozwolone_pola)
aktualizuj_profil(zalogowany_uzytkownik, dane_profilu)
To pseudokod ilustrujący zasadę, nie gotowa implementacja. Zależnie od frameworka ograniczenia można ustawić w mechanizmie mapowania, walidatorze albo osobnym obiekcie wejściowym, często nazywanym DTO. Taki obiekt opisuje dane dopuszczone dla konkretnej operacji, zamiast odzwierciedlać cały rekord z bazy.
Sama walidacja formatu nie wystarcza. Wartość administrator może być poprawną nazwą roli, ale zwykły użytkownik nadal nie ma prawa jej ustawić. Potrzebna jest więc również autoryzacja, czyli sprawdzenie, czy dana osoba może wykonać określoną zmianę.
Lista pól zabronionych jest bardziej podatna na przeoczenia: po dodaniu nowej właściwości modelu trzeba pamiętać o jej zablokowaniu. Lista dozwolonych pól nie udostępnia nowych właściwości automatycznie. Dokładne zachowanie i domyślne zabezpieczenia używanego frameworka należy potwierdzić w jego oficjalnej dokumentacji.
Jak sprawdzić własną aplikację
Testuj wyłącznie własny system lub środowisko, do którego masz zgodę. Dla operacji edycji profilu przygotuj żądanie z poprawnymi danymi, a następnie dodaj pole, którego użytkownik nie powinien zmieniać.
Sprawdź nie tylko odpowiedź serwera, lecz także zapisane dane i rzeczywiste uprawnienia konta. Bezpieczna implementacja powinna odrzucić niedozwoloną zmianę albo zignorować dodatkowe pole bez zmiany chronionej wartości.
Na początek przejrzyj miejsca, w których całe dane żądania trafiają bezpośrednio do metod tworzących lub aktualizujących rekordy. Dla każdego z nich zapisz dozwolone pola i dodaj test potwierdzający, że pozostałych nie da się zmienić.
Zobacz też: Co to jest Path Traversal
Przeczytaj także
