Programmering

Java-sikkerhedsudvikling og -koncepter, del 3: Applets sikkerhed

Java's tidlige vækst blev ansporet af kode, der kan downloades over et netværk, bedre kendt som applets. Applets sikkerhed har udviklet sig med Java-væksten og er i dag en kilde til hyppig forvirring på grund af de mange forskellige Java-versioner, kommercielt tilgængelige browsere og plug-ins.

Denne artikel, den tredje i serien, vil dække de forskellige krav til sikker kørsel af Java-kode downloadet fra et netværk. Selvom mobilkode ikke er et revolutionerende koncept, præsenterer Java og Internettet nogle unikke udfordringer for computersikkerhed. Udviklingen af ​​Java-arkitekturen og dens indvirkning på kernen i Java-sikkerhed blev diskuteret i del 1 og 2. Denne artikel tager en anden tackling: en praktisk tilgang til at binde alle koncepter sammen ved at installere en simpel applet, der skriver til det lokale filsystem .

Java-sikkerhedsudvikling og -koncepter: Læs hele serien!

  • Del 1: Lær computersikkerhedskoncepter og -termer i denne introduktionsoversigt
  • Del 2: Oplev ind og ud af Java-sikkerhed
  • Del 3: Takle Java-applets sikkerhed med tillid
  • Del 4: Lær, hvordan valgfri pakker udvider og forbedrer Java-sikkerhed
  • Del 5: J2SE 1.4 tilbyder adskillige forbedringer af Java-sikkerhed

Som eksempel på applets kerne er public-key kryptografi, der blev introduceret tidligere i denne serie. Kode, der er signeret ved hjælp af underskriverens private nøgle, kan køres på klientmaskiner, når den offentlige nøgle, der svarer til underskriveren, anses for at være tillid til den respektive maskine. Vi diskuterer også, hvordan politikfiler, der giver tilladelser og keystore, kan bruges som et lager for offentlige og private nøgler. Desuden fremhæver vi Java 2 SDK-sikkerhedsværktøjer og Netscape's tegneværktøj, da de muliggør implementering.

Denne artikel sporer udviklingen af ​​Java-sikkerhed, begyndende med applikationssikkerhed i den oprindelige udgivelse af Java 2 og videre til den nyeste version af Java 2, version 1.3. Denne tilgang hjælper med at introducere begreberne gradvist, begyndende med meget enkle begreber og kulminerer i et ret avanceret eksempel.

Denne serie har ikke til hensigt at give en omfattende guide til computersikkerhed. Computersikkerhed er et mangesidet emne, der berører flere discipliner, afdelinger og kulturer. Investeringer i teknologier bør følges op med investeringer i uddannelse af personale, streng håndhævelse af politikker og periodisk gennemgang af den overordnede sikkerhedspolitik.

Bemærk: Denne artikel indeholder en kørende Java-applet designet til at demonstrere problemer med applets sikkerhed. Læs nedenfor for flere detaljer.

Applikationssikkerhed

Lad os starte vores undersøgelse ved at se på applikationssikkerhed. I del 2 så vi, hvordan Java-sikkerhed har udviklet sig fra en sandkassemodel til en finkornet sikkerhedsmodel. Vi så også, at applikationer (lokal kode) som standard får en gratis regeringstid og ikke er underlagt den samme kontrol som applets (netværk, der kan downloades), som typisk betragtes som utro. I en ændring fra fortiden kan sikkerhedsapplikationer i Java 2 valgfrit være underlagt samme niveau af kontrol som applets.

Først en hurtig note om skrivFil.java, koden, der blev brugt i denne artikel til at illustrere sikkerhedsfunktionerne i Java 2. Dette program er en let ændret version af appletkoden leveret af Sun, tilgængelig på internettet for at illustrere nogle af funktionerne i Java 2-sikkerhed. Programmet, der er modificeret til at yde applikationsstøtte, forsøger at oprette og skrive en fil på det lokale filsystem. Adgang til et lokalt filsystem screenes af sikkerhedsadministratoren. Vi vil se igennem denne artikel, hvordan denne særlige operation kan tillades på en sikker måde.

