Difference between revisions of "Relying on package-level scope"

From OWASP
Jump to: navigation, search
 
Line 1: Line 1:
 
  
 
{{Template:SecureSoftware}}
 
{{Template:SecureSoftware}}
Line 63: Line 62:
  
 
[[Category:Environmental Problem]]
 
[[Category:Environmental Problem]]
 +
 +
[[Category:OWASP_CLASP_Project]]

Revision as of 13:34, 16 May 2006


Overview

Java packages are not inherently closed; therefore, relying on them for code security is not a good practice.

Consequences

  • Confidentiality: Any data in a Java package can be accessed outside of the Java framework if the package is distributed.
  • Integrity: The data in a Java class can be modified by anyone outside of the Java framework if the packages is distributed.

Exposure period

Design through Implementation: This flaw is a style issue, so it is important to not allow direct access to variables and to protect objects.

Platform

  • Languages: Java
  • Operating platforms: Any

Required resources

Any

Severity

Medium

Likelihood of exploit

Medium

Avoidance and mitigation

  • Design through Implementation: Data should be private static and final whenever possible. This will assure that your code is protected by instantiating early, preventing access and tampering.

Discussion

The purpose of package scope is to prevent accidental access. However, this protection provides an ease-of-software-development feature but not a security feature, unless it is sealed.

Examples

In Java:

package math;

public class Lebesgue implements Integration{

public final Static String youAreHidingThisFunction(functionToIntegrate){
    return ...;

}

Related problems

Not available.

Categories