Difference between revisions of "Java leading security practice"

From OWASP
Jump to: navigation, search
(Class Access)
(Initialisation)
Line 14: Line 14:
  
 
===Initialisation===
 
===Initialisation===
 +
Allocation of objects [without calling a constructor is possible. One does not neet to call a constructor to instantiate an object, so dont rely on initialization as there are many ways to allocate uninitialized objects.
 +
 +
#Get the class to verify that it has been initialized prior to it performing any function.
 +
Add a boolean that is set to "TRUE" when initialized, make this private. This can be checked when required by all non-constructor methods.
 +
#Make all variables private and use setters/getters.
 +
#Make static vairables private, this prevents access to uninitialized vairables.
 +
 
===Finality===
 
===Finality===
 
===Scope===
 
===Scope===

Revision as of 06:08, 15 August 2007

OWASP Code Review Guide Table of Contents

Contents


Introduction

This section covers the main Java-centric areas which are perscribed as leading security practice when developing java applications and code. So when we are performing a codfe review on some Java code we should look at the following areas of concern. Getting developers to adopt leading practice techniques gives the inherent basic security features all code should have, "Self Defending Code".


Class Access

  1. Methods
  2. Fields
  3. Mutable Objects

Put simply don't have public fields or methods in a class unless required. Every method, field, class that is not private is a potential avenue of attack. Provide accessors to them so you can limit their accessibility.

Initialisation

Allocation of objects [without calling a constructor is possible. One does not neet to call a constructor to instantiate an object, so dont rely on initialization as there are many ways to allocate uninitialized objects.

  1. Get the class to verify that it has been initialized prior to it performing any function.

Add a boolean that is set to "TRUE" when initialized, make this private. This can be checked when required by all non-constructor methods.

  1. Make all variables private and use setters/getters.
  2. Make static vairables private, this prevents access to uninitialized vairables.

Finality

Scope

Inner Classes

Code Signing

Hard Coding

Archive Files

Cloneability

Serialization/Deserialization

Comparisons