Wstg: Standardizing capture output

[victoriadrake]

Discussion in #573 brought up the point of adding a standard format for capture output to the contribution guide. This would exemplify how much information from the capture to provide, as well as the format to provide it in.

The goal is to present the information in an easy-to-read format, with a level of accuracy that is appropriate for educational purposes.

The last iteration of the proposed format is:

Request:

Request URL: https://site-under.test/securityRealm/createAccount
Request method: POST
...
POST data:
username=user456
fullname=User 456
password1=My-Protected-Password-808
password2=My-Protected-Password-808

Response:

Response headers:
HTTP/1.1 200 OK
Set-Cookie: JSESSIONID.a7731d09=node011yew1ltrsh1x1k3m6g6b44tip8.node0; Path=/; Secure; HttpOnly

_Originally posted by @victoriadrake in https://github.com/OWASP/wstg/pull/573#issuecomment-703983146_

Any further discussion points or iterations that better achieve the goal are welcome! Otherwise, this issue is for the implementation of the new standard form in the contribution guide and test case examples.

[patrickceg]

I won't have time until later this week to even know if I'll have the time for this task, but I think the first step would be to know which of the articles either have captures or should have captures. This is both for follow-up tasks and to know if that format fits all the other articles.

For example, that format may make less sense if you have multiple captures in a row (since you'll take up more vertical space). It would be good to know if any test cases have a chain of requests (for example if the attack contains intentionally invalid items like multiple redundant request headers: I've seen that in some attacks that fool content delivery networks - CDN).

[ThunderSon]

I prefer having the raw HTTP requests and responses, instead of cleaning them up for readers. That's how they'll be seen everywhere.
Everything that is not relevant to the test scenario at hand is removed, except the first 2 lines (GET / .... HTTP/1.1 and Host) for example. If let's say this is testing auth, a cookie or a token should be present, or a certain service fingerprint.

[kingthorin]

I'm in agreement with @ThunderSon.

[patrickceg]

We should also pick a way to cut out excess information, preferably some way that doesn't mess with all the format scripts. I think ellipsis with no surrounding brackets, so ... seemed to work for the issue I worked on.

Things I think won't work

• <> is bad because it would mess with XML and HTML contents
• Quotation marks in general cause a mess

[github-actions[bot]]

Please comment if you are still working on this issue, as it has been inactive for 30 days. To give everyone a chance to contribute, we are releasing it to new contributors.