Programavimas

Suprasti „Java“ saugumo raktus - smėlio dėžę ir autentifikavimą

Galbūt girdėjote apie naujausią JDK 1.1 ir „HotJava 1.0“ saugumo trūkumą, kurį neseniai atrado Prinstono universiteto Saugaus interneto programavimo komanda (vadovaujama vieno iš autorių). Jei norite visos istorijos, skaitykite toliau. Tačiau „Java“ saugumas yra ne tik šios naujausios saugos skylės specifika. Paimkime šiek tiek perspektyvos.

„Java“ saugumas ir visuomenės suvokimas

Visi žino, kad „Java“ saugumas yra didelis dalykas. Kai tik nustatoma saugumo skylė, istorija labai greitai įsiveržia į kompiuterio naujienas (o kartais ir verslo naujienas). Galbūt nenustebsite sužinoję, kad populiarioji spauda stebi komp.rizikos ir kitos su saugumu susijusios naujienų grupės. Jie renkasi saugumo istorijas, kad išryškintų, atrodo, atsitiktinai, nors kadangi „Java“ šiais laikais yra labai karšta, jie beveik visada spausdina „Java“ saugumo istorijas.

Problema ta, kad dauguma naujienų visiškai nepaaiškina skylių. Tai gali sukelti klasikinę „verkiančio vilko“ problemą, kai žmonės įpranta matyti „šios savaitės saugumo istoriją“ ir nesimoko apie realią vykdomojo turinio riziką. Be to, pardavėjai linkę sumenkinti savo saugumo problemas, taip dar labiau supainiodami pagrindines problemas.

Geros naujienos yra tai, kad „JavaSoft“ saugos komanda rimtai siekia, kad „Java“ būtų saugi. Blogos naujienos yra tai, kad dauguma „Java“ kūrėjų ir vartotojų gali patikėti ažiotažu, kylančiu iš tokių įvykių kaip „JavaOne“, kur saugumo problemos nėra labai svarbios. Kaip sakėme savo knygoje, „Java Security“: priešiškos programėlės, skylės ir priešnuodžiai, „Sun Microsystems“ turi daug ką įgyti, jei tai priverčia patikėti, kad „Java“ yra visiškai saugi. Tiesa, kad pardavėjai dėjo daug pastangų, kad „Java“ diegimas būtų kuo saugesnis, tačiau kūrėjai nenori pastangų; jie nori rezultatų.

Kadangi „Java“ palaikanti žiniatinklio naršyklė leidžia „Java“ kodą įterpti į tinklalapį, atsisiųsti visame tinkle ir paleisti vietiniame kompiuteryje, saugumas yra labai svarbus klausimas. Vartotojai gali atsisiųsti „Java“ programėles ypač lengvai - kartais to net nežinodami. Tai kelia „Java“ vartotojams didelę riziką.

„Java“ dizaineriai puikiai žino daugybę su vykdomuoju turiniu susijusių pavojų. Norėdami kovoti su šia rizika, jie sukūrė „Java“ specialiai atsižvelgdami į saugumo problemas. Pagrindinis tikslas buvo išspręsti saugumo problemą tiesiogiai, kad naiviems vartotojams (tarkime, daugumai milijonų interneto naršytojų) nereikėtų tapti saugumo ekspertais, kad tik saugiai apžvelgtų internetą. Tai yra pagirtinas tikslas.

Trys „Java“ smėlio dėžės dalys

„Java“ yra labai galinga kūrimo kalba. Nepatikimoms programėlėms neturėtų būti leidžiama pasiekti visos šios galios. „Java“ smėlio dėžė neleidžia programėlėms atlikti daug veiklos. Geriausias techninis dokumentas apie programėlių apribojimus yra Franko Yellino „Žemo lygio saugumas„ Java “.

„Java“ saugumas priklauso nuo trijų gynybos sričių: baitų kodo tikrintuvo, klasės pakrovėjo ir saugos tvarkyklės. Kartu šios trys šakės atlieka apkrovos ir vykdymo laiko patikrinimus, kad apribotų failų sistemos ir tinklo prieigą bei prieigą prie naršyklės vidinių dalių. Kiekviena iš šių šakelių tam tikru būdu priklauso nuo kitų. Kad saugos modelis veiktų tinkamai, kiekviena dalis turi tinkamai atlikti savo darbą.

Baito kodo tikrintuvas:

Baitų kodo tikrintuvas yra pirmasis „Java“ saugumo modelio šakas. Sudarant „Java“ šaltinio programą, ji kaupiama iki platformos nepriklausomo „Java“ baito kodo. „Java“ baito kodas yra „patikrintas“, kol jis gali paleisti. Ši tikrinimo schema skirta užtikrinti, kad baitų kodas, kurį galbūt sukūrė ar negalėjo sukurti „Java“ kompiliatorius, žaidžia pagal taisykles. Galų gale, baitų kodą galėjo sukurti „priešiškas kompiliatorius“, surinkęs baitų kodą, skirtą avarinei „Java“ mašinai sugadinti. Programos baito kodo patikrinimas yra vienas iš būdų, kuriuo „Java“ automatiškai patikrina nepatikimą išorinį kodą prieš leidžiant bėgioti. Tikrintojas patikrina baito kodą keliais skirtingais lygiais. Paprasčiausias testas užtikrina, kad baito kodo fragmento formatas yra teisingas. Mažiau pagrindiniame lygyje kiekvienam kodo fragmentui taikoma įmontuota teoremų patarlė. Teoremų patarėjas padeda įsitikinti, kad baitų kodas nesuklastoja rodyklių, nepažeidžia prieigos apribojimų ir nepasiekia objektų naudodamas neteisingą tipo informaciją. Patvirtinimo procesas, suderinamas su kompiliatoriuje įdiegtomis kalbos funkcijomis, padeda nustatyti pagrindinį saugumo garantijų rinkinį.

Programėlių klasės krautuvas:

Antroji saugumo gynybos šaka yra „Java Applet Class Loader“. Visi „Java“ objektai priklauso klasėms. „Applet Class Loader“ nustato, kada ir kaip programėlė gali pridėti klases į veikiančią „Java“ aplinką. Dalis jo užduočių yra užtikrinti, kad svarbios „Java“ vykdymo laiko aplinkos dalys nebūtų pakeistos kodu, kurį bando įdiegti programėlė. Apskritai veikiančioje „Java“ aplinkoje gali būti aktyvūs daugybė „Class Loaders“, kurių kiekvienas apibrėžia savo „vardų erdvę“. Pavadinimų tarpai leidžia „Java“ klases suskirstyti į atskiras „rūšis“ pagal jų kilmę. „Applet Class Loader“, kurį paprastai teikia naršyklės pardavėjas, įkelia visas programėles ir klases, į kurias jie nukreipia. Kai programėlė įkeliama visame tinkle, „Applet Class Loader“ gauna dvejetainius duomenis ir juos iškart sukuria kaip naują klasę.

Apsaugos vadybininkas:

Trečioji „Java“ saugumo modelio dalis yra „Java Security Manager“. Ši saugos modelio dalis riboja būdus, kuriais programėlė gali naudoti matomas sąsajas. Taigi saugos vadybininkas įgyvendina nemažą dalį viso saugumo modelio. „Security Manager“ yra vienas modulis, kuris gali atlikti „pavojingų“ metodų vykdymo laiko patikrinimus. „Java“ bibliotekos kodas konsultuojasi su saugos vadybininku, kai ketinama atlikti pavojingą operaciją. Saugos vadybininkui suteikiama galimybė vetuoti operaciją sukuriant saugos išimtį (visur „Java“ kūrėjų banga). Apsaugos vadybininko priimtuose sprendimuose atsižvelgiama į tai, kuris „Class Loader“ įkėlė prašomą klasę. Integruotoms klasėms suteikiama daugiau privilegijų nei klasėms, kurios buvo įkeltos per tinklą.

Nepatikimas ir ištremtas į smėlio dėžę

Trys „Java“ saugumo modelio dalys sudaro smėlio dėžę. Idėja yra apriboti tai, ką programėlė gali padaryti, ir įsitikinti, kad ji žaidžia pagal taisykles. „Sandbox“ idėja yra patraukli, nes ji skirta bėgti nepatikimas kodą kompiuteryje nesijaudindami. Tokiu būdu galite nebaudžiamai naršyti internete, paleisdami kiekvieną „Java“ programėlę, su kuria kada nors susidūrėte, be jokių saugumo problemų. Na, jei „Java“ smėlio dėžė neturi saugos skylių.

Alternatyva smėlio dėžei:

Autentifikavimas pasirašant kodą

