[Owasp-testing] [Owasp-codereview] Fwd: Code review Structure

James Kist kist at meridiansecurity.net
Wed Jan 17 13:11:20 EST 2007


I'm good with it.

  _____  

From: eoinkeary at gmail.com [mailto:eoinkeary at gmail.com] On Behalf Of Eoin
Sent: Wednesday, January 17, 2007 12:59 PM
To: James Kist
Cc: Andrew van der Stock; owasp-testing at lists.owasp.org
Subject: Re: [Owasp-testing] [Owasp-codereview] Fwd: Code review Structure


Best practice - > yes.
Vulnerability sections - > No, each vulnerability has language specific sub
section for a language example. Some languages dont have a perticular
vulnerability.
Design review -> Yes (a small bit if we have to).
 
So we have the "Reviewing Code for...." (Akin to the testing guide which is
"Testing for .....")
 
This shall have sections of code examples in different languages.
 
yep? No?
 
-ek
 
 
 
 
 
 


 
On 17/01/07, James Kist <kist at meridiansecurity.net> wrote: 

So, are we going to have the language-specific chapters ?

  _____  

From: owasp-testing-bounces at lists.owasp.org
<mailto:owasp-testing-bounces at lists.owasp.org>
[mailto:owasp-testing-bounces at lists.owasp.org] On Behalf Of Eoin
Sent: Wednesday, January 17, 2007 12:29 PM
To: Andrew van der Stock; owasp-testing at lists.owasp.org
<mailto:owasp-testing at lists.owasp.org> 
Subject: Re: [Owasp-testing] [Owasp-codereview] Fwd: Code review Structure

 

Agreed, context is king. A vuln may be high on an external system that does
not require authentication but  if it was found in a secure LAN on an
internal system with one user it may not be such a big deal.
 
There is a section on context in the introduction which could be made more
use of but it explains this idea.
 
Relating to best practice structure I like the structure James Kist has
suggested. It is important to explain why it is good practice and giving an
example why?
 
Eoin


 
On 17/01/07, Andrew van der Stock <vanderaj at owasp.org
<mailto:vanderaj at owasp.org> > 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's related to a
business process and asset they care about. 

This is why I'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're not
interested in, or you can learn from the other language's issues to avoid
them in your own. 

Thanks,
Andrew


On 1/12/07 10:25 AM, "James Kist" <kist at meridiansecurity.net
<mailto:kist at meridiansecurity.net> > 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: owasp-testing-bounces at lists.owasp.org [
<mailto:owasp-testing-bounces at lists.owasp.org]>
mailto:owasp-testing-bounces at lists.owasp.org] On Behalf Of Eoin
Sent: Thursday, January 11, 2007 10:45 AM
To: Mark Roxberry
Cc: Owasp-codereview at lists.owasp.org; owasp-testing at lists.owasp.org
Subject: Re: [Owasp-testing] Fwd: Code review Structure 

Hi Mark,
i believe there is a design section but it has not been touched yet:
 
http://www.owasp.org/index.php/OWASP_Code_Review_Guide_Table_of_Contents
 
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 <me at markroxberry.net> 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 <http://asp.net/>   <http://asp.net/>
<http://asp.net/>  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  <mailto:eoin.keary at owasp.org> <mailto:eoin.keary at owasp.org>  
 
To: owasp-testing at lists.owasp.org    <mailto:owasp-testing at lists.owasp.org>
<mailto:owasp-testing at lists.owasp.org> ; Owasp-codereview at lists.owasp.org 
 
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 &  circumvention 


 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 




 

.NET  

PHP  

Automating Code Reviews  


	Preface 

Reasons for using automated  tools 

Education and cultural  change 

Tool Deployment  Model 


 

 

 

 

 

 

 




 

References  

 








-- 
Eoin Keary OWASP - Ireland
http://www.owasp.org/local/ireland.html
http://www.owasp.org/index.php/OWASP_Testing_Project
<http://www.owasp.org/index.php/OWASP_Testing_Project> 
http://www.owasp.org/index.php/OWASP_Code_Review_Project
<http://www.owasp.org/index.php/OWASP_Code_Review_Project> 

_______________________________________________
Owasp-testing mailing list
Owasp-testing at lists.owasp.org  <mailto:Owasp-testing at lists.owasp.org> 
http://lists.owasp.org/mailman/listinfo/owasp-testing







-- 
Eoin Keary OWASP - Ireland
http://www.owasp.org/local/ireland.html
http://www.owasp.org/index.php/OWASP_Testing_Project
http://www.owasp.org/index.php/OWASP_Code_Review_Project 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.owasp.org/pipermail/owasp-testing/attachments/20070117/4aad253e/attachment-0001.html 


More information about the Owasp-testing mailing list