Iespējams, esat dzirdējis par jaunāko JDK 1.1 un HotJava 1.0 drošības trūkumu, ko nesen atklāja Prinstonas universitātes Drošā interneta programmēšanas komanda (kuras vadītājs ir viens no autoriem). Ja vēlaties visu stāstu, lasiet tālāk. Bet Java drošībai ir vairāk nekā specifika par šo jaunāko drošības caurumu. Iegūsim zināmu perspektīvu.
Java drošība un sabiedrības uztvere
Visi zina, ka Java drošība ir liels darījums. Ikreiz, kad tiek atklāta drošības caurums, stāsts ļoti ātri ieplūst datoru jaunumos (un dažreiz arī biznesa jaunumos). Jūs, iespējams, nebrīnīsities, uzzinot, ka populārā prese uzrauga komp.riskumi un citas ar drošību saistītas ziņu grupas. Viņi izvēlas drošības stāstus, lai izceltu šķietami nejauši, lai gan, tā kā Java mūsdienās ir tik karsts, viņi gandrīz vienmēr izdrukā Java drošības stāstus.
Problēma ir tā, ka lielākā daļa ziņu vispār nepilnīgi izskaidro caurumus. Tas varētu novest pie klasiskas "raudāt vilka" problēmas, kad cilvēki pierod redzēt "šīs nedēļas drošības stāstu" un neizglīto sevi par reālajiem izpildāmā satura riskiem. Turklāt pārdevēji mēdz mazināt savas drošības problēmas, tādējādi vēl vairāk sajaucot galvenos jautājumus.
Labā ziņa ir tā, ka JavaSoft drošības komanda nopietni vēlas padarīt Java drošu. Sliktā ziņa ir tā, ka lielākā daļa Java izstrādātāju un lietotāju var ticēt uzmundrinājumam, kas izriet no tādiem notikumiem kā JavaOne, kur drošības problēmām netiek pievērsta liela uzmanība. Kā mēs teicām savā grāmatā, Java drošība: naidīgi sīklietotnes, caurumi un pretindes, Sun Microsystems ir daudz ko iegūt, ja tas liek uzskatīt, ka Java ir pilnīgi droša. Ir taisnība, ka pārdevēji ir darījuši visu iespējamo, lai Java ieviešana būtu pēc iespējas drošāka, taču izstrādātāji nevēlas pūles; viņi vēlas rezultātus.
Tā kā ar Java iespējots tīmekļa pārlūks ļauj Java kodu iegult Web lapā, lejupielādēt tīklā un palaist vietējā mašīnā, drošība ir kritiska problēma. Lietotāji var lejupielādēt Java sīklietotnes ārkārtīgi viegli - dažreiz pat to nezinot. Tas pakļauj Java lietotājus ievērojamam riskam.
Java dizaineri labi pārzina daudzos riskus, kas saistīti ar izpildāmo saturu. Lai apkarotu šos riskus, viņi īpaši izstrādāja Java, ņemot vērā drošības problēmas. Galvenais mērķis bija tieši pievērsties drošības problēmai, lai naiviem lietotājiem (teiksim, lielākajai daļai miljonu tīmekļa sērfotāju) nebūtu jākļūst par drošības ekspertiem, lai tikai droši izpētītu tīmekli. Tas ir apbrīnas vērts mērķis.
Trīs Java smilškastes daļas
Java ir ļoti spēcīga attīstības valoda. Neuzticamām sīklietotnēm nevajadzētu ļaut piekļūt visai šai jaudai. Java smilškaste neļauj sīklietotnēm veikt daudzas darbības. Labākais tehniskais dokuments par sīklietotņu ierobežojumiem ir Franka Jellina "Zema līmeņa drošība Java".
Java drošība balstās uz trim aizsardzības pakāpēm: baitu koda pārbaudītāju, klases ielādētāju un drošības pārvaldnieku. Šie trīs zari kopā veic ielādes un izpildes laika pārbaudes, lai ierobežotu piekļuvi failu sistēmai un tīklam, kā arī piekļuvi pārlūka iekšējiem elementiem. Katrs no šiem zariem savā ziņā ir atkarīgs no citiem. Lai drošības modelis darbotos pareizi, katrai daļai ir pareizi jādara savs darbs.
Baitu koda verificētājs:
Baitu koda verificētājs ir pirmais Java drošības modeļa atzarojums. Kad tiek apkopota Java avota programma, tā tiek apkopota līdz platformas neatkarīgam Java baitu kodam. Java baita kods ir "verificēts", pirms tas var darboties. Šī verifikācijas shēma ir paredzēta, lai nodrošinātu, ka baitu kods, kuru, iespējams, nav izveidojis Java kompilators, spēlē noteikumus. Galu galā baitu kodu varēja izveidot "naidīgs kompilators", kurš samontēja baitu kodu, kas paredzēts Java virtuālās mašīnas avārijai. Apletes baita koda pārbaude ir viens no veidiem, kā Java automātiski pārbauda neuzticamu ārējo kodu pirms drīkst palaist. Verificētājs pārbauda baitu kodu dažādos līmeņos. Visvienkāršākais tests nodrošina, ka baita koda fragmenta formāts ir pareizs. Mazāk pamata līmenī katram koda fragmentam tiek piemērots iebūvēts teorēmu sakāmvārds. Teorēmu sakāmvārds palīdz pārliecināties, ka baitu kods nevilto norādes, nepārkāpj piekļuves ierobežojumus vai piekļūst objektiem, izmantojot nepareizu veida informāciju. Pārbaudes process kopā ar kompilatora valodā iebūvētajiem drošības elementiem palīdz izveidot drošības garantiju pamatkopu.
Sīklietotņu klases iekrāvējs:
Otrais drošības aizsardzības elements ir Java Applet klases ielādētājs. Visi Java objekti pieder klasēm. Applet klases ielādētājs nosaka, kad un kā sīklietotne var pievienot klases darbošai Java videi. Daļa no tā uzdevuma ir pārliecināties, ka svarīgas Java izpildlaika vides daļas netiek aizstātas ar kodu, kuru mēģina instalēt sīklietotne. Parasti darbojas Java vidē var būt aktīvi daudzi klases iekrāvēji, no kuriem katrs nosaka savu "nosaukuma vietu". Vārdu atstarpes ļauj Java klases sadalīt atšķirīgos "veidos" atbilstoši to izcelsmei. Applet klases ielādētājs, kuru parasti piegādā pārlūka pārdevējs, ielādē visus sīklietotnes un klases, uz kurām tie atsaucas. Kad sīklietotne tiek ielādēta visā tīklā, sīklietotņu klases ielādētājs saņem bināros datus un padara tos par jauniem.
Drošības vadītājs:
Trešais Java drošības modeļa atzars ir Java Security Manager. Šī drošības modeļa daļa ierobežo veidus, kā sīklietotne var izmantot redzamās saskarnes. Tādējādi drošības pārvaldnieks ievieš lielu daļu no visa drošības modeļa. Drošības pārvaldnieks ir viens modulis, kas var veikt "bīstamu" metožu izpildes laika pārbaudes. Kods Java bibliotēkā konsultējas ar drošības pārvaldnieku ikreiz, kad tiek mēģināts veikt bīstamu darbību. Drošības pārvaldniekam tiek dota iespēja uzlikt veto operācijai, ģenerējot drošības izņēmumu (Java izstrādātāju bane visur). Drošības pārvaldnieka pieņemtajos lēmumos tiek ņemts vērā, kurš klases ielādētājs ielādēja pieprasītāju. Iebūvētajām klasēm tiek piešķirta lielāka privilēģija nekā klasēm, kas ir ielādētas tīklā.
Neuzticēts un padzīts līdz smilšu kastei
Trīs Java drošības modeļa daļas kopā veido smilšu kasti. Ideja ir ierobežot sīklietotnes darbību un pārliecināties, ka tā spēlē saskaņā ar noteikumiem. Smilšu kastes ideja ir pievilcīga, jo tā ir paredzēta, lai ļautu jums darboties neuzticami kodu, neuztraucoties par to. Tādā veidā jūs varat nesodīti sērfot tīmeklī, palaižot katru Java sīklietotni, ar kuru esat saskāries, bez drošības problēmām. Nu, ja vien Java smilškastē nav drošības caurumu.
Alternatīva smilšu kastei:
Autentifikācija, izmantojot kodu parakstīšanu
ActiveX ir vēl viena augsta līmeņa izpildāmā satura forma. Microsoft popularizēto ActiveX ir kritizējuši datoru drošības profesionāļi, kuri uzskata, ka tās pieeja drošībai nav pietiekama. Atšķirībā no Java drošības situācijas, kad sīklietotne ir ierobežota ar programmatūras kontroli, veicot dažādas darbības, ActiveX vadīklas rīcībai nav ierobežojumu, tiklīdz tā tiek izsaukta. Rezultāts ir tāds, ka ActiveX lietotājiem jābūt ļoti uzmanīgiem, lai palaistu tikai pilnīgi uzticams kods. Savukārt Java lietotājiem ir greznība diezgan droši palaist neuzticamu kodu.
ActiveX pieeja balstās uz digitālajiem parakstiem, sava veida šifrēšanas tehnoloģiju, kurā patvaļīgus bināros failus var "parakstīt" izstrādātājs vai izplatītājs. Tā kā digitālajam parakstam ir īpašas matemātiskas īpašības, tas ir neatsaucams un neaizmirstams. Tas nozīmē, ka tāda programma kā jūsu pārlūkprogramma var pārbaudīt parakstu, ļaujot jums būt drošam, kurš garantē kodu. (Vismaz tā ir teorija. Lietas reālajā dzīvē ir nedaudz neskaidras.) Vēl labāk: jūs varat norādīt savam pārlūkam vienmēr pieņemt kodu, kuru parakstījusi kāda uzticama puse, vai vienmēr noraidīt kodu, kuru parakstījusi kāda jūsu puse. neuzticos.
Digitālais paraksts satur daudz informācijas. Piemēram, tas var jums pateikt, ka, kaut arī kodu pārdala vietne, kurai neuzticaties, to sākotnēji ir uzrakstījis kāds, kuram uzticaties. Vai arī tas var jums pateikt, ka, lai arī kodu ir uzrakstījis un izplatījis kāds nezināms, jūsu draugs ir parakstījis kodu, apliecinot, ka tas ir drošs. Vai arī tas var vienkārši pateikt, kurš no tūkstošiem lietotāju ir aol.com uzrakstīja kodu.
(Sīkāku informāciju par digitālajiem parakstiem, tostarp piecām galvenajām īpašībām, skatiet sānjoslā.)
Izpildāmā satura nākotne: iziešana no smilšu kastes
Vai digitālie paraksti padara ActiveX pievilcīgāku drošības ziņā nekā Java? Mēs uzskatām, ka nē, it īpaši ņemot vērā faktu, ka Java JDK 1.1.1 (līdz ar citiem drošības uzlabojumiem) tagad ir pieejamas digitālā paraksta iespējas. Tas nozīmē, ka Java valodā jūs saņemat visu, ko ActiveX dara drošības nolūkos plus spēja diezgan droši palaist neuzticamu kodu. Java drošību nākotnē vēl vairāk uzlabos elastīga, detalizēta piekļuves kontrole, kuru, pēc JavaSoft Java drošības arhitekta Li Gong teiktā, plānots izlaist JDK 1.2. Labāka piekļuves kontrole iekļūs arī nākamajā pārlūkprogrammu kārtā, ieskaitot Netscape Communicator un MicroSoft Internet Explorer 4.0.
Kopā ar piekļuves kontroli koda parakstīšana ļaus sīklietotnēm pakāpeniski iziet ārpus drošības smilškastes. Piemēram, sīklietotnei, kas paredzēta izmantošanai iekštīkla iestatījumos, varētu ļaut lasīt un rakstīt uz a īpaši uzņēmuma datu bāze, ja vien to ir parakstījis sistēmas administrators. Šāda drošības modeļa atvieglošana ir svarīga izstrādātājiem, kuri mazliet kaut ko pārdomā, lai viņu sīklietotnes darītu vairāk. Rakstīt kodu, kas darbojas saspringto smilšu kastes ierobežojumu ietvaros, ir sāpes. Sākotnējā smilšu kaste ir ļoti ierobežojoša.
Galu galā sīklietotnēm būs atļauts dažāds uzticēšanās līmenis. Tā kā tam nepieciešama piekļuves kontrole, uzticības nokrāsas pašlaik nav pieejamas, kaut arī kodu parakstīšana ir. Pašreizējā JDK 1.1.1 versijā Java sīklietotnes ir vai nu pilnībā uzticamas, vai arī pilnīgi neuzticamas. Parakstīts sīklietotne, kas atzīmēta kā uzticama, drīkst pilnībā izkļūt no smilšu kastes. Šāda sīklietotne vispār var visu un ir nav drošības ierobežojumu.
Java pieejas drošībai galvenā problēma ir tā, ka tā ir sarežģīta. Sarežģītās sistēmās parasti ir vairāk trūkumu nekā vienkāršās sistēmās. Drošības pētnieki, īpaši Prinstonas drošā interneta programmēšanas komanda, smilškastes agrīnās versijās ir atraduši vairākus nopietnus trūkumus. Daudzi no šiem trūkumiem bija ieviešanas kļūdas, bet daži bija specifikācijas kļūdas. Par laimi, JavaSoft, Netscape un Microsoft ir ļoti ātri novērsuši šādas problēmas, kad tās tiek atklātas. (Skaidri un pilnībā izskaidroti Java drošības trūkumi ir atrodami mūsu grāmatas 3. nodaļā.)
Pavisam nesen Saules tirgotāji (dažreiz saukti par evaņģēlistiem) steidzīgi norādīja, ka jau labu laiku nav atklāti jauni trūkumi. Viņi to uztvēra kā pierādījumu tam, ka Java nekad vairs necietīs no drošības problēmām. Viņi metās ar ieroci.
Kodu parakstīšanas caurums: Java ādu celi
Kodu parakstīšana ir sarežģīta. Tāpat kā sākotnējā smilškastes modelī, koda parakstīšanas sistēmas projektēšanā un ieviešanā ir daudz iespēju kļūdām. Nesenais robs bija diezgan vienkārša problēma Java ieviešanā Klase klase, kā paskaidrots gan Prinstonas vietnē, gan JavaSoft drošības vietnē. Konkrēti, metode Klase.getsigners () atgriež visu sistēmā zināmo parakstītāju maināmu masīvu. Sīklietotne var ļaunprātīgi izmantot šo informāciju. Labojums bija tik vienkāršs, kā atgriezt tikai masīva kopiju, nevis pašu masīvu.
Apsveriet situāciju, kurā izstrādātājam Alisei nav piešķirta nekāda drošības privilēģija tīmekļa lietotāja sistēmā. Patiesībā, pretēji sākotnējam JavaSoft paziņojumam par kļūdu, Alise var būt sistēmai pilnīgi nezināms. Citiem vārdiem sakot, Alises parakstītajam kodam neuzticas vairāk kā parastajam sīklietotnei ārpus ielas. Ja tīmekļa lietotājs (izmantojot pārlūku HotJava - pašlaik vienīgais komerciālais produkts, kas atbalsta JDK 1.1.1), ielādē Alises parakstītu sīklietotni, šī sīklietotne joprojām var iziet no smilškastes, izmantojot caurumu.
Svarīgi ir tas, ka sistēmas datu bāzē nav jābūt Alises publiskajai atslēgai. Tas nozīmē, ka Alise var būt jebkura patvaļīga uzbrucēja, kas zina, kā parakstīt sīklietotni ar pilnīgi nejaušu identitāti. Šādas identitātes izveidošana ir vienkārša, tāpat kā sīklietotnes parakstīšana ar šo identitāti. Tas patiešām padara šo caurumu ļoti nopietnu.
Atvere ļauj Alises uzbrukuma sīklietotim mainīt sistēmas ideju par to, kas to parakstīja. Tas ir īpaši slikti, ja Alisei netiek piešķirta privilēģija skriet ārpus smilšu kastes, bet Bobs ir. Alises sīklietotne var izmantot getigners () zvanu, lai mainītu atļaujas līmeni, iekļaujot visas Boba privilēģijas. Alises sīklietotne var iegūt maksimālo pieejamo privilēģiju daudzumu jebkuru sistēmai zināmu parakstītāju.
Ja jūs parakstu / privilēģiju identitātes salīdzināt ar mēteļiem skapī, Alises uzbrukuma sīklietotne var izmēģināt katru mēteli un izmēģināt dažādas neatļautas lietas, līdz tā atklāj, kuri no mēteļiem ir "maģiski", un ļauj tam iegūt privilēģijas. Ja tiek atklāts burvju mētelis, Alises sīklietotne var izkāpt no smilšu kastes un darīt lietas, kurām to darīt nedrīkst. Mēteļu uzvilkšana ir tikpat vienkārša kā neatļauta zvana mēģināšana un vērošana, lai redzētu, kas notiek.