„ActiveX“ yra dar viena aukšto lygio vykdomojo turinio forma. „Microsoft“ reklamuojamą „ActiveX“ kritikavo kompiuterių saugos specialistai, kurie mano, kad jos požiūris į saugumą yra nepakankamas. Skirtingai nuo „Java“ saugumo situacijos, kai programėlę programinė įranga kontroliuoja įvairiuose dalykuose, kuriuos ji gali padaryti, „ActiveX“ valdiklis neturi jokių apribojimų savo elgesiui, kai jis yra iškviečiamas. Rezultatas yra tas, kad „ActiveX“ vartotojai turi būti labai atsargūs, kad veiktų tik visiškai patikimas kodas. Kita vertus, „Java“ vartotojai turi prabangą gana saugiai paleisti nepatikimą kodą.

„ActiveX“ metodas remiasi skaitmeniniais parašais - tam tikra šifravimo technologija, kai savavališkus dvejetainius failus gali „pasirašyti“ kūrėjas ar platintojas. Kadangi skaitmeninis parašas pasižymi ypatingomis matematinėmis savybėmis, jis yra neatšaukiamas ir nepamirštamas. Tai reiškia, kad tokia programa, kaip jūsų naršyklė, gali patvirtinti parašą, todėl galite būti tikri, kas laidavo kodą. (Bent jau tokia teorija. Vykdomi dalykai yra kiek dviprasmiškesni realiame gyvenime.) Dar geriau: galite nurodyti savo naršyklei visada priimti kodą, kurį pasirašė kuri nors šalis, kuriuo pasitikite, arba visada atmesti kodą, kurį pasirašė jūsų šalis. nepasitiki.

Skaitmeniniame paraše yra daug informacijos. Pavyzdžiui, ji gali jums pasakyti, kad nors tam tikrą kodą perskirsto svetainė, kuria nepasitikite, ją iš pradžių parašė kažkas, kuo pasitikite. Arba gali jums pasakyti, kad nors kodą parašė ir išplatino kažkas, ko nepažįstate, jūsų draugas pasirašė kodą, patvirtindamas, kad jis yra saugus. Arba gali paprasčiausiai pasakyti, kuris iš tūkstančių vartotojų yra aol.com parašė kodą.

(Daugiau informacijos apie skaitmeninius parašus, įskaitant penkias pagrindines ypatybes, rasite šoninėje juostoje.)

Vykdomo turinio ateitis: išeiti iš smėlio dėžės

Ar skaitmeniniai parašai daro „ActiveX“ patrauklesnį saugumo požiūriu nei „Java“? Mes netikime, ypač atsižvelgiant į tai, kad skaitmeninio parašo galimybės dabar yra „Java“ JDK 1.1.1 versijoje (kartu su kitais saugumo patobulinimais). Tai reiškia, kad „Java“ sistemoje jūs gaunate viską, ką „ActiveX“ daro saugumui užtikrinti pliusas galimybė gana saugiai paleisti nepatikimą kodą. Ateityje „Java“ saugumą dar labiau sustiprins lanksti, tiksli prieigos kontrolė, kurią, pasak „JavaSoft“ „Java“ saugumo architekto Li Gongo, planuojama išleisti JDK 1.2. Geresnė prieigos kontrolė taip pat pateks į kitą naršyklių etapą, įskaitant „Netscape Communicator“ ir „MicroSoft Internet Explorer 4.0“.

Kartu su prieigos kontrole kodo pasirašymas leis programėlėms palaipsniui išeiti iš saugos smėlio dėžės. Pavyzdžiui, programėlei, skirtai naudoti intraneto nustatymuose, gali būti leidžiama skaityti ir rašyti į a ypač įmonės duomenų bazę tol, kol ją pasirašė sistemos administratorius. Toks saugumo modelio sušvelninimas yra svarbus kūrėjams, kurie šiek tiek mąsto, kad jų programėlės galėtų padaryti daugiau. Rašyti kodą, kuris veikia laikantis griežtų smėlio dėžės apribojimų, yra kančia. Originali smėlio dėžė yra labai ribojanti.

Galų gale programėlėms bus leista naudotis skirtingais pasitikėjimo lygiais. Kadangi tam reikalinga prieigos kontrolė, pasitikėjimo atspalvių šiuo metu nėra, net jei kodas yra pasirašytas. Šiuo metu „Java“ programėlės yra visiškai patikimos arba visiškai nepatikimos JDK 1.1.1 versijoje. Pasirašyta programėlė, pažymėta kaip patikima, gali visiškai išeiti iš smėlio dėžės. Tokia programėlė gali padaryti bet ką ir turi jokių saugumo apribojimų.

