<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
&gt; but I think it would also be helpful to include best practice
recommendations. <br>
<br>
1) Never use Applets for enterprise application. Java .class files
should never be deploying in untrusted environments. There, that was
easy. <br>
<br>
2) Ok, so we are truly talking J2EE servers primarily for web
application deployment (ok, this is OWASP afterall).<br>
<br>
2a) If someone starting talking about the importance of not using inner
classes, I'm going to scream :) I see so many recomendations that truly
have nothing to do with security. Sure, code quality is important be we
want to give specific recomendations to code Java/J2EE apps <br>
<br>
Ok, starting with Input Validation:<br>
<br>
<pre style="margin-left: 63.75pt; text-indent: -0.25in;"><!--[if !supportLists]--><span
 style=""><span style="">-<span
 style="font-family: &quot;Times New Roman&quot;; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span><!--[endif]-->Ensure that all form, header, cookie and configuration data is validated on the server </pre>
<pre style="margin-left: 63.75pt; text-indent: -0.25in;"><!--[if !supportLists]--><span
 style=""><span style="">-<span
 style="font-family: &quot;Times New Roman&quot;; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;   </span></span></span><!--[endif]-->Do not depend on any client-side input validation</pre>
<pre style="margin-left: 63.75pt; text-indent: -0.25in;"><!--[if !supportLists]--><span
 style=""><span style="">-<span
 style="font-family: &quot;Times New Roman&quot;; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span><!--[endif]-->Accept only unproblematic characters (white list input validation) as opposed to rejecting bad characters.</pre>
<pre style="margin-left: 63.75pt; text-indent: -0.25in;"><!--[if !supportLists]--><span
 style=""><span style="">-<span
 style="font-family: &quot;Times New Roman&quot;; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span><!--[endif]-->***** (big one) Use regular expressions in a way that is configurable by an InfoSec professional and does not require programmer intervention. This provides InfoSec administrators the possibility to react to 0-minute exploits. </pre>
<pre style="margin-left: 63.75pt; text-indent: -0.25in;"><!--[if !supportLists]--><span
 style=""><span style="">-<span
 style="font-family: &quot;Times New Roman&quot;; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span><!--[endif]-->Identify the legal characters (often a regular expression) and reject all else</pre>
<pre style="margin-left: 63.75pt; text-indent: -0.25in;"><!--[if !supportLists]--><span
 style=""><span style="">-<span
 style="font-family: &quot;Times New Roman&quot;; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span><!--[endif]-->Ensure that all input validation logic is placed in a centralized library that all programmers are forced to use</pre>
My biggest concern is that the topics on Java at
<a class="moz-txt-link-freetext" href="http://www.owasp.org/index.php/OWASP_Code_Review_Guide_Table_of_Contents">http://www.owasp.org/index.php/OWASP_Code_Review_Guide_Table_of_Contents</a>
are not even close to the "top 10":<br>
<br>
<ol>
  <li><a href="http://www.owasp.org/index.php/Inner_classes"
 title="Inner classes">Inner classes &nbsp; &nbsp;&nbsp; bah</a>
  </li>
  <li><a
 href="http://www.owasp.org/index.php?title=Class_comparison&amp;action=edit"
 class="new" title="Class comparison">Class comparison &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp; big
deal if you control the namespace</a>
  </li>
  <li><a
 href="http://www.owasp.org/index.php?title=Cloneable_classes&amp;action=edit"
 class="new" title="Cloneable classes">Cloneable classes &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp; yea
this is good</a>
  </li>
  <li><a
 href="http://www.owasp.org/index.php?title=Serializable_classes&amp;action=edit"
 class="new" title="Serializable classes">Serializable classes &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; dont do it</a>
  </li>
  <li><a
 href="http://www.owasp.org/index.php?title=Package_scope_and_encapsulation&amp;action=edit"
 class="new" title="Package scope and encapsulation">Package scope and
encapsulation &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp; nice, but not top 10</a>
  </li>
  <li><a
 href="http://www.owasp.org/index.php?title=Mutable_objects&amp;action=edit"
 class="new" title="Mutable objects">Mutable objects &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; nice but not top 10</a>
  </li>
  <li><a
 href="http://www.owasp.org/index.php?title=Native_Methods&amp;action=edit"
 class="new" title="Native Methods">Native Methods &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
dont do it</a>
  </li>
  <li><a
 href="http://www.owasp.org/index.php?title=Private_methods_%26_circumvention&amp;action=edit"
 class="new" title="Private methods &amp; circumvention">Private methods
&amp; circumvention &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; dont use applets or
native methods, enough said</a>
  </li>
  <li><a
 href="http://www.owasp.org/index.php?title=Static_Fields&amp;action=edit"
 class="new" title="Static Fields">Static Fields &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; make access to static threadsafe, but all the hype over
statics being bad is applet centric</a>
  </li>
