Add DAST vulnerability evidence to the Security Reports
Problem to solve
We currently don't provide evidence to back up what caused a DAST vulnerability. This makes it hard for a user to verify whether or not the vulnerability is a false positive.
The issues #37027 (closed) and #36332 (closed) propose displaying vulnerability evidence on the Security Dashboard/Pipeline/MR widgets. Any data added to the DAST report to facilitate building these issues will likely not adhere to the Common Report Format. This should be addressed in this issue, that is, an output of this issue should be evidence fields that adhere to the Common Report Format.
Intended users
Proposal
Each vulnerability
in the DAST JSON report should contain an evidence
field. evidence
should be an object, as we expect this to include other fields in future (e.g. request
, response
). The object should contain a field, summary
:
"vulnerabilities": [
{
...
"evidence": {
"summary": "378282246310005; Credit Card Type detected: American Express"
}
}
]
Summary should be made up of the ZAP alerts[].instances[].evidence
and the ZAP alerts.otherinfo
.
Previous proposal
One possible implementation of this might be that we include an evidence
field in each vulnerability. Of course, what information is required in the evidence field is yet to be determined. For DAST, in theory the entire request/response will be useful.
"vulnerabilities": [
{
...
"evidence": {
"summary": "378282246310005; Credit Card Type detected: American Express",
"request": {
"headers": [
{
"name": "Host",
"value": "www.my-target.com"
}
],
"http_version": "1.1",
"method": "GET",
"url": "http://www.my-target.com/fun-times?query=events"
},
"response": {
"headers": [
{
"name": "Content-Type",
"value": "text/html;charset=UTF-8"
}
],
"http_version": "1.1",
"reason_phrase": "OK",
"status_code": "200"
}
}
]
Another option is for the request/response fields to adhere to the HAR format.
Implementation
When a vulnerability is found, ZAP produces in the JSON output the following properties:
-
alert.otherinfo
: More information related to the context of the vulnerability. This is set by each vulnerability rule, so it use varies. Examples:<p>Credit Card Type detected: American Express</p>
<p>Failed to connect.</p><p>ZAP attempted to connect via: https://vulnerabletestserver:443/</p>
<p>NOTE: Because of its name this cookie may be important, but dropping it appears to have no effect: [JSESSIONID] </p><p>Cookies that don't have expected effects can reveal flaws in application logic. In the worst case, this can reveal where authentication via cookie token(s) is not actually enforced.</p><p>These cookies affected the response: </p><p>These cookies did NOT affect the response: JSESSIONID</p><p></p>
-
alert.instances[].evidence
. A specific value to help users know more about the issue. This is also set by each vulnerability, so its use also varies. Examples:378282246310005
<form method="POST" style="width: 200px;" action="/WebGoat/login">
Set-Cookie: JSESSIONID
The new field, evidence.summary
, should be made up with the following logic:
-
evidence.summary
:=alerts[].instances[].evidence
;alerts[].otherinfo
. - If there is no
evidence
orotherinfo
, then the fields do not need to be separated by;
- HTML tags should be stripped from
alerts[].otherinfo
- Superfluous whitespace should be removed
Out of scope
- Adding the
request
/response
toevidence
. This will be completed in #36332 (closed)