Pagrindinė „Java“ požiūrio į saugumą problema yra ta, kad jis yra sudėtingas. Sudėtingose ​​sistemose dažniausiai būna daugiau trūkumų nei paprastose sistemose. Saugumo tyrėjai, ypač „Princeton“ saugaus interneto programavimo komanda, ankstyvosiose „smėlio dėžės“ versijose aptiko keletą rimtų saugumo trūkumų. Daugelis šių trūkumų buvo įgyvendinimo klaidos, tačiau kai kurios buvo specifikacijos klaidos. Laimei, „JavaSoft“, „Netscape“ ir „Microsoft“ labai greitai išsprendė tokias problemas, kai jos buvo aptiktos. (Aiškius ir išsamius „Java“ saugumo spragų paaiškinimus galite rasti mūsų knygos 3 skyriuje.)

Visai neseniai Saulės rinkodaros specialistai (kartais vadinami evangelistais) greitai nurodė, kad per ilgą laiką nebuvo atrasta naujų trūkumų. Jie tai priėmė kaip įrodymą, kad „Java“ niekada daugiau nekankins saugumo problemų. Jie pašoko ginklą.

Kodo pasirašymo skylė: „Java“ nulupia kelį

Kodo pasirašymas yra sudėtingas. Kaip ir pradiniame smėlio dėžės modelyje, kuriant ir įgyvendinant kodo pasirašymo sistemą yra daug vietos klaidoms. Neseniai atsiradusi skylė buvo gana paprasta problema įgyvendinant „Java“ Klasė klasę, kaip paaiškinta Prinstono svetainėje ir „JavaSoft“ saugos svetainėje. Tiksliau, metodas „Class.getsigners“ () pateikia visų sistemai žinomų pasirašytojų masyvą. Programėlė gali piktnaudžiauti šia informacija. Pataisymas buvo toks paprastas, kaip grąžinti tik masyvo kopiją, o ne patį masyvą.

Apsvarstykite situaciją, kai kūrėjui Alice nebuvo suteikta jokia žiniatinklio vartotojo sistemos saugumo privilegija. Iš tikrųjų, priešingai nei teigiama originaliame „JavaSoft“ pareiškime apie klaidą, Alisa gali būti visiškai nežinomas sistemai. Kitaip tariant, Alisos pasirašytu kodu pasitikima labiau nei įprastu programėliu gatvėje. Jei žiniatinklio vartotojas (naudodamas „HotJava“ naršyklę - šiuo metu vienintelis komercinis produktas, palaikantis JDK 1.1.1) įkelia Alisės pasirašytą programėlę, ta programėlė vis tiek gali išeiti iš smėlio dėžės išnaudodama skylę.

Svarbu tai, kad sistemos duomenų bazėje nebūtina turėti viešojo „Alice“ rakto. Tai reiškia, kad Alisa gali būti bet koks savavališkas užpuolikas, mokantis pasirašyti programėlę visiškai atsitiktine tapatybe. Sukurti tokią tapatybę lengva, kaip ir pasirašyti programėlę su ta tapatybe. Tai iš tikrųjų daro skylę labai rimtą.

Ši skylė leidžia Alice atakos programėlei pakeisti sistemos idėją, kas ją pasirašė. Tai ypač blogai, jei Alisai nėra suteikta privilegija bėgti už smėlio dėžės ribų, bet Bobui tai yra. Alisos programėlė gali naudoti gaubtininkai () kvietimas pakeisti leidimo lygį, kad būtų įtrauktos visos Bobo privilegijos. Alisos programėlė gali gauti maksimalų galimų privilegijų kiekį bet kuris sistemai žinomas pasirašytojas.

Jei parašo / privilegijos tapatybę prilyginate paltams spintoje, Alice atakos programėlė gali išbandyti kiekvieną paltą ir bandyti įvairius neleistinus dalykus, kol atras, kurie iš paltų yra „stebuklingi“, ir leisti jam įgyti privilegiją. Jei bus atrastas stebuklingas paltas, Alisos programėlė gali išeiti iš smėlio dėžės ir daryti tai, ko jai neturėtų būti leidžiama. Bandymas apsivilkti paltus yra toks pat paprastas, kaip bandymas neleisti skambinti ir stebėti, kas vyksta.