</ol>
<br>
So what do we really want to focus on here, gentlemen?<br>
<br>
- Jim<br>
<br>
<br>
Mark Roxberry wrote:
<blockquote cite="mid45D97881108D41B18E6E34E94A2AE78D@AI034" type="cite">
  <pre wrap="">IMHO, I think if the guide is to have any worth, we need to be specific - general recommendations make a good opening section - but code quality is ultimately at the level of the code and the proper usage of the language in which that code was written.   I think, otherwise, we are talking about the items in a general sense that Jim outlined - it's good to know and reiterate "Input Validation" as a general term and broken access control examples in general terms, but I think it would also be helpful to include best practice recommendations.  For example, C++ code can use the strsafe.h functions (instead of the early more vulnerable functions, e.g. strcopy) or if using VS.NET use /clr:safe, you can compile with many restrictive security checks in place or whatever other components / libraries specific to the development environment.  I could list out many specific practices for each version of ASP.NET (C#, VB.NET, C++) / SQL Server, etc.  Another that comes to m
ind - in ADO.NET are we using datareaders and never closing the database connection, exposing the system to a DoS, even unintentionally?

I'm sorry to ramble, but I think it is important to maybe hit the Top 5 for each language / environment.  Just my .02.

Mark
  ----- Original Message ----- 
  From: Jim Manico 
  To: Andrew van der Stock 
  Cc: 'Mark Roxberry' ; <a class="moz-txt-link-abbreviated" href="mailto:Owasp-codereview@lists.owasp.org">Owasp-codereview@lists.owasp.org</a> ; <a class="moz-txt-link-abbreviated" href="mailto:owasp-testing@lists.owasp.org">owasp-testing@lists.owasp.org</a> ; 'Eoin' 
  Sent: Wednesday, January 17, 2007 3:50 PM
  Subject: Re: [Owasp-codereview] [Owasp-testing] Fwd: Code review Structure


  Noting that the LDAP server is unencrypted is part of a application infrastructure audit. Many very smart orginizations do this since encrypting LDAP is a HUUUUUGE hit, so they put LDAP in a private subnet and do a few other things to not have to encrypt LDAP. 

  99% of the time during an audit, there are no requirements docs to match against code. So as part of my audit, I both build the proper documentation for the app, and write the remediation/audit document. How can you audit business processes if there are not requirement's to match them against?

  When I do a code audit, I look for 3 main things: (And I'm doing mostly J2EE)

  1) Input Validation - like a religion, I check all input data from users, config files, databases even (output sanitization), headers - every piece of data entering a software system needs to be centrally validated.
  2) Authentication/Access control 
  3) Session Management (when its custom)
  4) Overall Code Quality

  Then I run all code through Fortify or FindBugs and use that to find low-hanging fruit.

  Manual review is clocking about 100 lines of code/hr when done with integrity, so most of my code reviews involve me creating large teams of auditors.

  Management always disagrees with me some, so I just document my opinions and findings CLEARLY to protect myself, and let management make the call. 

  - Jim

  Andrew van der Stock wrote: 
This is actually an important question which needs answering.

Personally, I code review in terms of business function as this is the
easiest way to demonstrate your value to your client. For example, if I tell
them that their LDAP server connection is unencrypted, so what? I instead
look at the use cases from the business requirements and ensure that they
are properly demonstrated in the code, and if as a side bar to that process,
I discover weaknesses, I will drop them in, so that:

* The user login process may allow attackers to view all credentials and
thus log in as anyone they want, including the LDAP manager. This destroys
any credibility of logs, transactions and may allow widespread destruction
or alteration of data.

Now the business has a reason to fix my finding as it&sup1;s related to a
business process and asset they care about.

This is why I&sup1;m not convinced its necessary to have language specific
chapters. Most of the information in those chapters applies will apply to
all languages / frameworks. You can always jump over examples you&sup1;re not
interested in, or you can learn from the other language&sup1;s issues to avoid
them in your own. 

Thanks,
Andrew


On 1/12/07 10:25 AM, "James Kist" <a class="moz-txt-link-rfc2396E" href="mailto:kist@meridiansecurity.net">&lt;kist@meridiansecurity.net&gt;</a> wrote:

  What is the desired structure for the best practices section? How about
something like this:
 
Vulnerability (with a link to the section that describes the vulnerability)
Best practice 1 - Description (includes how and to what level the
vulnerability is addressed by this best practice)
Best practice 1 - Code example (if applicable)
Best practice 2 - Description
Best practice 2 - Code example (if applicable)
 
etc.
 
 


