Mass Assignment: jak vzniká a jak mu zabránit
Autor: Redakce Domeny.ForSale Zveřejněno
Stručně: Mass Assignment je automatické přiřazování dat z požadavku HTTP do polí interního objektu nebo databázového modelu. Bezpečnostní zranitelnost vzniká tehdy, když aplikace tímto způsobem dovoluje měnit i pole, která by uživatel neměl ovládat — například roli správce. Ochrana spočívá především ve výslovném určení povolených polí a kontrole oprávnění na straně serveru.
Jak funguje automatické přiřazování polí
Webová aplikace přijímá data odesílaná prohlížečem, například při ukládání profilu. Požadavek HTTP, tedy zpráva odeslaná serveru, může obsahovat uživatelské jméno, e-mailovou adresu a další hodnoty. Server je pak musí přiřadit k odpovídajícím polím ve svém kódu.
Mass Assignment umožňuje provést toto přiřazení hromadně, bez ručního přiřazování jednotlivých hodnot. Mechanismus páruje názvy přijatých polí s vlastnostmi objektu. Pokud data obsahují pole jmeno, jeho hodnota se může přiřadit k vlastnosti jmeno v objektu uživatele.
Takové mapování se označuje také jako autobinding. V souvislosti s touto zranitelností se používá i označení object injection, které však v jiných oblastech bezpečnosti může znamenat odlišné mechanismy. Samotné automatické mapování není chybou: problém nastává, když server přijímá více polí, než by měl.
Jednoduchý příklad: úprava profilu a změna role
Předpokládejme, že formulář pro úpravu profilu umožňuje změnit pouze zobrazované jméno a e-mailovou adresu. Správná data odesílaná serveru vypadají takto:
{
"jmeno": "Anna",
"email": "anna (at) example.com"
}
Účet má však v databázi více vlastností. Kromě jména a adresy uchovává také pole role, které určuje oprávnění uživatele. Formulář ho nezobrazuje, protože běžný uživatel by ho neměl mít možnost měnit.
Útočník ale nemusí formulář používat. Může upravit odesílaný požadavek a přidat další pole:
{
"jmeno": "Anna",
"email": "anna (at) example.com",
"role": "administrator"
}
Pokud server bez omezení zkopíruje všechny přijaté vlastnosti do účtu, může uložit i novou roli. Jestliže systém oprávnění toto pole používá, může útočník získat přístup s oprávněními správce.
Skrytí pole ve formuláři není zabezpečení. O tom, co lze změnit, musí rozhodovat server, nikoli vzhled stránky nebo kód JavaScript spuštěný v prohlížeči.
Která data jsou zvlášť ohrožená
Mass Assignment se netýká jen uživatelských účtů. Riziko vzniká všude, kde se data zvenčí automaticky přiřazují do objektů obsahujících i interní vlastnosti.
Zvláštní kontrolu vyžadují například tato pole:
vlastnik_id— může určovat, komu patří dokument nebo objednávka;cena— může ovlivnit částku účtovanou za nákup;stav_platby— může označovat, zda byla objednávka zaplacena;email_overen— může rozhodovat o přeskočení ověření adresy.
Zákazník e-shopu by měl například odeslat identifikátor produktu a zvolený počet kusů. Cenu by měl server určit podle vlastní nabídky, nikoli bezpodmínečně přijmout hodnotu uvedenou v požadavku.
Ne každé přidané pole umožní úspěšný útok. Server ho musí přijmout, přiřadit a použít způsobem, který má vliv na fungování aplikace. Při analýze je proto nutné prověřit celý tok dat, nejen obsah formuláře.
Jak účinně omezit riziko Mass Assignment
Základní ochranou je seznam povolených polí: server pro danou operaci přijímá pouze vlastnosti určené programátorem. Pro běžnou úpravu profilu to mohou být jmeno a email, nikoli však role.
Postup může vypadat takto:
povolena_pole = ["jmeno", "email"]
data_profilu = vyber_pole(data_pozadavku, povolena_pole)
aktualizuj_profil(prihlaseny_uzivatel, data_profilu)
Jde o pseudokód ilustrující princip, nikoli o hotovou implementaci. Podle použitého frameworku lze omezení nastavit v mechanismu mapování, ve validátoru nebo v samostatném vstupním objektu, často označovaném jako DTO. Takový objekt popisuje data povolená pro konkrétní operaci, místo aby kopíroval strukturu celého databázového záznamu.
Samotná kontrola formátu nestačí. Hodnota administrator může být platným názvem role, ale běžný uživatel přesto nemá právo ji nastavit. Je proto nutná také autorizace, tedy kontrola, zda daná osoba smí konkrétní změnu provést.
U seznamu zakázaných polí snáze dojde k opomenutí: po přidání nové vlastnosti modelu je třeba pamatovat na její zablokování. Seznam povolených polí nové vlastnosti automaticky nezpřístupňuje. Přesné chování a výchozí ochranná opatření používaného frameworku je nutné ověřit v jeho oficiální dokumentaci.
Jak prověřit vlastní aplikaci
Testujte pouze vlastní systém nebo prostředí, k jehož testování máte souhlas. Pro úpravu profilu připravte požadavek se správnými daty a poté přidejte pole, které by uživatel neměl měnit.
Zkontrolujte nejen odpověď serveru, ale také uložená data a skutečná oprávnění účtu. Bezpečná implementace by měla nepovolenou změnu odmítnout nebo přidané pole ignorovat, aniž by změnila chráněnou hodnotu.
Nejprve projděte místa, kde se veškerá data požadavku předávají přímo metodám vytvářejícím nebo aktualizujícím záznamy. Pro každé takové místo sepište povolená pole a přidejte test potvrzující, že ostatní pole nelze změnit.
Viz také: Co je Path Traversal
Přečtěte si také
