637917 - Enable Cookie Flag SECURE

Status: VERIFIED FIXED

(Websites :: donate.mozilla.org, defect)

Description

[Michael Coates [:mcoates] (acct no longer active)]

Issue

The donation page at https://donate.mozilla.org/page/contribute/protect-the-web does not use the SECURE flag to protect cookies that are set by the page. As a result it is possible for an attacker to obtain these cookie values by convincing the victim to make a request to an HTTP version of the page. This attack is possible even though the site is not accessible over HTTP.

The following cookies are vulnerable:

Set-Cookie: PHPSESSID=85bbe1711ae8aea01d8494bf66903c72; path=/
Set-Cookie: spud=alU8W1ErYJyJRVxTeVf8dcf0; expires=Thu, 28-Feb-2013 23:38:56 GMT; path=/
Set-Cookie: X-CheckNode=; domain=donate.mozilla.org; path=/
Set-Cookie: X-Mapping-jljaemke=C9726B2CD53B7B7F7450346B87C0977E; path=/


Steps to Reproduce:
1. Browse to https://donate.mozilla.org/page/contribute/protect-the-web
2. Inspect the HTTP response and observe the set-cookie does not contain "SECURE" for each cookie value.

Recommended Remediation
Set the SECURE flag for all cookies that are set by the application.

Comment 1

[Seth Reznik]

These two cookies are set by our load balancer software:

X-CheckNode - this can be used in debugging to see which backend node served a request and contains no user-specific information
X-Mapping-xxxxxxxx - this is the session affinity cookie that the load balancer uses

If either of those are of concern we'll potentially need to contact our load balancer vendor about if how those cookies are set can be changed.

PHPSESSID is the PHP session id. For most of our clients, the majority of their site is not on https, and some have no secure cert at all. But we can add a configuration option to use secure cookies when a site is 100% on https.

"spud" is a tracking cookie. Similarly we can make this secure if the client has no non-secure pages.

Comment 2

[Michael Coates [:mcoates] (acct no longer active)]

(In reply to comment #1)
> These two cookies are set by our load balancer software:
> 
> X-CheckNode - this can be used in debugging to see which backend node served a
> request and contains no user-specific information
> X-Mapping-xxxxxxxx - this is the session affinity cookie that the load balancer
> uses
> 
> If either of those are of concern we'll potentially need to contact our load
> balancer vendor about if how those cookies are set can be changed.
> 
> PHPSESSID is the PHP session id. For most of our clients, the majority of their
> site is not on https, and some have no secure cert at all. But we can add a
> configuration option to use secure cookies when a site is 100% on https.
> 
> "spud" is a tracking cookie. Similarly we can make this secure if the client
> has no non-secure pages.

My understanding is that there are only two webpages for the donation process, the donation page where the CC is submitted and then the thank you web page. Both of these will be HTTPS.  We should go ahead and mark both PHPSESSID and spud as SECURE. In the event we have any HTTP pages we'd want to convert them to HTTPS anyway, so the SECURE flag is definitely preferred.


Regarding the spud tracking cookie, can you provide a little more info on what sort of tracking is occurring?

Comment 3

[Seth Reznik]

Thanks. On the SPUD stuff, I am adding an attachment that goes through it. It should be noted that we have been asked about using SPUD by members of the project team to have more advanced thank you options after people make donations.

Comment 4

[Seth Reznik]

Attachment: SPUD description

Comment 5

[Michael Coates [:mcoates] (acct no longer active)]

Julie & Alex,

Wanted to verify you've reviewed or are aware of the SPUD user tracking (see attachment)

Comment 6

[Michael Coates [:mcoates] (acct no longer active)]

(In reply to comment #5)
> Julie & Alex,
> 
> Wanted to verify you've reviewed or are aware of the SPUD user tracking (see
> attachment)

The privacy discussion has been moved to bug 638962

Comment 7

[Julie Martin]

Hi, Michael.

No I was not aware of this.  I will defer to Alex to resolve as our new privacy lead.  You and he can certainly consult with me on any questions about it.

Julie

Comment 8

[Seth Reznik]

SPUD has now been turned off, let me know what you guys think of the load balancer cookies.

Comment 9

[Michael Coates [:mcoates] (acct no longer active)]

PHPSESSID definitely needs the SECURE flag.

I'd prefer the load balancer cookies to also have SECURE. Can we explore if that is possible?

Comment 10

[Seth Reznik]

The load-balancers are now configured to set the "Secure" flag on all framework cookies for all of mozilla's secure pages – including php session id.

Regarding the two loadbalancer cookies it seems that while it's trivial to have the LB's set the secure flag on cookies issued from the framework, it's actually impossible to have it set the flag on cookies it issues directly. We've filed a bug report with the vendor. But we feel that the cookies themselves are not hugely important.

The X-CheckNode cookie is something we use for troubleshooting site problems. The cookie's value will always be empty for end users, only BSD engineers actually have the ability to populate the cookie. Even when not null, it does not contain any user information. If the client prefers, we can simply disable it for their site entire, however they should be aware that it has the potential to slow down our ability to troubleshoot certain site problems.

The X-Mapping cookie also contains no user information, it is only used by the load balancers to preserve a users "affinity" with a backend webserver. As with the X-CheckNode cookie, we can "disable" this by changing the session affinity algorithm, but again, the client needs to be aware that it may affect site performance or end user experience.

It should also be noted that the contents of these cookies are essentially the same-- mainly the hostname of the backend server that served the request(s).

Comment 11

[Michael Coates [:mcoates] (acct no longer active)]

Confirmed SECURE flag is set for the following 2 cookies:
Set-Cookie: PHPSESSID=e7b2889bdb96f077d289803729e36c0d; path=/; secure
Set-Cookie: spud=deleted; expires=Mon, 08-Mar-2010 23:48:25 GMT; path=/; secure

We are ok to proceed without the SECURE flag for X-CheckNode and X-Mapping cookies since neither contain user data.