Java体系l构
Java的体pȝ构如下图所C，首先Java的源代码Java文gq译器~译成Java的二q制字节码class文gQ然后class文g? Java虚拟Z的类装蝲器进行加载，同时c装载器q(sh)(x)加蝲Java的原?nbsp;API Class文gQ类加蝲器主要负责加载、连接和初始化这些class 文g以后Q就交给虚拟Z的执行引擎运行，执行引擎class文g中的Java指o(h)解释成具体的本地操作pȝҎ(gu)来执?而安全管理器在执行q程中根 据设|的安全{略控制指o(h)对外部资源的讉K?br />
Java的执行方式不是编译执行而是解释执行Q不同^C面相同的源代码编译成W合Java规范的相同的二进制字节码Q然后再交给支持各自q_的虚? 机去解释执行Q?先编译，后解释，再执?三步走的方式使得Java实现?一ơ编写，到处q行"Q如果Java应用使用的是100Q标? Java APIq且没有直接调用本地Ҏ(gu)Q那可以不加修改地q用在多U^CQ这L(fng)q_无关性得在异构的网l环境或者嵌入式斚w的应用更方便和现 实。Java的网l移动性带来了(jin)一U全新的软g模式Q在分布式处理模式的基础之上Q可以将软g和数据通过|络传送到客户端去Q这L(fng)保了(jin)客户端有必备的Y 件来览和操U通过|络传输的数据，Java体系l构支持把单一的执行文件切割成的二进制字节码文gClass文gQ而这些文件可以按照应用的需要动? q接、动态扩展。Java体系l构对安全性的支持主要是通过Java语言本n安全性、虚拟机的类加蝲器和安全理器以?qing)Java提供的安全API几个斚w 来实玎ͼ(x)防止恶意E序的攻击，E序不能破坏用户计算机环境；防止入RQ程序不能获取主机或所在内|的保密信息Q鉴别，验证E序提供者和使用者的w䆾Q加 密，对传输交换的数据q行加密Q或者给持久化的数据q行加密Q验?Ҏ(gu)作设|规则ƈ且进行验证?br />
Java信息安全的必要?br />
随着互联|应用越来越q泛Qƈ且互联网其本w独特的资源׃n性，因此能够按照用户需求及(qing)时准获得信息和处理信息的应用对用户而言q当重要，q也? Java得以q速发展和被广泛接受的原因。但同时|络也提供了(jin)一条攻?yn)L入计机的潜在途径Q特别是当用户下载网lY件在本地q行Q这p求Java能够 对病?木马的问题加以防范，对信息以?qing)本地环境进行保护。比如我们浏览一个网늚时候，|页上的Applet可能?x)自动下载ƈ且运行，而这? Applet完全有可能来自不可靠的地方，又或者我们用通过JINI服务查找到的|络上不可靠的服务对象来获得服务Q如果没有Java体系l构提供的安 全机Ӟq就很有可能引入?jin)一个怀有敌意的E序造成信息丢失、资料泄密、相信伪造数据和修改本地计算机安全设|等{后果，带来未知的严重后果?br />
Java语言本n安全?br />
Java语言的设计者们是在C++的基上设计出来Java的，因此与C++相比它的语法更加单清晎ͼl构、单元、运符重蝲、虚拟基cȝ? Java中都没有采用Qƈ且取消了(jin)多重l承而采用实现多个接口的方式。这栯降低开发h员犯错误的几率，帮助他们写出更安全的代码?nbsp;
Java中去除了(jin)C++语言中的令h费解、容易出错的"指针"Q用列表、堆、哈希表{结构来代替Q避免了(jin)M不安全的l构。Java也没有烦(ch)引核查的 数组讉KQ因往(xin)往(xin)?x)导致不定的、不可预的E序操作Q它所有的数组讉K都必d(g)查是否越界。Java要求所有的变量在初始化以前不能使用Q对于基? 数据cd变量都会(x)自动地赋l某个初始|避免?jin)未初始化变量获取内存?sh)息。所有这些都使得E序不能讉KL的内存地址Q对于内存(sh)的实体信息只能通过有权 限的对象q行讉KQ而不?x)出现象C++那样把类型指针强制{换成内存的指针，然后通过内存查找的方法找到私有的变量?br />
Java分配内存对于开发h员来说是透明的，开发h员(sh)用newҎ(gu)新徏对象,q时候虚拟机׃(x)从堆内存?sh)找到合适的内存I间Q开发h员(sh)需要也不能 够进行干预。而对于内存的回收QJava避免?jin)开发h员明干预对象的回收Q比如C的free或C++的delete命o(h)Q避免了(jin)开发h员无意间对内存的 破坏。Java采用虚拟机的"垃圾回收"机制来实现的内存自动理Q释放不再被使用的内存资源，内存回收器就像一台垃圾收集RQ但是和我们在大街上看到? 攉车，仅仅攉大家攑֜垃圾桉面的垃圾不同的是Q它q要C安d你找出那些东西是不要用的垃圾Q然后把q些东西拿走Q最后还要整理家里的I间Q腾 出最大的I间让你放新东西。Java的内存回收器目的是扑ֈ不再引用的对象，释放内存I间Qƈ且需要整理内存的片I间Q尽量避免出?内存?sh)?的情 c(din)?br />
对于在网l中交换的序列化对象很容易在重徏对象的时候访问到对象的私有信息，q时候Java提供?jin)两U办法来保护信息Q一U就是采用给变量加上 transient关键字的Ҏ(gu)Q这样对象序列化的时候就不会(x)d该变量，另一U就是在实现Externalizable接口而不? Serizlizable接口Q这样对象就只能通过writeExternal和readExternalҎ(gu)来保存和重徏Q其他方法无法进行了(jin)?nbsp;
以上q些都是Java语言本n对信息安全提供的基础?br />
cd载器
虽然名字叫类加蝲器，但是实际上Java虚拟Z的类加蝲器不光要负责加蝲而且要负责连接和初始化应用程序需要用到的Javacd。加载就是把二进? 形式的字节码d虚拟ZQ而连接就是给q个已经d的类型分配类变量内存?sh)?qing)把类型中用到帔R池中的符可{换ؓ(f)直接引用Q最后的初始化过E就是赋l类? 变量合适的初始倹{?br />
cd载器为加载的cL供了(jin)不同的命名空_(d)l一源代码生成的字节码被加蝲到同一个命名空间中Q相同命名空间不能加载类名相同的c，同一个命名空间内? cd以直接进行交互，而不同的命名I间的类是不能交互的Q除非显式地提供?jin)交互机Ӟ通过命名I间和类成员讉K权限的设|保护了(jin)被信ȝc边界?br />
cd载器分成?jin)启动类加蝲器、标准扩展类加蝲器、\径类加蝲器和|络cd载器四种。启动类加蝲器从本地pȝ中加载原始的Java APIc，用来启动 Java虚拟机，而其他三U加载器是在q行时加载用户定义的c，标准扩展cd载器加蝲的是不同虚拟机提供商扩展的标准Javac，而在classpath 中的cȝ路径cd载器来加载，|络cd载器加蝲通过|络下蝲得到的类文gQ每一U加载器在加载类的时候都?x)徏立一个加载器实例。类加蝲器采用双亲委zN? 式（q个模式很类似GOF在《设计模式》一书中提到的责任链模式Q除?jin)启动类加蝲器以外，每个cd载器都有自己?双亲"。一个类可以通过有三U方法定? 自己的双Ԍ(x)W一U通过引用Q比如AcM引用?jin)Bc（即A和B有关联关p）(j)Q那么Bcȝ加蝲器就?x)作为Acȝ加蝲器的"双亲"Q早于Acd载；W二U? loadClassҎ(gu)来自定义"双亲"Q这时被load的类?双亲"x(chng)w这个类加蝲器；W三U在没有采用前两U的情况下用的默认方式Q默认把启动 cd载器作ؓ(f)"双亲"?br />
在加载过E中Q当发出加蝲h的时候，加蝲器首先询问它?双亲"――\径类加蝲器――来查找q加载这个类Q而这个加载器也向它的"双亲"h加蝲Q? 一层一层请求上去，直到启动加蝲器获得请求，来查扑ƈ加蝲q个c，如果q个cL有被加蝲q且查找不到Q返回结果给它的子加载器Q由子加载器加蝲Q直到请? q回l原来的加蝲器，q时q没有加载成功的话，ql类加蝲器试图从|络中寻扑ƈ下蝲Q如果还?sh)成功将抛出NoClassDefFoundError? 常?br />
q个q程保证?jin)启动类加蝲器可以抢在标准扩展类加蝲器之前加载类Q而标准扩展类加蝲器又可以抢在路径cd载器之前加蝲c，最后才ql类加蝲器加载? 比如应用被试囑֊载一个带有恶意代码的java.lang.Stringc，因ؓ(f)它本来是Java API的一部分Q它们加载到的命名空间可以得到被信Q cȝҎ(gu)讉K权限Q但是由于启动类加蝲器是最早被加蝲的，所以java.lang.String只会(x)被启动类从Java原始的API中加载，而带有恶意代 码的java.lang.StringcM?x)被加蝲q来Q这h效的保护?jin)被信Q的类边界?br />
cd载器中还包括?jin)一个类型检查的功能模块Q它负责保证E序的健壮性，它在cd的生命周期中要进行四ơ检查。第一ơ检查是在加载的时候，主要(g)查二q? 制字节码的结构，首先格式要满Java语言定义的规范，然后要保证将要加载的cd节码是一l合法的Java指o(h)。第二次(g)查是在连接的时候，主要是类? 数据的语义检查，保证字节码在~译时候遵守了(jin)规范Q比如对finalcM?x)派生出子类Q也不会(x)重蝲final的方法；每个cd有一个超c；没有把基本数? cd强制转换成其他数据类型。第三次(g)查也是在q接的时候，x(chng)于指令的l构Q保证指令的操作数类型和值正，操作数堆栈不?x)出C溢出或者下溢出。最? 一ơ检查在动态连接的时候，主要(g)查类型中的符号引用被解析时是否正。以上的问题都会(x)产生恶意的行为所以必dq行前进行检查，而一部分(g)查工作会(x)在虚 拟机q行字节码的时候检查，比如数组界Q对象类型的转换{等Q一旦检查发C(jin)问题׃(x)抛出异常Q得程序不被执行?nbsp;
cd载器避免?jin)出现某些怀有敌意的人编写自qJavac，而这些类Ҏ(gu)中含有蟩转到Ҏ(gu)之外的指令，D虚拟机的崩溃和保密信息被获取的可能，保证 ?jin)程序的健壮性，也不?x)出现替代原有Java APIcȝ恶意代码被运行的情况Qƈ且类加蝲器防止了(jin)恶意代码d涉善意的代码Q守护了(jin)被信ȝAPIcd 边界Q确保了(jin)代码可以q行的操作?br />
安全理?br />
安全理器ؓ(f)Java虚拟机的环境建立?jin)一个vC护作用的"沙箱"Q这?沙箱"为程序提供了(jin)一个限制了(jin)应用的操作运行环境，保护?jin)虚拟机外部的? 源不?x)被虚拟机内部的恶意代码破坏。安全管理器的安全策略可以灵zȝ建立l粒度的讉K控制{略Q将不同的资源访问权限授予不同的代码单元Q这也是Java 体系l构安全模型的最大特点和优势之一?br />
首先在赋予权限前我们要明代码单元的来源Q签名担保可以用户认文g的来源，q且q些文g在本地虚拟机加蝲前没有被修改Q只有保证了(jin)源代码来源的 可靠性，才能分配相应的操作权限。对class文g或者jar文g的签名可以用jdk中的jarsignerq个工具。它首先Ҏ(gu)据文件内容进行单向散? 计算Q生一个散列|然后把这个散列加到文件后面作为文件的一部分传递给用户Q用h到文件后重新生成一ơ散列|然后跟文件后部的散列D行比较，? 果这两个散列值相同说明文件内Ҏ(gu)有被改动Q虽然不同的文g内容可能生成相同的散列|但是一般Java采用的是124位散列，q个长度惌从一个不同的 输入产生一个已知散列值的计算是不可行的。仅仅通过散列值是没有办法保证代码的来源的Q因为怀有恶意的人完全可以把整个文g和散列值都替换掉，Z(jin)防止q? U事情发生，必须在发送前用私钥对散列D行加密，Z么不Ҏ(gu)个文件进行加密呢Q因为jarsigner默认采用的是DES法Q加密本w也是一个费? 的过E，我们的目的只是ؓ(f)?jin)保证文件的来源而不是文件本w的保密性，所以只需要对散列D行加密，用户收到文g以后用文件提供者的公钥q行解密来验证散? 值没有被替换?nbsp;
明确?jin)代码来源，q且保证没有被修改以后，可以给它分配操作权限。安全策略是一个java.sercurity.Policy的实? c，Policy中主要包含了(jin)代码来源和相应的权限的对应关pM息，安全理器的checkҎ(gu)根据Policy对象判断l导入的代码赋予什么样的操? 权限。代码来源是由java.security.CodeSource表示的，q个对象中包含了(jin)一lCertificate对象Q说明了(jin)个代码文件担 保的{。而权限是用java.sercurity.Permission的子cd例来表示的，每一个Permission有三个属性：(x)cd、名U和可进 行的操作Q类型说明了(jin)权限控制的资源类型，比如FilePermission说明?jin)是?gu)件操作的权限Q名U说明了(jin)q个权限控制的对象，比如 FilePermission的名UCؓ(f)"/mydoc/order.txt",说明?jin)对文gorder.txt的操作权限，可进行的操作属性说明了(jin)q个? 限可以进行的操作Q比?read"说明q个FilePermission可以对order.txtq行L作?br />
开发h员可以通过~写代码l承SecurityManagercd立自q安全理器来讄安全{略Q更方便和常用的Ҏ(gu)是通过讄{略文g来实现? q是一个策略文件的例子Q?br />
//从mykeys文g中获得签名的公钥
keystore "mykeys"
//由father{的代码赋予读order.txt文g的权?br /> grant signedBy "father"{
permission java.io.FilePermission "order.txt","read";
}
//来自{Java_Home}/security/ex/目录下面的所有jar文g和class文g有读写order.txt文g的权?br /> grant codeBase "file:${Java_Home}/security/ex/*"{
permission java.io.FilePermission "order.txt","read,write";
}
//来自{Java_Home}/security/ex/目录下面的带有wife{的所有jar文g和class文g有接受、连接和监听8080端口 的权?br /> grant signedBy "wife" codeBase "file:${Java_Home}/security/ex/*"{
permission java.io.SocketPermission "*:8080","accept,connect,listen";
}
//所有代码都有读写appversion.properties文g的权?br /> grant {
permission java.io.FilePermission "appversion.properties","read,write";
}
如果一个应用程序没有指定启动安全管理器q行q预Q它的所有操作不?x)受到管理器的限Ӟ指定启动安全理器有两种方式Q一U是在运行应用程序的时候指 定，一U是在代码中指定?br />
java -Djava.serciruty.manager myapplication
q里指定?jin)启动默认安全管理器Q这时候将Ҏ(gu)Java默认的全局{略文g来设|安全策略，q个文g?br />
/JAVA_HOME/lib/security/java.policy?br /> java -Djava.serciruty.manager QDjava.serciruty.policyQ?nbsp;myapplication
q里启动安全理器，除了(jin)默认的全局{略文g外，也会(x)按照Djava.serciruty.policy参数指定的策略文件来讄安全{略Q文件指? 可以用URL也可以直接用文g名称?br />
如果是在代码中指定，E序通过setSecurityManagerҎ(gu)讄一个java.lang.SecurityManager的实例时候，q? 时候安全管理器׃(x)开始控制应用程度的操作?jin)。这时当cd载器加蝲cd虚拟机的时候，安全理器根据代码来源和{扑ֈ相应的权限，然后建立q个cȝ保护 域ProtectionDomainQ保护域定义?jin)这个类所有的权限。当应用E序用到q个cdƈ要进行Q何可能的不安全操作时Q都?x)向安全理器请求操作? 可，安全理器中有一pd的checkҎ(gu)来检查操作是否可行，比如checkReadҎ(gu)?x)检查是否能够读取某个文ӞcheckWriteҎ(gu)(g)查是 否能够写入某个文Ӟ理器根据操作请求类型调用相关的checkҎ(gu)QcheckҎ(gu)Ҏ(gu)cȝ保护域判断操作是否可行，如果操作没有权限的话抛Z? 异常Q操作收到这个异常后不能执行，如果操作可行的话QcheckҎ(gu)顺利返回，操作l箋(hu)执行?br />
以上{验证、定义安全策略以?qing)安全管理器(g)查操作权限一pdq程Q有效的保护?jin)被Java应用使用的外部资源的安全性。要注意的是而由启动cd载器 加蝲的核?j)APIcL不受q个安全理器的权限控制Q这也是Z么要用类加蝲器防止核?j)API被恶意代码替换的原因?br />
Java体系l构提供的安全API
Java体系l构提供?jin)三cM要的安全APIQJava 认证和授权服? QJava Authentication and Authorization ServiceQJAASQ、Java 安全套接字扩? QJava Secure Socket ExtensionQJSSEQ和 Java 加密扩展 QJava Cryptography ExtensionQJCEQ。前面已l提C(jin)安全理器中用到的JAASQ这一节我们提到的是API主要? Java提供的对信息q行加密的Java加密扩展包JCE和Java安全套接字扩展包JSSE, q些API提供?jin)加密算法可以按照我们的需要，实现对Q 意数据的加密和解密?br />
Java加密扩展包JCE提供的是Z密钥的加密，它通过javax.crypto.CiphercL实现数据加密合解密，加密解密的对象可以ɽE序 中的数组对象Q也可以是通过Java接口读出或者写入的数据。用Ciphercd密可以选择多种加密法、加密模式和填补机制。加密算法JCE中提? ?jin)DES、多重DES、PBEWithMD5AndDES、RSA和Blowfish{等。DES是很多机构组l采用的数据加密标准Q而多重DES使用? 个DES密码q行多长DES加密Q加大了(jin)d的难度但是也增加?jin)加密解密过E说q旉QPBEWithMD5AndDES前面提到q，主要是计散列， 然后Ҏ(gu)列进行DES加密Q来实现{认证QRSA法?978q公布的一U分l加密算法，也是现在应用得最q泛的公钥密钥算法；Blowfish是由 Bruce Schneier公布的一U加密算法，没有甌专利Qƈ且公布了(jin)实现的代码，它适合不需要经常更换密钥的情况?br />
选择加密模式是ؓ(f)?jin)对加密数据做进一步调_(d)从而增加解密难度，模式q可以将分组明文作ؓ(f)明文进行处理，减少每次处理的数据量QJCE中提供了(jin)?sh)? 密码本模式ECB、密码封装链接模式CBC、密码反馈模式CFB和输出反馈模式OFB。电(sh)子密码本模式ECB是最单的一U模式，只是Ҏ(gu)文每8个字节进 行分l，q且一ơ完成整个明文分l的加密Q它适合对二q制数据?hu)进行加密；密码装链接模式CBCQ把一?字节的分l作入数据对另一l加密结果进? 修正Q这样可以把明文中包含的数据cdq行隐藏Q这U模式可以对文本数据q行加密Q密码反馈模式CFBQ类gCBC模式只是实现E有不同Q不同的? CBC模式需要明文分l来q行修正Q而CFB需要的数据量小一些，q且长度可以q行调整;输出反馈模式OFBQ适合那种加密数据在传输过E中有可能生变 化的情况Q生变化出错只?x)对q一位生媄(jing)响而不?x)?jing)响整个分l。JCE可以选择两种填补机制PCKS5Padding和NoPaddingQ前者将Ҏ(gu) 文进行分l时候，如果字节C?的倍数p行填充，保证数据的长度ؓ(f)一个完整的分组Q而后者不Ҏ(gu)据进行填充，当明文进行分l时候，字节C?的倍数 ?x)抛Z个异常?br />
Java安全套接字扩展包JSSE提供的是Z套接字之间传输的数据q行加密Q它与JCE最大的不同是数据的加密过E和传输q程是不分离的，如果? JAAS让我们可以识别应用程序提供者ƈ限制他们只能讉K授权使用的那部分pȝQ那么JSSE保证?jin)我们应用程序传输的数据安全性。JSSE实现? SSLQ安全套接字层）(j)的加密，SSL作ؓ(f)HTTPS协议的基Q提供了(jin)在TCP套接字上Ҏ(gu)据进行加密的Ҏ(gu)Q也是基于WEB应用最常用的一U加密方 式。用JSSE API首先我们需要徏立SSL环境QSSL服务器端建立密钥库存放服务器U钥和验证n份的证书Q而SSL客户端徏立信d验证信Q的证 书，密钥库和信Q库都是通过JDK中keytoolq个工具来进行管理；其次Q我们需要从一?nbsp;JSSE 套接字工厂而不是直? ?nbsp;java.net.Socket c获得套接字Q客L(fng)代码?nbsp;SSLSocketFactory 获取套接字，而服务器端代? ?nbsp;SSLServerSocketFactory 获取套接字；通过从这些工厂获取套接字Q我们就可以利用 JSSE 提供E序提供的框Ӟ而不? ?nbsp;java.net 包允许我们所作的那样Q简单地创徏标准的、不安全的套接字。?nbsp;JSSEQ我们可以定义运行Q意应用程序协?-? ?nbsp;HTTP、TCP/IP、FTPQ甚?nbsp;Telnet--的客h与服务器之间的安全套接字q接?br />
ȝQ?br />
信息的安全性是计算机领域必重视和解决的问题，Java体系l构对信息安全的提供灉|而健壮框Ӟ只要我们使用得当p够很好的保证信息安全性，? 低我们的代h(hun)和风险，同时我们也要加强一些其他相关的安全工作Q比如保护好我们的私钥等{，q样才能保证Java安全框架发挥最大的作用。Java安全? 架还有一些不的地方Q比如应用程序不断分配内存或者新建线E造成拒绝服务、将安全模型与系l用戯行映等{，随着信息技术的不断发展Q信息安全也?x)? 临越来越大的?xi)战Q这些都需要Java安全框架更加完善和进一步发展?
]]>