Развитие и концепции за защита на Java, Част 3: Защита на аплета

Ранният растеж на Java беше стимулиран от код за изтегляне в мрежа, по-известен като аплети. Защитата на аплетите се разви с нарастването на Java и днес е източник на често объркване поради разнообразието от версии на Java, предлаганите в търговската мрежа браузъри и приставки.

Тази статия, третата от поредицата, ще обхване различните изисквания за сигурно изпълнение на Java код, изтеглен от мрежа. Въпреки че мобилният код не е революционна концепция, Java и Интернет представляват някои уникални предизвикателства пред компютърната сигурност. Еволюцията на архитектурата на Java и нейното въздействие върху основната защита на Java беше обсъдена в части 1 и 2. Тази статия има различен подход: практически подход за свързване на всички концепции заедно чрез разполагане на прост аплет, който пише в локалната файлова система .

Развитие и концепции за сигурност на Java: Прочетете цялата поредица!

• Част 1: Научете концепции и термини за компютърна сигурност в този уводен преглед
• Част 2: Открийте тънкостите на Java сигурността
• Част 3: Справете се със сигурността на аплета Java
• Част 4: Научете как незадължителните пакети разширяват и подобряват защитата на Java
• Част 5: J2SE 1.4 предлага множество подобрения в защитата на Java

В примерното ядро ​​на аплета е криптографията с публичен ключ, въведена по-рано в тази поредица. Код, подписан с помощта на частния ключ на подписалия, може да се изпълнява на клиентски машини, след като публичният ключ, съответстващ на подписалия се счита за доверен на съответната машина. Ще обсъдим също как файловете с правила, които предоставят разрешения и хранилището на ключове, могат да се използват като хранилище за публични и частни ключове. Освен това ще подчертаем инструментите за защита на Java 2 SDK и Netscape signtool, тъй като те позволяват внедряването.

Тази статия проследява еволюцията на защитата на Java, започвайки със защитата на приложенията в първоначалната версия на Java 2 и преминавайки към последната версия на Java 2, версия 1.3. Този подход помага да се въведат понятията постепенно, като се започне с много прости понятия и завърши с доста напреднал пример.

Тази серия няма за цел да предостави изчерпателно ръководство за компютърна сигурност. Компютърната сигурност е многостранен въпрос, засягащ няколко дисциплини, отдели и култури. Инвестициите в технологии трябва да бъдат последвани от инвестиции в обучение на персонала, стриктно прилагане на политиките и периодичен преглед на цялостната политика за сигурност.

Забележка: Тази статия включва работещ аплет Java, предназначен да демонстрира проблеми със сигурността на аплета. Прочетете по-долу за повече подробности.

Сигурност на приложенията

Нека започнем нашето разследване, като разгледаме сигурността на приложенията. В част 2 видяхме как защитата на Java се е развила от модел на пясъчник до фино модел на защита. Също така видяхме, че приложенията (локален код) по подразбиране получават безплатно управление и не подлежат на същия контрол като аплетите (код за изтегляне от мрежата), които обикновено се считат за ненадеждни. Като промяна от миналото, в Java 2 приложенията за защита могат по избор да бъдат обект на същото ниво на контрол като аплетите.

Първо, кратка бележка за writeFile.javaкода, използван в тази статия за илюстриране на защитните функции в Java 2. Тази програма е леко модифицирана версия на кода на аплета, предоставена от Sun, достъпна в мрежата, за да илюстрира някои от характеристиките на Java 2 сигурност. Програмата, модифицирана за осигуряване на поддръжка на приложения, се опитва да създаде и напише файл в локалната файлова система. Достъпът до локална файлова система се проверява от мениджъра на сигурността. Ще видим в тази статия как тази конкретна операция може да бъде разрешена по сигурен начин.

