Adding sections (description, impact...) for reports

[JulianGR]

Hello,

Context:
I work as a penetration tester and when we finish an audit we have to hand in a report. In such report we aim a lesser technical profile (managers) and a more technical profile (developers or other pentesters). When writing the details of each vulnerability, we are expected to provide a description, impact, exploitation steps, remediation recommendations, references...

The issue:
Here in section 3.2 Finding details, the guide recommends what to report (title, impact, description and so on). However, these sections are not present in the vulnerabilites themselves: taking IDOR as an example, while it's true that there is a summary section, there is no high-level description, no impact, no remediation recommendations and so on.

What I request:
After being in a couple of companies, I can see that each of them uses an internal database with such sections, so that pentesters dont need to write them every single time they report. Could more sections be added?

I can make the work if you let/ want me to. The idea would be to add to each vulnerability at least:

• High level description
• Impact taking the CIA triad in consideration
• Remediation recommendations

Thanks and keep it up with the amazing kob =)

[rbsec]

Taking IDOR as an example, while it's true that there is a summary section, there is no high-level description, no impact, no remediation recommendations and so on.

The summary contains a description of what IDOR is - but it's aimed at the tester rather than a non-technical manager, because the whole WSTG is intended to be used by testers. And while there could potentially be a less technical version of it added, the high level description you give in a pentest report should explain the issue in the context of the environment - which needs to be bespoke text.

It's true that there's no recommendation - many of the other sections in the WSTG have (brief) recommendations, so that one might just be an oversight. Although IDOR issues are often bespoke enough that generic recommendations aren't too useful

But what is the CIA impact of IDOR? It could be anything from minor information leakage, to allowing users to steal money on a banking application, to physical destruction and loss of life on a SCADA application. Impact and likelihood can only really be assessed in the context of the application and environment that you're testing - you can't just take generic text and values for them.

There's also the problem that there isn't a 1:1 mapping between sections in the WSTG and issues in a report. For example, what would the impact and likelihood be for the Test Payment Functionality page? You could have a dozen or more issues from that section alone, so trying to add all those sections for every possible issue related to the guide wouldn't really work.

---

Ultimately, I think this comes down to a question about the scope of the project (which is more one for @kingthorin and @ThunderSon). There's certainly value to a "common issues" type database (although there's also a lot of problems with it), and it's always slightly irked me how every pentesting company makes their own, with huge duplication of effort. But I'm not sure that would be part of the the Web Security Testing Guide.

I wonder if a public common issues/vulnerabilities database would make sense as its own OWASP project? I'm sure that there would be some argument about the format of them, but if your company is interested in open-sourcing their database then I'm sure there would be interest in that from the community.

[JulianGR]

I agree that this Web security testing guide might not be the project for such requests, but its the closest I could find, that's why I opened the issue here.

[...] give in a pentest report should explain the issue in the context of the environment - which needs to be bespoke text.

[...] testing - you can't just take generic text and values for them.

Yes that's true, but the goal is not to provide the perfect description, but rather a template so that less writing is needed, and also to avoid repeating the same vulnerabilty descriptions every time.

I wonder if a public common issues/vulnerabilities database would make sense as its own OWASP project? I'm sure that there would be some argument about the format of them, but if your company is interested in open-sourcing their database then I'm sure there would be interest in that from the community.

I haven't reach out to them with these ideas, therefore I can't share many details, but I'm sure an example won't violate any policy:

We have a big spreadsheet with manual-made description, impact, remediation, OWASP ID, CWE and so on. In each row we have each vulnerabilty, and the columns represent said sections (you can see the exact columns belows). One example:

---

OWASP WSTG: WSTG-CONF-04
CWE: CWE-200, CWE-530
CATEGORY: Configuration and Deployment Management
SUBCATEGORY: Application configuration
VULNERABILITY: Backup File Identification
POSITIVE ASPECT: No application backup files were found accessible.
TITLE: Backup file identification
DESCRIPTION:
"A major source of vulnerability lies in files that have nothing to do with the application, but are created as a result of editing application files, or after creating backups on the fly, or by leaving old files or unreferenced files in the web tree.On-the-fly editing or other administrative actions on production web servers can inadvertently leave backup copies, generated automatically by the editor while editing files, or by the administrator who is compressing a set of files to create a backup.

Editing files may leave automatic backup copies of type .bak, .sav, .old, or ~. The web server does not have by default defined an interpretation for this type of files, so the result is usually either to display their contents or to proceed to download them.

In this case, the identified file [EXPLAIN]"

IMPACT:
The presence of such files can reveal sensitive information and give the attacker access to internal workings, backdoors, administrative interfaces or even credentials to connect to the administrative interface or database server and even confidential information such as source code for company applications. In this case, [EXPLAIN WHAT INFORMATION IT DISCLOSES].

REMEDIATION:
"It is necessary to delete the backup file found in order to eliminate the risk. To resolve this type of defect in general, it is necessary to periodically search the server for files with the extensions .bak, .bac, .sav, .old, .BAK, .BAC, .SAV, .OLD, ~, .tar, .gz, .tgz and remove them from the server.

Additionally, for extra precaution it is recommended to configure the web server to be able to interpret these extensions, so as not to cause the file to be downloaded or the browser to display the contents of the file.

File system snapshots should not be accessible via web if the document root is on a file system that uses this technology. Configure your web server to deny access to such directories, for example, in Apache a location directive like this should be used:

<Location ~ "".snapshot"">

Order deny,allow

Deny from all

"

REFERENCES:
"+ https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/04-Review_Old_Backup_and_Unreferenced_Files_for_Sensitive_Information

• https://cwe.mitre.org/data/definitions/200.html
• https://cwe.mitre.org/data/definitions/530.html"

RECOMMENDED CVSSv3.1:
CVSSv3.1: 7.5 HIGH AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
[REMEMBER TO CHANGE IF NECESSARY]

---

This project is far from being perfect for various reasons:

• The list is incomplete
• Sometimes, CWE changes and the codes don't match anymore, or the references fields contains broken links.
• All sections are made by us manually. That means that there may be inacuracies or they could be better explained.

However, it is very useful for us. We have a tool that parses the spreadsheet and fills a docx with the information of the spreadsheet. As you can see, some sections contains annotations such as "In this case, [EXPLAIN]", which means that we have to manually write what was it about regarding the context, but at least we skip the general description.

I really think that a big spreadsheet like such, maintained by community, is much better than one made internally.

[kingthorin]

While I agree that there's arguably a need to simplify or centralize those details I don't think the WSTG is the place for it.

[rbsec]

@kingthorin are you aware of any OWASP (or non-OWASP) projects that this might fit in? Or is it perhaps something that could/should be a new one?

[kingthorin]

Hmmm good question(s), I’ll put some thought into that.

[JulianGR]

ping @kingthorin @rbsec

[kingthorin]

I haven’t been able to come up with another project this fits into.

[JulianGR]

I've released the spreasheet with all the vulns here: https://github.com/JulianGR/OWASP_WSTG_ASVS

Maybe you want to check it out and see if you can take benefit from it to WSTG or ASVS =)