[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAAYo3BvcTv66Cr5m6p32u+AXLx1eyFwM+mfb2O4rZOHtnk__mw@mail.gmail.com>
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.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