/ ** * По подразбиране това поражда изключение за защита като аплет. * * С JDK 1.2 appletviewer, * ако конфигурирате вашата система да предоставя аплети, подписани от "Duke" * и изтеглени от уебсайта на Java Software, за да напишете файл * във вашата / tmp директория (или във файла с име "C: \ tmpfoo "на * система Windows), тогава този аплет може да работи. * * @version JDK 1.2 * @author Marianne Mueller * @Modified by Raghavan Srinivas [Rags] * / import java.awt. *; импортиране на java.io. *; импортиране на java.lang. *; импортиране на java.applet. *; публичен клас writeFile разширява аплета {String myFile = "/ tmp / foo"; Файл f = нов файл (myFile); DataOutputStream dos; public void init () {String osname = System.getProperty ("os.name"); ако (osname.indexOf ("Windows")! = -1) {myFile = "C:" + File.separator + "tmpfoo";}} публична невалидна боя (Графика g) {try {dos = new DataOutputStream (new BufferedOutputStream (new FileOutputStream (myFile), 128)); dos.writeBytes ("Котките могат да ви хипнотизират, когато най-малко очаквате \ n"); dos.flush (); dos.close (); g.drawString ("Успешно записах във файла с име" + myFile + "- отидете да го разгледате!", 10, 10); } catch (SecurityException e) {g.drawString ("writeFile: уловено изключение за сигурност", 10, 10); } catch (IOException ioe) {g.drawString ("writeFile: catch i / o изключение", 10, 10); }} public static void main (String args []) {Frame f = new Frame ("writeFile"); writeFile writefile = new writeFile (); writefile.init (); writefile.start (); f.add ("Център", запис на файл); f.setSize (300, 100); f.show (); }}}}}}Котките могат да ви хипнотизират, когато най-малко очаквате \ n "); dos.flush (); dos.close (); g.drawString (" Успешно записах във файла с име "+ myFile +" - погледнете го ! ", 10, 10);} catch (SecurityException e) {g.drawString (" writeFile: уловено изключение за сигурност ", 10, 10);} catch (IOException ioe) {g.drawString (" writeFile: catch i / o изключение ", 10, 10);}} публична статична празнота main (String args []) {Frame f = new Frame (" writeFile "); writeFile writefile = new writeFile (); writefile.init (); writefile.start ( ); f.add ("Център", запис на файл); f.setSize (300, 100); f.show ();}}Котките могат да ви хипнотизират, когато най-малко очаквате \ n "); dos.flush (); dos.close (); g.drawString (" Успешно записах във файла с име "+ myFile +" - погледнете го ! ", 10, 10);} catch (SecurityException e) {g.drawString (" writeFile: уловено изключение за сигурност ", 10, 10);} catch (IOException ioe) {g.drawString (" writeFile: catch i / o изключение ", 10, 10);}} публична статична празнота main (String args []) {Frame f = new Frame (" writeFile "); writeFile writefile = new writeFile (); writefile.init (); writefile.start ( ); f.add ("Център", запис на файл); f.setSize (300, 100); f.show ();}}} catch (SecurityException e) {g.drawString ("writeFile: уловено изключение за сигурност", 10, 10); } catch (IOException ioe) {g.drawString ("writeFile: catch i / o изключение", 10, 10); }} public static void main (String args []) {Frame f = new Frame ("writeFile"); writeFile writefile = new writeFile (); writefile.init (); writefile.start (); f.add ("Център", запис на файл); f.setSize (300, 100); f.show (); }}} catch (SecurityException e) {g.drawString ("writeFile: уловено изключение за сигурност", 10, 10); } catch (IOException ioe) {g.drawString ("writeFile: catch i / o изключение", 10, 10); }} public static void main (String args []) {Frame f = new Frame ("writeFile"); writeFile writefile = new writeFile (); writefile.init (); writefile.start (); f.add ("Център", запис на файл); f.setSize (300, 100); f.show (); }}

Изпълнявайки байт кода, генериран в Java 2 Runtime Environment, Standard Edition (JRE) ще позволи на приложението да модифицира файла в локалната файлова система по подразбиране, тъй като политиката по подразбиране не подлага приложения Java 2 на мениджър на сигурността. Тази политика е оправдана, тъй като приложенията обикновено са локално генериран код и не се изтеглят по мрежата. Следващият команден ред създава прозореца, показан на фигура 1, показващ, че файлът е създаден и записан в.

$ java writeFile 

За да подложите кода на мениджъра за защита на Java 2, извикайте следния команден ред, който трябва да доведе до резултатите, посочени на фигура 2. Забележете, че приложението генерира изключение за защита, причинено от опит за модифициране на локалната файлова система. Изрично включеният мениджър на защитата генерира изключението.

$ java -Djava.security.manager writeFile 

Илюстрираните по-горе случаи представляват екстремни примери за политика на сигурност. В първия случай приложението не е било обект на контрол; в последния беше подложен на много строг контрол. В повечето случаи ще е необходимо да зададете политиката някъде между тях.

Можете да постигнете междуполитика, като използвате файл с политика. За целта създайте файл с правила, извикан all.policyв работната директория:

grant {разрешение java.io.FilePermission "<>", "write"; };

Изпълнението на една и съща част от кода със следния команден ред ще позволи модификация на локалната файлова система:

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

В този пример приложението беше предмет на диспечера на защитата, но цялостната политика се управляваше от файла с политиката, който позволяваше да бъдат модифицирани всички файлове в локалната файлова система. По-строга политика би могла да бъде да се разреши промяна само на съответния файл - tmpfooв този случай.

По-нататък в тази статия ще разгледам повече подробности за файла с правилата, включително синтаксиса на записите. Но първо, нека разгледаме защитата на аплета и да я сравним със защитата на приложенията.

Защита на аплета

Досега проучихме сигурността на приложенията. Като такива, повечето от защитните функции могат да бъдат достъпни и модифицирани чрез командния ред. Предоставянето на адекватно сигурна и все пак донякъде гъвкава политика в аплет среда се оказва значително по-голямо предизвикателство. Ще започнем, като разгледаме разполагането на аплет в Appletviewer. По-късно ще разгледаме приложените в браузъра аплети.

