فا

‫ Java Secure Coding - Introduction

IRCAR201212160
 
Date: 2012-12-24
 
Software vulnerability reports and reports of software exploitations continue to grow at an alarming rate, and a significant number of these reports result in technical security alerts. To address this growing threat to the government, corporations, educational institutions, and individuals, systems that are free of software vulnerabilities must be developed.
Coding errors cause the majority of software vulnerabilities. For example, 64 percent of the nearly 2,500 vulnerabilities in the National Vulnerability Database in 2004 were caused by programming errors [Heffley 2004].
Java is a relatively secure language. It has no explicit pointer manipulation; array and string bounds are automatically checked; attempts at referencing a null pointer are trapped; the arithmetic operations are well defined and platform independent, as are the type conversions. The built-in bytecode verifier ensures that these checks are always in place. Moreover, Java provides comprehensive, fine-grained security mechanisms that can control access to individual files, sockets, and other sensitive resources.
Java program safety, however, can be compromised. The remainder of this chapter describes use cases under which Java programs might be exploited and examples of rules that mitigate against these attacks. Not all of the rules apply to all Java language programs; frequently, their applicability depends on how the software is deployed and your assumptions concerning trust.
Input Validation and Data Sanitization
 
Validation: Validation is the process of ensuring that input data falls within the expected domain of valid program input. This requires that inputs conform to type and numeric range requirements as well as to input invariants for the class or subsystem.
Sanitization: In many cases, the data is passed directly to a component in a different trusted domain. Data sanitization is the process of ensuring that data conforms to the requirements of the subsystem to which it is passed. Sanitization also involves ensuring that data conforms to security-related requirements regarding leaking or exposure of sensitive data when output across a trust boundary. Sanitization may include the elimination of unwanted characters from the input by means of removing, replacing, encoding, or escaping the characters. Sanitization may occur following input (input sanitization) or before the data is passed across a trust boundary (output sanitization).
 
Leaking Sensitive Data
A system’s security policy determines which information is sensitive. Sensitive data may include user information such as social security or credit card numbers, passwords, or private keys. When components with differing degrees of trust share data, the data are said to flow across a trust boundary. Because Java allows components under different trusted domains to communicate with each other in the same program, data can be transmitted across a trust boundary. Systems must ensure that data is not transmitted to a component in a different trusted domain if authorized users in that domain are not permitted access to the data.
 
Leaking Capabilities
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 [Dennis 1966]. 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.
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 (see “Security Aspects in Java Bytecode Engineering” [Schoenefeld 04] for an example).
 
Denial of Service
Denial of service attacks attempt to make a computer resource unavailable or insufficiently available to its intended users. Such attacks are generally of greater concern for persistent, server-type systems than for desktop applications; nevertheless, denial of service issues can arise for all classes of application.
 
Privilege Escalation
According to the principle of least privilege, every program and every user of the system should operate using the least set of privileges necessary to complete their particular task [Saltzer 1974, Saltzer 1975]. The Build Security In website [DHS 2006] provides additional definitions of this principle. Executing with minimal privileges mitigates against exploitation in case a vulnerability is discovered in the code. These principles can be applied in various ways to Java language programming. Occasionally a system will have components, most of which require only a base set of privileges, but a few require more privileges than the base set; these are said to run with elevated privileges.
 
Source:
 
 

نظرات

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

نوشته

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

دسته‌ها

امتیاز

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