[OWASP-TESTING] Testing Part 2 Outline questions

Daniel Daniel at deeper.co.za
Mon Jul 5 07:31:36 EDT 2004


Initially the pentest checklist was started out of a need to have some
kind of document which would make the auditors happy and also provide some
record to people doing the tests of what has been done and what was
At some point it will become an appendix to the testing guide, but for the
meantime i feel it's useful on its own.

The idea of splitting the doc into infrastructure and application has been
raised and i can see how this would benefit the document.

Thanks for the comments, i'll add them to the outline and send an updated
version towards the end of the week.


> 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
> simplified.
> 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 :)
> Cheers,
> Lluis
> .
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> owasp-testing mailing list
> owasp-testing at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owasp-testing

More information about the Owasp-testing mailing list