From: <a class="moz-txt-link-abbreviated" href="mailto:owasp-testing-bounces@lists.owasp.org">owasp-testing-bounces@lists.owasp.org</a>
[<a class="moz-txt-link-freetext" href="mailto:owasp-testing-bounces@lists.owasp.org">mailto:owasp-testing-bounces@lists.owasp.org</a>] On Behalf Of Eoin
Sent: Thursday, January 11, 2007 10:45 AM
To: Mark Roxberry
Cc: <a class="moz-txt-link-abbreviated" href="mailto:Owasp-codereview@lists.owasp.org">Owasp-codereview@lists.owasp.org</a>; <a class="moz-txt-link-abbreviated" href="mailto:owasp-testing@lists.owasp.org">owasp-testing@lists.owasp.org</a>
Subject: Re: [Owasp-testing] Fwd: Code review Structure

Hi Mark,
i believe there is a design section but it has not been touched yet:
 
<a class="moz-txt-link-freetext" href="http://www.owasp.org/index.php/OWASP_Code_Review_Guide_Table_of_Contents">http://www.owasp.org/index.php/OWASP_Code_Review_Guide_Table_of_Contents</a>
 
Designing for security (section).
 
You you consider putting a .NET design section within this.
 
Authoring the .NET best practice section would be great!! I'll put your name
beside it.
thanks,
Eoin

 
On 11/01/07, Mark Roxberry <a class="moz-txt-link-rfc2396E" href="mailto:me@markroxberry.net">&lt;me@markroxberry.net&gt;</a> wrote:
     
 
 
I'll do .NET Code Review Best Practices.
 
 
 
Can I include Design Guidance as a section?  Or maybe we need to  consider
Secure Application Design for an OWASP project (or do we have plans  for this
already)?  An example, in ASP.NET <a class="moz-txt-link-rfc2396E" href="http://asp.net/">&lt;http://asp.net/&gt;</a>  2.0, when do we
recommend using the  MembershipProviders and integrating with .NET framework
before rolling your  own access control system.  Design guidance would
outline the  scenarios for each security design.  What do you think?
 
 
 
I'll post a topic list by tomorrow.
 

Regards,
 
 
 
Mark
 
       
 
----- Original Message -----
 
From: Eoin <a class="moz-txt-link-rfc2396E" href="mailto:eoin.keary@owasp.org">&lt;mailto:eoin.keary@owasp.org&gt;</a>
 
To: <a class="moz-txt-link-abbreviated" href="mailto:owasp-testing@lists.owasp.org">owasp-testing@lists.owasp.org</a>  <a class="moz-txt-link-rfc2396E" href="mailto:owasp-testing@lists.owasp.org">&lt;mailto:owasp-testing@lists.owasp.org&gt;</a> ;
<a class="moz-txt-link-abbreviated" href="mailto:Owasp-codereview@lists.owasp.org">Owasp-codereview@lists.owasp.org</a>
 
Sent: Tuesday, January 09, 2007 10:47  AM
 
Subject: [Owasp-testing] Fwd: Code  review Structure
 

 
 
Hi,
 
Below is the current structure of the code review guide.
 

If anyone would like to take on a section (improve a section/add  more info)
please let me know and ill pen you in for it.
 
thanks,
 
Eoin
 
 
 
 

Methodology  
        Introduction  

Steps and  Roles

Code Review  Processes
 

Design review 
Designing for security
 

Examples by Vulnerability
 

 

 

           
        Buffer Overruns and  Overflows

OS Injection  

SQL Injection 

Data  Validation

Error Handling

Logging issues

The Secure Code  Environment

Transaction  Analysis

Authorization 

Authentication

Session  Integrity

Cross Site Request  Forgery

Cryptography  

Dangerous HTTP  Methods

Race  Conditions
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

           

Language specific best practice

Java  
        Inner  classes

Class  comparison

Cloneable  classes

Serializable  classes

Package scope and  encapsulation

Mutable  objects

Private methods &amp;  circumvention
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

           

.NET  

PHP  

Automating Code Reviews
        Preface  

Reasons for using automated  tools

Education and cultural  change

Tool Deployment  Model
 

 

 

 

 

 

 

 

           

References  

 
        


  ----------------------------------------------------------------------------
_______________________________________________
Owasp-codereview mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Owasp-codereview@lists.owasp.org">Owasp-codereview@lists.owasp.org</a>
<a class="moz-txt-link-freetext" href="http://lists.owasp.org/mailman/listinfo/owasp-codereview">http://lists.owasp.org/mailman/listinfo/owasp-codereview</a>
  

  </pre>
  <pre wrap="">
<hr size="4" width="90%">
_______________________________________________
Owasp-codereview mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Owasp-codereview@lists.owasp.org">Owasp-codereview@lists.owasp.org</a>
<a class="moz-txt-link-freetext" href="http://lists.owasp.org/mailman/listinfo/owasp-codereview">http://lists.owasp.org/mailman/listinfo/owasp-codereview</a>
  </pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">-- 
Best Regards,
Jim Manico
GIAC GSEC Professional, Sun Certified Java Programmer
<a class="moz-txt-link-abbreviated" href="mailto:jim@manico.net">jim@manico.net</a>
808.652.3805</pre>
</body>
</html>