/ ** * Som standard hæver dette en sikkerhedsundtagelse som en applet. * * Med JDK 1.2 appletviewer, * hvis du konfigurerer dit system til at give applets underskrevet af "Duke" * og downloadet fra Java Software Website til at skrive en fil * til din / tmp-mappe (eller til filen med navnet "C: \ tmpfoo "på et * Windows-system), så kan denne applet køre. * * @version JDK 1.2 * @forfatter Marianne Mueller * @Modificeret af Raghavan Srinivas [Rags] * / import java.awt. *; import java.io. *; import java.lang. *; importer java.applet. *; public class writeFile udvider 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 ugyldig maling (Grafik g) {prøv {dos = ny DataOutputStream (ny BufferedOutputStream (ny FileOutputStream (myFile), 128)); dos.writeBytes ("Katte kan hypnotisere dig, når du mindst venter det \ n"); dos.flush (); dos.close (); g.drawString ("Skrev med succes til filen med navnet" + myFile + "- kig på det!", 10, 10); } fange (SecurityException e) {g.drawString ("writeFile: fanget sikkerhedsundtagelse", 10, 10); } fange (IOException ioe) {g.drawString ("writeFile: fanget i / o undtagelse", 10, 10); }} offentlig statisk ugyldig hoved (String args []) {Frame f = new Frame ("writeFile"); skrivFil skrivfil = ny skrivFil (); skrivfil.init (); writefile.start (); f.add ("Center", skrivfil); f.setSize (300, 100); f.show (); }} 

Ved at køre den bytecode, der er genereret i et Java 2 Runtime-miljø, vil Standard Edition (JRE) lade applikationen ændre filen på det lokale filsystem som standard, da standardpolitikken ikke udsætter Java 2-applikationer for en sikkerhedsadministrator. Denne politik er berettiget, fordi applikationer typisk er lokalt genereret kode og ikke downloades over netværket. Den følgende kommandolinje producerer det vindue, der er vist i figur 1, hvilket indikerer, at filen blev oprettet og skrevet ind.

$ java writeFile 

For at underkaste koden for Java 2-sikkerhedsadministrator skal du påkalde følgende kommandolinje, som skal give de resultater, der er angivet i figur 2. Bemærk, at applikationen genererede en sikkerhedsundtagelse forårsaget af et forsøg på at ændre det lokale filsystem. Den eksplicit inkluderede sikkerhedsmanager genererede undtagelsen.

$ java -Djava.security.manager writeFile 

Ovennævnte sager repræsenterer ekstreme eksempler på sikkerhedspolitik. I det første tilfælde var ansøgningen ikke underlagt nogen kontrol; i sidstnævnte var det underlagt en meget stiv kontrol. I de fleste tilfælde vil det være nødvendigt at indstille politikken et sted imellem.

Du kan udføre en mellemliggende politik ved hjælp af en politikfil. For at gøre det skal du oprette en politikfil kaldet alle. politik i arbejdsmappen:

give {tilladelse java.io.FilePermission "<>", "skriv"; }; 

At køre det samme stykke kode med følgende kommandolinje tillader ændring af det lokale filsystem:

$ java -Djava.security.manager -Djava.security.policy = all.policy writeFile 

I dette eksempel var applikationen underlagt sikkerhedsadministratoren, men den overordnede politik blev styret af politikfilen, som tillod det alle filer på det lokale filsystem, der skal ændres. En strengere politik kunne have været at tillade ændring af kun den relevante fil - tmpfoo I dette tilfælde.

Jeg vil dække flere detaljer om politikfilen, herunder syntaksen for posterne, senere i denne artikel. Men lad os først se på applets sikkerhed og kontrastere det med applikationssikkerhed.

Applets sikkerhed

Indtil videre har vi studeret applikationssikkerhed. Som sådan kan de fleste af sikkerhedsfunktionerne fås og ændres via kommandolinjen. Tilvejebringelse af en tilstrækkelig sikker og alligevel noget fleksibel politik i et appletmiljø viser sig at være væsentlig mere udfordrende. Vi starter med at se på implementeringen af ​​en applet i Appletviewer. Vi ser på browser-implementerede applets senere.

Java-kodepolitik dikteres primært af CodeSource, som består af to stykker information: det sted, hvor koden opstod, og den person, der underskrev den.

Appletviewer

Opret en fil, der hedder writeFile.html med følgende indhold:

  Java-sikkerhedseksempel: Skrivning af filer 

At køre appleten med følgende kommandolinje vil resultere i vinduet vist i figur 3:

$ appletviewer writeFile.html 

Bemærk, at applet - i modsætning til hvad der ville ske med en applikation - genererede en undtagelse, da appleten som standard er underlagt sikkerhedsadministratoren. Installationen kan styres af en politik, der kan tilpasses, hvis det kræves. Kører følgende kommandolinje:

appletviewer -J "-Djava.security.policy = all.policy" writeFile.html 

ville, som du kunne forvente, tillade ændring af tmpfoo fil, da dette var tilladt i overensstemmelse med politikfilen.

Browsere

