[OWASP-TESTING] Testing Part 2 Outline questions

Lluis Mora llmora at sentryware.com
Mon Jul 5 08:14:17 EDT 2004

Hi all,

The Pentest Checklist lists a few checks to be performed that more or less
map to those on the ouline of the Part 2 document. Is this meant to be
synchronized in some way or is the checklist a separate document - I read
somewhere that the checklist might become an Appendix to the Part2 document,
just how much of an independent document is it and should the P2 document be
shaped around the pentest checklist (or the other way around)?

A few comments on the P2 outline (rev 0.3):

Configuration Management Infrastructure
- I would add "Reviewing virtual hosts configuration", this is something
listed in the Pentest checklist, but missing from the Phase2 outline.

Configuration Management Application
- "Process permissions" will be related to OS functionalities such as the
user that is running the webserver/applications, doing privilege/process
space separation, etc. Are we going to include here things such as running
in chroot()ed environments, using host-based security (grsec, etc...), at
least as a reference or is this outside the scope of the document?

Input injection
I would add double "url-decoding" (e.g. %252e)

Buffer overflow
I understand this has to be a basic introduction to the various scenarios
where overflows could turn into vulnerabilities. If so, I would add "Heap
management bugs (free() / malloc() bugs)"

I think that most of the testing will be at two levels: Infrastructure (web
server, environment, application server... - mostly related to configuration
management) and Application (authentication, parameter manipulation... -
mostly related to problems within the actual development of the
application). Although some of the subjects may overlap (for instance
session management can be performed by the underlying platform or the
application itself) I think it would be to our advantage to clearly separate
both levels: first give guidelines on how to test the underlying platform,
without taking into account the actual application running on top of it,
then provide tests for the application, assuming the underlying platform has
been properly reviewed. The outline is mostly structured in sections that
relate to the infrastructure or application levels, it is just a matter of
shifting them around.

This approach could be also useful when we come down to the Application side
of the document. I would start at the basic checks (input filtering,
parameter normalization...) and move up from there, so that things at a
higher level (e.g. directory traversal) do not have to include references to
it. Let me give you an example with directory traversal:

When checking for directory traversal, you can (arguably) just check for
"../". But the parameter can also be url-encoded, or encoded using unicode,
or have non-normalized paths ("e.g. ././//..//), etc. If we got input
filtering/parameter normalization out of the way before talking about
directory traversal, the description and readability could be greatly

More on document scope: HTTP is a huge protocol, and most of the protocol
processing can be performed by the underlying platform or the application
itself. Just how much do we want to get into those? For instance we could
write on Transfer-Encoding manipulation (badly-formed chunk data) or MIME
parsing (multipart form submissions) which are usually taken care of by the
platform - but then some technologies leave it up to the application (CGI
comes to mind). What is the general feeling on where (if at all) should we
draw a line? (my personal opinion is to assume a high-level platform and
forget about low-level nightmares, focusing on the non-protocol related
development problems).

If this has been already discussed let me know, I am new to the list and
have spent just a moderate time reading through the archives :)



More information about the Owasp-testing mailing list