Handle case where site property is an array in DAST report
Related issues:
- https://gitlab.com/gitlab-org/gitlab-ee/issues/11380
- https://gitlab.com/gitlab-org/gitlab-ce/issues/61264
What does this MR do?
In some cases, the site
property in DAST reports might be an array instead of an object, which prevents the frontend from parsing the report properly since it expects an object.
This MR fixes this issue by handling both cases.
Before the fix
Here's what we would see before the fix, the security dashboard reports no DAST vulnerability, even though some have been reported by the backend:
After the fix
Once fixed, DAST vulnerabilities are properly extracted out of the site
array and displayed in the UI:
How to test this?
To test this on your local EE instance:
- Make sure your
master
(or default) branch has a DAST job setup - In the DAST JSON report, convert the
site
property into an array (or use the sample JSON below) - Run a pipeline on that branch
- Open the project's security dashboard or the Security tab in the pipeline details page
You should see some DAST vulnerabilities being reported.
gl-dast-report.json
{
"site": [
{
"alerts": [
{
"sourceid": "3",
"wascid": "15",
"cweid": "16",
"reference": "<p>http://msdn.microsoft.com/en-us/library/ie/gg622941%28v=vs.85%29.aspx</p><p>https://www.owasp.org/index.php/List_of_useful_HTTP_headers</p>",
"otherinfo": "<p>This issue still applies to error type pages (401, 403, 500, etc) as those pages are often still affected by injection issues, in which case there is still concern for browsers sniffing pages away from their actual content type.</p><p>At \"High\" threshold this scanner will not alert on client or server error responses.</p>",
"solution": "<p>Ensure that the application/web server sets the Content-Type header appropriately, and that it sets the X-Content-Type-Options header to 'nosniff' for all web pages.</p><p>If possible, ensure that the end user uses a standards-compliant and modern web browser that does not perform MIME-sniffing at all, or that can be directed by the web application/web server to not perform MIME-sniffing.</p>",
"count": "2",
"pluginid": "10021",
"alert": "X-Content-Type-Options Header Missing",
"name": "X-Content-Type-Options Header Missing",
"riskcode": "1",
"confidence": "2",
"riskdesc": "Low (Medium)",
"desc": "<p>The Anti-MIME-Sniffing header X-Content-Type-Options was not set to 'nosniff'. This allows older versions of Internet Explorer and Chrome to perform MIME-sniffing on the response body, potentially causing the response body to be interpreted and displayed as a content type other than the declared content type. Current (early 2014) and legacy versions of Firefox will use the declared content type (if one is set), rather than performing MIME-sniffing.</p>",
"instances": [
{
"param": "X-Content-Type-Options",
"method": "GET",
"uri": "http://bikebilly-spring-auto-devops-review-feature-br-3y2gpb.35.192.176.43.xip.io"
},
{
"param": "X-Content-Type-Options",
"method": "GET",
"uri": "http://bikebilly-spring-auto-devops-review-feature-br-3y2gpb.35.192.176.43.xip.io/"
}
]
}
],
"@ssl": "false",
"@port": "80",
"@host": "bikebilly-spring-auto-devops-review-feature-br-3y2gpb.35.192.176.43.xip.io",
"@name": "http://bikebilly-spring-auto-devops-review-feature-br-3y2gpb.35.192.176.43.xip.io"
}
],
"@generated": "Fri, 13 Apr 2018 09:22:01",
"@version": "2.7.0"
}
What's next?
The fix proposed here simply grabs the first element in site
if it's an array, in the future, we might want to improve on this.
Quoting @gonzoyumo:
the fix is about taking the first item in the array, but we probably need a follow-up about how to handle multiple sites
Does this MR meet the acceptance criteria?
Conformity
Performance and testing
-
Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
Closes #11380 (closed)