Proposes a new layout for the guide contents

[victoriadrake]

Refers to #253 (see issue for full discussion)

[ThunderSon]

I think this should be in draft mode? 😄

[victoriadrake]

Updated list per @rejahrehim's review

[kingthorin]

So you're proposing to drop both section numbers and identifiers?

[victoriadrake]

@kingthorin No; I’ve only left them out until we agree on the ordering. Please see more details in #253.

[kingthorin]

Thanks 🙂 That makes more sense.

[kingthorin]

My only concern is the IG content, otherwise this looks good I think.

[victoriadrake]

Once we’ve come to an agreement, I can address the layout. This file doesn’t actually need to be merged.

[kingthorin]

If people would rather it was more aligned to process flow or basic > advanced then we could do something like:

    README.md (Table of Contents)
    0_Foreword
        README.md (formerly 0_Foreword.md)
    1_Frontispiece
        1.2_About_The_Open_Web_Application_Security_Project.md
        README.md (formerly 1_Frontispiece.md)
    2_Introduction_to_the_Guide
        README.md (formerly 2_Introduction.md)
    Introduction_to_Web_Testing (formerly 4.1_Introduction_to_Web_Testing)
    Information_Gathering (formerly 4.2_Information_Gathering)
    Testing
        Application_Programming_Interface_Testing (formerly Testing_for_APIs.md)
        Authentication_Testing (formerly 4.5_Authentication_Testing)
        Authorization_Testing (formerly 4.6_Authorization_Testing)
        Business_Logic_Testing (formerly 4.11_Business_Logic_Testing)
        Client_Side_Testing (formerly 4.12_Client_Side_Testing)
        Configuration_and_Deployment_Management_Testing (formerly 4.3_Configuration_and_Deployment_Management_Testing)
        Cryptography_and_Encryption_Testing (formerly 4.10_Testing_for_Weak_Cryptography)
        Error_Handling_Testing (formerly 4.9_Testing_for_Error_Handling)
        Identity_Management_Testing (formerly 4.4_Identity_Management_Testing)
        Input_Validation_Testing (formerly 4.8_Input_Validation_Testing)
        Server-Side_Request_Forgery_Testing (formerly Testing_for_Server-Side_Request_Forgery.md)
        Session_Management_Testing (formerly 4.7_Session_Management_Testing)
    Reporting (formerly 5_Reporting)
    Appx.A_Testing_Tools_Resource
    Appx.B_Suggested_Reading
    Appx.C_Fuzz_Vectors
    Appx.D_Encoded_Injection
    Appx.E_Misc

[victoriadrake]

@kingthorin That keeps the progression and is still an improvement organizationally. I’m down.

@ThunderSon does this address your above comment?

[MatOwasp]

In version 4 we put the paragraphs in order of testing. I mean for example after testing the authentication you will test the Authorization than Session Management and so on. I'd prefer that the paragraphs will be shown following the methodology of testing. What do you think?

[victoriadrake]

@MatOwasp Do you mean the order shown in the v4 description of Phase 2? (Page 28)

If so, and we take that ordering as a source of truth when it comes to progression, how would we go about deciding where new types of tests should be slotted in?

Also, if it is the purpose of the WSTG to recommend that ordering as a progression, I think that would be better communicated if it were made explicit. For example, using a numbered list and calling each category a “step” instead. Currently, it reads more like many options for types of testing that the user may implement as needed.

[ThunderSon]

What @MatOwasp said is true, yet not a fact. Testing can be done pretty much based on the user's needs. If I am looking for high ROI from my tests, I'll pick the most crucial tests to start with. In terms of testing, I believe that the ordering doesn't matter that much, more so than the document and the engagement (discussion, info gathering, etc.).

The benefits to the new proposal is this: Ordering in Alphabetical order makes it a bit easier to maintain and to map things better in the repository.

We currently use the IDs in a way that allows to do this: WSTG-<Test-Type>-ID -> This <Test-Type> depicts that we are able to play with this around.

This begs the question as well: Why is testing cryptography almost at the end, and not after configuration? The order can definitely be questioned based on knowledge and requirements.

[victoriadrake]

This last commit incorporates the suggestions so far, presenting the Introduction and Information Gathering sections as a progressive flow, then the Testing section, in which the tests are ordered alphabetically.

The test IDs still need to be updated (and added).

[kingthorin]

Thanks!

[ThunderSon]

Let's take it in. I will be reconsidering this and see its pros and cons to later see if this structure will be taken as such, and how different it would feel. Thanks V!

[ThunderSon]

A small new proposition. Layer 4 for the special cases, and removed 1.2 after we took it out.

[kingthorin]

Agreed, closing.

See #253 for further discussion.