368502 - Bugzilla_logincookie should not be accessible via javascript

Status: RESOLVED FIXED

(Bugzilla :: Bugzilla-General, defect)

Description

[Olav Vitters]

Bugzilla should prevent the Bugzilla_logincookie from being accessible from javascript. This can be done by using the httponly flag. This is currently only supported by IE6SP1+. This requires CGI 3.21 or newer. My intention is only to set that http flag when the CGI version is new enough.

See also:
bug 178993
http://search.cpan.org/src/LDS/CGI.pm-3.25/Changes
http://msdn.microsoft.com/workshop/author/dhtml/httponly_cookies.asp

Comment 1

[:glob ✱]

Note Bug 178993 tracks httponly support for Firefox.

Comment 2

[Max Kanat-Alexander]

Bugzilla 3.2 is now frozen. Only enhancements blocking 3.2 or specifically approved for 3.2 may be checked in to the 3.2 branch. If you would like to nominate your enhancement for Bugzilla 3.2, set the "blocking3.2" flag to "?". Then, either the target milestone will be changed back, or the blocking3.2 flag will be granted, if we will accept this enhancement for Bugzilla 3.2.

This particular bug has not been touched in over eight months, and thus is being retargeted to "---" instead of "Bugzilla 4.0". If you believe this is a mistake, feel free to retarget it to Bugzilla 4.0.

Comment 3

[Reed Loden [:reed]]

Can we get this in for Bugzilla 3.2?

Comment 4

[Reed Loden [:reed]]

Attachment: patch - v1

This adds -httponly to the CGI send_cookie() code.

Comment 5

[Max Kanat-Alexander]

Comment on attachment 335120 [details] [diff] [review]
patch - v1

A few questions:

1) What about future JSON calls that need to use XHR, do those still work?

2) I'm pretty sure that -httponly should have a value, like 1.

3) CGI.pm 3.21 does not come with Perl 5.8.8, which is annoying, but since we have install-module I suppose it's OK.

Comment 6

[Max Kanat-Alexander]

Not a blocker.

Comment 7

[Reed Loden [:reed]]

(In reply to comment #5)
> 1) What about future JSON calls that need to use XHR, do those still work?

Hopefully bz can answer this.

> 2) I'm pretty sure that -httponly should have a value, like 1.

Yeah, duh. Oops. :(

> 3) CGI.pm 3.21 does not come with Perl 5.8.8, which is annoying, but since we
> have install-module I suppose it's OK.

Most people have newer CGI.pm versions anyway, thanks to distributions shipping them.

Comment 8

[Reed Loden [:reed]]

Attachment: patch - v1.1

Dumb mistake. :(

Comment 9

[Boris Zbarsky [:bzbarsky]]

XHR will send the cookie, I believe.  It just won't expose it to the script.

Comment 10

[Frédéric Buclin]

(In reply to comment #1)
> Note Bug 178993 tracks httponly support for Firefox.

If a web browser doesn't support httponly, what happens?

Comment 11

[Reed Loden [:reed]]

(In reply to comment #10)
> (In reply to comment #1)
> > Note Bug 178993 tracks httponly support for Firefox.
> 
> If a web browser doesn't support httponly, what happens?

Nothing. The browser will (hopefully, if it parses the cookie spec properly) ignore the extra "HttpOnly;" part in the cookie, so it's not protected by this security feature.

Comment 12

[Reed Loden [:reed]]

Attachment: patch - v1.2

mkanat wanted me to move the line addition above the -expires.

Comment 13

[Max Kanat-Alexander]

Comment on attachment 335127 [details] [diff] [review]
patch - v1.2

Okay, great, but also update the relnotes.html.tmpl to note that the version for CGI is new. (Very simple, you'll see.)

Also add a comment that we require CGI.pm 3.21 to support httponly (in Install::Requirements, there.)

Comment 14

[Reed Loden [:reed]]

Attachment: patch - v1.3

Review comments addressed.

Comment 15

[Max Kanat-Alexander]

Comment on attachment 335128 [details] [diff] [review]
patch - v1.3

Yeah, looks fine to me. :-)

Comment 16

[Reed Loden [:reed]]

tip:

Checking in Bugzilla/Auth/Persist/Cookie.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Auth/Persist/Cookie.pm,v  <--  Cookie.pm
new revision: 1.6; previous revision: 1.5
done
Checking in Bugzilla/Install/Requirements.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Install/Requirements.pm,v  <--  Requirements.pm
new revision: 1.50; previous revision: 1.49
done
Checking in template/en/default/pages/release-notes.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/pages/release-notes.html.tmpl,v  <--  release-notes.html.tmpl
new revision: 1.23; previous revision: 1.22
done

BUGZILLA-3_2-BRANCH:

Checking in Bugzilla/Auth/Persist/Cookie.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Auth/Persist/Cookie.pm,v  <--  Cookie.pm
new revision: 1.5.4.1; previous revision: 1.5
done
Checking in Bugzilla/Install/Requirements.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Install/Requirements.pm,v  <--  Requirements.pm
new revision: 1.47.2.3; previous revision: 1.47.2.2
done
Checking in template/en/default/pages/release-notes.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/pages/release-notes.html.tmpl,v  <--  release-notes.html.tmpl
new revision: 1.17.2.7; previous revision: 1.17.2.6
done

Comment 17

[Daniel Veditz [:dveditz]]

(In reply to comment #5)
> 1) What about future JSON calls that need to use XHR, do those still work?

Confirming bz, cookies are automagically handled by XHR.

(In reply to comment #11)
> > If a web browser doesn't support httponly, what happens?
> 
> The browser will (hopefully, if it parses the cookie spec properly)
> ignore the extra "HttpOnly;" part in the cookie, so it's not protected by this
> security feature.

No "hopefully" about it, httponly is in wide use and browsers that don't
understand it treat them as regular cookies, just as older versions of Firefox
did. For examples of httponly in use see the many social networking sites like
Facebook and LiveJournal.

Comment 18

[Dave Miller [:justdave]]

Hmm, would this break Greasemonkey scripts that access this cookie?  Or is it exempt because of being part of an extension?  I have more than one Bugzilla account, and I use a GreaseMonkey script that keeps track of which user I'm logged in as and changes the border color on my page to remind me.  At the time it was written, Bugzilla didn't embed anything in the page that was easy to scrape to figure it out, so the login cookie was the easiest way to get it.  I'll have to push to get that info embedded in the HTML somehow if it'll break my script :)

Comment 19

[Dave Miller [:justdave]]

Actually, Bugzilla_login is your userid, it has nothing to do with your session (other than an extra identifier to make sure the session token you're using actually belongs to you).  There's not anything given up by allowing that one to be read, is there?  Bugzilla_logincookie is the only one that's dangerous to expose.

Comment 20

[Max Kanat-Alexander]

Added to release notes for 3.2 in bug 463244.