Link to all possible alerts raised

[psiinon]

On https://www.zaproxy.org/docs/alerts

• Pscan add-on rules
• Ascan add-on rules
• Pscan script rules
• Ascan script rules
• Pscan websocket rules
• Improve content - ensure all details included (will require ZAP code changes)

[rezen]

I'd love to spruce up the template for individual alerts if that would be interesting?
https://www.zaproxy.org/docs/alerts/42/

[psiinon]

@rezen yes please! As you know we're not graphic designers :P
FYI theres an open PR which will slightly change the format, but not that significantly: zaproxy/zap-admin#398

[kingthorin]

I don't want to derail what you've been building but would it be better if the script built json or yaml (vs html) and then the site just had a template or include to display the details.

That'd probably be less finicky and easier to maintain/tweak style-wise in the future.

[psiinon]

Completely agree, but I dont think it derails anything. The changes I've made should make that easier to do.
@rezen can you convert the website to use json or yaml as part of your sprucing up? I can easily change the script to generate the structured data...

[rezen]

So I can think of two paths around the data.

• Option 1 All the data gets placed into site/data/alerts.yaml and each alert still has a generated markdown file but simply with the title, and a reference to the id of the alert.
  • The template would load the data from the data file and inject into the template
  • There could also be a shortcode which renders the alert, with which we could embed alert details other places if it was useful
  • Requires generating an additional file that has all the alerts
  • Using a shortcode for rendering alerts gives more flexibility
  • Having all alerts in one data file enables other people to consume it for other purposes
• Option 2 Instead of having the alert details in each post's body, the details would be in yaml format in the header
  • The template would get the data out of the header
  • No additional files needed
  • Easy to modify current setup

[psiinon]

For me a key requirement is that alert details are always available via a predictable URL based on the alert id - eg https://www.zaproxy.org/docs/alerts/0/
If only one of those options supports this then that the one I think we should use :)
Other than that, the second easier option sounds good to me - theres always plenty of other things we can spend our time on ;)

[rezen]

Both will achieve that option, but Option 2 will have more minimal changes 👍

[rezen]

Okay so I will create a PR with a template. I will adjust the content with the yaml header but omit that from the PR and include a screenshot - that sound good?

[psiinon]

Sounds good to me 👍 If you can give an example of the yaml header you require then I can update the script to generate it.

[rezen]

Here is what it looks like. If this looks ok I'll make the PR

[kingthorin]

Looks good to me, how’s it look on mobile?

[rezen]

Thank you for reminding me!

[rezen]

Okay, about to send the PR, I can also do a PR for the script that generates the new format?

---
title: "Directory Browsing"
name: Directory Browsing
alertid: 0
alert_type: "Active Scan Rule"
alertcount: 1
status: release
type: alert
alert_type: Active Scan Rule
risk: Medium
solution: |
    Disable directory browsing.  If this is required, make sure the listed files does not induce risks.
references:
    - http://httpd.apache.org/docs/mod/core.html#options
    - http://alamo.satlug.org/pipermail/satlug/2002-February/000053.html
cwe: 548
wasc: 48
code:  https://github.com/zaproxy/zap-extensions/blob/master/addOns/ascanrulesBeta/src/main/java/org/zaproxy/zap/extension/ascanrulesBeta/SourceCodeDisclosureGitScanRule.java
date: 2020-08-14 11:48:43.628Z
lastmod: 2020-08-14 11:48:43.628Z
---
<!-- Summary lives down here -->
It is possible to view the directory listing.  Directory listing may reveal hidden scripts, include files, backup source files, etc. which can be accessed to read sensitive information.

[thc202]

How are multiple alerts handled/shown?

[kingthorin]

Questions on the header block:

• Is count really needed?
• Was the duplicate type just a copy/paste issue?
• Title vs. name?
• Do any of the values actually need to be quoted strings?

[rezen]

• @thc202 not sure I understand about multiple alerts - do you mean the alerts list page?
• @kingthorin anything that seems unneeded/duplicate is very likely that. Also I don't think anything needs to actually be quoted.

[psiinon]

@rezen some alerts can raise multiple alerts, and we recently changes the scripting to cope with that = an example is https://www.zaproxy.org/docs/alerts/10020/

[rezen]

To verify, the fields for alerts should be:

• name
• risk
• description
• solution
• references
• cwe
• wasc

so then the schema should be like

---
title: Directory Browsing
alertid: 0
alert_type: Active Scan Rule
status: release
type: alert
alerts:
    - name: Directory Browsing
      risk: Medium
      description: Incomplete ....
      solution: |
        Disable directory browsing.  If this is required, make sure the listed files does not induce risks.
      references:
        - http://httpd.apache.org/docs/mod/core.html#options
        - http://alamo.satlug.org/pipermail/satlug/2002-February/000053.html
      cwe: 548
      wasc: 48
code:  https://github.com/zaproxy/zap-extensions/blob/master/addOns/ascanrulesBeta/src/main/java/org/zaproxy/zap/extension/ascanrulesBeta/SourceCodeDisclosureGitScanRule.java
date: 2020-08-14 11:48:43.628Z
lastmod: 2020-08-14 11:48:43.628Z
---

[thc202]

Yes. What does the summary map to?

[rezen]

Good question 🤔 I think that mapped to description before I understood the model accurately - ignore then!

[iagoscm]

Hello, is this still in need of help?

[kingthorin]

I think so, but you'd have to dig around the extensions repo to figure out which bits exactly.

[thc202]

Closing this one since the website already supports showing the info for all alert types. For further work see/ask in zaproxy/zaproxy#6119 and zaproxy/community-scripts#440.