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

From OWASP
Jump to: navigation, search
 
(2 intermediate revisions by one user not shown)
Line 1: Line 1:
 +
{{Template:Vulnerability}}
 
{{Template:SecureSoftware}}
 
{{Template:SecureSoftware}}
{{Template:Vulnerability}}
 
 
[[Category:FIXME|This is the text from the old template. This needs to be rewritten using the new template.]]
 
  
 
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
 
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
  
 
[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]
 
[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]
 
[[ASDR Table of Contents]]
 
__TOC__
 
 
  
 
==Description==
 
==Description==

Latest revision as of 10:27, 28 February 2009

This is a Vulnerability. To view all vulnerabilities, please see the Vulnerability Category page.



Last revision (mm/dd/yy): 02/28/2009

Vulnerabilities Table of Contents

Description

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

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.

Risk Factors

TBD


Examples

In Java:

package math;

public class Lebesgue implements Integration{

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

}

Related Attacks


Related Vulnerabilities

Related Controls

  • 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.


Related Technical Impacts


References

TBD