Java's tidlige vekst ble ansporet av koden som kan lastes ned over et nettverk, bedre kjent som applets. Applets sikkerhet har utviklet seg med veksten av Java, og er i dag en kilde til hyppig forvirring på grunn av mangfoldet av Java-versjoner, kommersielt tilgjengelige nettlesere og plug-ins.
Denne artikkelen, den tredje i serien, vil dekke de ulike kravene for sikker kjøring av Java-kode lastet ned fra et nettverk. Selv om mobilkode ikke er et revolusjonerende konsept, presenterer Java og Internett noen unike utfordringer for datasikkerhet. Utviklingen av Java-arkitekturen og dens innvirkning på kjernen i Java-sikkerhet ble diskutert i del 1 og 2. Denne artikkelen tar en annen takling: en praktisk tilnærming for å knytte alle konseptene sammen ved å distribuere en enkel applet som skriver til det lokale filsystemet .
Java-sikkerhetsutvikling og konsepter: Les hele serien!
- Del 1: Lær datasikkerhetskonsepter og begreper i denne innledende oversikten
- Del 2: Oppdag innsiden av Java-sikkerhet
- Del 3: Takle Java-applets sikkerhet med tillit
- Del 4: Lær hvordan valgfrie pakker utvider og forbedrer Java-sikkerhet
- Del 5: J2SE 1.4 tilbyr mange forbedringer av Java-sikkerhet
Kjernen i eksemplet på applet er kryptografi med offentlig nøkkel, introdusert tidligere i denne serien. Kode signert med den private nøkkelen til underskriveren kan kjøres på klientmaskiner når den offentlige nøkkelen som tilsvarer underskriveren anses å være klarert på den respektive maskinen. Vi diskuterer også hvordan policyfiler, som gir tillatelser og nøkkelbutikk, kan brukes som et lager for offentlige og private nøkler. Videre vil vi markere Java 2 SDK sikkerhetsverktøy og Netscape skiltverktøy, siden de muliggjør distribusjon.
Denne artikkelen sporer utviklingen av Java-sikkerhet, og begynner med applikasjonssikkerhet i den første utgivelsen av Java 2 og går videre til den nyeste versjonen av Java 2, versjon 1.3. Denne tilnærmingen hjelper deg med å introdusere konseptene gradvis, med veldig enkle konsepter og kulminerer i et ganske avansert eksempel.
Denne serien har ikke til hensikt å gi en omfattende guide til datasikkerhet. Datasikkerhet er et mangesidig tema som berører flere fagfelt, avdelinger og kulturer. Investeringer i teknologi bør følges opp med investeringer i opplæring av personell, streng håndheving av politikk og periodisk gjennomgang av den overordnede sikkerhetspolitikken.
Merk: Denne artikkelen inneholder en kjørende Java-applet designet for å demonstrere problemer med applet-sikkerhet. Les nedenfor for mer informasjon.
Søknadssikkerhet
La oss starte undersøkelsen vår ved å se på søknadssikkerhet. I del 2 så vi hvordan Java-sikkerhet har utviklet seg fra en sandkassemodell til en finkornet sikkerhetsmodell. Vi så også at applikasjoner (lokal kode) som standard får gratis regjeringstid og ikke er underlagt den samme kontrollen som applets (nettverksnedlastbar kode), som vanligvis betraktes som ikke-klarerte. I en endring fra fortiden kan sikkerhetsapplikasjoner i Java 2 valgfritt være underlagt samme nivå av kontroll som applets.
Først et raskt notat om writeFile.java, koden som brukes i denne artikkelen for å illustrere sikkerhetsfunksjonene i Java 2. Dette programmet er en litt modifisert versjon av appletkoden levert av Sun, tilgjengelig på nettet for å illustrere noen av funksjonene i Java 2-sikkerhet. Programmet, modifisert for å gi applikasjonsstøtte, prøver å opprette og skrive en fil på det lokale filsystemet. Tilgang til et lokalt filsystem blir skjermet av sikkerhetsansvarlig. Vi vil se gjennom denne artikkelen hvordan denne operasjonen kan tillates på en sikker måte.
/ ** * Som standard øker dette et sikkerhets unntak som en applet. * * Med JDK 1.2 appletviewer, * hvis du konfigurerer systemet ditt til å gi appletter signert av "Duke" * og lastet ned fra Java Software Website for å skrive en fil * til / tmp-katalogen (eller til filen som heter "C: \ tmpfoo "på et * Windows-system), så kan denne appleten kjøres. * * @version JDK 1.2 * @forfatter Marianne Mueller * @Modifisert av Raghavan Srinivas [Rags] * / import java.awt. *; importer java.io. *; importer java.lang. *; importere java.applet. *; public class writeFile utvider Applet {String myFile = "/ tmp / foo"; Fil f = ny fil (myFile); DataOutputStream dos; offentlig ugyldig init () {String osname = System.getProperty ("os.name"); hvis (osname.indexOf ("Windows")! = -1) {myFile = "C:" + File.separator + "tmpfoo"; }} offentlig tomrom (Grafikk g) {prøv {dos = ny DataOutputStream (ny BufferedOutputStream (ny FileOutputStream (myFile), 128)); dos.writeBytes ("Katter kan hypnotisere deg når du minst forventer det \ n"); dos.flush (); dos.close (); g.drawString ("Skrev vellykket filen" + myFile + "- se på den!", 10, 10); } fangst (SecurityException e) {g.drawString ("writeFile: fanget sikkerhets unntak", 10, 10); } fangst (IOException ioe) {g.drawString ("writeFile: fanget i / o unntak", 10, 10); }} public static void main (String args []) {Frame f = new Frame ("writeFile"); writeFile wrote-file = new writeFile (); writefile.init (); writefile.start (); f.add ("Center", skrivfil); f.setSize (300, 100); f.show (); }} Når du kjører bytekoden generert i et Java 2 Runtime-miljø, vil Standard Edition (JRE) la applikasjonen endre filen på det lokale filsystemet som standard, siden standardpolicyen ikke utsetter Java 2-applikasjoner for en sikkerhetsbehandling. Denne policyen er berettiget fordi applikasjoner vanligvis er lokalgenerert kode og ikke lastes ned over nettverket. Følgende kommandolinje produserer vinduet vist i figur 1, som indikerer at filen ble opprettet og skrevet inn.
$ java writeFile
For å underkaste koden for Java 2-sikkerhetsbehandling, påkaller du følgende kommandolinje, som skal gi resultatene som er angitt i figur 2. Legg merke til at applikasjonen genererte et sikkerhets unntak forårsaket av et forsøk på å endre det lokale filsystemet. Den eksplisitt inkluderte sikkerhetsansvarlige genererte unntaket.
$ java -Djava.security.manager writeFile
Sakene illustrert ovenfor representerer ekstreme eksempler på sikkerhetspolitikk. I det første tilfellet var søknaden ikke underlagt noen kontroll; i sistnevnte var det underlagt en meget stiv kontroll. I de fleste tilfeller vil det være nødvendig å sette policyen et sted i mellom.
Du kan utføre en mellomliggende policy ved hjelp av en policyfil. For å gjøre det, opprett en policyfil som heter all.policy i arbeidskatalogen:
gi {tillatelse java.io.FilePermission "<>", "skriv"; }; Å kjøre samme kode med følgende kommandolinje vil tillate endring av det lokale filsystemet:
$ java -Djava.security.manager -Djava.security.policy = all.policy writeFile
I dette eksemplet var applikasjonen underlagt sikkerhetsansvarlig, men den generelle policyen ble styrt av policyfilen, som tillot det alle filer på det lokale filsystemet som skal endres. En strengere policy kan ha vært å tillate endring av bare den aktuelle filen - tmpfoo i dette tilfellet.
Jeg vil dekke mer detaljer om policyfilen, inkludert syntaksen for oppføringene, senere i denne artikkelen. Men la oss først se på applets sikkerhet og kontrastere den med applikasjonssikkerhet.
Applets sikkerhet
Så langt har vi studert applikasjonssikkerhet. Som sådan kan de fleste sikkerhetsfunksjonene nås og endres via kommandolinjen. Å gi en tilstrekkelig sikker og likevel noe fleksibel policy i et appletmiljø viser seg å være betydelig mer utfordrende. Vi starter med å se på distribusjonen av en applet i Appletviewer. Vi ser på nettleserdistribuerte applets senere.
Java-kodepolitikk dikteres primært av CodeSource, som består av to opplysninger: stedet der koden stammer og personen som signerte den.
Appletviewer
Opprett en fil som heter writeFile.html med følgende innhold:
Java Security Eksempel: Skrive filer
Å kjøre appleten med følgende kommandolinje vil resultere i vinduet vist i figur 3:
$ appletviewer writeFile.html
Legg merke til at - i motsetning til hva som ville skje med et program - genererte appleten et unntak siden appleten er underlagt sikkerhetsadministratoren som standard. Installasjonen kan styres av en tilpassbar policy, om nødvendig. Kjører følgende kommandolinje:
appletviewer -J "-Djava.security.policy = all.policy" writeFile.html
ville, som du forventer, tillate endring av tmpfoo siden dette var tillatt i samsvar med policy-filen.
Nettlesere
Applets sikkerhet i nettlesere prøver å forhindre at ikke-klarerte applets utfører potensielt farlige operasjoner, samtidig som det gir optimal tilgang til pålitelige applets. Applets sikkerhetsdistribusjon i nettlesere er vesentlig forskjellig fra det vi har sett så langt, hovedsakelig på grunn av følgende årsaker:
- En standard mangel på tillit til kode lastet ned over nettverket
- Utilstrekkelig tilgang til kommandolinjealternativene for å kjøre JVM, siden JVM er vert i sammenheng med en nettleser
- Utilstrekkelig støtte for noen av de nyeste sikkerhetsfunksjonene i JVM-ene som følger med nettlesere
Når det gjelder det første problemet, brukte tidligere versjoner av Java sandkassemodellen (se "Sidefelt 1: Sandkassemodell") for å avhjelpe potensielle problemer som følge av kjøring av ikke-klarert kode. Tillit er et stort sett filosofisk eller emosjonelt spørsmål, snarere enn et teknisk spørsmål; Imidlertid kan teknologi hjelpe. For eksempel kan Java-kode signeres ved hjelp av sertifikater. I dette eksemplet garanterer undertegnede implisitt koden ved å signere den. Det påhviler til slutt brukeren som kjører koden for å stole på signeringsenheten eller ikke, gitt at disse sertifikatene garanterer at koden faktisk ble signert av den tiltenkte personen eller organisasjonen.
Det andre problemet stammer fra manglende tilgang til alternativene for å kjøre JVM i nettlesersammenheng. For eksempel er det ingen enkel måte å distribuere og bruke tilpassede policyfiler som vi kunne i forrige eksempel. I stedet må slike policyer settes av filer basert på JRE-installasjonen. Tilpassede klasselastere eller sikkerhetsledere kan ikke installeres enkelt.
Det tredje problemet, mangel på støtte for de nyeste versjonene av JRE i standard JVM med nettleseren, løses ved hjelp av Java-plugin-modulen (se "Sidefelt 2: Java Plug-in Primer"). Faktisk er et underliggende problem at endring av policyfiler ikke er veldig grei. Siden applikasjoner kan distribueres på tusenvis eller til og med millioner av klientmaskiner, kan det være miljøer der brukerne kanskje ikke har god forståelse for sikkerhet eller kanskje ikke er kjent med metoder for å endre policyfilen. Java-plugin-modulen gir en løsning, selv om det anbefales å bruke policyfiler der det er praktisk og aktuelt.
Deretter ser vi nærmere på applets sikkerhet som involverer eksempler på kodesignering i et nettlesermiljø med en Java-plugin. Vi begrenser diskusjonen til Java-plugin-versjon 1.3 med mindre annet er uttrykkelig oppgitt.
Java-plugin-modulen og sikkerhet
Java-plugin-modulen støtter standard Java 2 SDK, Standard Edition (J2SE), inkludert sikkerhetsmodellen. Alle applets kjøres under standard applet-sikkerhetsbehandling, som forhindrer potensielt ondsinnede applets fra å utføre farlige operasjoner, for eksempel å lese lokale filer. RSA-signerte applets kan distribueres ved hjelp av Java-plugin-modulen. I tillegg forsøker Java-plugin-modulen å kjøre applets på identisk måte i både Netscape Navigator og Internet Explorer ved å unngå nettleserspesifikke ressurser. Dette sikrer at en RSA-signert applet vil kjøre identisk i begge nettlesere med Java-plugin-modulen. Java-plugin-modulen støtter også HTTPS, en sikker versjon av HTTP.
For at en plug-in-forbedret nettleser skal kunne stole på en applet og gi den alle rettigheter eller et sett med finkornede tillatelser (som spesifisert i en J2EE-policyfil), må brukeren forhåndskonfigurere sin cache med pålitelige signeringssertifikater (de .keystore fil i JRE 1.3) for å legge til appletens underskriver til den. Denne løsningen skaleres imidlertid ikke godt hvis appleten må distribueres på tusenvis av klientmaskiner, og det kan hende at det ikke alltid er mulig å gjøre det fordi brukere kanskje ikke vet på forhånd hvem som signerte appleten at de prøver å kjøre. Også tidligere versjoner av Java plug-in støttet kodesignering ved hjelp av DSA, som ikke er så utbredt som RSA.
En ny klasselaster, sun.plugin.security.PluginClassLoader i Java-plugin 1.3, overvinner begrensningene nevnt ovenfor. Den implementerer støtte for RSA-verifisering og dynamisk tillitsstyring.
Software Development Kit (SDK) verktøy
De tre verktøyene som håndterer sikkerhet, tilgjengelig som en del av Java 2 SDK, er:
nøkkelverktøy- Administrerer nøkkelbutikker og sertifikaterjarsigner- Genererer og verifiserer JAR-signaturerpolitiverktøy- Behandler policyfiler via et GUI-basert verktøy
Vi vil se på noen av disse verktøyens viktige alternativer i avsnittene nedenfor. Se Ressurser for mer detaljert dokumentasjon knyttet til bestemte verktøy.