Applets sikkerhed i browsere stræber efter at forhindre utro, der er tillid til, i at udføre potentielt farlige handlinger, samtidig med at det giver optimal adgang til pålidelige applets. Applets sikkerhedsudrulning i browsere er væsentligt forskellig fra det, vi hidtil har set, primært på grund af følgende årsager:

  • En standardmangel på tillid til kode, der downloades over netværket
  • Utilstrækkelig adgang til kommandolinjemulighederne til at køre JVM, da JVM er hostet i forbindelse med en browser
  • Utilstrækkelig support til nogle af de nyeste sikkerhedsfunktioner i JVM'erne, der følger med browsere

Hvad det første problem angår, for at undgå de potentielle problemer som følge af kørsel af ikke-betroet kode, brugte tidligere versioner af Java sandkassemodellen (se "Sidepanel 1: Sandkassemodel"). Tillid er et stort set filosofisk eller følelsesmæssigt spørgsmål snarere end et teknisk spørgsmål; dog kan teknologien hjælpe. For eksempel kan Java-kode underskrives ved hjælp af certifikater. I dette eksempel indestår underskriveren implicit for koden ved at underskrive den. Det påhviler i sidste ende brugeren, der kører koden, til at stole på signeringsenheden eller ej, da disse certifikater garanterer, at koden faktisk er underskrevet af den tilsigtede person eller organisation.

Det andet problem stammer fra den manglende adgang til mulighederne for at køre JVM i browserkonteksten. For eksempel er der ingen enkel måde at distribuere og bruge tilpassede politikfiler på, som vi kunne i det foregående eksempel. I stedet for skal sådanne politikker indstilles af filer baseret på JRE-installationen. Tilpassede klasselæssere eller sikkerhedsadministratorer kan ikke installeres let.

Det tredje problem, manglen på support til de nyeste versioner af JRE i standard-JVM med browseren, løses ved hjælp af Java-plug-in (se "Sidebar 2: Java Plug-in Primer"). Faktisk er et underliggende problem, at ændring af politikfiler ikke er meget ligetil. Da applets kan installeres på tusinder eller endda millioner af klientmaskiner, kan der være miljøer, hvor brugerne muligvis ikke har en god forståelse af sikkerhed eller måske ikke er bekendt med metoder til at ændre politikfilen. Java-plug-in'en giver en løsning, selvom det anbefales at bruge politikfiler, hvor det er praktisk og relevant.

Dernæst ser vi mere detaljeret på applets sikkerhed, der involverer eksempler på kodesignering i et browsermiljø med et Java-plug-in. Vi begrænser diskussionen til Java plug-in version 1.3, medmindre andet udtrykkeligt er angivet.

Java-plug-in og sikkerhed

Java-plug-in'en understøtter standard Java 2 SDK, Standard Edition (J2SE), inklusive sikkerhedsmodellen. Alle applets køres under standardapplet-sikkerhedsadministratoren, som forhindrer potentielt ondsindede applets i at udføre farlige handlinger, såsom at læse lokale filer. RSA-signerede applets kan implementeres ved hjælp af Java-plug-in. Derudover forsøger Java-plug-in'et at køre applets på en identisk måde i både Netscape Navigator og Internet Explorer ved at undgå browserspecifikke ressourcer. Dette sikrer, at en RSA-signeret applet kører identisk i begge browsere med Java-plug-in. Java-plug-in'en understøtter også HTTPS, en sikker version af HTTP.

For at en plug-in-forbedret browser skal have tillid til en applet og give den alle privilegier eller et sæt finkornede tilladelser (som angivet i en J2EE-politikfil), skal brugeren forudkonfigurere sin cache med pålidelige underskriftscertifikater (det .keystore fil i JRE 1.3) for at tilføje appletens underskriver til den. Denne løsning skaleres dog ikke godt, hvis appleten skal distribueres på tusindvis af klientmaskiner og muligvis ikke altid er mulig, fordi brugerne muligvis ikke på forhånd ved, hvem der har underskrevet appleten, som de prøver at køre. Tidligere versioner af Java-plug-in understøttede også kodesignering ved hjælp af DSA, som ikke er så udbredt som RSA.

En ny klasselæsser, sun.plugin.security.PluginClassLoader i Java-plugin 1.3, overvinder de ovennævnte begrænsninger. Det implementerer support til RSA-verifikation og dynamisk tillidsstyring.

Softwareudviklingssættet (SDK) -værktøjerne

De tre værktøjer, der beskæftiger sig med sikkerhed, fås som en del af Java 2 SDK, er:

  • nøgleværktøj - Administrerer keystores og certifikater
  • jarsigner - Genererer og verificerer JAR-signaturer
  • politiværktøj - Administrerer politikfiler via et GUI-baseret værktøj

Vi vil se på nogle af disse værktøjers vigtige muligheder i afsnittene nedenfor. Se ressourcer for mere detaljeret dokumentation, der er knyttet til bestemte værktøjer.

$config[zx-auto] not found$config[zx-overlay] not found