Biztonság a web-en Java
által |
A számítógépek és a
hálózatok biztonságát sokan félreértik és alábecsülik. Még napjainkban is, mikor több ezer
hitelkártyás visszaélésről hallani és nem ritkák a legelterjedtebb
böngésző és levelező programokban talált hibák sem, még mindig túl
sokan vannak, akik egyszerűen figyelmen kívül hagyják ezt a tényt, vagy
egyszerűen feláldozzák a biztonságosságot a használhatóság kedvéért. A Java védelmi rendszere ezt a problémát próbálja
meg megoldani úgy, hogy mind a böngészők, mind az alkalmazások
forgalmazóinak kezébe adja az eszközt, hogy olyan biztonsági rendszert
építsenek termékeikbe, melyet a felhasználó átlláthat, testreszabhat és
illeszthet a változó kívánalmakhoz. A Java biztonsági rendszeréről elmondható,
hogy úgy nyújt magas szintű biztonságot, hogy az nem megy a
használhatóság rovására. Nem is túl szigorú mikor az nem indokolt, és nem is
túl engedékeny veszélyes helyzetekben. Java rendszerek esetében nem létezik
az a kísértés, mely már sok rendszer vesztét okozta. Nevezetesen arról a
kísértésről van szó, hogy a felhasználó megkerülje a biztonság rendszert
csak azért, hogy elvégezzen egy műveletet. A Java 2 védelmi tartományai jól vizsgáznak olyan
nem megbízható környezetekben, mint például a Web, és kiterjeszthetők
olyan területekre is, ahol a Java felület még csak most kezdi megvetni a
lábát. A Java Cryptography System alapjául szolgálhat elektronikus
kereskedelmi rendszereknek és egyéb olyan rendszereknek is, ahol a
biztonságos szállítás fontos szerephez jut. A védelmi tartományok és a
titkosítási rendszer együtt egy olyan konzisztens, kiterjeszthető és
felületfüggetlen rendszert alkotnak, mely kereskedelmi forgalomban kapható,
általános célú rendszerek esetén igen ritka. Meglepően nehéz 3GL rendszerekre biztonságos
rendszereket építeni. A C, C++ vagy Basic nyelven írott kódokban lévő
programhibák támadási felületetet biztosítanak az okos, jól informált
támadóknak. A Java felület biztonságosabb, mint más futtatható tartalmat
támogató eszközök. Ez a Java felület bizonyos tulajdonságaiból adódik, melyek
közül nem is mindegyik biztonsági okokból került be a Jávába. Talán a
legfontosabb különbség a Java felület és a hagyományos operációs rendszerek
között az, hogy a Java kód nem közvetlenül a felhasználó számítógépén fut. A
Java kód az úgynevezett virtuális gépen fut, mely nem más, mint egy program,
mely értelmezi a Java bájtkódot, és lefordítja azt CPU utasításokká. Ez az
indirekt programvégrehajtás teszi lehetővé a sokat emlegetett “írd meg egyszer,
s futtasd bárhol” filozófia megvalósítását. Java appleteknek soha nincs közvetlen hozzáférésük a
CPU-hoz és az operációs rendszerhez, ezért a virtuális gép megakadályozhatja
fájlok ellopását és vírusok bevitelét.
Az applet nem nyithat meg fájlokat közvetlenül az operációs rendszer
rutinjain keresztül, nem hozhat létre hálózati kapcsolatot, s nincs joga más
egyéb kockázatos műveletekhez sem. Az applet ezeket a műveleteket
csak a Java osztályain keresztül hajtja végre. Szemléletesen szólva a virtuális
gép biztonsági őr módjára belépés előtt lefegyverzi az appletet,
nehogy az odabent, a felhasználó gépén valami galibát okozzon. A Java
biztonsági modelljének alapja tehát az indirekt programvégrehajtás és a
virtuális gép. Az indirekt programvégrehajtáson kívül nyelvi
eszközök is rendelkezésre állnak a kód biztonságossá tételére. Ami pedig még
fontosabb, a Java nyelvből hiányoznak azok az elemek, melyek
megnehezítik a kód biztonságossá tételét. Ezt a fajta védelmet egyrészt a
nyelv, másrészt a futtatható rendszer garantálja. -
A Java nyelvben nincs
lehetőség mutatók használatára. A memória csak objektumokon keresztül
kezelhető. -
A Java nyelv a tömbök
indexelését futásidőben ellenőrzi. A tömbök tudják magukról, hogy
mekkorák, így nem lehet őket túlindexelni. Ezáltal a program véletlenül
sem tud hozzáférni olyan memóriaterülethez, melyhez nincs joga. -
A sztring objektumok
létrehozásuk után nem változtathatók meg. Ez megelőzi a C és C++
nyelvekben oly gyakori buffer túlcsordulásokat -
A Java erősen
típusos. Az explicit típuskonverzió csak kompatibilis objektumok között
lehetséges, így nem fordul elő, hogy nem létező metódus hívódik meg
egy objektumban. -
A Java az
objetkumokhoz és azok mezőihez négy különböző hozzáférési módot
biztosít. A public azt jelenti,
hogy mindenki használhatja, aki hozzá tud férni az adott osztályhoz. A protected azt jelenti, hogy csak az
adott osztályból, és annak leszármazottaiból látszik. A private
típusú mezők csak az adott osztályból láthatók. A default típusú mezőket az adott osztállyal egy csomagban
lévő osztályok látják. -
Ha egy objektumhoz
vagy primitívhez nincs megadva explicit módon kezdeti érték, akkor az egy jól
definiált alapértelmezett kezdeti értéket vesz fel. A Java nyelv biztonsági szolgáltatásai szerves
részét képezik a Java biztonsági modelljének. Ez tehát azt jelenti, hogy
abszolut nem támaszkodhatunk a fordítóprogramra a nyelv biztonságossá
tételéhez. A fordítóprogramot nem tudjuk korlátozni, ezért nem épülhet rá a biztonsági modell. Ezért van az, hogy
a Java nyelv esetében ezek a biztonsági ellenőrzések a program
futtatásakor történnek, mikor már a birtokunkban van a kód és
megvizsgálhatjuk azt az általunk biztonságosnak ítélt virtuális géppel. A Java biztonság mechanizmusai az ellenséges kód
kiszűrése helyett inkább megakadályozzák az ellenséges műveleteket.
A nem megbízható appleteknek nagyon sok mindenhez nincs joguk Jáva környezetben két fajta program futhat,
alkalmazás (application) és
programka (applet). A Jáva
biztonsági mechanizmusainak nagy része csak a programkákra vonatkozik, az
alkalmazások korlátozások nélkül használhatják a rendszer erőforrásait. A
programkák biztonsági modellje 3 szintre bontható. Először jönnek a Jáva
nyelvnek a programok megbízhatóságát növelő tulajdonságai. Második lépésként
a köztes kódú programokat betöltés közben, futtatás előtt szigorú
ellenőrzésnek vetik alá, hogy a program megfelel-e a virtuális gép által
megkövetelt szemantikának. Harmadszorra jönnek a böngészőkben megvalósított
virtuális gép és könyvtárak, amelyek a programkáknak szigorúan felügyelt,
korlátozott futási környezetet nyújtanak. A harmadik szintet "homokozó" (sandbox) modellként is emlegetik. A
homokozó irányelvek: az appleteknek nincs joguk: a felhasználó gépének
fájlrendszerét olvasni; a felhasználó gépének fájlrendszerét írni; a
felhasználó gépén lévő fájlokról információt szerezni; a felhasználó
gépének fájlrendszeréből fájlt törölni; néhány kivétellel lekérdezni a
rendszer tulajdonságait; a kliens valamely hálózati portjára csatlakozni; a
származási HTTP szervertől különböző gép bármely hálózati portjára
csatlakozni; könyvtárat vagy DLL-t betölteni; más prgoramot vagy szkriptet
végrehajtani; a virtuális gépet kilépésre kényszeríteni; címsor nélküli
előugró ablakot nyitni. Megemlítenék a Jáva környezetben
meglévő néhány potenciális biztonsági problémát: implementációs problémák; a
biztonsági menedzser; erőforrások túlterhelése; naplózás hiánya A Java felület
újabb kiadásainak elterjedésével és az újabb szolgáltatások bevezetésével
vélhetően újabb hibák fognak előkerülni. Szomorú tény, hogy
egyrészt minden nagy rendszerben van hiba, másrészt, hogy a programhibákon
keresztül általában meg lehet támadni a rendszert. A Java nyelv
biztonságossága lecsökkentheti a hibák számát és a hibák által okozott kár
mértékét, de nem változtathatja meg ezt a tapasztalati tényt. Amint
az bizonyára feltűnt, a biztonság nem állapot, hanem folyamat. Nem lehet olyan rendszert építeni, mely
100 százalékosan biztonságos. |
Finta Annamária |