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

Eoin eoin.keary at owasp.org
Wed Jan 17 12:29:27 EST 2007


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> 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> 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]<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> <eoin.keary at owasp.org>
>
> *To:* owasp-testing at lists.owasp.org
> <mailto:owasp-testing at lists.owasp.org> <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_Code_Review_Project
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.owasp.org/pipermail/owasp-testing/attachments/20070117/d78266c6/attachment.html 


More information about the Owasp-testing mailing list