Bugzilla cookies HTTP only

[Daniel Veditz]

Taking your points in reverse order

> 2) Large sites now use a different domain name for attachments anyway.

We introduced HTTPOnly cookies at least six months before we finally
fixed the attachment bug. Smaller sites may not use a different domain.
Attachments aren't the only thing you want to protect, in particular,
bugzilla instances with zero private bugs may still want to prevent
malicious outsiders from having free reign to mess with someone's account.

> 1) It doesn't work, because if they've managed to get code running in
> your Bugzilla page context, the attacker can just make any requests
> they want using XMLHttpRequest, and the auth cookies will get sent
> right along:

True, but the damage can only be done while the victim is on that page.
There's plenty of damage that can be done in that window of time, but it
does at least prevent attackers from browsing the user's account later
at their leisure.

On 1/13/10 8:37 AM, Gervase Markham wrote:
> I ask because I was hoping to allow Greasemonkey scripts/Jetpacks etc.
> which run in the context of Bugzilla pages to grab the auth cookie and
> pass it on to the API, which can then use it to access Bugzilla.

Any add-on can get the real cookies through the cookie service. Maybe
you don't want this to be a limited GreaseMonkey user-script.

> This obviates the rather irritating and insecure step of having to
> configure every Jetpack or Greasemonkey script with your Bugzilla
> username and password. However, having refactored BzAPI for this

Isn't it somewhat irritating--and temporary--that the BzAPI doesn't
actually live at bugzilla.mozilla.org ? Once the API is production-ready
it will presumably be hosted at BMO and this won't be a problem.

The fact that a GreaseMonkey script wants to ship the BMO cookie off to
a 3rd party server is suspicious and alarming and we shouldn't be
training people that this is a perfectly normal and OK behavior.

> The usual threat that HTTPonly is said to protect against is cookie
> stealing by malicious scripts.

That is the only thing it protects against, yes. And hey, it seems to
work! The protection stopped you, and the only difference between what
you're doing and a malicious script is whether people trust you not to
be malicious. There's no way to bake that kind of judgment into
software. To my mind requiring the explicit configuration is good
because it's getting opt-in consent from users for you to use their
credentials.

Wait a minute, aren't bugzilla login cookies scoped to an IP address? If
users are bouncing requests off your server why isn't BMO rejecting the
cookie when it comes in from that different address?

-Dan Veditz
_______________________________________________
dev-apps-bugzilla mailing list
dev-apps-bugzilla at lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-bugzilla