Posted by DamienMcKenna on April 4, 2017 at 3:35pm
We have clear(-ish) instructions on how to report a security issue but we don't clearly define what we consider not to be a security problem. It would be useful if we had a clearly defined list of things that are not considered security issues to reduce the amount of issues being opened unnecessarily, thus reduce the amount of time needed to triage the security issue queue; also, this list should either be present on the "how to report" page or at least linked off it right at the top of the page. For example, an error that logs a single watchdog message per (generated) page request should not be perceived to be vulnerable to a DOS attack on the possibility that the server have a large volume of unique uncached page requests
Comments
Security team email templates
Security team email templates are a good starting point what we close regularly in the private tracker https://www.drupal.org/node/1750678
to reduce the amount of
I'm not sure I agree with that goal. It seems useful to know what things people consider to be problems.
Also: we have clear documentation about username enumeration and still get tons of emails/issues opened about it, so I'm not sure if your strategy is likely to be effective at gaining the goal you seek.
knaddison blog | Morris Animal Foundation
we have clear documentation
But where is that information? How far do people have to search before they find this information? That's part of my point. We should have a list of things that are not considered security problems with possibly links to more information / PSAs explaining why.
user name enumeration policy
user name enumeration policy is here: https://www.drupal.org/node/1004778
Where would you like the
Where would you like the information to be?
knaddison blog | Morris Animal Foundation
A page that outlines common identified false positives
Hi,
I think it would help the community to see a page that outlines common false positives identified by security scans. The community could then contributed to the best information to dispute the fall positives. It will also raise the awareness of how to write better code. In the example below, community members would see how RedirectCommand could be used insecurely. Additionally, we could inform scanning services to include keywords like 'RedirectCommand' in their scans to help identify it as a potential vulnerability.
Something like the following for example.
ajax.js : 1164 Cross-Site Scripting: DOM
Abstract: The method redirect() in ajax.js sends unvalidated data to a web browser on line 1164, which can result in the browser executing malicious code.Sending unvalidated data to a web browser can result in the browser executing malicious code.
Code:
<?phpredirect: function (ajax, response, status) {
window.location = response.url;
},
?>
False Positive Disput This method isn't invoked directly. It only redirects when it's used. This is Drupal Ajax framework that allows server side logic to invoke client side methods in a standard way. You can see the server side logic in Drupal\Core\Ajax::RedirectCommand(): https://api.drupal.org/api/drupal/core!lib!Drupal!Core!Ajax!RedirectCommand.php/class/RedirectCommand/8.2.x And, see this test file Drupal\Tests\Core\Ajax::testRedirectCommand(); https://api.drupal.org/api/drupal/core!tests!Drupal!Tests!Core!Ajax!AjaxCommandsTest.php:
Seems like a public page in
Seems like a public page in the area of https://www.drupal.org/docs/8/security would be beneficial? Is there a good place to load up this kind of documentation?
I also have some past examples form Qualys scans.
A new security guide?
The Reporting a security issue page does not provide any indication about username enumeration, nor does it have any links to the page. Also, the Security advisory process and permissions policy page doesn't mention it or link to it. So how are users supposed to discover this information?
I suggest the following:
I'm happy to do this work if there's agreement about it.