Date: Mon, 18 Jul 2016 12:12:11 +1000 From: David Black <dblack@...assian.com> To: cve-assign@...re.org Cc: oss-security@...ts.openwall.com Subject: Re: CVE request for the Play Framework On 15 July 2016 at 21:54, <cve-assign@...re.org> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > > In version 2.5.0 of the Play Framework a CSRF bypass that depends upon > > an implementation bug in chrome's beacon api was fixed. > > We think additional information would help in deciding whether this is > commonly recognized as a Play Framework vulnerability (which would > have a CVE ID) or Play Framework security hardening (which would not > have a CVE ID). Our understanding thus far is: > > - Play Framework is not an Atlassian product > Correct. > > - > https://github.com/playframework/playframework/pull/5527#discussion-diff-51786858 > says "In order to make Play's CSRF filter more resilient to > browser plugin vulnerabilities and new extensions, the default > configuration for the CSRF filter has been made far more > conservative." > > - Chromium issue 490015 has some debate about whether it is a > Chrome/Chromium vulnerability, e.g., "The issue is whether it's > the browser responsibility to act as a nanny to weak websites, or > we should leave weak websites as sacrifice for great justice." > versus "To be clear, this is a security bug ... There is a > security bug in Chrome, but no action is being done." > > Typically, it would be best not to have a CVE for Play Framework if > the essence of the Play Framework problem is "the product did not > proactively add workarounds for all browser-level vulnerabilities that > might be discovered later." > Perhaps the question(s) should also be - "should a CVE be assigned to chrome/chromium?" or perhaps in general for CSRF protection implementations that make an assumption that at least currently does not hold up in a widely used browser (content-type is not as restricted in cross-domain requests as some have assumed) ? -- David Black / Security Engineer.
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