Programovanie

Vývoj a koncepty zabezpečenia Java, časť 3: Zabezpečenie appletu

Skorý rast Javy podnietil kód stiahnuteľný cez sieť, lepšie známy ako applety. Bezpečnosť appletov sa vyvinula s rastom Java a dnes je zdrojom častých nejasností z dôvodu rozmanitosti verzií Java, komerčne dostupných prehliadačov a doplnkov.

Tento článok, tretí v poradí, sa bude venovať rôznym požiadavkám na bezpečné spustenie kódu Java stiahnutého zo siete. Aj keď mobilný kód nie je revolučným konceptom, Java a internet predstavujú pre počítačovú bezpečnosť niektoré jedinečné výzvy. O vývoji architektúry Java a jej vplyve na základné zabezpečenie Java sa diskutovalo v častiach 1 a 2. Tento článok sa zaoberá iným spôsobom: praktickým prístupom k spojeniu všetkých konceptov nasadením jednoduchého appletu, ktorý zapisuje do lokálneho súborového systému. .

Vývoj a koncepty zabezpečenia Java: Prečítajte si celú sériu!

  • Časť 1: Naučte sa koncepty a pojmy počítačovej bezpečnosti v tomto úvodnom prehľade
  • Časť 2: Objavte vstupy a výstupy zabezpečenia Java
  • Časť 3: Spoľahlivo riešte zabezpečenie Java appletu
  • Časť 4: Dozviete sa, ako voliteľné balíčky rozširujú a zvyšujú zabezpečenie Java
  • Časť 5: J2SE 1.4 ponúka početné vylepšenia zabezpečenia Java

Na príklade jadra appletu je kryptografia s verejným kľúčom, ktorá bola uvedená na začiatku tejto série. Kód podpísaný pomocou súkromného kľúča podpisovateľa je možné spustiť na klientskych počítačoch, akonáhle sa verejný kľúč zodpovedajúci podpisujúcemu považuje na príslušnom počítači za dôveryhodný. Budeme tiež diskutovať o tom, ako možno súbory zásad, ktoré udeľujú povolenia a sklad kľúčov, použiť ako úložisko pre verejné a súkromné ​​kľúče. Ďalej zdôrazníme bezpečnostné nástroje Java 2 SDK a Netscape signtool, pretože umožňujú nasadenie.

Tento článok sleduje vývoj zabezpečenia Java, počnúc zabezpečením aplikácií v počiatočnom vydaní Java 2 a prechodom na najnovšiu verziu Java 2, verzia 1.3. Tento prístup pomáha zavádzať koncepty postupne, počnúc veľmi jednoduchými konceptmi a končiac pomerne pokročilým príkladom.

Zámerom tejto série nie je poskytnúť komplexného sprievodcu počítačovou bezpečnosťou. Počítačová bezpečnosť je mnohostranný problém dotýkajúci sa niekoľkých disciplín, oddelení a kultúr. Po investíciách do technológií by mali nasledovať investície do školenia personálu, dôsledného presadzovania politík a pravidelného prehodnocovania celkovej bezpečnostnej politiky.

Poznámka: Tento článok obsahuje spustený applet Java navrhnutý na demonštráciu problémov so zabezpečením appletu. Prečítajte si ďalšie podrobnosti.

Zabezpečenie aplikácií

Začnime naše vyšetrovanie pohľadom na zabezpečenie aplikácií. V časti 2 sme videli, ako sa zabezpečenie Java vyvinulo z modelu karantény do modelu jemnozrnného zabezpečenia. Videli sme tiež, že aplikácie (miestny kód) predvolene získavajú bezplatné panovanie a nepodliehajú rovnakej kontrole ako applety (kód na stiahnutie v sieti), ktoré sa zvyčajne považujú za nedôveryhodné. V zmene z minulosti môžu byť bezpečnostné aplikácie v Java 2 voliteľne predmetom rovnakej úrovne kontroly ako applety.

