OWASP - User contributions [en]

Java leading security practice

2007-08-28T17:02:47Z

Mxyzplk: /* Introduction */

[[OWASP Code Review Guide Table of Contents]]__TOC__

==Introduction==
This section covers the main Java-centric areas which are prescribed as leading security practices when developing Java applications and code. So when we are performing a code review on 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===
#Methods
#Fields
#Mutable Objects

Put simply, don't have public fields or methods in a class unless required. Every method, field, or 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.

#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 variables private, this prevents access to uninitialized variables.

===Finality===
Non-Final classes let an attacker extend a class in a malicious manner. An application may have a USER object which by design would never be extended, so implementing this class as Final would prevent malicious code extending the user class.
Non-final classes should be such for a good reason. Extensibility of classes should be enabled if it is required not simply for the sake of being extensible.

===Scope===
Package scope is really used so there are no naming conflicts for an application especially when reusing classes from another framework. Packages are by default open, not sealed which means a rogue class can be added to your package.
If such a rogue class was added to a package the scope of protected fields would not yield any security. By default all fields and methods not declared public or private are protected and can only be accessed within the same package, don’t rely on this for security.

===Inner Classes===
Simply put, when translated into bytecode, inner classes are "rebuilt" as external classes in the same package. This means any class in the package can access this inner class. The owner/enclosing/father classes’ private fields are morphed into protected fields as they are accessible by the now external inner class.

===Hard Coding===
Don't hard code any passwords, user ID's, etc in your code. Silly and bad design. Can be decompiled. Place them in a protected directory in the deployment tree.

===Archive Files===
===Cloneability===
===Serialization/Deserialization===
===Comparisons===

[[Category:OWASP Code Review Project]]
[[Category:Java Leading Practice]]

Austin

2007-01-10T22:45:16Z

Mxyzplk:

{{Chapter Template|chaptername=Austin|extra=The chapter leader is [mailto:cdewitt@indepthsec.com Cris Dewitt]|mailinglistsite=http://lists.owasp.org/mailman/listinfo/owasp-austin|emailarchives=http://lists.owasp.org/pipermail/owasp-austin}}

== Local News ==

''If a link is available, click for more details on directions, speakers, etc. You can also review [http://lists.owasp.org/pipermail/owasp-austin/ Email Archives] to see what folks have been talking about''

'''Austin OWASP chapter kickoff meeting''' - Thursday, 7/27, 12-2pm @ Whole Foods Market (downtown, plaza level, sign in with receptionist)

[[August 2006 Austin Chapter Meeting]] - Tuesday- 8/29, 11:30-1:30 on the National Instruments campus, Mopac B (the middle building), conference room 112 (in the Human Resources area to the left of the receptionist). See [http://maps.google.com/maps?f=q&hl=en&q=11500+N+Mo-Pac+Expy,+Austin,+TX+78759&ie=UTF8&ll=30.406377,-97.726135&spn=0.017211,0.036778&om=1 directions to National Instruments]. ''Hint:'' It is on your left on Mopac if you were heading up to Fry's from Austin.

[[September 2006 Austin Chapter Meeting]] - 9/26, 12-1:00 at Texas ACCESS Alliance building located at the intersection of IH-35 South and Ben White

[[October 2006 Austin Chapter Meeting]] - 10/31 - Boo!

[[November 2006 Austin Chapter Meeting]] - 11/21, 11:30am - 1:00pm at National Instruments, 11500 N Mopac, Building C Conference Room 1S14.

<b>December Meeting</b> - Due to the holidays, there will be no December OWASP meeting. However, we are looking for speakers for the January meeting. If you or anyone you know would be a good candidate, let us know! Happy Holidays!

[[January 2007 Austin Chapter Meeting]] - 1/30, 11:30am - 1:00pm at National Instruments, 11500 N Mopac, Building C Conference Room 1S15.

== Presentation Archives ==

The following presentations have been given at local chapter meetings:

* Single Sign On (7/27)

* [http://www.threatmind.net/papers/franz-basic-j2ee-tools-owasp-austin.pdf A Rough Start of a Toolset for Assessing Java/J2EE Web Apps] (7/27) - [[MattFranz]] discussed some custom Python tools he has been writing for conducting security testing of a Struts (and other Java) web applications.

* [http://www.owasp.org/index.php/Image:DenimGroup_AJAXSecurityHereWeGoAgain_Content_20060829.pdf AJAX Security: Here we go again] - Dan Cornell from [http://www.denimgroup.org Denim Group] discussed security issues in the one the popular Web 2.0 technlogy (8/29)

Austin

2006-08-14T15:53:42Z

Mxyzplk: