A biztonságtudatos alkalmazástervezés hiánya párosul a fejlesztői trehánysággal abban a hibában, amely sok millió felhasználó érzékeny adatait szolgáltatja ki hekkereknek. A varázsszó: IDOR (Insecure Direct Object References vagy nem biztonságos közvetlen objektumhivatkozások). A hiba a webes világ egyik kulcselemét érinti: a biztonsági kutatók akkor beszélnek IDOR jellegű sérülékenységről, amikor egy webes alkalmazás vagy API backendje nem ellenőrzi megfelelően, hogy egy felhasználó valóban hozzáférhet-e adott adathoz.

Mint az OWASP definíciójából kiderül, ilyenkor adott alkalmazás a felhasználó által megadott bemenet alapján ad közvetlen hozzáférést egy objektumhoz. Ehhez csak az objektumra közvetlenül mutató paraméter értékét kell módosítania.

Ha például egy weboldal, amely a

http://foo.bar/gettransaction?id=12345

URL-sémát követve mutatja meg a "12345" azonosítószámú tranzakciót, tartalmazza az IDOR sérülékenységet, hozzáférhetünk bármely más tranzakció adataihoz, ha az azonosítószám átírjuk például "12346"-ra. (Ideális esetben ez lehetetlen, mert a rendszer minden esetben ellenőrzi, hogy a bejelentkezett felhasználónak van-e hozzáférési jogosultsága adott tranzakció adataihoz.)

A CISA (Cybersecurity and Infrastructure Security Agency) múlt héten kiadott riasztása szerint egyre gyakoribbak az IDOR jellegű sérülékenységek. Az ügynökség négyféle típust különít el. A horizontális típus esetében valaki illetéktelenül fér hozzá olyan szintű adathoz, amely megfelel a jogosultsági szintjének (pl. a banki ügyfél más számlájának egyenlegét is lekérheti). A vertikális típus esetében olyan adathoz fér hozzá, amelyhez elvileg az övénél magasabb jogosultsági szint kellene. Az objektumszintű típusnál a felhasználó közvetlenül módosíthat vagy törölhet olyan objektumot, amelyet nem módosíthatna vagy törölhetne. A funkciószintű típusnál pedig olyan funkcióhoz fér hozzá, amihez elvileg nem lenne szabad hozzáférnie.

Csak a biztonságtudatos fejlesztés segít

A sérülékenység bármilyen típusú webes alkalmazásban benne lehet. A CISA közleménye példaként a First American Financial 2019-es ügyét hozta. A pénzügyi szolgáltatótól 800 millió személyes pénzügyi adat szivárgott ki, köztük bankszámlakivonatok, bankszámlaszámok, jelzáloghitelekkel kapcsolatos dokumentumok és társadalombiztosítási azonosítók. Bár az esetet részletesen megíró Brian Krebs biztonsági kutató nem nevezte IDOR sérülékenységnek az incidenst, beszámolójából és a First American Financial általa idézett közleményéből is erre lehet következtetni: a hibát egyik alkalmazásuk tervezési hibájára vezették vissza, amelynek következtében az ügyfelek adataihoz a megfelelő jogosultság nélkül lehetett hozzáférni.

A közelmúltban biztonsági kutatók találtak okosotthon-rendszerekben és csevegőprogramokban – pl. a Microsoft Teamsben – is IDOR sebezhetőséget.

A CISA közleménye szerint az IDOR jellegű sérülékenységek megelőzésének leghatékonyabb módja, ha az alkalmazásfejlesztés minden egyes szakaszában kiemelten kezelik a biztonságos fejlesztés elvét. Ehhez az automatizált kódelemző és tesztelő eszközök széles skáláját használhatják a fejlesztők. Ha például nincs elegendő erőforrás (többnyire nincs!) a különféle penetration tesztek elvégzésére, érdemes legalább ún. DAST (Dynamic Application Security Testing) eszközöket alkalmazni, melyek egy futó alkalmazásban kívülről keresik kontrollált, biztonságos körülmények között a sérülékenységeket.