Najprv krátka poznámka o writeFile.java, kód použitý v tomto článku na ilustráciu bezpečnostných funkcií v prostredí Java 2. Tento program je mierne upravenou verziou kódu appletu poskytovaného spoločnosťou Sun, ktorá je k dispozícii na webe na ilustráciu niektorých funkcií zabezpečenia v prostredí Java 2. Program upravený tak, aby poskytoval podporu aplikácií, sa pokúša vytvoriť a zapísať súbor do lokálneho súborového systému. Prístup k lokálnemu súborovému systému sleduje bezpečnostný manažér. V tomto článku uvidíme, ako je možné bezpečným spôsobom povoliť túto konkrétnu operáciu.

/ ** * V predvolenom nastavení sa ako applet zvýši bezpečnostná výnimka. * * S appletviewerom JDK 1.2, * ak konfigurujete váš systém tak, aby udeľoval applety podpísané „Dukeom“ * a stiahnuté z webovej stránky Java Software, aby ste napísali súbor * do svojho adresára / tmp (alebo do súboru s názvom „C: \ tmpfoo“) „v systéme * Windows), potom je možné spustiť tento applet. * * @version JDK 1.2 * @author Marianne Mueller * @Modified by Raghavan Srinivas [Rags] * / import java.awt. *; import java.io. *; import java.lang. *; import java.applet. *; verejná trieda writeFile rozširuje applet {String myFile = "/ tmp / foo"; Súbor f = nový Súbor (myFile); DataOutputStream dos; public void init () {Reťazec osname = System.getProperty ("os.name"); if (osname.indexOf ("Windows")! = -1) {myFile = "C:" + File.separator + "tmpfoo"; }} public void paint (Grafika g) {try {dos = new DataOutputStream (nový BufferedOutputStream (nový FileOutputStream (myFile), 128)); dos.writeBytes ("Mačky vás môžu hypnotizovať, keď to najmenej čakáte \ n"); dos.flush (); dos.close (); g.drawString ("Úspešne zapísaný do súboru s názvom" + myFile + "- choďte sa na to pozrieť!", 10, 10); } catch (SecurityException e) {g.drawString ("writeFile: chycená bezpečnostná výnimka", 10, 10); } catch (IOException ioe) {g.drawString ("writeFile: chytená i / o výnimka", 10, 10); }} public static void main (String args []) {Frame f = new Frame ("writeFile"); writeFile writefile = nový writeFile (); writefile.init (); writefile.start (); f.add ("Centrum", súbor na zápis); f.setSize (300, 100); f.show (); }} 

Spustenie bajtkódu vygenerovaného v prostredí Java 2 Runtime Environment, Standard Edition (JRE) umožní aplikácii štandardne upraviť súbor v lokálnom súborovom systéme, pretože predvolená politika nepodlieha aplikáciám Java 2 správcovi zabezpečenia. Táto zásada je oprávnená, pretože aplikácie sú zvyčajne miestne generovaný kód a nie sú sťahované cez sieť. Nasledujúci príkazový riadok vytvára okno zobrazené na obrázku 1, čo naznačuje, že súbor bol vytvorený a zapísaný do neho.

$ java writeFile 

Ak chcete predložiť kód správcovi bezpečnosti Java 2, vyvolajte nasledujúci príkazový riadok, ktorý by mal priniesť výsledky uvedené na obrázku 2. Všimnite si, že aplikácia vygenerovala bezpečnostnú výnimku spôsobenú pokusom o úpravu lokálneho súborového systému. Explicitne zahrnutý bezpečnostný manažér vygeneroval výnimku.

$ java -Djava.security.manager writeFile 

Vyššie ilustrované prípady predstavujú extrémne príklady bezpečnostnej politiky. V prvom prípade žiadosť nepodliehala nijakej kontrole; v druhom prípade podliehalo veľmi prísnej kontrole. Vo väčšine prípadov bude potrebné nastaviť politiku niekde medzi tým.

Medzikontinentálnu politiku môžete dosiahnuť pomocou súboru politík. Ak to chcete urobiť, vytvorte súbor politiky s názvom všetko.polícia v pracovnom adresári:

