Difference between revisions of "Publicizing of private data when using inner classes"

From OWASP
Jump to: navigation, search
(Examples)
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:32, 16 May 2006


Overview

Java byte code has no notion of an inner class; therefore inner classes provide only a package-level security mechanism. Furthermore, the inner class gets access to the fields of its outer class even if that class is declared private.

Consequences

  • Confidentiality: "Inner Classes" data confidentiality aspects can often be overcome.

Exposure period

Implementation: This is a simple logical flaw created at implementation time.

Platform

  • Languages: Java
  • Operating platforms: Any

Required resources

Any

Severity

Medium

Likelihood of exploit

Medium

Avoidance and mitigation

  • Implementation: Using sealed classes protects object-oriented encapsulation paradigms and therefore protects code from being extended in unforeseen ways.
  • Implementation: Inner Classes do not provide security. Warning: Never reduce the security of the object from an outer class, going to an inner class. If your outer class is final or private, ensure that your inner class is private as well.

Discussion

A common misconception by Java programmers is that inner classes can only be accessed by outer classes. Inner classes' main function is to reduce the size and complexity of code. This can be trivially broken by injecting byte code into the package. Furthermore, since an inner class has access to all fields in the outer class - even if the outer class is private - potentially access to the outer classes fields could be accidently compromised.

Examples

In Java:

private class Secure(){
   private password="mypassword"
   public class Insecure(){...}
}

Related problems

Not available.

Categories