[OWASP-TESTING] OWAST Testing Project Comments

Mark Curphey mark at curphey.com
Sat Nov 6 07:33:13 EST 2004

I am not sure which version this is? 
Much of this was cut in a heavy editing process early on for consistency and
flow of the document. It was decided it was better for Part 2. 


From: owasp-testing-admin at lists.sourceforge.net
[mailto:owasp-testing-admin at lists.sourceforge.net] On Behalf Of Stan Guzik
Sent: Saturday, November 06, 2004 2:47 AM
To: owasp-testing at lists.sourceforge.net
Subject: [OWASP-TESTING] OWAST Testing Project Comments

Chapter 5 Comments:


In general this is a very good chapter.  Good job to whoever wrote it.  I
just have a few comments.


1)      Page 19 Advantages and Disadvantages  The last paragraph mentions
automated tools.  I suggest adding a section to the document explaining
technical and business logical application vulnerabilities.  Then we can
suggest where to use automated tools.


Automated tools can be very helpful finding the technical vulnerabilities in
application.  They can be a very useful time saver and quickly find most of
the OWASP Top 10 vulnerabilities.  On the other hand, automated tools are
not good for find vulnerabilities in the business logic of applications.
Therefore a manual code review is required.


2)      Page 20 Approaches to Source Code Review  Maybe we can elaborate on
the 4 different approaches.  For example the Call Tree Exploration can be
performed from top->down or bottom->up.


3)      Page 21 Using Documentation  This is the only section of the
document that I disagree with.  The first paragraph suggests that
documentation lies and reviewers should be extremely skeptical.  This may
be the case for a non-critical applications or a small company which will,
probably, never go through a security code review.


Critical production applications that warrant a security code review are
build following well document development standards and go through change
control processes.  Maybe the documentation does not lie but it hasnt been
updated to reflect the latest changes to the application.  The code review
should be used as a check against the documentation to verify that the
developer is following the documented standards.  


Well thats my 2 cents  Very good job.



Stan Guzik

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.owasp.org/pipermail/owasp-testing/attachments/20041106/c6696e60/attachment.html 

More information about the Owasp-testing mailing list