[Owasp-testing] Plan for OTGv5

Ismael Rocha ismaelrocha.projetos at gmail.com
Fri Mar 3 22:35:54 UTC 2017


Hello Safuat,

Good points. I have some comments on a few of them:

1. OTG should get in line with OWASP ASVS Level 1 (according to "them"
they are currently working on 3.1 with the goal to make every Level 1
item pentestable, see
http://lists.owasp.org/pipermail/owasp-application-security-verification-standard/2017-January/001017.html
) Thus, a mapping like OTG-uvw = ASVS Vx.yz would be an obvious thing
to do (and not doing this is yet another missed chance to foster
consistency - yes, in the past OTG and ASVS were contradicting at some
points). Specifically, let's talk to the ASVS folks!
IG: I think if we focus only on ASVS Level 1 we will miss good points
based on ASVS Levels 2/3.  Also, some itens of ASVS is more related to
development process/definition os security requirements/documentation
than the practical security aspects of an application. Then, it would
feet on a process auditing rather then application security testing
(E.g. Verify that all application components are identified and are
known to be needed).
My suggestion is to keep a mapping between OTG / ASVS but not limit it
to ASVS 1. Eventually we might have n OTG itens to 1 ASVS item.
Also, ASVS presents Mobile requirements. Are we going to address
Mobile Apps in the OTG? Should we joing forces with people from OWASP
MTG?

4. Now I get to the core: the actual items are sometimes overlapping,
unclear, or not consistent. For instance, AUTHN-004 is a mess. Why on
earth is session ID prediction there, if SESS-001 would be a more
obvious place? And many other items that I would like to discuss
later. Moreover, both, ASVS and WAHH have items that are not covered
by OTG. (For instance, directory browsing which I use to cover under
CONFIG-002 - not because it belongs there but because I didn't find a
better place.) Further, there are some pentesting cheat cheats whose
wisdom should be included into OTG, e.g. XSS Filter Evasion and REST
Assessment.
IG: here we would need to review testing items that could be
collapsed, news to be added/ and items to be removed. Maybe start with
a small group of people to bring a new version and present that later
with everybody?

Ismael Goncalves
https://sharingsec.blogspot.com

On Tue, Feb 28, 2017 at 11:01 AM, Safuat Hamdy <safuat.hamdy at secorvo.de> wrote:
> Now that there are so many volunteers the obvious question is how to proceed.
>
> As I told Matteo, a good entry point would be to collect issues with v4. To give it a start, here are some that I have:
>
> 1. OTG should get in line with OWASP ASVS Level 1 (according to "them" they are currently working on 3.1 with the goal to make every Level 1 item pentestable, see http://lists.owasp.org/pipermail/owasp-application-security-verification-standard/2017-January/001017.html ) Thus, a mapping like OTG-uvw = ASVS Vx.yz would be an obvious thing to do (and not doing this is yet another missed chance to foster consistency - yes, in the past OTG and ASVS were contradicting at some points). Specifically, let's talk to the ASVS folks!
>
> 2. OTG is quite unbalanced at some items. Compare INFO-002 (almost trivial) and INPVAL-005 (epic) for instance. Some items appear (to me) sub-items of something larger, while especially INPVAL-005 is simply too deep. Other items like AUTHN-004 or AUTHZ-004 have sub-items. The questions to me are: How much practical guidance should each item contain? And how should that be presented? And how balanced should the items of OTG be?
> At this point I want to throw in another invaluable source for web app pentesting, namely the Web Application Hacker's Handbook (WAHH). Chapter 21 there presents a methodology similar to what OTG (or ASVS L1) try to achieve, while the preceding chapters are actually the technical guidance. The ASVS is the exact opposite: There they say things like "verify that this and that" and leave it to the reader to find out what to do in order to verify. What I envision for OTG is something similar like WAHH, but reverse: present the methodology first and postpone technical guidance (at reasonable depth) to supplementing appendices. This way the main text body becomes more crisp and clear, and methodology ("what do I need to do, and what is expected") is separated from technical guidance ("how do I get to the verdict").
>
> 3. Tools: OTG mentions tools a part of almost every item, and in many cases it is a proxy, where sometimes it is ZAP, sometimes it is  Burp, sometimes it is WebScarab (Huh? Is that maintained, or is that OWASP archeology?). See e.g. AUTHN-004. I guess, the mentioning of specific tools can be factored out and moved to a section on tools.
>
> 4. Now I get to the core: the actual items are sometimes overlapping, unclear, or not consistent. For instance, AUTHN-004 is a mess. Why on earth is session ID prediction there, if SESS-001 would be a more obvious place? And many other items that I would like to discuss later. Moreover, both, ASVS and WAHH have items that are not covered by OTG. (For instance, directory browsing which I use to cover under CONFIG-002 - not because it belongs there but because I didn't find a better place.) Further, there are some pentesting cheat cheats whose wisdom should be included into OTG, e.g. XSS Filter Evasion and REST Assessment.

> 5. Most items start with "Test for xyz" which gives at least a vague idea of what to do, and in most cases, what to expect. So later you can assign a verdict like "ok" or "not ok because...". INFO seems to be an exception, but even there you can give a verdict, except for INFO-006 and INFO-007. These two are pure reconnaissance, while other can result in a verdict (e.g. INFO-008: Using a framework with known issues? - not ok - INFO-002: webserver leaks detailed version information - not ok - and so on). Reconnaissance should be drawn out of the main testing chapter (cf. Sections 1 and 2 of Chapter 21 in WAHH), my take on OTG is that each testing item should - if applicable - result in a verdict.
>
> 6. Perusing several items of the OTG and the according examples, the items and examples seems to reflect the good old monolithic PHP application as was custom ten years ago, but for modern applications OTG appears less a guidance on pentesting. This should be addressed for OTGv5. Yes, the CLIENT section has some stuff in that direction but there is still room for improvement.
>
>
>
> And some more, but this should do for starters.
>
>
> Regards
> Safuat Hamdy
> _______________________________________________
> Owasp-testing mailing list
> Owasp-testing at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-testing



-- 
Ismael Gonçalves


More information about the Owasp-testing mailing list