Date: Wed, 25 Jun 2014 19:07:27 -0400 (EDT) From: cve-assign@...re.org To: vdanen@...hat.com Cc: cve-assign@...re.org, oss-security@...ts.openwall.com Subject: Re: Question regarding CVE applicability of missing HttpOnly flag -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 There admittedly isn't a precise distinction between "opportunity for security improvement" (a CVE ID cannot be assigned) and "exposure" (a CVE ID can be assigned in some cases). In web applications that function correctly with the HTTPOnly flag for a cookie, absence of this flag might be categorized as a CWE-668 ("Exposure of Resource to Wrong Sphere") issue. In general, factors that can be considered include: -- are there compatibility downsides to setting the flag? (An example of a downside might be: a popular but noncompliant browser completely ignores the cookie if the flag is set.) [ Obviously each CVE assignment is on a per-product basis, and there wouldn't be a CVE about HTTPOnly if a product's design relies on script access to a cookie. ] -- does the flag interfere with plausible use cases? (An example of a use case might be: script code that doesn't need to know the value of a cookie, but was designed to read the cookie anyway to assess whether an attack involving long cookie values is occurring.) -- are there vendors who recommend against the flag? -- compared to the development cost in arranging for the flag to be set, is it possible that the real-life benefit is too small? -- are there other known or potential costs to setting the flag? (There might not be a good example here, e.g., there probably aren't bandwidth considerations where 9 or 10 more bytes is a deal breaker.) If the answer to all of these questions is no, then it starts becoming reasonable to argue that absence of the flag is an implementation error. > like running SELinux (or AppArmor), running a virus scanner, and > having a firewall All of those seem to, in practice, have a relatively much greater chance of introducing new vulnerabilities because of the required implementation complexity. - -- CVE assignment team, MITRE CVE Numbering Authority M/S M300 202 Burlington Road, Bedford, MA 01730 USA [ PGP key available through http://cve.mitre.org/cve/request_id.html ] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (SunOS) iQEcBAEBAgAGBQJTq1TxAAoJEKllVAevmvmsyjwH/1x0dPNXz53WnUklU1uzNLNt h7SGdpfpiwjsiPADMj4aJNhJEQsZWcmmyDqgc7NINOyh1C0eUyG5y9zB8Sn+MAgy MnaVvNfhiP1MWFZ5fZdJ1WCY2stCyTDYlvYpxVPQtxdIKqpSlCS6wBEqDmripWx+ y7sTK1iShNUYc0TQMcYmy6STChjscxZixInLxOA7LZqAksKrQuKH4n8R1vnZ7YU8 m5CKE0sPXiNasijf2UPUTyTEe3wYVFInbkV2TDYmaPQol9Ym749tdb5913l+LfBT dYUHJRighPzWjxw0lxjlQgRovk1vsCtc4y4c+uKSA3lb03tWIr+Cwobt1GS47gs= =MYyX -----END PGP SIGNATURE-----
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.