A következő vizsgált kérdéskör a hozzáférési szintek, és jogosultságok biztonsági kérdései. A weblapok 78%-a sebezhető ezen a módon. A hozzáférési szintek biztonsági kockázata azt jelenti, hogy a támadó hozzáfér egy azonos jogosultsági szinten lévő másik felhasználó adataihoz, vagy egy magasabb jogosultságokkal rendelkező felhasználó számára fenntartott funkciókhoz, adatokhoz.
Titkos URL-ek
Az egyik módszer ahogy a webalkalmazások alkotói megpróbálják a jogosultsági szinteket kezelni, az az, hogy az alacsonyabb jogosultságú felhasználók nem kapják meg a felületükre azokat a linkeket amelyek elvezetnek az emelt jogosultságú funkciókhoz. Természetes, hogy ne legyenek a felületünkön olyan linkek amelyeket úgy sem használhatunk, de ez védekezésként vagy korlátozásként roppant kevés.
Ilyen url lehet egy /admin, vagy mondjuk egy /f23ui/admin.
Egyrészt legtöbb ilyen esetben maga a “titkos” url könnyen kitalálható vagy megtippelhető. Másrészt ha az url nehezen kitalálható akkor is számtalan helyen megjelenik, mint a böngésző címsora, a history, a szerver logokban, a userek emlékezetében akik korábban hozzáfértek ezekhez, könyvjelzőkben, stb.
Az is előfordul, hogy a programozó JavaScript segítségével tünteti el, vagy adja hozzá az emelt jogosultsági szinthez tartozó linkeket. A kliens oldali biztonsági ellenőrzés problémáiról már írtunk korábban.
Egyedi azonosítók
Előfordul olyan is, hogy a programozó egyedi URL-eket rendel mondjuk letölthető dokumentumokhoz és szintén az egyediség az egyetlen ami a nem kívánt hozzáférések ellen kíván védeni. Egy http://sehol.se/titkosDoksik.php?id=584563214 biztosan elég egyedi és nehezen megjegyezhető, de ha a user fogja és átírja a számokat akkor más védelem híján máris hozzáfér más bizalmas adatokhoz. Hogy ez a tipus mennyire jellemző azt az is mutatja, hogy kb 3/4 évvel ezelőtt volt egy botrány amikor egy újságíró valamelyik nagy szoftver cég bejelentéséhez tartozó sajtó anyagát találta meg ezzel a módszerrel 2 nappal a bejelentés előtt. Hopp!
Persze ha a számok nem sorszámok hanem véletlen generált sorozatok, akkor is egy rövidke script segítségével pár perc alatt véletlen stringek százezrei kerülhetnek tesztelésre.
Sima fájlok
Ha a titkos URL-ünk egy sima fájlra mutat, mint a http://sehol.se/542135468.pdf akkor a webszerver ezt közvetlenül kiszolgálja, azaz praktikusan nincs webalkalmazás szintű hozzáférés kezelésünk. Az URL itt is módosítható. Ezzel a módszerrel on-line megvásárolt e-book-okat, szoftvereket szereztek már meg. A probléma a sima fájlok kiszolgálása és a következőkben leírt többlépcsős funkciók feltételezéséből született, és nem vizsgálták, hogy egy sikeres fizetés után a vásárló pontosan mit, jobban mondva miket tölt le.
Több lépcsős funkciók
A fejlesztők néha abból a (téves) feltételezésből indulnak ki, hogy a user végigjárta azt az utat amit a fejlesztő olyan gondosan megtervezett. Ha egy csoport adminisztrátora vagy akkor megjelenik a userek kezelése menü, ha erre rákattintasz akkor egy selectben megjelennek a hozzád tartozó userek és onnan fogod kiválasztani, hogy kit akarsz éppen megszemélyesíteni, kitörölni. Azonban ha a támadó egyből a select-álós url-t hívja meg és kihagyja az előző két lépést, akkor lehet, hogy minden user kezeléséhez hozzá fog férni, mivel nem ment át azon a lépésen ami a szűrést végezte. Vagy a select helyett kézzel küld be egy más csoportba tartozó user azonosítót.
Nem biztonságos hozzáférési szint beállítás
Vannak olyan alkalmazások amelyek egy egyszerű URL paraméter alapján adnak ki magasabb hozzáférési jogokat. Ezek legyenek olyan egyértelműek mint a http://sehol.se/?admin=true vagy éppen kicsit kacifántosabbak, mint a http://sehol.se/?wqtz=957uh vagy könnyen kitalálhatóak lesznek, vagy megtalálhatók a logokban, stb ahonnan végigpróbálgathatóak.
Ennek a módszernek egy kifinomultabb változata, hogy az alkalmazás vizsgálja a Referer headert és az alapján dönt arról, hogy kiadható-e az admin jog. A Referer headerrel csak egy bajunk van, hogy a usertől jön, hamisítható, azaz nem megbízható.
Óvintézkedések
Nézzük tehát fejlesztőként mire kell figyelnünk ha el akarjuk kerülni a hozzáférési szintjeink kompromittálását. Persze az általános szabály itt is az mint mindenhol máshol, ne bízzunk a usertől jövő adatokban.
- Ne függjünk az URL-ek egyediségén vagy titkosságán. Ezek mellett / helyett a fájlok kiszolgálása előtt le kell ellenőriznünk, hogy a user valóban hozzáférhet-e a kért tartalomhoz
- Ne bízzunk a userek által elküldött paraméterekben (
admin=true) - Ne feltételezzük, hogy a userek egy meghatározott sorrend szerint fognak végiglépkedni a funkciókon
- Támaszkodjunk a session-ban tárolt jogosultsági szintekre
- Minden egyes lekérésnél ellenőrizzük a jogosultsági szintet – ezt a legkönnyebben úgy tehetjük meg ha az alkalmazásunkban központosítjuk a hozzáférési szintek ellenőrzését
- Teszteljük le a fent leírt minták szerint, hogy valahogyan kijátszható-e a jogosultsági rendszerünk
- Különösen érzékeny adatok esetében használjunk külön biztonsági ellenőrzést, mint az IP cím szűrés, vagy éppen egy RSA, SMS jelszó bekérés.
- A sima fájlokat mozgassuk a webroot-on kívülre, hogy ne lehessen őket az alkalmazás kikerülésével elérni közvetlen URL-eken keresztül.
A következő részben a kód beoltásokkal fogunk foglalkozni.