Provide the ability to remove alerts from reports by marking as false positive

[binarymist]

There's an option in the Zap API to updateAlertsConfidence for specific alerts. We can change the confidence level to 0 - False Positive. This doesn't change the number of alerts raised, but the specific alert won't be included in the reports. We've tested HTML and JSON reports.

After a scan has finished, fetch all alerts with: http://localhost:8888/HTML/alert/view/alerts/?baseurl=&start=&count=&riskId=

Which returns an object with an alerts array like so:

{
  "alerts": [
    {
      "sourceid": "3",
      "other": "86400000, which evaluates to: 1972-09-27 12:00:00",
      "method": "",
      "evidence": "86400000",
      "pluginId": "10096",
      "cweid": "200",
      "confidence": "Low",
      "wascid": "13",
      "description": "A timestamp was disclosed by the application/web server - Unix",
      "messageId": "",
      "url": "https://firefox.settings.services.mozilla.com/v1/buckets/main/collections/message-groups/changeset?_expected=1595616291726",
      "reference": "http://projects.webappsec.org/w/page/13246936/Information%20Leakage",
      "solution": "Manually confirm that the timestamp data is not sensitive, and that the data cannot be aggregated to disclose exploitable patterns.",
      "alert": "Timestamp Disclosure - Unix",
      "param": "",
      "attack": "",
      "name": "Timestamp Disclosure - Unix",
      "risk": "Informational",
      "id": "7",
      "alertRef": "10096"
    },
    {
      "sourceid": "3",
      "other": "604800000, which evaluates to: 1989-03-02 13:00:00",
      "method": "",
      "evidence": "604800000",
      "pluginId": "10096",
      "cweid": "200",
      "confidence": "Low",
      "wascid": "13",
      "description": "A timestamp was disclosed by the application/web server - Unix",
      "messageId": "",
      "url": "https://firefox.settings.services.mozilla.com/v1/buckets/main/collections/cfr/changeset?_expected=1637772466266",
      "reference": "http://projects.webappsec.org/w/page/13246936/Information%20Leakage",
      "solution": "Manually confirm that the timestamp data is not sensitive, and that the data cannot be aggregated to disclose exploitable patterns.",
      "alert": "Timestamp Disclosure - Unix",
      "param": "",
      "attack": "",
      "name": "Timestamp Disclosure - Unix",
      "risk": "Informational",
      "id": "14",
      "alertRef": "10096"
    },
    {
      "sourceid": "3",
      "other": "1073741823, which evaluates to: 2004-01-11 02:37:03",
      "method": "",
      "evidence": "1073741823",
      "pluginId": "10096",
      "cweid": "200",
      "confidence": "Low",
      "wascid": "13",
      "description": "A timestamp was disclosed by the application/web server - Unix",
      "messageId": "",
      "url": "https://my.domain.com/static/js/2.4eed2cb1.chunk.js",
      "reference": "http://projects.webappsec.org/w/page/13246936/Information%20Leakage",
      "solution": "Manually confirm that the timestamp data is not sensitive, and that the data cannot be aggregated to disclose exploitable patterns.",
      "alert": "Timestamp Disclosure - Unix",
      "param": "",
      "attack": "",
      "name": "Timestamp Disclosure - Unix",
      "risk": "Informational",
      "id": "61",
      "alertRef": "10096"
    }
  ]
}

There could be hundreds or thousands of alerts.

We could have an updateAlertsConfidence property on the attributes property of the Job's appScanner resource object that has a value like the following:

[{
  confidenceId: <number> // [0 | 1 | 2 | 3 | 4] 0 being false positive
  filter: {
    name: <String>
    cweid: <String> 
    wascid:  <String>
    confidence:  <String>
    risk:  <String>
    description:  <String>
    url:  <String>
  }
}]

The Build User could provide none to all of the filter properties. Start off by providing a limited subset like the above.

Where an alert has all of the filter property values that match a given element's filter property properties of updateAlertsConfidence then take it's id and the confidenceId provided by the Build User and feed them to: http://localhost:8888/UI/alert/action/updateAlertsConfidence/

So we'd be filtering the alerts array with the filter property values that the Build User provides, then using the filtered alerts id's to invoke the Zaproxy API updateAlertsConfidence end-point for every element of updateAlertsConfidence property in the Job file.

The Zaproxy API calls would be in the PostScanning strategy.

[binarymist]

Also read this: https://www.zaproxy.org/faq/how-do-i-handle-a-false-positive/

[shaneg07]

Hi @binarymist, could you please assign me to this issue?