This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Difference between revisions of "Unsafe Mobile Code: Inner Class"
Weilin Zhong (talk | contribs) (Moved the definition of mobile code and its security concern to :Category:Unsafe Mobile Code.) |
|||
| Line 2: | Line 2: | ||
{{Template:Fortify}} | {{Template:Fortify}} | ||
| − | + | [[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}}''' | ||
| + | |||
| + | [[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]] | ||
| + | |||
| + | [[ASDR Table of Contents]] | ||
| + | __TOC__ | ||
| − | |||
==Description== | ==Description== | ||
| + | |||
| + | The program violates secure coding principles for mobile code by making use of an inner class. | ||
Inner classes quietly introduce several security concerns because of the way they are translated into Java bytecode. In Java source code, it appears that an inner class can be declared to be accessible only by the enclosing class, but Java bytecode has no concept of an inner class, so the compiler must transform an inner class declaration into a peer class with package level access to the original outer class. More insidiously, since an inner class can access private fields in their enclosing class, once an inner class becomes a peer class in bytecode, the compiler converts private fields accessed by the inner class into protected fields. | Inner classes quietly introduce several security concerns because of the way they are translated into Java bytecode. In Java source code, it appears that an inner class can be declared to be accessible only by the enclosing class, but Java bytecode has no concept of an inner class, so the compiler must transform an inner class declaration into a peer class with package level access to the original outer class. More insidiously, since an inner class can access private fields in their enclosing class, once an inner class becomes a peer class in bytecode, the compiler converts private fields accessed by the inner class into protected fields. | ||
| Line 12: | Line 20: | ||
For more details about mobile code and its security concerns, please see [[:Category:Unsafe Mobile Code]]. | For more details about mobile code and its security concerns, please see [[:Category:Unsafe Mobile Code]]. | ||
| − | ==Examples == | + | |
| + | ==Risk Factors== | ||
| + | |||
| + | TBD | ||
| + | |||
| + | ==Examples== | ||
The following Java Applet code mistakenly makes use of an inner class. | The following Java Applet code mistakenly makes use of an inner class. | ||
| Line 25: | Line 38: | ||
</pre> | </pre> | ||
| − | ==Related | + | ==Related [[Attacks]]== |
| + | |||
| + | * [[Attack 1]] | ||
| + | * [[Attack 2]] | ||
| + | |||
| + | |||
| + | ==Related [[Vulnerabilities]]== | ||
| + | |||
| + | * [[Vulnerability 1]] | ||
| + | * [[Vulnerabiltiy 2]] | ||
| + | |||
| + | |||
| + | |||
| + | ==Related [[Controls]]== | ||
| + | |||
| + | * [[Use encapsulation]] | ||
| + | |||
| + | |||
| + | ==Related [[Technical Impacts]]== | ||
| + | |||
| + | * [[Technical Impact 1]] | ||
| + | * [[Technical Impact 2]] | ||
| + | |||
| + | |||
| + | ==References== | ||
| + | |||
| + | TBD | ||
| + | [[Category:FIXME|add links | ||
| + | |||
| + | In addition, one should classify vulnerability based on the following subcategories: Ex:<nowiki>[[Category:Error Handling Vulnerability]]</nowiki> | ||
| + | |||
| + | Availability Vulnerability | ||
| + | |||
| + | Authorization Vulnerability | ||
| + | |||
| + | Authentication Vulnerability | ||
| + | |||
| + | Concurrency Vulnerability | ||
| − | + | Configuration Vulnerability | |
| − | + | Cryptographic Vulnerability | |
| − | + | Encoding Vulnerability | |
| − | + | Error Handling Vulnerability | |
| − | + | Input Validation Vulnerability | |
| − | + | Logging and Auditing Vulnerability | |
| + | Session Management Vulnerability]] | ||
| + | |||
| + | __NOTOC__ | ||
| + | |||
| + | |||
| + | [[Category:OWASP ASDR Project]] | ||
[[Category:Code Quality Vulnerability]] | [[Category:Code Quality Vulnerability]] | ||
| − | |||
[[Category:Access Control Vulnerability]] | [[Category:Access Control Vulnerability]] | ||
| − | |||
[[Category:Unsafe Mobile Code]] | [[Category:Unsafe Mobile Code]] | ||
| − | |||
[[Category:Java]] | [[Category:Java]] | ||
| − | |||
[[Category:Implementation]] | [[Category:Implementation]] | ||
| − | |||
[[Category:Code Snippet]] | [[Category:Code Snippet]] | ||
Revision as of 13:50, 3 October 2008
This is a Vulnerability. To view all vulnerabilities, please see the Vulnerability Category page.
- This article includes content generously donated to OWASP by
Last revision (mm/dd/yy): 10/3/2008
Vulnerabilities Table of Contents
Description
The program violates secure coding principles for mobile code by making use of an inner class.
Inner classes quietly introduce several security concerns because of the way they are translated into Java bytecode. In Java source code, it appears that an inner class can be declared to be accessible only by the enclosing class, but Java bytecode has no concept of an inner class, so the compiler must transform an inner class declaration into a peer class with package level access to the original outer class. More insidiously, since an inner class can access private fields in their enclosing class, once an inner class becomes a peer class in bytecode, the compiler converts private fields accessed by the inner class into protected fields.
For more details about mobile code and its security concerns, please see Category:Unsafe Mobile Code.
Risk Factors
TBD
Examples
The following Java Applet code mistakenly makes use of an inner class.
public final class urlTool extends Applet {
private final class urlHelper {
...
}
...
}
Related Attacks
Related Vulnerabilities
Related Controls
Related Technical Impacts
References
TBD