Политиката на Java кода се диктува предимно от CodeSource, която включва две части: мястото, откъдето произхожда кодът и лицето, което го е подписало.

Appletviewer

Създайте файл, наречен writeFile.htmlсъс следното съдържание:

  Пример за защита на Java: Писане на файлове 
   

   
    

    
Running the applet with the following command line would result in the window shown in Figure 3:
    
$ appletviewer writeFile.html 
    
Notice that -- in contrast to what would happen with an application -- the applet generated an exception since the applet is subject to the security manager by default. The installation can be governed by a customizable policy, if required. Running the following command line:
    
appletviewer -J"-Djava.security.policy=all.policy" writeFile.html 
    
would, as you might expect, allow modification of the tmpfoo file, since this was permitted in accordance with the policy file.
    
Browsers
    
Applet security in browsers strives to prevent untrusted applets from performing potentially dangerous operations, while simultaneously allowing optimal access to trusted applets. Applet security deployment in browsers is substantially different from what we have seen so far, primarily due to the following reasons:
    

     
A default lack of trust in code downloaded over the network
     
Insufficient access to the command-line options for running the JVM, since the JVM is hosted in the context of a browser
     
Inadequate support for some of the latest security features in the JVMs bundled with browsers
    
    
As for the first problem, to obviate the potential problems resulting from running untrusted code, earlier versions of Java used the sandbox model (see "Sidebar 1: Sandbox Model"). Trust is a largely philosophical or emotional issue, rather than a technical issue; however, technology can help. For example, Java code can be signed using certificates. In this example, the signer implicitly vouches for the code by signing it. The onus is ultimately upon the user running the code to trust the signing entity or not, given that these certificates guarantee that the code was indeed signed by the intended person or organization.
    
The second problem stems from the lack of access to the options for running the JVM in the browser context. For example, there is no simple way to deploy and use customized policy files as we could in the previous example. Instead, such policies will have to be set by files based on the JRE installation. Customized class loaders or security managers cannot be installed easily.
    
The third problem, the lack of support for the latest versions of the JRE in the default JVM with the browser, is solved by using the Java plug-in (see "Sidebar 2: Java Plug-in Primer"). Indeed, an underlying issue is that modification of policy files is not very straightforward. Since applets may be deployed on thousands or even millions of client machines, there might be environments where users might not have a good understanding of security or may not be acquainted with methods for modifying the policy file. The Java plug-in provides a workaround, although it's recommended to use policy files wherever practical and applicable.
    
Next, we'll look in more detail at applet security involving code-signing examples in a browser environment with a Java plug-in. We will confine the discussion to Java plug-in version 1.3 unless explicitly stated otherwise.
    
The Java plug-in and security
    
The Java plug-in supports the standard Java 2 SDK, Standard Edition (J2SE), including the security model. All applets run under the standard applet security manager, which prevents potentially malicious applets from performing dangerous operations, such as reading local files. RSA-signed applets can be deployed using the Java plug-in. Additionally, the Java plug-in attempts to run applets in an identical way in both Netscape Navigator and Internet Explorer by avoiding browser-specific resources. This ensures that an RSA-signed applet will run identically in both browsers with the Java plug-in. The Java plug-in also supports HTTPS, a secure version of HTTP.
    
In order for a plug-in-enhanced browser to trust an applet and grant it all privileges or a set of fine-grained permissions (as specified in a J2EE policy file), the user has to preconfigure his or her cache of trusted signer certificates (the .keystore file in JRE 1.3) to add the applet's signer to it. However, this solution does not scale well if the applet needs to be deployed on thousands of client machines, and may not always be feasible because users may not know in advance who signed the applet that they are trying to run. Also, earlier versions of the Java plug-in supported code signing using DSA, which is not as widely prevalent as RSA.
    
A new class loader, sun.plugin.security.PluginClassLoader in the Java plug-in 1.3, overcomes the limitations mentioned above. It implements support for RSA verification and dynamic trust management.
    
The Software Development Kit (SDK) tools
    
The three tools dealing with security, available as part of the Java 2 SDK, are:
    

     
keytool -- Manages keystores and certificates
     
jarsigner -- Generates and verifies JAR signatures
     
policytool -- Manages policy files via a GUI-based tool
    
    
We will look at some of these tools' important options in the sections below. Refer to Resources for more detailed documentation associated with particular tools.

    
	

	
	

	




    
може да ви хареса също

    

                    

                

                    
                                            
                

                

                    
                        
   Защо технологията iBeacons на Apple не е отишла никъде
                   
                

               
            

                

                    
                                            
                

                

                    
                        
   10 прогнози за разработка на софтуер за 2018 г.
                   
                

               
            

                

                    
                                            
                

                

                    
                        
   Социалната мрежа App.net за изключване, платформата с отворен код