[OWASP-TESTING] Updated Doc
jfernandez at germinus.com
Thu Mar 18 03:33:30 EST 2004
Mark Curphey wrote:
> Completed Chapter 1 (the easy chapter)
> I will now work on Chapter 2 the scope and send out an update later
Regarding the "Source Code Review" I believe it would be interesting
to point out (after point '5' Use what you have learned. ) that many
companies should make an effort in order to design security related
functionality (session management, input validation, etc..) in a way
that makes it possible to share this code amongst different projects.
It might be really obvious, but we've had some requests from big
companies that were interested in having a "library" of security
functions that could be used by the company's programming teams in
order to avoid programmers solving issues in different ways. After
all, if you are developing, for example, an ODBC connector, there are
some things regarding input validation that you want to cover in a
generic way (in order to avoid SQL injection) regardless of wether you
do a deeper input validation in the code (i.e. accept only
alphanumeric chars for a given parameter)
Regarding the "e. Application’s Fall and Recovery", shouldn't it be
"e. Application’s Failure and Recovery"? Also, it might be interesting
to point out that web applications should be designed in such a way
that there is no single point of failure.
In "Principles of Testing" I'm missing something on the lines of:
"Don't expect to find _all_ the problems when doing a security test of
an application. With very complex applications full coverage (both in
source code review and black box testing) might be next to impossible.
It is thus, very important to discover trends of insecure uses, that
is, mistakes that are often repeated regardless of wether they lead to
security issues or not. For example, if the web application is made up
of 10 small applications, only 5 are tested and 3 of them do not do
proper input validation (even if not directly exploitable to
compromise the server or data) you can expect the remaining (untest) 5
to also have these same issues. Since testing is, at the end, limited
in scope by time, it might provide more valuable lessons if a global
issue (affecting all aplications) is uncovered than saying "there is a
security issue here and here". The first one can lead to a revisiting
of the programming development methods which will improve all
applications while as the second one will lead to a single bug getting
fix (but many more might lie uncovered)"
I believe this is specially true in the case of black box testing of
finished applications (as part of a penetration test) and I've
experienced this in many ocasions. I know this has been discussed
already in the list, sorry if this is repeating the obvious.
I'm sorry I haven't contributed comments to previous drafts. Sorry.
BTW, are you planning to include the stuff we wrote back in
october-november? That could make a nice Appendix IMHO.
More information about the Owasp-testing