udeliť {povolenie java.io.FilePermission "<>", "zapísať"; }; 

Spustenie rovnakej časti kódu s nasledujúcim príkazovým riadkom umožní modifikáciu lokálneho súborového systému:

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

V tomto príklade podliehala aplikácia správcovi bezpečnosti, ale celková politika sa riadila súborom politiky, ktorý umožňoval všetko súbory v lokálnom súborovom systéme, ktoré sa majú upraviť. Prísnejšou politikou mohlo byť umožnenie úpravy iba príslušného súboru - tmpfoo v tomto prípade.

Viac podrobností o súbore pravidiel, vrátane syntaxe položiek, sa budem venovať ďalej v tomto článku. Najprv sa však pozrime na zabezpečenie appletu a porovnajme ho so zabezpečením aplikácie.

Zabezpečenie appletu

Doteraz sme študovali zabezpečenie aplikácií. Väčšina bezpečnostných prvkov je preto prístupná a upraviteľná pomocou príkazového riadku. Poskytovanie adekvátne bezpečnej a napriek tomu trochu flexibilnej politiky v prostredí appletov sa ukazuje ako podstatne náročnejšie. Začneme tým, že sa pozrieme na nasadenie appletu v Appletviewer. Na applety nasadené v prehliadači sa pozrieme neskôr.

Zásadu kódovania Java primárne určuje CodeSource, ktorá obsahuje dve informácie: miesto, z ktorého kód pochádza, a osoba, ktorá ho podpísala.

Appletviewer

Vytvorte súbor s názvom writeFile.html s nasledujúcim obsahom:

  Príklad zabezpečenia Java: Písanie súborov 

Spustenie appletu s nasledujúcim príkazovým riadkom by malo za následok okno zobrazené na obrázku 3:

$ appletviewer writeFile.html 

Všimnite si, že na rozdiel od toho, čo by sa stalo s aplikáciou, applet vygeneroval výnimku, pretože na applet sa predvolene vzťahuje správca bezpečnosti. Inštalácia sa môže v prípade potreby riadiť prispôsobiteľnou politikou. Spustenie nasledujúceho príkazového riadku:

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

by, ako by ste čakali, umožnil úpravu tmpfoo tento súbor bol povolený v súlade so súborom zásad.

Prehliadače

Zabezpečenie appletu v prehľadávačoch sa snaží zabrániť nedôveryhodným appletom vykonávať potenciálne nebezpečné operácie a súčasne umožňovať optimálny prístup k dôveryhodným appletom. Nasadenie zabezpečenia appletu v prehľadávačoch sa podstatne líši od toho, čo sme videli doteraz, hlavne z nasledujúcich dôvodov:

  • Predvolený nedostatok dôvery v kód stiahnutý cez sieť
  • Nedostatočný prístup k možnostiam príkazového riadku na spustenie JVM, pretože JVM je hostený v kontexte prehľadávača
  • Nedostatočná podpora pre niektoré z najnovších bezpečnostných funkcií v JVM dodávaných s prehľadávačmi

Pokiaľ ide o prvý problém, aby sa predišlo možným problémom vyplývajúcim zo spustenia nedôveryhodného kódu, staršie verzie Java používali sandboxový model (pozri „Bočný panel 1: Sandboxový model“). Dôvera je skôr filozofická alebo emocionálna záležitosť ako technická záležitosť; technológia však môže pomôcť. Napríklad kód Java možno podpísať pomocou certifikátov. V tomto príklade podpisovateľ implicitne ručí za kód podpísaním. V konečnom dôsledku je na používateľovi, ktorý kód spustí, dôvera alebo nedôvera podpisujúcej entite, pretože tieto certifikáty zaručujú, že kód bol skutočne podpísaný zamýšľanou osobou alebo organizáciou.

