[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201406252307.s5PN7RRD020627@linus.mitre.org>
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.
