Since that I found two other that was also on the kit and not listed on Google help page. End of this side of the story, now let start why I’m here.
As I never put any more effort than this email they are no CVE or NVT for those XSS, and even the website listed my original email have still the file present.
I now want to make some effort in order to fix this, so my question are:
Should I ask/create a CVE for those XSS ?
Should I ask/create a NVT ?
In order to create an NVT:
Should I create one per file, or only one for all those file ?
Should I only check the presence of the file, or should I be able to prove the XSS on each file ?
and thanks for for your interest in VT development. The topic is quite interesting and i’m trying to give some answers on the VT side:
When reading your posted link https://support.google.com/admanager/answer/7622991 correctly it seems affected users needs to proactively remove the files and this doesn’t happen automatically? If yes then it could still makes sense to create a VT for those, even if the disclosure was done the last year.
In earlier VT-Development days this was done within one single VT. While this was easier to implement it has various drawbacks i could explain in more detail if required.
Today we’re mostly split such VTs in several files:
One “Detection-VT” for each product/vendor (the provided link is talking about different vendors affected)
One “Vulnerability-VT” for each product/vendor using the collected detection-information of 1.
This depends on how the vendor has mitigated the issue. If there were some updates (like sanitize the user input) to the files itself a check for the presence of the file might be prone to false positives. Thus i’m always in favor to either check the version of a specific file/product (if this is exposed) or doing an active check (prove the XSS) for the vulnerability.
One side-note concerning active XSS tests:
Older VTs had e.g. used something like file.html?parameter=<script>alert(1)</script> and just checked if <script>alert(1)</script> is included in the response to proof the existence of the vulnerability. Such checks are generally quite prone to false positives and its recommended to do a comparison between the vulnerable and fixed version to be able to write a reliable VT.
Related to this i had updated the 2016/gb_cisco_asa_vpn_portal_xss_vuln.nasl VT (should be somewhere in /var/lib/openvas/plugins or similar) a few weeks ago to do such a more reliable test for a XSS vulnerability.
Yes user have to delete those files. The one I have linked into my original email still have the file hosted and the XSS
I’m also on favor to have individual check, but the reported list of file fall in different categories:
Vendor provide file that directly include the XSS (inside the hosted file)
Vendor provide file that include a script loaded from an external source. In thise case vendor may have fixe the issue.
I originally found the XSS for only half of the file that Google suggest to remove. I’m not able to provide (with my skill) active XSS test for the second half of the file.
As I understand, I will wrote individual test. Is it possible for file that I don’t know how the XSS is testable to have some sort of warning ? (I can still regexp part of the file to confirm this is a file from the kit, and not a soft 404)
when re-thinking about this it could be also covered by a single VT similar to the following (found within your current plugin dir):
2018/gb_sensitive_file_disclosures_http.nasl
With this you could define a list of files to check and a regex for each file (with possible extra patterns) and even could add additional known locations (e.g. if you know a specific CMS, Shop or similar has shipped such a file) from additional Detection-VTs of these products.
This could avoid to write 22 Detection-VTs (one for each vendor) and 22 additional Vulnerability-VTs which are around nearly the same issue / vulnerability.