Javan varhaista kasvua vauhditti verkon kautta ladattava koodi, joka tunnetaan paremmin nimellä sovelmia. Applet-tietoturva on kehittynyt Javan kasvun myötä, ja nykyään se aiheuttaa usein sekaannusta johtuen erilaisista Java-versioista, kaupallisesti saatavilla olevista selaimista ja laajennuksista.
Tämä sarjan kolmas artikkeli kattaa verkosta ladatun Java-koodin turvallisen käytön erilaiset vaatimukset. Vaikka mobiilikoodi ei ole vallankumouksellinen käsite, Java ja Internet asettavat ainutlaatuisia haasteita tietoturvalle. Java-arkkitehtuurin evoluutiosta ja sen vaikutuksista Java-ydinturvallisuuteen keskusteltiin osissa 1 ja 2. Tässä artikkelissa käsitellään eri tavalla: käytännönläheinen lähestymistapa kaikkien käsitteiden yhdistämiseen ottamalla käyttöön yksinkertainen sovelma, joka kirjoittaa paikalliseen tiedostojärjestelmään .
Java-tietoturvan kehitys ja käsitteet: Lue koko sarja!
- Osa 1: Opi tietokoneturvakäsitteet ja termit tästä johdantokatsauksesta
- Osa 2: Tutustu Java-tietoturvan haittoihin
- Osa 3: Käsittele Java-sovelmien turvallisuus turvallisesti
- Osa 4: Opi, kuinka valinnaiset paketit laajentavat ja parantavat Java-tietoturvaa
- Osa 5: J2SE 1.4 tarjoaa lukuisia parannuksia Java-tietoturvaan
Esimerkkisovelluksen ytimessä on julkisen avaimen salaus, joka esiteltiin aiemmin tässä sarjassa. Allekirjoittajan yksityisellä avaimella allekirjoitettu koodi voidaan ajaa asiakaskoneissa, kun allekirjoittajaa vastaava julkinen avain katsotaan luotettavaksi kyseisessä koneessa. Keskustelemme myös siitä, miten käytäntötiedostoja, jotka myöntävät käyttöoikeudet ja avaimenvaraston, voidaan käyttää julkisten ja yksityisten avainten arkistona. Lisäksi korostamme Java 2 SDK: n suojaustyökalut ja Netscape: n signtool, koska ne mahdollistavat käyttöönoton.
Tämä artikkeli seuraa Java-tietoturvan kehitystä, alkaen sovellusturvasta Java 2: n alkuperäisessä julkaisussa ja siirtymällä Java 2: n uusimpaan versioon, versioon 1.3. Tämä lähestymistapa auttaa käsitteiden käyttöönottoa vähitellen, aloittaen hyvin yksinkertaisista käsitteistä ja huipentumalla melko pitkälle edenneeseen esimerkkiin.
Tämä sarja ei aio tarjota kattavaa opasta tietoturvaan. Tietoturva on monipuolinen asia, joka koskettaa useita aloja, osastoja ja kulttuureja. Teknologiaan tehtäviä investointeja olisi seurattava investoinneilla henkilöstön koulutukseen, politiikkojen tiukkaan toimeenpanoon ja yleisen turvallisuuspolitiikan säännölliseen tarkistamiseen.
merkintä: Tässä artikkelissa on käynnissä oleva Java-sovelma, joka on suunniteltu osoittamaan sovelmien suojausongelmat. Lue lisätietoja alla.
Sovelluksen turvallisuus
Aloitetaan tutkimuksemme tarkastelemalla sovellusten turvallisuutta. Osassa 2 näimme, kuinka Java-turvallisuus on kehittynyt hiekkalaatikkomallista hienorakeiseksi suojausmalliksi. Huomasimme myös, että sovellukset (paikallinen koodi) saavat oletusarvoisesti ilmaisen hallinnan ja että niitä ei valvota samalla tavalla kuin sovelmia (verkkoon ladattava koodi), joita pidetään tyypillisesti epäluotettavina. Aikaisemmasta muutoksesta johtuen Java 2: n tietoturvasovelluksiin voidaan mahdollisesti soveltaa samaa valvonnan tasoa kuin sovelmiin.
Ensinnäkin, nopea muistiinpano writeFile.java, tässä artikkelissa käytetty koodi Java 2: n turvaominaisuuksien havainnollistamiseksi. Tämä ohjelma on hieman muunnettu versio Sunin toimittamasta sovelmakoodista, joka on saatavana Internetissä havainnollistamaan joitain Java 2 -suojauksen ominaisuuksia. Ohjelma, jota on muokattu tarjoamaan sovellustukea, yrittää luoda ja kirjoittaa tiedoston paikalliseen tiedostojärjestelmään. Suojauspäällikkö tarkastaa pääsyn paikalliseen tiedostojärjestelmään. Näemme tässä artikkelissa, kuinka tämä toiminto voidaan sallia turvallisella tavalla.
/ ** * Oletusarvoisesti tämä aiheuttaa tietoturvapoikkeuksen sovelmana. * * JDK 1.2 -sovellusten katseluohjelmalla, * jos määrität järjestelmän myöntämään Duke'n * allekirjoittamia ja Java-ohjelmistosivustolta ladattuja sovelmia kirjoittamaan tiedosto * / tmp-hakemistoon (tai tiedostoon nimeltä C: \ tmpfoo "* Windows-järjestelmässä), tämä sovelma voi toimia. * * @versio JDK 1.2 * @author Marianne Mueller * @Muokattu Raghavan Srinivas [Rags] * / import java.awt. *; tuo java.io. *; tuo java.lang. *; tuo java.applet. *; public class writeFile laajentaa sovelman {String myFile = "/ tmp / foo"; Tiedosto f = uusi tiedosto (myFile); DataOutputStream-annokset; public void init () {String osname = System.getProperty ("os.nimi"); if (osname.indexOf ("Windows")! = -1) {myFile = "C:" + File.separator + "tmpfoo"; }} public void paint (Grafiikka g) {try {dos = new DataOutputStream (new BufferedOutputStream (new FileOutputStream (myFile), 128)); dos.writeBytes ("Kissat voivat hypnotisoida sinut, kun odotat sitä vähiten \ n"); dos.huuhtelu (); dos.close (); g.drawString ("Kirjoittaminen onnistuneesti tiedostoon nimeltä" + myFile + "- mene katsomaan sitä!", 10, 10); } catch (SecurityException e) {g.drawString ("writeFile: pyydetty suojauspoikkeus", 10, 10); } catch (IOException ioe) {g.drawString ("writeFile: pyydetty i / o-poikkeus", 10, 10); }} public staattinen void main (String args []) {Kehys f = uusi kehys ("writeFile"); writeFile writefile = uusi writeFile (); writefile.init (); writefile.start (); f.add ("Center", kirjoitustiedosto); f. setSize (300, 100); f.näytä (); }} Java 2 Runtime Environment, Standard Edition (JRE) -sovelluksessa luodun tavukoodin suorittaminen antaa sovelluksen oletusarvoisesti muokata paikallisen tiedostojärjestelmän tiedostoa, koska oletuskäytäntö ei aseta Java 2 -sovelluksia suojauksenhallinnalle. Tämä käytäntö on perusteltu, koska sovellukset ovat tyypillisesti paikallisesti tuotettua koodia, eikä niitä ladata verkon kautta. Seuraava komentorivi tuottaa kuvassa 1 esitetyn ikkunan, joka osoittaa, että tiedosto on luotu ja kirjoitettu.
$ java writeFile
Jos haluat antaa koodin Java 2 -turvallisuushallinnalle, käytä seuraavaa komentoriviä, jonka pitäisi tuottaa kuvassa 2 esitetyt tulokset. Huomaa, että sovellus loi tietoturvapoikkeuksen, joka johtui yrityksestä muuttaa paikallista tiedostojärjestelmää. Erityisesti mukana oleva tietoturvapäällikkö loi poikkeuksen.
$ java -Djava.security.manager writeFile
Edellä kuvatut tapaukset edustavat äärimmäisiä esimerkkejä turvallisuuspolitiikasta. Ensimmäisessä tapauksessa hakemusta ei valvottu; jälkimmäisessä se oli erittäin jäykän valvonnan alainen. Useimmissa tapauksissa on tarpeen asettaa käytäntö jonnekin väliin.
Voit suorittaa välisen käytännön käytäntötiedoston avulla. Luo näin luomalla käytäntötiedosto nimeltä kaikki. politiikka työhakemistossa:
anna {lupa java.io.FilePermission "<>", "kirjoita"; }; Saman koodikappaleen suorittaminen seuraavalla komentorivillä sallii paikallisen tiedostojärjestelmän muokkaamisen:
$ java -Djava.security.manager -Djava.security.policy = kaikki.policy writeFile
Tässä esimerkissä sovellus oli tietoturvapäällikön alainen, mutta yleistä käytäntöä hallitsi käytäntötiedosto, joka salli kaikki muokattavan paikallisen tiedostojärjestelmän tiedostot. Tiukempi käytäntö on saattanut olla sallia vain asiaankuuluvan tiedoston muokkaaminen - tmpfoo tässä tapauksessa.
Käsittelen lisätietoja käytännötiedostosta, mukaan lukien merkintöjen syntaksin, myöhemmin tässä artikkelissa. Mutta ensin tarkastellaan applet-suojausta ja verrataan sitä sovellusten turvallisuuteen.
Applet-suojaus
Tähän mennessä olemme tutkineet sovellusten turvallisuutta. Sellaisena useimpiin turvaominaisuuksiin pääsee käsiksi ja niitä voidaan muokata komentorivin kautta. Riittävän turvallisen ja silti joustavan käytännön tarjoaminen sovelmaympäristössä osoittautuu huomattavasti haastavammaksi. Aloitetaan tarkastelemalla sovelman käyttöönottoa Appletviewer. Tarkastelemme myöhemmin selaimen asentamia sovelmia.
Java-koodikäytännön sanelee ensisijaisesti CodeSource, joka sisältää kaksi tietoa: paikka, josta koodi on alkanut, ja sen allekirjoittaneen henkilön.
Appletviewer
Luo tiedosto nimeltä writeFile.html seuraavalla sisällöllä:
Java Security -esimerkki: Tiedostojen kirjoittaminen
Sovelluksen suorittaminen seuraavalla komentorivillä johtaisi kuvassa 3 esitettyyn ikkunaan:
$ appletviewer writeFile.html
Huomaa, että toisin kuin sovelluksella tapahtuisi, sovelma loi poikkeuksen, koska sovelma on oletusarvoisesti tietoturvapäällikön alainen. Asennusta voidaan tarvittaessa muokata muokattavalla käytännöllä. Suorita seuraava komentorivi:
appletviewer -J "-Djava.security.policy = all.policy" writeFile.html
, kuten voit odottaa, sallisi tmpfoo tiedosto, koska tämä oli sallittua käytäntötiedoston mukaisesti.
Selaimet
Applet-suojaus selaimissa pyrkii estämään epäluotettavia sovelmia suorittamasta mahdollisesti vaarallisia toimintoja ja samalla optimaalisen pääsyn luotettuihin sovelmiin. Applet-tietoturvan käyttöönotto selaimissa eroaa huomattavasti tähänastisesta, lähinnä seuraavista syistä:
- Oletusarvoinen epäluottamus verkon kautta ladattuun koodiin
- Riittämätön pääsy komentorivivaihtoehtoihin JVM: n ajamiseksi, koska JVM: ää isännöidään selaimen yhteydessä
- Riittämätön tuki joillekin selainten mukana toimitettujen JVM: ien uusimmille turvaominaisuuksille
Ensimmäisen ongelman osalta epäluotettavan koodin suorittamisesta mahdollisesti aiheutuvien ongelmien välttämiseksi Java: n aiemmat versiot käyttivät hiekkalaatikkomallia (katso "Sivupalkki 1: Hiekkalaatikkomalli"). Luottamus on pitkälti filosofinen tai emotionaalinen kysymys, ei tekninen; tekniikka voi kuitenkin auttaa. Esimerkiksi Java-koodi voidaan allekirjoittaa varmenteilla. Tässä esimerkissä allekirjoittaja vakuuttaa implisiittisesti koodin allekirjoittamalla sen. Koodia käyttävän käyttäjän on viime kädessä luotettava allekirjoittavaan yksikköön vai ei, koska nämä varmenteet takaavat, että aiottu henkilö tai organisaatio on todella allekirjoittanut koodin.
Toinen ongelma johtuu JVM: n suorittamisen vaihtoehtojen puuttumisesta selainyhteydessä. Esimerkiksi räätälöityjä käytäntötiedostoja ei ole yksinkertaista tapaa ottaa käyttöön ja käyttää kuten edellisessä esimerkissä. Sen sijaan tällaiset käytännöt on määritettävä JRE-asennukseen perustuvien tiedostojen avulla. Räätälöityjä luokan kuormaajia tai tietoturvapäälliköitä ei voida asentaa helposti.
Kolmas ongelma, JRE: n uusimpien versioiden tuen puute selaimen JVM-oletusarvoisesti, ratkaistaan Java-laajennuksella (katso "Sidebar 2: Java Plug-in Primer"). Itse asiassa taustalla on, että käytäntötiedostojen muokkaaminen ei ole kovin suoraviivaista. Koska sovelmia voidaan käyttää tuhansille tai jopa miljoonille asiakaskoneille, saattaa olla ympäristöjä, joissa käyttäjät eivät ehkä ymmärrä tietoturvaa hyvin tai eivät ole perehtyneet käytäntötiedoston muokkausmenetelmiin. Java-laajennus tarjoaa kiertotavan, vaikka on suositeltavaa käyttää käytäntötiedostoja aina, kun se on käytännöllistä ja soveltuvaa.
Seuraavaksi tarkastelemme tarkemmin applettien suojausta, johon sisältyy koodin allekirjoittamisen esimerkkejä selainympäristössä, jossa on Java-laajennus. Rajoitamme keskustelun Java-laajennuksen versioon 1.3, ellei nimenomaisesti toisin mainita.
Java-laajennus ja suojaus
Java-laajennus tukee standardia Java 2 SDK, Standard Edition (J2SE), mukaan lukien suojausmalli. Kaikki sovelmat toimivat tavallisen sovelman tietoturvahallinnan alla, mikä estää mahdollisesti haitallisia sovelmia suorittamasta vaarallisia toimintoja, kuten paikallisten tiedostojen lukemista. RSA-allekirjoitetut sovelmat voidaan ottaa käyttöön Java-laajennuksen avulla. Lisäksi Java-laajennus yrittää ajaa sovelmia samalla tavalla sekä Netscape Navigatorissa että Internet Explorerissa välttämällä selainkohtaisia resursseja. Tämä varmistaa, että RSA-allekirjoitettu sovelma toimii identtisesti molemmissa selaimissa Java-laajennuksen kanssa. Java-laajennus tukee myös HTTPS: ää, suojattua HTTP-versiota.
Jotta laajennuksella parannettu selain voi luottaa sovelmaan ja myöntää sille kaikki oikeudet tai joukon hienoja käyttöoikeuksia (kuten J2EE-käytäntötiedostossa on määritelty), käyttäjän on määritettävä ennalta luotettujen allekirjoittajavarmenteiden välimuisti ( .kahvila tiedosto JRE 1.3: ssa) lisätäksesi sovelman allekirjoittajan siihen. Tämä ratkaisu ei kuitenkaan skaalaa hyvin, jos sovelma on asennettava tuhansille asiakaskoneille, eikä se välttämättä ole aina mahdollista, koska käyttäjät eivät ehkä tiedä etukäteen, kuka on allekirjoittanut sovelman, jota he yrittävät ajaa. Myös Java-laajennuksen aiemmat versiot tukivat koodin allekirjoittamista DSA: n avulla, mikä ei ole yhtä yleistä kuin RSA.
Uusi luokan kuormaaja, sun.plugin.security.PluginClassLoader Java-laajennuksen 1.3, voittaa yllä mainitut rajoitukset. Se tukee RSA-todentamista ja dynaamista luottamuksen hallintaa.
Ohjelmistokehityspaketin (SDK) työkalut
Kolme turvallisuutta käsittelevää työkalua, jotka ovat saatavana osana Java 2 SDK: ta, ovat:
avaimen työkalu- Hallitsee avaimenvarastoja ja varmenteitajarrsigner- Luo ja tarkistaa JAR-allekirjoituksetpoliisin työkalu- Hallitsee käytäntötiedostoja GUI-pohjaisen työkalun avulla
Seuraavassa tarkastellaan joidenkin näiden työkalujen tärkeitä vaihtoehtoja. Katso resursseista tarkempia asiakirjoja, jotka liittyvät tiettyihin työkaluihin.
