Javier Fernandez-Sanguino 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
> tonight.

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 mailing list