Počáteční růst Javy byl urychlen kódem stahovatelným přes síť, lépe známý jako applety. Zabezpečení appletů se vyvinulo s růstem prostředí Java a dnes je zdrojem častých nejasností kvůli rozmanitosti verzí Java, komerčně dostupných prohlížečů a zásuvných modulů.
Tento článek, třetí v řadě, pojednává o různých požadavcích na bezpečně spuštěný kód Java stažený ze sítě. Ačkoli mobilní kód není revolučním konceptem, Java a internet představují některé jedinečné výzvy pro počítačovou bezpečnost. Vývoj architektury Java a její dopad na základní zabezpečení Javy byl popsán v částech 1 a 2. Tento článek má jiný směr: praktický přístup k propojení všech konceptů nasazením jednoduchého appletu, který zapisuje do místního souborového systému .
Vývoj a koncepce zabezpečení Java: Přečtěte si celou sérii!
- Část 1: Naučte se koncepty a pojmy zabezpečení počítače v tomto úvodním přehledu
- Část 2: Objevte zápletky zabezpečení Java
- Část 3: Spolehlivě řešte zabezpečení Java appletu
- Část 4: Zjistěte, jak volitelné balíčky rozšiřují a zvyšují zabezpečení Java
- Část 5: J2SE 1.4 nabízí řadu vylepšení zabezpečení Java
V příkladu je jádrem appletu kryptografie s veřejným klíčem, představená dříve v této sérii. Kód podepsaný pomocí soukromého klíče podepisujícího lze spustit na klientských počítačích, jakmile je veřejný klíč odpovídající podepisujícímu považován za důvěryhodný na příslušném počítači. Budeme také diskutovat o tom, jak lze soubory zásad, které udělují oprávnění a úložiště klíčů, použít jako úložiště pro veřejné a soukromé klíče. Kromě toho zdůrazníme bezpečnostní nástroje Java 2 SDK a nástroje Netscape signtool, protože umožňují nasazení.
Tento článek sleduje vývoj zabezpečení Java, počínaje zabezpečením aplikací v počátečním vydání prostředí Java 2 a přechodem na nejnovější verzi prostředí Java 2, verze 1.3. Tento přístup pomáhá zavádět koncepty postupně, počínaje velmi jednoduchými koncepty a vrcholící v poměrně pokročilém příkladu.
Tato série nemá v úmyslu poskytnout komplexního průvodce po zabezpečení počítače. Počítačová bezpečnost je mnohostranný problém, který se dotýká několika oborů, oddělení a kultur. Po investicích do technologií by měly následovat investice do školení personálu, přísného prosazování zásad a pravidelného přezkumu celkové bezpečnostní politiky.
Poznámka: Tento článek obsahuje spuštěný applet Java navržený k prokázání problémů se zabezpečením appletu. Přečtěte si níže další podrobnosti.
Zabezpečení aplikací
Začněme naše vyšetřování pohledem na zabezpečení aplikací. V části 2 jsme viděli, jak se zabezpečení Java vyvinulo z modelu izolovaného prostoru na jemně zrnitý model zabezpečení. Viděli jsme také, že aplikace (místní kód) ve výchozím nastavení získávají bezplatné vládnutí a nepodléhají stejné kontrole jako applety (kód ke stažení do sítě), které jsou obvykle považovány za nedůvěryhodné. Při změně z minulosti mohou být bezpečnostní aplikace v Javě 2 volitelně podrobeny stejné úrovni kontroly jako applety.
Nejprve krátká poznámka o writeFile.java, kód použitý v tomto článku k ilustraci funkcí zabezpečení v prostředí Java 2. Tento program je mírně upravenou verzí kódu appletu poskytovaného společností Sun, která je k dispozici na webu a ilustruje některé funkce zabezpečení prostředí Java 2. Program upravený tak, aby poskytoval podporu aplikací, se pokouší vytvořit a zapsat soubor do místního souborového systému. Správce zabezpečení prověřuje přístup k místnímu souborovému systému. V tomto článku uvidíme, jak lze bezpečně povolit tuto konkrétní operaci.
/ ** * Ve výchozím nastavení to vyvolá bezpečnostní výjimku jako applet. * * S appletviewerem JDK 1.2, * pokud nakonfigurujete svůj systém tak, aby poskytoval applety podepsané „Duke“ * a stažené z webových stránek Java Software pro zápis souboru * do vašeho adresáře / tmp (nebo do souboru s názvem „C: \ tmpfoo“ "v systému * Windows), pak lze tento applet spustit. * * @version JDK 1.2 * @author Marianne Mueller * @Modified by Raghavan Srinivas [Rags] * / import java.awt. *; importovat java.io. *; import java.lang. *; import java.applet. *; public class writeFile rozšiřuje Applet {String myFile = "/ tmp / foo"; Soubor f = nový soubor (myFile); DataOutputStream dos; public void init () {String osname = System.getProperty ("os.name"); if (osname.indexOf ("Windows")! = -1) {myFile = "C:" + File.separator + "tmpfoo"; }} public void paint (Graphics g) {try {dos = new DataOutputStream (new BufferedOutputStream (new FileOutputStream (myFile), 128)); dos.writeBytes ("Kočky vás mohou hypnotizovat, když to nejméně očekáváte \ n"); dos.flush (); dos.close (); g.drawString ("Úspěšně zapsáno do souboru s názvem" + myFile + "- jděte se na to podívat!", 10, 10); } catch (SecurityException e) {g.drawString ("writeFile: chycená bezpečnostní výjimka", 10, 10); } catch (IOException ioe) {g.drawString ("writeFile: chycen výjimka I / O", 10, 10); }} public static void main (String args []) {Frame f = new Frame ("writeFile"); writeFile writefile = nový writeFile (); writefile.init (); writefile.start (); f.add ("Center", writefile); f. setSize (300, 100); f.show (); }} Spuštění bytecode generovaného v prostředí Java 2 Runtime Environment, Standard Edition (JRE) umožní aplikaci ve výchozím nastavení upravit soubor v místním souborovém systému, protože výchozí zásada nepodléhá aplikacím Java 2 správci zabezpečení. Tato zásada je oprávněná, protože aplikace jsou obvykle lokálně generovaný kód a nejsou stahovány přes síť. Následující příkazový řádek vytváří okno zobrazené na obrázku 1, což naznačuje, že soubor byl vytvořen a zapsán do něj.
$ java writeFile
Chcete-li podrobit kód správci zabezpečení Java 2, vyvolejte následující příkazový řádek, který by měl přinést výsledky uvedené na obrázku 2. Všimněte si, že aplikace vygenerovala bezpečnostní výjimku způsobenou pokusem o úpravu místního souborového systému. Explicitně zahrnutý správce zabezpečení vygeneroval výjimku.
$ java -Djava.security.manager writeFile
Výše uvedené případy představují extrémní příklady bezpečnostní politiky. V prvním případě aplikace nepodléhala žádné kontrole; ve druhém případě to podléhalo velmi přísné kontrole. Ve většině případů bude nutné zásady nastavit někde mezi nimi.
Mezilehlou zásadu můžete provést pomocí souboru zásad. Chcete-li tak učinit, vytvořte soubor zásad s názvem vše. politika v pracovním adresáři:
udělit {oprávnění java.io.FilePermission "<>", "write"; }; Spuštění stejné části kódu s následujícím příkazovým řádkem umožní úpravu lokálního souborového systému:
$ java -Djava.security.manager -Djava.security.policy = all.policy writeFile
V tomto příkladu aplikace podléhala správci zabezpečení, ale celková zásada se řídila souborem zásad, který umožňoval Všechno soubory v místním souborovém systému, které mají být upraveny. Přísnější zásadou mohlo být umožnění úpravy pouze příslušného souboru - tmpfoo v tomto případě.
Podrobněji o souboru zásad, včetně syntaxe položek, se budu zabývat dále v tomto článku. Nejprve se ale podívejme na zabezpečení appletu a porovnejme jej se zabezpečením aplikace.
Zabezpečení appletu
Dosud jsme studovali zabezpečení aplikací. Většinu bezpečnostních funkcí lze tedy zpřístupnit a upravit pomocí příkazového řádku. Poskytování adekvátně zabezpečené a přesto poněkud pružné politiky v prostředí appletu se ukazuje jako podstatně náročnější. Začneme tím, že se podíváme na rozmístění appletu v Prohlížeč aplikací. Na applety nasazené v prohlížeči se podíváme později.
Zásady Java kódu jsou primárně diktovány Zdroj kódu, který obsahuje dvě informace: místo, kde kód vznikl, a osoba, která jej podepsala.
Prohlížeč aplikací
Vytvořte soubor s názvem writeFile.html s následujícím obsahem:
Příklad zabezpečení Java: Zápis souborů
Spuštění appletu s následujícím příkazovým řádkem by mělo za následek okno zobrazené na obrázku 3:
$ appletviewer writeFile.html
Všimněte si, že - na rozdíl od toho, co by se stalo s aplikací - applet vygeneroval výjimku, protože applet je ve výchozím nastavení předmětem správce zabezpečení. Instalaci lze v případě potřeby řídit přizpůsobitelnými zásadami. Spuštění následujícího příkazového řádku:
appletviewer -J "-Djava.security.policy = all.policy" writeFile.html
by, jak byste mohli očekávat, umožnil úpravu tmpfoo soubor, protože to bylo povoleno v souladu se souborem zásad.
Prohlížeče
Zabezpečení appletů v prohlížečích se snaží zabránit nedůvěryhodným appletům v provádění potenciálně nebezpečných operací a současně umožňuje optimální přístup k důvěryhodným appletům. Nasazení zabezpečení appletů v prohlížečích se podstatně liší od toho, co jsme dosud viděli, a to především z následujících důvodů:
- Výchozí nedostatek důvěry v kód stažený přes síť
- Nedostatečný přístup k možnostem příkazového řádku pro spuštění JVM, protože JVM je hostován v kontextu prohlížeče
- Nedostatečná podpora pro některé z nejnovějších bezpečnostních funkcí v JVM dodávaných s prohlížeči
Pokud jde o první problém, aby se předešlo možným problémům vyplývajícím ze spuštění nedůvěryhodného kódu, dřívější verze prostředí Java používaly sandboxový model (viz „Postranní panel 1: Sandboxový model“). Důvěra je spíše filozofický nebo emocionální problém než technická záležitost; technologie však může pomoci. Například kód Java lze podepsat pomocí certifikátů. V tomto příkladu podpisovatel implicitně ručí za kód jeho podepsáním. Břemeno je nakonec na uživateli, který kód spouští, aby důvěřoval podepisující entitě, nebo ne, vzhledem k tomu, že tyto certifikáty zaručují, že kód byl skutečně podepsán zamýšlenou osobou nebo organizací.
Druhý problém pramení z nedostatečného přístupu k možnostem spuštění JVM v kontextu prohlížeče. Například neexistuje žádný jednoduchý způsob, jak nasadit a používat přizpůsobené soubory zásad, jak bychom mohli v předchozím příkladu. Místo toho budou takové zásady muset nastavit soubory založené na instalaci JRE. Přizpůsobené zavaděče tříd nebo správce zabezpečení nelze snadno nainstalovat.
Třetí problém, nedostatek podpory nejnovějších verzí prostředí JRE ve výchozím prostředí JVM s prohlížečem, je vyřešen pomocí modulu plug-in Java (viz „Postranní panel 2: Java Plug-in Primer“). Skutečným základním problémem je, že úprava souborů zásad není příliš přímočará. Vzhledem k tomu, že applety mohou být nasazeny na tisíce nebo dokonce miliony klientských počítačů, mohou existovat prostředí, kde uživatelé nemusí dobře rozumět zabezpečení nebo nemusí být seznámeni s metodami úpravy souboru zásad. Zásuvný modul Java poskytuje alternativní řešení, ačkoli se doporučuje používat soubory zásad, kdekoli je to možné a použitelné.
Dále se podrobněji podíváme na zabezpečení appletu zahrnující příklady podepisování kódu v prostředí prohlížeče s modulem plug-in Java. Diskuse se omezí na zásuvný modul Java verze 1.3, pokud není výslovně uvedeno jinak.
Plug-in a zabezpečení Java
Modul plug-in Java podporuje standardní sadu Java 2 SDK, Standard Edition (J2SE), včetně bezpečnostního modelu. Všechny applety běží pod standardním správcem zabezpečení appletů, což zabraňuje potenciálně škodlivým appletům provádět nebezpečné operace, jako je čtení místních souborů. Applety podepsané RSA lze nasadit pomocí modulu plug-in Java. Modul plug-in Java se navíc pokouší spouštět applety stejným způsobem v Netscape Navigator i Internet Explorer tím, že se vyhýbá prostředkům specifickým pro daný prohlížeč. Tím je zajištěno, že applet podepsaný RSA poběží shodně v obou prohlížečích s modulem plug-in Java. Modul plug-in Java podporuje také HTTPS, zabezpečenou verzi protokolu HTTP.
Aby mohl prohlížeč vylepšený pomocí zásuvných modulů důvěřovat appletu a udělit mu všechna oprávnění nebo sadu podrobných oprávnění (jak je uvedeno v souboru zásad J2EE), musí uživatel předem nakonfigurovat mezipaměť důvěryhodných podpisových certifikátů. (dále jen obchod s klíči soubor v JRE 1.3) a přidejte k němu signatáře appletu. Toto řešení se však dobře nemění, pokud je třeba applet nasadit na tisíce klientských počítačů, a nemusí být vždy proveditelné, protože uživatelé nemusí předem vědět, kdo podepsal applet, který se pokouší spustit. Také dřívější verze modulu plug-in Java podporovaly podepisování kódu pomocí DSA, které není tak rozšířené jako RSA.
Nový třídní nakladač, sun.plugin.security.PluginClassLoader v modulu plug-in Java 1.3 překonává výše uvedená omezení. Implementuje podporu pro ověřování RSA a dynamickou správu důvěryhodnosti.
Nástroje pro vývoj softwaru (SDK)
Tři nástroje zabývající se zabezpečením, které jsou k dispozici jako součást sady Java 2 SDK, jsou:
klíčový nástroj- Spravuje úložiště klíčů a certifikátyjarsigner- Generuje a ověřuje podpisy JARpolitický nástroj- Spravuje soubory zásad pomocí nástroje založeného na grafickém uživatelském rozhraní
V následujících částech se podíváme na důležité možnosti některých těchto nástrojů. Podrobnější dokumentace související s konkrétními nástroji najdete v části Zdroje.
