Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