Java agrīno izaugsmi veicināja tīklā lejupielādējams kods, labāk zināms kā sīklietotnes. Apletu drošība ir attīstījusies līdz ar Java izaugsmi, un mūsdienās tas bieži vien rodas neskaidrības Java versiju, komerciāli pieejamo pārlūkprogrammu un spraudņu dēļ.
Šis raksts, trešais sērijā, aptvers dažādas prasības no tīkla lejupielādēta Java koda drošai darbībai. Kaut arī mobilais kods nav revolucionārs jēdziens, Java un internets datoru drošībai rada dažas unikālas problēmas. Java arhitektūras attīstība un tās ietekme uz Java pamatdrošību tika apspriesta 1. un 2. daļā. Šajā rakstā ir norādīts cits: praktiska pieeja, lai sasaistītu visus jēdzienus, izvietojot vienkāršu sīklietotni, kas raksta vietējā failu sistēmā .
Java drošības attīstība un jēdzieni: Izlasiet visu sēriju!
- 1. daļa: Uzziniet datora drošības jēdzienus un terminus šajā ievada pārskatā
- 2. daļa: Atklājiet Java drošības trūkumus
- 3. daļa: Droši apkarojiet Java sīklietotņu drošību
- 4. daļa: Uzziniet, kā papildu paketes paplašina un uzlabo Java drošību
- 5. daļa: J2SE 1.4 piedāvā daudzus Java drošības uzlabojumus
Sīklietotnes piemērs ir publiskās atslēgas kriptogrāfija, kas tika ieviesta iepriekš šajā sērijā. Kodu, kas parakstīts, izmantojot parakstītāja privāto atslēgu, var palaist klientu mašīnās, tiklīdz parakstītājam atbilstošā publiskā atslēga attiecīgajā mašīnā tiek uzskatīta par uzticamu. Mēs arī apspriedīsim, kā politikas failus, kas piešķir atļaujas un atslēgu krātuvi, var izmantot kā publisko un privāto atslēgu krātuvi. Turklāt mēs izcelsim Java 2 SDK drošības rīkus un Netscape signtool, jo tie ļauj izvietot.
Šis raksts izseko Java drošības attīstību, sākot ar lietojumprogrammu drošību sākotnējā Java 2 laidienā un pārejot uz jaunāko Java 2 versiju 1.3. Šī pieeja palīdz pakāpeniski ieviest jēdzienus, sākot ar ļoti vienkāršiem jēdzieniem un beidzot ar diezgan progresīvu piemēru.
Šajā sērijā nav paredzēts sniegt visaptverošu rokasgrāmatu par datoru drošību. Datoru drošība ir daudzpusīgs jautājums, kas skar vairākas disciplīnas, departamentus un kultūras. Ieguldījumi tehnoloģijās būtu jāpapildina ar ieguldījumiem personāla apmācībā, stingru politikas izpildi un periodisku vispārējās drošības politikas pārskatīšanu.
Piezīme: Šajā rakstā ir palaista Java sīklietotne, kas paredzēta sīklietotņu drošības problēmu demonstrēšanai. Sīkāku informāciju lasiet zemāk.
Lietojumprogrammu drošība
Sāksim izmeklēšanu, aplūkojot lietojumprogrammu drošību. 2. daļā mēs redzējām, kā Java drošība ir attīstījusies no smilškastes modeļa līdz smalkgraudainam drošības modelim. Mēs arī redzējām, ka lietojumprogrammas (vietējais kods) pēc noklusējuma iegūst brīvu valdīšanas laiku un uz tām neattiecas tāda pati kontrole kā sīklietotnēm (tīklā lejupielādējams kods), kuras parasti tiek uzskatītas par neuzticamām. Pārmaiņās no pagātnes Java 2 drošības lietojumprogrammas pēc izvēles var pakļaut tādam pašam kontroles līmenim kā sīklietotnes.
Pirmkārt, ātra piezīme par writeFile.java, kods, kas šajā rakstā izmantots, lai ilustrētu Java 2 drošības elementus. Šī programma ir Sun modificēta sīklietotņu koda nedaudz modificēta versija, kas ir pieejama tīmeklī, lai ilustrētu dažas Java 2 drošības funkcijas. Programma, kas pārveidota, lai nodrošinātu lietojumprogrammu atbalstu, mēģina izveidot un rakstīt failu vietējā failu sistēmā. Piekļuvi vietējai failu sistēmai pārbauda drošības pārvaldnieks. Šajā rakstā mēs redzēsim, kā šo konkrēto darbību var atļaut drošā veidā.
/ ** * Pēc noklusējuma tas izvirza drošības izņēmumu kā sīklietotni. * * Ar JDK 1.2 appletviewer *, ja konfigurējat sistēmu piešķirt sīklietotnēm, kuras parakstījis "Duke" * un lejupielādēts no Java programmatūras vietnes, lai ierakstītu failu * direktorijā / tmp (vai failā ar nosaukumu "C: \ tmpfoo") "uz * Windows sistēmas), tad šī sīklietotne var darboties. * * @version JDK 1.2 * @author Marianne Mueller * @Modificējis Raghavan Srinivas [Rags] * / import java.awt. *; importēt java.io. *; importēt java.lang. *; importēt java.applet. *; publiskā klase writeFile paplašina sīklietotni {String myFile = "/ tmp / foo"; Fails f = jauns fails (myFile); DataOutputStream dos; public void init () {String osname = System.getProperty ("os.name"); if (osname.indexOf ("Windows")! = -1) {myFile = "C:" + File.separator + "tmpfoo"; }} public void paint (Grafika g) {try {dos = new DataOutputStream (new BufferedOutputStream (new FileOutputStream (myFile), 128)); dos.writeBytes ("Kaķi var jūs hipnotizēt, kad jūs to vismazāk gaidāt \ n"); dos.skalot (); dos.close (); g.drawString ("Veiksmīgi uzrakstījāt failā ar nosaukumu" + myFile + "- ejiet to apskatīt!", 10, 10); } catch (SecurityException e) {g.drawString ("writeFile: noķerts drošības izņēmums", 10, 10); } catch (IOException ioe) {g.drawString ("writeFile: nozvejots i / o izņēmums", 10, 10); }} public static void main (String args []) {Rāmis f = jauns Rāmis ("writeFile"); writeFile writefile = jauns writeFile (); writefile.init (); writefile.start (); f.add ("Centrs", rakstīšanas fails); f.setSize (300, 100); f.parādīt (); }} Palaidot Java 2 izpildlaika vidē ģenerēto baitkodu, Standard Edition (JRE) ļaus lietojumprogrammai pēc noklusējuma modificēt vietējās failu sistēmas failu, jo pēc noklusējuma politikas Java 2 lietojumprogrammas netiek pakļautas drošības pārvaldniekam. Šī politika ir pamatota, jo lietojumprogrammas parasti ir lokāli ģenerēts kods un netiek lejupielādētas tīklā. Šajā komandrindā tiek parādīts logs, kas parādīts 1. attēlā, norādot, ka fails ir izveidots un ierakstīts.
$ java writeFile
Lai pakļautu kodu Java 2 drošības pārvaldniekam, izsauciet šādu komandrindu, kurai jāsniedz 2. attēlā norādītie rezultāti. Ievērojiet, ka lietojumprogramma radīja drošības izņēmumu, ko izraisīja mēģinājums modificēt vietējo failu sistēmu. Īpaši iekļautais drošības pārvaldnieks radīja izņēmumu.
$ java -Djava.security.manager writeFile
Iepriekš ilustrētie gadījumi ir ārkārtīgi drošības politikas piemēri. Pirmajā gadījumā pieteikums nebija pakļauts nekādai kontrolei; pēdējā tā tika pakļauta ļoti stingrai kontrolei. Vairumā gadījumu politika būs jānosaka kaut kur pa vidu.
Izmantojot politikas failu, jūs varat veikt starpposma politiku. Lai to izdarītu, izveidojiet politikas failu ar nosaukumu viss.politika darba direktorijā:
piešķirt {atļauju java.io.FilePermission "<>", "rakstīt"; }; Palaist to pašu koda daļu ar šādu komandrindu ļaus modificēt vietējo failu sistēmu:
$ java -Djava.security.manager -Djava.security.policy = all.policy writeFile
Šajā piemērā lietojumprogramma bija pakļauta drošības pārvaldniekam, taču kopējo politiku noteica politikas fails, kas to ļāva visi faili lokālajā failu sistēmā, kas jāmaina. Stingrāka politika, iespējams, bija atļaut mainīt tikai attiecīgo failu - tmpfoo šajā gadījumā.
Sīkāka informācija par politikas failu, tostarp ierakstu sintakse, tiks aplūkota vēlāk šajā rakstā. Bet vispirms apskatīsim sīklietotņu drošību un salīdzināsim to ar lietojumprogrammu drošību.
Apletu drošība
Līdz šim mēs esam izpētījuši lietojumprogrammu drošību. Lielākai daļai drošības funkciju var piekļūt un tos var mainīt, izmantojot komandrindu. Pietiekami drošas un tomēr nedaudz elastīgas politikas nodrošināšana sīklietotņu vidē izrādās daudz sarežģītāka. Mēs sāksim aplūkot sīklietotnes izvietošanu Appletviewer. Mēs vēlāk apskatīsim pārlūkprogrammā izvietotās sīklietotnes.
Java kodu politiku galvenokārt nosaka CodeSource, kas satur divas informācijas: vietu, kur kods radies, un personu, kas to parakstīja.
Appletviewer
Izveidojiet failu ar nosaukumu writeFile.html ar šādu saturu:
Java drošības piemērs: failu rakstīšana
Palaižot sīklietotni ar šādu komandrindu, tiks parādīts 3. attēlā redzamais logs:
$ appletviewer writeFile.html
Ievērojiet, ka pretēji tam, kas notiktu ar lietojumprogrammu, sīklietotne radīja izņēmumu, jo sīklietotne pēc noklusējuma ir pakļauta drošības pārvaldniekam. Ja nepieciešams, instalēšanu var regulēt pielāgojama politika. Palaist šādu komandrindu:
appletviewer -J "-Djava.security.policy = all.policy" writeFile.html
kā jūs varētu sagaidīt, ļautu modificēt tmpfoo failu, jo tas bija atļauts saskaņā ar politikas failu.
Pārlūkprogrammas
Apletu drošība pārlūkprogrammās cenšas novērst neuzticamu sīklietotņu potenciāli bīstamu darbību veikšanu, vienlaikus ļaujot optimāli piekļūt uzticamām sīklietotnēm. Apletu drošības izvietošana pārlūkprogrammās būtiski atšķiras no līdz šim redzētā, galvenokārt šādu iemeslu dēļ:
- Noklusējuma neuzticēšanās kodam, kas lejupielādēts tīklā
- Nepietiekama piekļuve komandrindas opcijām, lai palaistu JVM, jo JVM tiek mitināts pārlūkprogrammas kontekstā
- Nepietiekams atbalsts dažām jaunākajām drošības funkcijām pārlūkprogrammās iekļautajos JVM
Attiecībā uz pirmo problēmu, lai novērstu iespējamās problēmas, kas rodas no neuzticama koda palaišanas, agrākās Java versijās tika izmantots smilškastes modelis (sk. "1. sānjosla: smilškastes modelis"). Uzticība ir galvenokārt filozofiska vai emocionāla, nevis tehniska problēma; tomēr tehnoloģijas var palīdzēt. Piemēram, Java kodu var parakstīt, izmantojot sertifikātus. Šajā piemērā parakstītājs netieši garantē kodu, parakstot to. Galu galā lietotājam, kurš darbojas ar kodu, ir jāuzticas parakstīšanas entītijai vai ne, ņemot vērā, ka šie sertifikāti garantē, ka kodu patiešām ir parakstījusi paredzētā persona vai organizācija.
Otra problēma rodas no piekļuves trūkuma JVM palaišanas opcijām pārlūkprogrammas kontekstā. Piemēram, nav vienkārša veida, kā izvietot un izmantot pielāgotus politikas failus, kā mēs to varētu izdarīt iepriekšējā piemērā. Tā vietā šādas politikas būs jāiestata failiem, kuru pamatā ir JRE instalācija. Pielāgotus klases iekrāvējus vai drošības pārvaldniekus nevar viegli uzstādīt.
Trešā problēma - JRE jaunāko versiju atbalsta trūkums noklusējuma JVM ar pārlūku tiek atrisināta, izmantojot Java spraudni (sk. "Sidebar 2: Java Plug-in Primer"). Patiešām, pamatjautājums ir tāds, ka politikas failu modificēšana nav ļoti vienkārša. Tā kā sīklietotnes var izvietot tūkstošiem vai pat miljoniem klientu mašīnu, var būt vide, kurā lietotājiem, iespējams, nav laba izpratne par drošību vai viņi nav iepazinušies ar politikas faila modificēšanas metodēm. Java spraudnis nodrošina risinājumu, lai gan ieteicams izmantot politikas failus visur, kur tas ir praktiski un piemēroti.
Tālāk mēs sīkāk aplūkosim sīklietotņu drošību, iekļaujot koda parakstīšanas piemērus pārlūka vidē ar Java spraudni. Mēs tikai aprobežosimies ar Java spraudņa versiju 1.3, ja vien nav skaidri norādīts citādi.
Java spraudnis un drošība
Java spraudnis atbalsta standarta Java 2 SDK, Standard Edition (J2SE), ieskaitot drošības modeli. Visas sīklietotnes darbojas zem standarta sīklietotņu drošības pārvaldnieka, kas neļauj potenciāli ļaunprātīgām sīklietotnēm veikt bīstamas darbības, piemēram, lasīt vietējos failus. RSA parakstītas sīklietotnes var izvietot, izmantojot Java spraudni. Turklāt Java spraudnis mēģina identiski palaist sīklietotnes gan Netscape Navigator, gan Internet Explorer, izvairoties no pārlūkprogrammai specifiskiem resursiem. Tas nodrošina, ka RSA parakstīts sīklietotne darbosies identiski abās pārlūkprogrammās ar Java spraudni. Java spraudnis atbalsta arī HTTPS, drošu HTTP versiju.
Lai ar spraudni uzlabota pārlūkprogramma varētu uzticēties sīklietotnei un piešķirt tai visas privilēģijas vai precīzu atļauju kopu (kā norādīts J2EE politikas failā), lietotājam ir iepriekš jākonfigurē uzticamo parakstītāju sertifikātu kešatmiņa. ( .veikaliņš failu JRE 1.3), lai tam pievienotu sīklietotnes parakstu. Tomēr šis risinājums nav labi mērogojams, ja sīklietotne ir jāizvieto tūkstošiem klientu mašīnu, un tas ne vienmēr ir iespējams, jo lietotāji var iepriekš nezināt, kurš sīklietotni parakstīja, ka mēģina palaist. Arī agrākās Java spraudņa versijas atbalstīja koda parakstīšanu, izmantojot DSA, kas nav tik izplatīta kā RSA.
Jauns klases iekrāvējs, sun.plugin.security.PluginClassLoader Java spraudnī 1.3 pārvar iepriekš minētos ierobežojumus. Tas īsteno atbalstu RSA pārbaudei un dinamiskai uzticības pārvaldībai.
Programmatūras izstrādes komplekta (SDK) rīki
Trīs rīki, kas nodarbojas ar drošību un ir pieejami kā Java 2 SDK daļa, ir:
atslēgas rīks- Pārvalda atslēgu krātuves un sertifikātusburcinieks- Ģenerē un pārbauda JAR parakstuspolitikas rīks- Pārvalda politikas failus, izmantojot GUI balstītu rīku
Tālāk esošajās sadaļās mēs aplūkosim dažus no šiem rīkiem svarīgās iespējas. Skatiet Resursi, lai iegūtu detalizētāku dokumentāciju, kas saistīta ar konkrētiem rīkiem.
