Olet ehkä kuullut viimeisimmästä JDK 1.1: n ja HotJava 1.0: n tietoturva-aukosta, jonka Princetonin yliopiston Secure Internet Programming -tiimi (yksi tekijöistä johti) löysi äskettäin. Jos haluat koko tarinan, lue eteenpäin. Mutta Java-turvallisuudessa on enemmän kuin tämän viimeisimmän tietoturva-aukon yksityiskohdat. Katsotaanpa näkökulma.
Java-turvallisuus ja yleinen käsitys
Kaikki tietävät, että Java on iso juttu tietoturvasta. Aina kun löytyy tietoturva-aukko, tarina räjähtää tietokoneuutisiin (ja joskus liikeuutisiin) hyvin nopeasti. Et voi olla yllättynyt kuullessasi, että suosittu lehdistö valvoo komp.riskit ja muut turvallisuuteen liittyvät uutisryhmät. He valitsevat tietoturvatarinat korostamaan näennäisesti satunnaisesti, vaikka koska Java on niin kuuma näinä päivinä, he melkein aina tulostavat Java-suojaustarinoita.
Ongelmana on, että useimmat uutiset eivät selitä reikiä lainkaan. Tämä voi johtaa klassiseen "itäsusi" -ongelmaan, jossa ihmiset tottuvat näkemään "tämän viikon turvallisuustarinan" eivätkä kouluta itseään suoritettavan sisällön todellisista riskeistä. Lisäksi myyjät pyrkivät pienentämään tietoturvaongelmiaan, mikä hämmentää edelleen avainkysymyksiä.
Hyvä uutinen on, että JavaSoft-tietoturvaryhmä on tosissaan tekemässä Java turvalliseksi. Huono uutinen on, että suurin osa Java-kehittäjistä ja -käyttäjistä saattaa uskoa hyppyjä tapahtumista, kuten JavaOne, joissa tietoturvaongelmille ei anneta paljon esityksiä. Kuten sanoimme kirjassa, Java-suojaus: vihamieliset sovelmat, reiät ja vastalääkkeet, Sun Microsystemsillä on paljon voittoa, jos se saa sinut uskomaan, että Java on täysin turvallinen. On totta, että toimittajat ovat pyrkineet tekemään Java-toteutuksensa mahdollisimman turvalliseksi, mutta kehittäjät eivät halua ponnisteluja; he haluavat tuloksia.
Koska Java-yhteensopiva verkkoselain sallii Java-koodin upottamisen verkkosivulle, lataamisen verkon kautta ja suorittamisen paikallisella koneella, turvallisuus on kriittinen huolenaihe. Käyttäjät voivat ladata Java-sovelmia poikkeuksellisen helposti - toisinaan edes tietämättä sitä. Tämä altistaa Java-käyttäjät huomattavalle riskille.
Java-suunnittelijat ovat hyvin tietoisia suoritettavaan sisältöön liittyvistä monista riskeistä. Näiden riskien torjumiseksi he suunnittelivat Java nimenomaan turvallisuusnäkökohdat huomioon ottaen. Päätavoitteena oli käsitellä tietoturvakysymystä heti, jotta naiivien käyttäjien (esimerkiksi miljoonien web-surffaajien) ei tarvitse tulla tietoturva-asiantuntijoiksi pelkästään Webin turvalliseksi tutkimiseksi. Tämä on ihailtava tavoite.
Java-hiekkalaatikon kolme osaa
Java on erittäin voimakas kehityskieli. Epäluotettavien sovelmien ei pitäisi antaa käyttää kaikkea tätä virtaa. Java-hiekkalaatikko rajoittaa sovelmia suorittamasta monia toimintoja. Paras applettirajoituksia koskeva tekninen paperi on Frank Yellinin "Low Level Security in Java".
Java-tietoturva perustuu kolmeen puolustushaaraan: tavukoodivahvistimeen, luokan kuormaajaan ja tietoturvan hallintaan. Nämä kolme piikkiä suorittavat yhdessä lataus- ja ajoaikatarkastuksia rajoittaakseen tiedostojärjestelmän ja verkon käyttöä sekä pääsyä selaimen sisäisiin osiin. Jokainen näistä piikkeistä riippuu jollain tavalla muista. Jotta suojausmalli toimisi oikein, jokaisen osan on tehtävä tehtävänsä oikein.
Tavu-koodin todentaja:
Tavu-koodin vahvistin on Java-tietoturvamallin ensimmäinen kärki. Kun Java-lähdeohjelma käännetään, se kääntyy alustasta riippumattomaan Java-tavukoodiin. Java-tavukoodi on "vahvistettu" ennen kuin se voidaan suorittaa. Tämän varmennusjärjestelmän tarkoituksena on varmistaa, että tavukoodi, jonka Java-kääntäjä on saattanut luoda tai olla luonut, noudattaa sääntöjä. Loppujen lopuksi tavukoodin olisi voinut luoda "vihamielinen kääntäjä", joka kokosi tavukoodin, joka on suunniteltu kaatamaan Java-virtuaalikone. Appletin tavukoodin tarkistaminen on yksi tapa, jolla Java tarkistaa epäluotettavan ulkopuolisen koodin automaattisesti ennen kuin sen annetaan käydä. Todentaja tarkistaa tavukoodin useilla eri tasoilla. Yksinkertaisin testi varmistaa, että tavukoodiosan muoto on oikea. Vähemmän perustasolla sisäänrakennettua lauseohjelmaa sovelletaan kuhunkin koodin fragmenttiin. Lauseenlukija auttaa varmistamaan, että tavukoodi ei väärennä osoittimia, riko pääsyrajoituksia tai käytä objekteja väärin tyyppitietojen avulla. Vahvistusprosessi, yhdessä kääntäjän kautta kielelle rakennettujen turvaominaisuuksien kanssa, auttaa luomaan tietoturvatakeiden perusjoukon.
Applet-luokan kuormaaja:
Turvallisuuden puolustuksen toinen osa on Java Applet Class Loader. Kaikki Java-objektit kuuluvat luokkiin. Applet Class Loader määrittää, milloin ja miten appletti voi lisätä luokkia käynnissä olevaan Java-ympäristöön. Osa sen tehtävästä on varmistaa, että Java-ajo-ympäristön tärkeitä osia ei korvata koodilla, jonka sovelma yrittää asentaa. Yleensä juoksevassa Java-ympäristössä voi olla useita aktiivisia Class Loadereita, joista kukin määrittelee oman "nimiavaruutensa". Nimitilojen avulla Java-luokat voidaan erottaa erillisiksi "tyypeiksi" niiden alkuperän mukaan. Applet Class Loader, jonka tavallisesti toimittaa selaimen toimittaja, lataa kaikki sovelmat ja luokat, joihin ne viittaavat. Kun sovelma latautuu verkon yli, Applet-luokan latauslaite vastaanottaa binaaritiedot ja välittää ne uudeksi luokaksi.
Turvallisuuspäällikkö:
Java-tietoturvamallin kolmas osa on Java Security Manager. Tämä suojausmallin osa rajoittaa tapoja, joilla sovelma voi käyttää näkyviä rajapintoja. Siten Security Manager toteuttaa suuren osan koko suojausmallista. Security Manager on yksittäinen moduuli, joka voi suorittaa ajoaikaisia tarkastuksia "vaarallisille" menetelmille. Java-kirjaston koodi kysyy Security Managerilta aina, kun vaarallista operaatiota yritetään yrittää. Suojauspäällikkö saa veto-operaation luomalla suojauspoikkeuksen (Java-kehittäjien bane kaikkialla). Security Managerin tekemissä päätöksissä otetaan huomioon, mikä luokan kuormaaja latasi pyytävän luokan. Sisäänrakennetuille luokille annetaan enemmän etuoikeuksia kuin luokille, jotka on ladattu verkon yli.
Ei luotettu ja karkotettu hiekkalaatikkoon
Java-suojausmallin kolme osaa muodostavat yhdessä hiekkalaatikon. Ajatuksena on rajoittaa sitä, mitä sovelma voi tehdä, ja varmistaa, että se toimii sääntöjen mukaan. Hiekkalaatikko-ajatus on houkutteleva, koska sen on tarkoitus antaa sinun juosta epäluotettava koodia koneellesi huolimatta siitä. Näin voit surffailla verkossa rankaisematta, suorittamalla kaikki Java-sovelmat, joita olet koskaan törmännyt ilman turvallisuusongelmia. No, niin kauan kuin Java-hiekkalaatikossa ei ole turva-aukkoja.
Vaihtoehto hiekkalaatikolle:
Todennus koodin allekirjoittamisen avulla
ActiveX on toinen korkean profiilin suoritettavan sisällön muoto. Microsoftin mainostamana tietoturva-alan ammattilaiset ovat arvostelleet ActiveX: ää, jotka pitävät sen lähestymistapaa turvallisuuteen puuttuvana. Toisin kuin Java-tietoturvatilanne, jossa sovelma on rajoitettu ohjelmistohallinnalla monissa asioissa, joita se voi tehdä, ActiveX-komponenttien käyttäytymiselle ei ole rajoituksia, kun niitä kutsutaan. Tuloksena on, että ActiveX: n käyttäjien on oltava hyvin varovaisia vain ajaessaan täysin luotettu koodi. Java-käyttäjillä on toisaalta ylellisyyttä käyttää epäluotettavaa koodia melko turvallisesti.
ActiveX-lähestymistapa perustuu digitaalisiin allekirjoituksiin, eräänlaiseen salaustekniikkaan, jossa kehittäjä tai jakelija voi "allekirjoittaa" mielivaltaiset binaaritiedostot. Koska digitaalisella allekirjoituksella on erityisiä matemaattisia ominaisuuksia, se on peruuttamaton ja unohtumaton. Tämä tarkoittaa, että selaimesi kaltainen ohjelma voi vahvistaa allekirjoituksen, jolloin voit olla varma, kuka on antanut koodin. (Ainakin tämä on teoria. Asiat ovat hieman epäselvämpiä tosielämässä.) Vielä parempaa, voit ohjeistaa selaimesi aina hyväksymään jonkin luotettavan osapuolen allekirjoittaman koodin tai hylätä aina jonkun osapuolen allekirjoittaman koodin. älä luota.
Digitaalinen allekirjoitus sisältää paljon tietoa. Se voi esimerkiksi kertoa sinulle, että vaikka sivusto, johon et luota, jakaa osan koodista, on sen kirjoittanut alun perin joku, johon luotat. Tai se voi kertoa sinulle, että vaikka koodin on kirjoittanut ja jakanut joku tuntematon, ystäväsi on allekirjoittanut koodin todistaen sen olevan turvallinen. Tai se voi yksinkertaisesti kertoa sinulle, kuka tuhansista käyttäjistä on aol.com kirjoitti koodin.
(Katso sivupalkista lisätietoja digitaalisista allekirjoituksista, mukaan lukien viisi keskeistä ominaisuutta.)
Suoritettavan sisällön tulevaisuus: Poistu hiekkalaatikosta
Onko digitaalisten allekirjoitusten avulla ActiveX houkuttelevampi tietoturvan kannalta kuin Java? Emme usko, etenkään kun otetaan huomioon, että digitaalinen allekirjoitusominaisuus on nyt saatavana Javan JDK 1.1.1: ssä (yhdessä muiden suojausparannusten kanssa). Tämä tarkoittaa, että Java-käyttöjärjestelmässä saat kaiken, mitä ActiveX tekee turvallisuuden takaamiseksi plus kyky käyttää epäluotettavaa koodia melko turvallisesti. Javan tietoturvaa parannetaan tulevaisuudessa entistäkin pidemmällä joustavalla, hienorakenteisella kulunvalvonnalla, jonka JavaSoftin Java-suojausarkkitehti Li Gongin mukaan on tarkoitus julkaista JDK 1.2: ssa. Parempi kulunvalvonta pääsee myös seuraavalle selainkierrokselle, mukaan lukien Netscape Communicator ja MicroSoft Internet Explorer 4.0.
Yhdessä kulunvalvonnan kanssa koodin allekirjoittaminen antaa sovelmille mahdollisuuden astua hiekkalaatikon ulkopuolelle asteittain. Esimerkiksi intranet-asetuksissa käytettäväksi suunnitellun sovelman voidaan sallia lukea ja kirjoittaa a: lle tietty yrityksen tietokantaan niin kauan kuin järjestelmänvalvoja on allekirjoittanut sen. Tällainen tietoturvamallin rentoutuminen on tärkeää kehittäjille, jotka hämmentävät bittiä sovelmiensa tekemiseksi enemmän. Hiekkalaatikon tiukkojen rajoitusten mukaisen koodin kirjoittaminen on tuskaa. Alkuperäinen hiekkalaatikko on hyvin rajoittava.
Lopulta sovelmille annetaan erilainen luottamustaso. Koska tämä edellyttää pääsynvalvontaa, luottamuksen sävyt eivät tällä hetkellä ole käytettävissä, vaikka koodin allekirjoittaminen onkin. Nykyisin JDK 1.1.1: ssä Java-sovelmat ovat joko täysin luotettavia tai täysin epäluotettavia. Luotetuksi merkitty allekirjoitettu sovelma saa poistua hiekkalaatikosta kokonaan. Tällainen sovelma voi tehdä mitä tahansa ja on ei turvallisuusrajoituksia.
Suurin ongelma Java-lähestymistavassa turvallisuuteen on, että se on monimutkaista. Monimutkaisissa järjestelmissä on yleensä enemmän virheitä kuin yksinkertaisissa järjestelmissä. Turvallisuustutkijat, etenkin Princetonin Secure Internet Programming -tiimi, ovat löytäneet useita vakavia turvallisuusvirheitä hiekkalaatikon varhaisissa versioissa. Monet näistä virheistä olivat toteutusvirheitä, mutta jotkut olivat määritysvirheitä. Onneksi JavaSoft, Netscape ja Microsoft ovat ratkaisseet ongelmat nopeasti, kun ne havaitaan. (Selkeät ja täydelliset selitykset Java-tietoturva-aukoista löytyvät kirjamme luvusta 3.)
Aivan äskettäin aurinkomarkkinoijat (joskus kutsutaan evankelisteiksi) huomauttivat nopeasti, ettei uusia vikoja ollut löydetty jo jonkin aikaa. He pitivät tätä todisteena siitä, että Java ei koskaan enää kärsi turvallisuusongelmista. He hyppäsivät aseeseen.
Koodin allekirjoitusreikä: Java nyljee polvensa
Koodin allekirjoittaminen on monimutkaista. Kuten alkuperäisessä hiekkalaatikkomallissa, koodin allekirjoitusjärjestelmän suunnittelussa ja toteuttamisessa on paljon virheitä. Viimeaikainen reikä oli melko yksinkertainen ongelma Java-sovellusten toteuttamisessa Luokka luokka, kuten sekä Princetonin että JavaSoftin tietoturvasivustolla on selitetty. Erityisesti menetelmä Class.getsigners () palauttaa muutettavissa olevan taulukon kaikista järjestelmän tuntemista allekirjoittajista. Applet voi käyttää näitä tietoja väärin. Korjaus oli yhtä yksinkertaista kuin palauttaa vain kopio taulukosta, ei itse taulukkoa.
Tarkastellaan tilannetta, jossa kehittäjälle Alice ei ole myönnetty mitään suojausoikeuksia verkkokäyttäjän järjestelmään. Itse asiassa, toisin kuin alkuperäinen JavaSoft-lausunto virheestä väitti, Alice voi olla täysin tuntematon järjestelmälle. Toisin sanoen, Alicen allekirjoittamaan koodiin ei luoteta enempää kuin tavallinen appletti kadun ulkopuolella. Jos verkkokäyttäjä (käyttäen HotJava-selainta - tällä hetkellä ainoa kaupallinen tuote, joka tukee JDK 1.1.1: tä) lataa Alicen allekirjoittaman sovelman, kyseinen sovelma voi silti astua ulos hiekkalaatikosta hyödyntämällä aukkoa.
On tärkeää, että järjestelmässä ei tarvitse olla Alicen julkista avainta tietokannassa. Se tarkoittaa, että Alice voi olla mikä tahansa mielivaltainen hyökkääjä, joka osaa allekirjoittaa appletin täysin satunnaisella henkilöllisyydellä. Tällaisen identiteetin luominen on helppoa, samoin kuin appletin allekirjoittaminen kyseisellä henkilöllisyydellä. Tämä tekee reiästä todella vakavan.
Reiän avulla Alicen hyökkäyssovelma voi muuttaa järjestelmän ajatusta siitä, kuka sen allekirjoitti. Tämä on erityisen huono, jos Alice ei saa etuoikeutta juosta hiekkalaatikon ulkopuolella, mutta Bob on. Alice-sovelma voi käyttää merkkijonot () kutsu muuttaa sen käyttöoikeustasoa sisällyttämään kaikki Bobin oikeudet. Alice-sovelma voi saada enimmäismäärän käytettävissä olevia käyttöoikeuksia kaikki järjestelmän tuntemat allekirjoittajat.
Jos verrataan allekirjoituksen / etuoikeuden identiteettejä kaapissa oleviin takkeihin, Alice-hyökkäyssovellus voi kokeilla jokaista takkia ja yrittää erilaisia kiellettyjä asioita, kunnes se huomaa, mitkä takit ovat "taikoja", ja antaa sille mahdollisuuden saada etuoikeus. Jos löydetään taika takki, Alicen sovelma voi astua ulos hiekkalaatikosta ja tehdä asioita, joita sen ei pitäisi sallia. Takkien kokeilu on yhtä yksinkertaista kuin kielletyn puhelun yrittäminen ja katsominen, mitä tapahtuu.
