Zgodnjo rast Jave je spodbudila koda, ki jo je mogoče naložiti v omrežje, bolje poznano kot apleti. Varnost apletov se je razvila z rastjo Jave in je danes vir pogostih zmede zaradi različnih različic Jave, komercialno dostopnih brskalnikov in vtičnikov.
Ta članek, tretji v seriji, bo zajemal različne zahteve za varno izvajanje kode Java, prenesene iz omrežja. Čeprav mobilna koda ni revolucionaren koncept, Java in internet predstavljata nekaj edinstvenih izzivov za računalniško varnost. Razvoj arhitekture Java in njen vpliv na osnovno varnost Java je bil obravnavan v delih 1 in 2. Ta članek se loteva drugače: praktični pristop k povezovanju vseh konceptov z uporabo preprostega programčka, ki piše v lokalni datotečni sistem .
Razvoj in koncepti varnosti Java: preberite celotno serijo!
- 1. del: Naučite se konceptov in izrazov računalniške varnosti v tem uvodnem pregledu
- 2. del: Odkrijte podrobnosti varnosti Java
- 3. del: Zaupanje se lotite varnosti Java-aplikacij
- 4. del: Naučite se, kako neobvezni paketi razširjajo in povečujejo varnost Java
- 5. del: J2SE 1.4 ponuja številne izboljšave varnosti Java
Primerno jedro apleta je kriptografija javnega ključa, predstavljena prej v tej seriji. Koda, podpisana z zasebnim ključem podpisnika, se lahko zažene na odjemalskih računalnikih, ko se javni ključ, ki ustreza podpisniku, šteje za zaupanja vrednega na ustreznem računalniku. Razpravljali bomo tudi o tem, kako lahko datoteke s pravilniki, ki dodeljujejo dovoljenja in shrambo ključev, uporabimo kot skladišče javnih in zasebnih ključev. Poleg tega bomo izpostavili varnostna orodja Java 2 SDK in Netscape signtool, saj omogočajo uvajanje.
Ta članek sledi razvoju varnosti Java, začenši z varnostjo aplikacij v začetni izdaji Java 2 in nadaljevanjem do najnovejše različice Java 2, različice 1.3. Ta pristop pomaga pri postopnem uvajanju konceptov, začenši z zelo preprostimi koncepti in konča v dokaj naprednem primeru.
Namen te serije ni celovit vodnik po računalniški varnosti. Računalniška varnost je večplastno vprašanje, ki se dotika več disciplin, oddelkov in kultur. Naložbam v tehnologije je treba slediti z naložbami v usposabljanje osebja, dosledno uveljavljanje politik in redni pregled celotne varnostne politike.
Opomba: Ta članek vsebuje delujoči programček Java, zasnovan za prikaz varnostnih težav programčka. Za več podrobnosti preberite spodaj.
Varnost aplikacij
Začnimo preiskavo s preučevanjem varnosti aplikacij. V 2. delu smo videli, kako se je varnost Java iz modela peskovnika razvila v natančno določen varnostni model. Ugotovili smo tudi, da aplikacije (lokalna koda) privzeto dobijo brezplačno vladavino in niso podvržene enakemu nadzoru kot programčki (koda, ki jo je mogoče prenesti z omrežja), ki se običajno štejejo za nezaupljive. Kot sprememba v preteklosti so lahko v Java 2 varnostne aplikacije po izbiri podvržene isti ravni nadzora kot programčki.
Najprej na kratko o writeFile.java, koda, uporabljena v tem članku za ponazoritev varnostnih funkcij v Javi 2. Ta program je nekoliko spremenjena različica kode programčka, ki jo ponuja Sun, in je na voljo prek spleta za ponazoritev nekaterih funkcij varnosti Java 2. Program, prirejen za podporo aplikaciji, poskuša ustvariti in zapisati datoteko v lokalni datotečni sistem. Dostop do lokalnega datotečnega sistema pregleda skrbnik varnosti. V tem članku bomo videli, kako je mogoče to določeno operacijo dovoliti na varen način.
/ ** * To privzeto sproži varnostno izjemo kot programček. * * Z JDK 1.2 appletviewer *, če sistem konfigurirate tako, da podeljuje programčke s podpisom "Duke" * in prenesene s spletnega mesta Java Software, da v datoteko / tmp (ali v datoteko z imenom "C: \ tmpfoo "v sistemu * Windows), potem se lahko ta programček zažene. * * @version JDK 1.2 * @author Marianne Mueller * @Modified by Raghavan Srinivas [Rags] * / import java.awt. *; uvoz java.io. *; uvoz java.lang. *; uvoz java.applet. *; javni razred writeFile razširi programček {String myFile = "/ tmp / foo"; Datoteka f = nova datoteka (myFile); DataOutputStream dos; javna void init () {String osname = System.getProperty ("os.name"); če (osname.indexOf ("Windows")! = -1) {myFile = "C:" + File.separator + "tmpfoo"; }} javna void paint (Graphics g) {try {dos = new DataOutputStream (new BufferedOutputStream (new FileOutputStream (myFile), 128)); dos.writeBytes ("Mačke vas lahko hipnotizirajo, kadar to najmanj pričakujete \ n"); dos.flush (); dos.close (); g.drawString ("Uspešno zapisano v datoteko z imenom" + myFile + "- poglejte si jo!", 10, 10); } catch (SecurityException e) {g.drawString ("writeFile: ujeta varnostna izjema", 10, 10); } catch (IOException ioe) {g.drawString ("writeFile: catch i / o izjema", 10, 10); }} public static void main (String args []) {Frame f = new Frame ("writeFile"); writeFile writefile = new writeFile (); writefile.init (); writefile.start (); f.add ("Center", zapis datoteke); f.setSize (300, 100); f.show (); }} Z zagonom bajtkode, ustvarjene v okolju izvajalnega okolja Java 2, bo Standard Edition (JRE) dovolil aplikaciji privzeto spremeniti datoteko v lokalnem datotečnem sistemu, saj privzeti pravilnik aplikacij Java 2 ne podreja upravljalniku varnosti. Ta pravilnik je upravičen, ker so aplikacije običajno lokalno generirana koda in se ne prenašajo po omrežju. Naslednja ukazna vrstica ustvari okno, prikazano na sliki 1, ki kaže, da je bila datoteka ustvarjena in zapisana.
$ java writeFile
Če želite kodo podrediti upravitelju varnosti Java 2, pokličite naslednjo ukazno vrstico, ki naj bi dala rezultate, prikazane na sliki 2. Upoštevajte, da je aplikacija ustvarila varnostno izjemo, ki jo je povzročil poskus spreminjanja lokalnega datotečnega sistema. Izrecno vključen varnostni upravitelj je ustvaril izjemo.
$ java -Djava.security.manager writeFile
Zgornji primeri so izjemni primeri varnostne politike. V prejšnjem primeru vloga ni bila predmet nobenega nadzora; pri slednjem je bil pod zelo rigidnim nadzorom. V večini primerov bo treba politiko postaviti nekje vmes.
Vmesno politiko lahko dosežete z datoteko pravilnika. Če želite to narediti, ustvarite datoteko s pravilnikom, imenovano vse.politika v delovnem imeniku:
grant {dovoljenje java.io.FilePermission "<>", "write"; }; Zagon istega dela kode z naslednjo ukazno vrstico bo omogočil spreminjanje lokalnega datotečnega sistema:
$ java -Djava.security.manager -Djava.security.policy = all.policy writeFile
V tem primeru je bila aplikacija podrejena upravitelju varnosti, vendar je celotno politiko urejala datoteka pravilnika, ki je dovoljevala vse datoteke v lokalnem datotečnem sistemu, ki jih je treba spremeniti. Strožji pravilnik bi morda bil, da dovoli spreminjanje samo ustrezne datoteke - tmpfoo v tem primeru.
Več podrobnosti o datoteki s pravilniki, vključno s sintakso vnosov, bom zajel kasneje v tem članku. Najprej pa si oglejmo varnost aplikacij in jo primerjajmo z varnostjo aplikacij.
Varnost apletov
Do zdaj smo preučevali varnost aplikacij. Kot taka je do večine varnostnih funkcij mogoče dostopati in jih spreminjati prek ukazne vrstice. Zagotavljanje ustrezno varne in vendar nekoliko prilagodljive politike v okolju apletov se izkaže za bistveno bolj zahtevno. Začeli bomo s preučevanjem namestitve programčka v Appletviewer. Kasneje si bomo ogledali programčke, ki jih namešča brskalnik.
Politiko Java kode narekuje predvsem CodeSource, ki vsebuje dva podatka: kraj, kjer je koda nastala, in oseba, ki jo je podpisala.
Appletviewer
Ustvarite datoteko z imenom writeFile.html z naslednjo vsebino:
Primer varnosti Java: pisanje datotek
Zagon programčka z naslednjo ukazno vrstico bi povzročil okno, prikazano na sliki 3:
$ appletviewer writeFile.html
Upoštevajte, da je - v nasprotju s tem, kar bi se zgodilo z aplikacijo - programček ustvaril izjemo, saj je programček privzeto pod nadzorom upravitelja varnosti. Po potrebi lahko namestitev ureja prilagodljiv pravilnik. Zagon naslednje ukazne vrstice:
appletviewer -J "-Djava.security.policy = all.policy" writeFile.html
bi, kot bi lahko pričakovali, dovolil spreminjanje tmpfoo datoteko, saj je bilo to dovoljeno v skladu z datoteko s pravilniki.
Brskalniki
Varnost apletov v brskalnikih skuša preprečiti nezaupnim programčkom izvajanje potencialno nevarnih operacij, hkrati pa omogoča optimalen dostop do zaupanja vrednih programčkov. Uvajanje varnosti apletov v brskalnikih se bistveno razlikuje od tistega, kar smo videli doslej, predvsem iz naslednjih razlogov:
- Privzeto pomanjkanje zaupanja v kodo, preneseno prek omrežja
- Nezadosten dostop do možnosti ukazne vrstice za zagon JVM, saj JVM gostuje v okviru brskalnika
- Nezadostna podpora nekaterim najnovejšim varnostnim funkcijam v JVM-jih, priloženih brskalnikom
Kar zadeva prvo težavo, so starejše različice Jave za odpravo morebitnih težav, ki so posledica zagonja nezaupljive kode, uporabljale model peskovnika (glejte "Stranska vrstica 1: Model peskovnika"). Zaupanje je predvsem filozofsko ali čustveno vprašanje in ne tehnično vprašanje; vendar lahko tehnologija pomaga. Kodo Java lahko na primer podpišete s certifikati. V tem primeru podpisnik implicitno jamči za kodo, tako da jo podpiše. Na koncu uporabnik, ki izvaja kodo, zaupa podpisni entiteti ali ne, saj ta potrdila zagotavljajo, da je kodo res podpisala predvidena oseba ali organizacija.
Druga težava izvira iz pomanjkanja dostopa do možnosti za zagon JVM v kontekstu brskalnika. Na primer, ni preprostega načina za uvajanje in uporabo prilagojenih datotek s pravilniki, kot bi lahko v prejšnjem primeru. Namesto tega bodo takšne pravilnike morale nastaviti datoteke, ki temeljijo na namestitvi JRE. Nalagalnikov po meri ali varnostnih upraviteljev ni mogoče enostavno namestiti.
Tretja težava, pomanjkanje podpore najnovejšim različicam JRE v privzetem JVM z brskalnikom, je rešena z uporabo vtičnika Java (glejte "Stranska vrstica 2: Priročnik za vtičnike Java"). Dejansko je osnovno vprašanje, da spreminjanje datotek s pravilniki ni zelo enostavno. Ker se lahko apleti uvedejo na tisoče ali celo milijone odjemalskih strojev, lahko obstajajo okolja, v katerih uporabniki morda ne razumejo dobro varnosti ali pa se ne seznanijo z načini spreminjanja datoteke s pravilniki. Vtičnik Java ponuja rešitev, čeprav je priporočljivo uporabljati datoteke s pravilniki, kjer koli je to praktično in primerno.
Nato si bomo podrobneje ogledali varnost aplikacij, ki vključuje primere podpisovanja kode v okolju brskalnika z vtičnikom Java. Razpravo bomo omejili na vtičnik Java različice 1.3, razen če ni izrecno navedeno drugače.
Vtičnik Java in varnost
Vtičnik Java podpira standardni Java 2 SDK, standardna izdaja (J2SE), vključno z varnostnim modelom. Vsi programčki se izvajajo pod standardnim upraviteljem varnosti programčka, ki potencialno zlonamernim programčkom preprečuje izvajanje nevarnih operacij, kot je branje lokalnih datotek. Aplete s podpisom RSA je mogoče razviti z vtičnikom Java. Poleg tega vtičnik Java poskuša na enak način zagnati programčke v Netscape Navigatorju in Internet Explorerju, tako da se izogne virom, specifičnim za brskalnik. To zagotavlja, da se bo programček, podpisan z RSA, v obeh brskalnikih z vtičnikom Java zagnal enako. Vtičnik Java podpira tudi HTTPS, varno različico HTTP.
Da bi brskalnik, ki je izboljšan z vtičnikom, zaupal programčku in mu podelil vse privilegije ali niz natančnih dovoljenj (kot je določeno v datoteki pravilnika J2EE), mora uporabnik predhodno konfigurirati svoj predpomnilnik zaupanja vrednih potrdil podpisnikov ( . keystore datoteko v JRE 1.3), da ji dodate podpisnik programčka. Vendar ta rešitev ni dobro prilagojena, če je treba programček namestiti na tisoče odjemalskih strojih, in morda ni vedno izvedljiva, ker uporabniki morda vnaprej ne vedo, kdo je podpisal programček, ki ga poskuša zagnati. Tudi starejše različice vtičnika Java so podpirale podpisovanje kode z uporabo DSA, ki ni tako razširjena kot RSA.
Nov razred nakladalca, sun.plugin.security.PluginClassLoader v vtičniku Java 1.3 premaga zgoraj omenjene omejitve. Izvaja podporo za preverjanje RSA in dinamično upravljanje zaupanja.
Orodja za razvoj programske opreme (SDK)
Tri orodja, ki se ukvarjajo z varnostjo in so na voljo kot del Java 2 SDK, so:
orodje za ključe- Upravlja shrambe ključev in potrdilajarrsigner- Ustvari in preveri podpise JARpolicytool- Upravlja datoteke s pravilniki prek orodja, ki temelji na GUI
V spodnjih oddelkih si bomo ogledali nekatere pomembne možnosti teh orodij. Za podrobnejšo dokumentacijo, povezano s posameznimi orodji, glejte Vire.
