The object-oriented programming paradigm extends the traditional func- tional and procedural programming approaches by bundling access paths to information via types and objects. Data is stored in object instances and is available via the public interface defined by the type definition of the object.
2.4.1 Key Concepts
Object systems base on a set of key concepts (Gollmann, 1999).
• Objects bundle behavior (state transitions and accessor methods) and structure held in attributes or instance variables. This configu- ration is often referred to as data encapsulation.
• Types define the behavior and structure of objects. In JAVAterms, these are the defined classes.
• The public interface of an object is accessible without restrictions, whereas its superset, the private interface is only available in the inte- rior coding of the object. There may also be intermediate accessibil- ity levels such as protected and package visibility in JAVA or friend class definitions in C++.
• Attributes of objects are either objects or primitive data items, such as data without identity as atomic numeric values such as an integer object with value 5.
• Inheritance of type information allows deriving behavior and struc- ture from a general type (superclass, i.e. car) as well as defining a specialized type (subclass, i.e. sports utility vehicle). A subclass has access to the public and protected interface of its superclass.
Object Oriented Security 91
• Methods define the behavior of an object and documented change of the internal state. Special methods are responsible for the life cycle management of object, as constructors create objects and destruc- tors (finalizers in JAVAterms) destroy objects. There are extensions to this rule, such as cloning and deserializing constructors that play a role in the later vulnerability discussion.
• Messages are used to trigger methods in objects. They contain pa- rameters (requests) and return values (replies) of method invoca- tions. Synchronous method invocations bundle a request to a con- sequent reply message, whereas asynchronous method calls do not impose this dependency.
• Information Hiding and allocation of local isolated address space is assigned to each individual object. Visibility rules protect data inside the address space against external interference. Thus manipulation of the data needs the granted access rights to the object, which is in charge of the visibility scope.
Data encapsulation and information hiding provide the basis for secu- rity measures for distributed single language object oriented systems such as the JAVAplatform or heterogeneous systems based on CORBA. Secu- rity mechanisms in these systems are based on instance objects them- selves (such as java.security.Principal and java.security.Access- ControlContext). These types carry the metadata to enforce the security policy.
2.4.2 Layered Security
Object-oriented systems do only provide protection on their semantical level. Therefore attacks from the layers below (Gollmann, 1999), such as the network communication have to be prevented by additional low-level security measures provided by the underlying layers such as the default
security measures of the JAVAvirtual machine which be discussed later in detail. TCB Attack Attack Organisational and physical mechanisms
Figure 2.10: Layer Below Attack
2.5 Summary
This chapter has shown the structural background of large software ap- plications, using patterns to describe abstract solutions for problems with structural constraints. Antipatterns provide suboptimal solutions for these problems, and may result in quality impacts such security vulnerabilities. We list here the relationship between software flaws and vulnerabilities and possible types of flaws for their creation. The detection of vulnera- bilities is an important step for the preparation of a penetration test, a specialized testing method for security breaches. By applying refactorings to security antipatterns, vulnerable code can be remove and replaced by secure versions to improve the security of the overall system.
3 Distributed Middleware Security
This chapter discusses the requirements, problems and solutions for pro- viding the necessary security level for distributed systems. The security foundations built in the last chapter will be revisited and brought into re- lation to the characteristics of distributed systems.
3.1 Distributed systems
The first generations of IT were based on the idea of centralized pro- cessing. Terminals were only used to provide a textual representation of remote computing resources, such as mainframe computers. Data and functionality for computation was located physically in a local address space and did not leave the system. There was little need for network facilities and communication, and when used it was most often based on proprietary formats mutual dial-up connections, so trust between commu- nication partners was implicitly derived from the trust on communication media.
With the growing importance of IT in enterprises and administration as well as the advent of standardized IP based protocols and its driving force on networking, centralized system had to communicate to the emerging client-server-system, and became part of distributed systems themselves. It is common that business transactions are transmitted over insecure shared networks such as the Internet.
This shift in technology parameters makes clear that building trust and protection has gained importance for the components of distributed ap- plications that are connected via public networks. New dimensions of
threats come from a new type of communication partner, the attacker that tries to break the security of systems.
Attackers appear in different forms as automated attacking tools such as malware (Skoudis and Zeltser, 2003), a term that includes viruses, worms or trojan programs.
Security in distributed systems has already been discussed in the pre- vious chapters and shall be here only repeated in brief. The central con- cern of security is to provide protection against attackers that aim non- authorized access to the single components of distributed system and harm their
• Confidentiality • Integrity and • Availability.
For business scenarios the aspect of Accountability or Non-Repudiation has gained importance. From a technical perspective these goals are de- rived from the technical Integrity goal.