Druhý problém pramení z nedostatočného prístupu k možnostiam spustenia JVM v kontexte prehľadávača. Napríklad neexistuje žiadny jednoduchý spôsob nasadenia a použitia prispôsobených súborov zásad, ako by sme to mohli urobiť v predchádzajúcom príklade. Namiesto toho budú musieť byť tieto pravidlá nastavené súbormi na základe inštalácie JRE. Prispôsobené zavádzače tried alebo správcovia zabezpečenia sa nedajú ľahko nainštalovať.

Tretí problém, nedostatok podpory najnovších verzií JRE v predvolenom prostredí JVM s prehliadačom, sa rieši pomocou doplnku Java (pozri „Bočný panel 2: Java Plug-in Primer“). Podstatným problémom v skutočnosti je, že modifikácia súborov zásad nie je veľmi jednoduchá. Pretože applety môžu byť nasadené na tisícoch alebo dokonca miliónoch klientskych počítačov, môžu existovať prostredia, v ktorých používatelia nemusia dobre rozumieť bezpečnosti alebo nemusia byť oboznámení s metódami úpravy súboru politiky. Doplnok Java poskytuje riešenie, aj keď sa odporúča použiť súbory zásad všade, kde je to praktické a použiteľné.

Ďalej sa podrobnejšie pozrieme na zabezpečenie appletu, ktoré obsahuje príklady podpisovania kódu v prostredí prehliadača s doplnkom Java. Diskusiu obmedzíme na doplnok Java verzie 1.3, pokiaľ nie je výslovne uvedené inak.

Doplnok Java a zabezpečenie

Doplnok Java podporuje štandardnú sadu Java 2 SDK, Standard Edition (J2SE) vrátane bezpečnostného modelu. Všetky applety bežia pod štandardným správcom zabezpečenia appletov, ktorý zabraňuje potenciálne škodlivým appletom vykonávať nebezpečné operácie, napríklad čítať miestne súbory. Applety podpísané RSA je možné nasadiť pomocou doplnku Java. Doplnok Java sa navyše pokúša spúšťať applety rovnakým spôsobom v Netscape Navigator aj Internet Explorer tým, že sa vyhýba prostriedkom špecifickým pre daný prehliadač. To zaisťuje, že applet podpísaný RSA bude bežať rovnako v oboch prehliadačoch s doplnkom Java. Doplnok Java podporuje aj HTTPS, bezpečnú verziu protokolu HTTP.

Aby mohol prehliadač vylepšený pomocou doplnkov dôverovať appletu a udeliť mu všetky privilégiá alebo množinu podrobných povolení (ako je uvedené v súbore politík J2EE), musí používateľ vopred nakonfigurovať svoju vyrovnávaciu pamäť dôveryhodných podpisových certifikátov. (the .kľúčový obchod súbor v JRE 1.3), aby ste doň mohli pridať podpisovateľa appletu. Toto riešenie však nemá dobré škálovanie, ak je potrebné applet nasadiť na tisíce klientskych počítačov, a nemusí byť vždy uskutočniteľné, pretože používatelia nemusia vopred vedieť, kto podpísal applet, ktorý sa pokúšajú spustiť. Staršie verzie doplnku Java tiež podporovali podpisovanie kódu pomocou DSA, ktoré nie je tak rozšírené ako RSA.

Nový nakladač triedy, sun.plugin.security.PluginClassLoader v doplnku Java 1.3 prekonáva vyššie uvedené obmedzenia. Implementuje podporu pre overenie RSA a dynamickú správu dôvery.

Nástroje na vývojovú sadu softvéru (SDK)

Tri nástroje zaoberajúce sa bezpečnosťou, ktoré sú k dispozícii ako súčasť súpravy Java 2 SDK, sú:

  • keytool - Spravuje úložiská kľúčov a certifikáty
  • jarsigner - Generuje a overuje podpisy JAR
  • politický nástroj - Spravuje súbory politík pomocou nástroja založeného na grafickom používateľskom rozhraní

V nasledujúcich častiach sa pozrieme na dôležité možnosti niektorých z týchto nástrojov. Podrobnejšie informácie o konkrétnych nástrojoch nájdete v časti Zdroje.

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