‫ Java Secure Coding: Leaking Capabilities

Date: 26/05/2013

A capability is a communicable, unforgeable token of authority. It refers to a value that references an object along with an associated set of access rights. A user program on a capability-based operating system must use a capability to access an object.

The term capability was introduced by Dennis and Van Horn. The basic idea is that for a program to access an object, it must have a special token. This token designates an object and gives the program the authority to perform a specific set of actions (such as reading or writing) on that object. Such a token is known as a capability.

In an object-capability language, all program state is contained in objects that cannot be read or written without a reference, which serves as an unforgeable capability. All external resources are also represented as objects. Objects encapsulate their internal state, providing reference holders access only through prescribed interfaces.

Every Java object has an unforgeable identity in addition to its contents, because the == operator tests reference equality. This unforgeable identity allows use of a reference to an object as a token, serving as an unforgeable proof of authorization to perform some action.

Authority is embodied by object references, which serve as capabilities. Authority refers to any effects that running code can have other than to perform side-effect-free computations. Authority includes effects not only on external resources such as files and network sockets but also on mutable data structures that are shared with other parts of the program.

References to objects whose methods can perform sensitive operations can serve as capabilities that enable the holder to perform those operations (or to request that the object perform those operations on behalf of the holder). Consequently, such references must themselves be treated as sensitive data and must not be leaked to untrusted code.

One surprising source of leaked capabilities and leaked data is inner classes, which have access to all the fields of their enclosing class. Java bytecodes lack built-in support for inner classes; consequently, inner classes are compiled into ordinary classes with stylized names, such as OuterClass$InnerClass. Because inner classes must be able to access the private fields of their enclosing class, the access control for those fields is changed to package access in the bytecode. Consequently, handcrafted bytecode can access these nominally private fields.

Rules regarding capabilities include:

ERR09-J. Do not allow untrusted code to terminate the JVM

Page: MET04-J. Do not increase the accessibility of overridden or hidden methods

Page: OBJ08-J. Do not expose private members of an outer class from within a nested class

Page: SEC00-J. Do not allow privileged blocks to leak sensitive information across a trust boundary

Page: SEC04-J. Protect sensitive operations with security manager checks

Page: SER08-J. Minimize privileges before deserializing from a privileged context



بدون نظر
شما برای نظر دادن باید وارد شوید


تاریخ ایجاد: 18 مرداد 1393



امتیاز شما
تعداد امتیازها:0