文档介绍：下载
下载
第6章对象的安全
如果我们不能保障我们所有的权力,那么就让我们保障那些我们能够做到的。
—托马斯·杰弗逊
当使用J a v a语言和平台进一步开发应用程序,尤其是考虑到安全因素时,你自觉或不自觉
地就会依赖于所指定对象的方向,诸如数据压缩,对象名空间分割和类的安全。这种依赖性
很明显地体现在运行时间的内部状态保护上。而这种状态经常被维持并表示为 J a v a对象。例
如,当应用Java RMI()程序包以跨越多重 J V M S的方式建立分布式 J a v a应用程序时,你有时会
发现,当对象状态从一台计算机传递到另一台计算机时,为了可靠和保密,确保保护对象的
可靠性和保密性是必须的而且很方便。当所指对象处于运行系统中(例如,在内存中) ,存储在
系统内部(比如,存储在程序包 I P中),或存储在系统外部(例如,存储在磁盘上),这些安全性
需求是有必要的。
这就意味着在系统开发过程中,必须正确解决全局的对象安全问题,此外还有代码签署,
策略驱动,细微访问控制机制,本章提供了许多技术,以便在 Java 语言中获得安全编程。另
外,本章还描述了三个新型界面,以签署、约束和监护 J a v a对象。下面我们开始讨论一些一
般性的实例。
安全异常
在低级代码中出现异常较为常见,因此要么通过把它传递到到高级异常中暂时隐蔽起来
待以后再次出现,要么作一些起基本的处理。
例如,假设你定义了一个类 M y P a s s s w o r d c h e c k e r,以便用户登录时核对密码。要是因为
用户名不存在,而密码核对失败,让用户知道名字写错了不是一个好办法,因为这样做会使
攻击者去猜测用户名。相反,应该给出一个一般性的错误信息,如“登录失败”。
然而,当编写代码以掩盖它或处理安全异常(如A c c e s s E x c e p t i o n和S e c u r i t y E x c e p t i o n )时,
必须非常小心,因为这一操作可能会潜在地掩盖严重违反安全规则的情况。有时开发者会因
安全异常感到烦恼,于是用自己定义的安全策略来代替 A c c e s s C o n t r o l l或S e c u r i t y M a n a g e r,这
种“替代代码工作”的方式非常危险,尤其是当代码被发展成系统代码,而且被完全信任时。
第6章对象的安全使用107
下载
通常情况下,开发设计应尽可能避免出现安全异常而且也不要有意掩盖它。
域和方法
J a v a语言提供四种访问模式,即: p u b l i c (公用的) , p r o t e c t e d (保护的),package private(包私
有的)和p r i v a t e (私有的),应该正确地应用它们。以下给出了一个不正确应用的示例:没有经
验的编程者,在定义一个时间区域类时,错误的将域和变量声明为可公开访问的。
public TimeZone defaultZone;
这个设计会出现一系列问题。首先,任何人和代码(包括不受信任的代码)都可以访问此
域,而且可直接修改缺省时间区域的值,其次,由于多线程也可访问此域,故需要同步。下面
的例子则是一个较好的设计:
假设现在需要核查安全状况,以防止未经准许就修改默认时间区域的值,则可以加上两
行安全代码,如下所示:
关于这个更新后的设计,重要的一点是它不会破坏向后的兼容性,也就是说运行在较早
发行版本的第三方应用程序,当在新版本上运行时,仍有相同的 A P I。如果 Ti m e Z o n e如第一
种设计那样直接放在公用域上,而且不改变 A P I,则安全核查(或同步特性)就无法执行。
综上所述,最好不要设计成可以直接访问的公用域和变量。相反,将这些域声明为私有
域,并提供公用的访问方法以间接访问这些域。并且,当访问很敏感,需要安全核查时,对每
个公用的访问方法都要小心的决定。若将域声明为常量,那么它是公用的,但应定义为静态
的量,且为最终值,这一点我们将在下一部分中讨论。
即使有些方法或域为保护域,只要此类不是最终的子类,都可以访问它们。因为攻击者
很容易就能提供一个子类,所以安全性得不到保证。与此类似,包私有方法和域可被同一个
程序包中的任何类访问。如果此程序包没有被适当的约束,攻击者就会很容易定义一个类,
且声明此类属于这个私有程序包。这样他就能访问此包私有方法和域。应当经常检查所有保
护与以及包私有方法和域,以确定它们是否被定义为私有的,如果没有,应当检查它们是否
通过执行安全核查的访问方法来访问。
静态域
静态