Re: Question regarding CVE applicability of missing HttpOnly flag

["Vincent Danen" <vdanen () redhat com>]

On 06/25/2014, at 17:07 PM, cve-assign () mitre org wrote:

> 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.

Your answers are fair, but I don't (personally) see how something being "easy" to implement makes the absence of it a 
flaw.  I mean, HttpOnly is a mechanism to prevent a flaw (in something else) from being exploitable.  That by its very 
definition is something like SELinux, or a firewall, etc.  The presence or absence of HttpOnly doesn't create the flaw, 
the faulty software does.  I mean, the flaw is still there, and would still need to be fixed, HttpOnly is a bandaid.  A 
very useful one, as bandaids often are, but it's still a bandaid.  It doesn't fix a flaw, nor does its absence create 
one.

"Implementation error" sounds, to me, like a bug.  Not a flaw.  The criteria set out doesn't really seem to define 
whether something is a flaw, but rather the business case for whether or not to call it one (is it too expensive to 
implement, is it worth it, does it make life more difficult for people, etc.).  Maybe I'm wrong or naive, but I wasn't 
under the impression that business-based use-cases (such as development cost/effort) had any impact on whether or not 
something is a security flaw -- I mean, it either is or it isn't.

Anyways, I was largely thinking out loud here to see what others thought about this as well.  I don't necessarily 
disagree with your reasoning, but I'm still not convinced that the absence of HttpOnly is a security _flaw_, regardless 
of how useful it might be.  Even Kurt's argument about everything containing XSS doesn't make me think that the lack of 
HttpOnly is a flaw -- the flaw is in the software.  Again, pointing to SELinux, even if we turned it on by default and 
made it available to the operating system, and if SELinux renders an exploitable flaw entirely ineffective, that 
doesn't make the flaw "not a flaw"; the flaw is still there and it's assigned a CVE.

Kurt's argument about everything having an XSS makes it sound like, and the reasoning provided here as well, that we 
should no longer consider XSS a security flaw, but the absence of HttpOnly the security flaw.  I mean, if setting this 
flag "fixes" all XSS issues, then we should no longer be assigning CVEs to XSS issues, only to web servers/services 
that do not set HttpOnly or browsers that do not respect/handle it properly.  They can't _both_ get CVEs or be 
considered flaws, can they?

I guess this is the ground where things get a little muddy.  =)

-- 
Vincent Danen / Red Hat Product Security

Attachment: signature.asc
Description: OpenPGP digital signature