Closed hazcod closed 3 years ago
Something like:
Can be generated pretty simply with tree -J -I 'images|README.md|00-*' --dirsfirst > list.json
then using sed
to make some replacements (directory > category, file > test). I had to manually trim a few things but I'm sure they're automateable too. The only thing I have left to sort out is extracting or grepping out the test IDs and maybe trimming/removing .md
.... anyway something can be done simply enough.
It may also be possible to do something with jq
: https://stedolan.github.io/jq/
I can work on it. @kingthorin
@rejahrehim Let's first agree on the structure that this list could hold. Having the IDs as such without anything on top looks to be really basic and raw. For now, I have 2 additional fields in mind. Link to the stable spot of this (or on github, doesn't really matter), and another one which describes the attack. I was thinking that the Test Objective sentences could help with this as they are short and explain what's going to be done in the test scenario.
Open for more suggestions!
Test id like WSTG-ATHN-01
and Test Objective sentences we have to add. Also, what you think of adding cross references to ASVS when its ready?
Can we use WSTG-ATHN
as category ID ?
Category IDs can definitely be used. What do you think about this:
{
"categories": {
"WSTG-INFO": [
{
"Objectives": "<Grab objectives>",
"Reference": "<URL to test 1>",
"CRE_ID": "<CRE_ID1>"
},
{
"Objectives": "<Grab objectives>",
"Reference": "<URL to test 2>",
"CRE_ID": "<CRE_ID2>"
}
],
"WSTG-ATHN": [
{
"Objectives": "<Grab objectives>",
"Reference": "<URL to test 1>",
"CRE_ID": "<CRE_ID1>"
},
{
"Objectives": "<Grab objectives>",
"Reference": "<URL to test 2>",
"CRE_ID": "<CRE_ID2>"
}
]
}
}
The arrays X objects is done for easy digestion by tools. It would start at 0, but people taking this into a tool should know that.
CRE (instead of ASVS) is where the references are happening and should be ready by v5 release, hopefully :crossed_fingers:
@RiieCco Do you think the above is needed Vs. what we're doing in the CRE? The input schema is starting to look like this. The inventory schema is still being built (well hopefully, I'll be done with it by tomorrow).
The suggested schema seems decent. I think we should set the "category" as the actual folder text or whatever (just because it removes any potential confusion around the acronyms in the identifiers), and then we should include the actual identifiers to remove consumers' need to count properly etc. (Which also gives us some future proofing in retiring or merging IDs etc)
If we put category
as actual folder name, then we have to put category Id as WSTG-ATHN
What you think ?
Sure that'd be fine, however if we're including the actual full test id (WSTG-AUTH-01) do we need it? I dunno, I guess there's no reason not to include it as a categoryId.
In the end, in a text based representation that will compress ridiculously well and be consumed by other programs/projects there's not much reason to exclude details. More really can be more.
I thought of adding some identifier that could programmatically validated if used by some tools or scripts.
{
"categories": {
"Information Gathering": {
"id": "WSTG-INFO",
"tests": [{
"name": "Conduct Search Engine Discovery Reconnaissance for Information Leakage",
"id": "WSTG-INFO-01",
"Objectives": "<Grab objectives>",
"Reference": "<URL to test 1>",
"CRE_ID": "<CRE_ID1>"
}]
},
"Authentication Testing": {
"id": "WSTG-ATHN",
"tests": [{
"name": "Testing for Credentials Transported over an Encrypted Channel",
"id": "WSTG-ATHN-01",
"Objectives": "<Grab objectives>",
"Reference": "<URL to test n>",
"CRE_ID": "<CRE_IDn>"
}]
}
}
}
Formatted by: https://jsonlint.com/
CRE_ID
or CRE-ID
Can we use hyphen like WSTG-ATHN-01
@ThunderSon
I doubt it's going to be in the first build of this JSON file. It could be cre
or cre-id
it doesn't really matter. This is used to be consumed.
I like the schema as well. Thanks :smile:
@rejahrehim are you going to be able to tackle this?
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.
@rejahrehim are you going to be able to tackle this?
Started working on it
Once we generated the Json what we have to do? commit back to the repo or we can publish in the web (latest) ? I am planning to trigger it with a Github action. @kingthorin @ThunderSon
For the time being I'd suggest the job should open a PR against the checklist directory.
Yep. Agreed on the location. I would prefer artifacts to be on GH, and not on the website. We can link to them from the website.
Yep. Agreed on the location. I would prefer artifacts to be on GH, and not on the website. We can link to them from the website.
Do we need to upload JSON file as release ?
We can, yes. It'd be easier for people to grab the XLSX and the JSON files from the release as well.
The XLSX can always be attached manually afterwards. I don't want it to delay any of our releases.
It should be possible to attach the JSON to the existing release (which is currently created by the PDF build on tag push [IIRC]).
You're the experts on this, leaving this in your hands :yum:
Hi, I think it would be awesome if we could compile all WSTGs into a JSON format as part of the CI/CD chain, e.g. https://github.com/bugcrowd/HUNT/blob/master/Burp/conf/owasptg.json