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