1340056 - [observatory] HTTP Strict Transport Security (HSTS) header not implemented

Status: VERIFIED FIXED

(support.mozilla.org - Lithium :: General, defect)

Description

[Roland Tanglao needinfo please :rolandtanglao, :mohnkuchen, :adobo, :sinigang, :roland]

From: https://observatory.mozilla.org/analyze.html?host=support.mozilla.org

HTTP Strict Transport Security (HSTS) header not implemented

Comment 1

[Roland Tanglao needinfo please :rolandtanglao, :mohnkuchen, :adobo, :sinigang, :roland]

Lithium Response: Supported and in the process of being enabled.

Comment 2

[Roland Tanglao needinfo please :rolandtanglao, :mohnkuchen, :adobo, :sinigang, :roland]

Response from Lithium

QUOTE

Created By: Kris Stewart (2/23/2017 12:44 PM)
[Recipients: Patrick McClard, Scott Riley, Ryan Ausano, Lisa Hern, [e-mail]]

Hi Roland,

Got it - thanks! I've relayed the header info to our engineering team to implement for CSP, alongside enabling HSTS support. We'll keep you posted on progress of setting that up.

END QUOTE

Assigning and needinfo'ing myself to see if I can somehow verify HSTS on Monday February 27, 2017 when I get back

Comment 3

[Roland Tanglao needinfo please :rolandtanglao, :mohnkuchen, :adobo, :sinigang, :roland]

still awaiting an ETA from Lithium

Comment 4

[Roland Tanglao needinfo please :rolandtanglao, :mohnkuchen, :adobo, :sinigang, :roland]

Hi April and Jonathan:

The Lithium folks have implemented HSTS on stage:
http://support-stage.allizom.org/

1. Could one of you please test HSTS on stage? Or tell me how test HSTS please? (stage is htaccess protected, I sent you both the htaccess password and userid  via email)
OR
2. Could one of tell me the IP address of the Mozilla observatory so they can whitelist it so we can use HSTS without htaccess on stage?

It would be great if 1 or 2. could be done by Tuesday March 7 at 9a.m. Pacific

Cheers!
...Roland "unencumbered by HSTS knowledge" :) Tanglao

Comment 5

[Jonathan Claudius [:claudijd] (use NEEDINFO)]

Roland: Here's a curl request on the stage site, you can see that both the Strict-Transport-Security (aka: HSTS) header is set 1 year and the CSP policy you asked for is applied.  The Observatory scanner should source from 63.245.214.162, but using the entire range (63.245.214.128/26) is a safer bet.

$ curl -u mozilla:REDACTED -ik https://support-stage.allizom.org/t5/Mozilla-Support-Community/ct-p/Mozilla-EN
HTTP/1.1 200 OK
Date: Mon, 06 Mar 2017 15:33:02 GMT
Server: Apache
Strict-Transport-Security: max-age=31536000;includeSubDomains
Set-Cookie: LiSESSIONID=3ED8748DB129FF51ED1B70849CF3ED69; Path=/; Secure; HttpOnly
Set-Cookie: LithiumUserInfo=""; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Path=/
Set-Cookie: LithiumUserSecure=""; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Path=/
Set-Cookie: LithiumVisitor=~2lOO53QLDhfx5BXHc~1w81PKShTxDmW_LDwkzw_pAPRpF7IU7UXQGMfodZ2ybSexqv84b3ifUHjbxvGMpGWqAm7L2_o8_stYvl5FvztA..; Expires=Thu, 04-Mar-2027 15:33:02 GMT; Path=/; HttpOnly
Content-Security-Policy: connect-src 'self' https://pushy-live-stage-aws-us-west-1.stage.aws.lcloud.com wss://pushy-live-stage-aws-us-west-1.stage.aws.lcloud.com; default-src 'none'; default_src https:; font-src 'self' https://themes.googleusercontent.com/static/fonts/sourcesanspro/v5/ODelI1aHBYDBqgeIAH2zlBM0YzuT7MdOe03otPbuUS0.woff; img-src 'self' data: https://*.i.lithium.com https://www.google-analytics.com https://www.gravatar.com; object-src 'none'; script-src 'self' data: 'unsafe-inline' 'unsafe-eval' https://*.i.lithium.com/ https://www.google-analytics.com/; style-src 'self' 'unsafe-inline'; 
Content-Security-Policy-Report-Only: connect-src 'self' https://pushy-live-stage-aws-us-west-1.stage.aws.lcloud.com wss://pushy-live-stage-aws-us-west-1.stage.aws.lcloud.com; default-src 'none'; font-src 'self' https://themes.googleusercontent.com/static/fonts/sourcesanspro/v5/ODelI1aHBYDBqgeIAH2zlBM0YzuT7MdOe03otPbuUS0.woff; img-src 'self' data: https://*.i.lithium.com https://www.google-analytics.com https://www.gravatar.com; object-src 'none'; report-uri https://csp-service.stage.aws.lcloud.com/csp-report/community/mozilla.stage/report; script-src 'self' data: 'unsafe-inline' 'unsafe-eval' https://*.i.lithium.com/ https://www.google-analytics.com/; style-src 'self' 'unsafe-inline'; 
Pragma: no-cache
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Cache-Control: no-cache, no-store, must-revalidate, private
X-Frame-Options: SAMEORIGIN
Vary: Accept-Encoding
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html;charset=UTF-8

Comment 6

[Roland Tanglao needinfo please :rolandtanglao, :mohnkuchen, :adobo, :sinigang, :roland]

(In reply to Jonathan Claudius [:claudijd] (use NEEDINFO) from comment #5)
> Roland: Here's a curl request on the stage site, you can see that both the
> Strict-Transport-Security (aka: HSTS) header is set 1 year and the CSP
> policy you asked for is applied.  The Observatory scanner should source from
> 63.245.214.162, but using the entire range (63.245.214.128/26) is a safer
> bet.
> 
> $ curl -u mozilla:REDACTED -ik
> https://support-stage.allizom.org/t5/Mozilla-Support-Community/ct-p/Mozilla-
> EN
> HTTP/1.1 200 OK
> Date: Mon, 06 Mar 2017 15:33:02 GMT
> Server: Apache
> Strict-Transport-Security: max-age=31536000;includeSubDomains
> Set-Cookie: LiSESSIONID=3ED8748DB129FF51ED1B70849CF3ED69; Path=/; Secure;
> HttpOnly
> Set-Cookie: LithiumUserInfo=""; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Path=/
> Set-Cookie: LithiumUserSecure=""; Expires=Thu, 01-Jan-1970 00:00:10 GMT;
> Path=/
> Set-Cookie:
> LithiumVisitor=~2lOO53QLDhfx5BXHc~1w81PKShTxDmW_LDwkzw_pAPRpF7IU7UXQGMfodZ2yb
> Sexqv84b3ifUHjbxvGMpGWqAm7L2_o8_stYvl5FvztA..; Expires=Thu, 04-Mar-2027
> 15:33:02 GMT; Path=/; HttpOnly
> Content-Security-Policy: connect-src 'self'
> https://pushy-live-stage-aws-us-west-1.stage.aws.lcloud.com
> wss://pushy-live-stage-aws-us-west-1.stage.aws.lcloud.com; default-src
> 'none'; default_src https:; font-src 'self'
> https://themes.googleusercontent.com/static/fonts/sourcesanspro/v5/
> ODelI1aHBYDBqgeIAH2zlBM0YzuT7MdOe03otPbuUS0.woff; img-src 'self' data:
> https://*.i.lithium.com https://www.google-analytics.com
> https://www.gravatar.com; object-src 'none'; script-src 'self' data:
> 'unsafe-inline' 'unsafe-eval' https://*.i.lithium.com/
> https://www.google-analytics.com/; style-src 'self' 'unsafe-inline'; 
> Content-Security-Policy-Report-Only: connect-src 'self'
> https://pushy-live-stage-aws-us-west-1.stage.aws.lcloud.com
> wss://pushy-live-stage-aws-us-west-1.stage.aws.lcloud.com; default-src
> 'none'; font-src 'self'
> https://themes.googleusercontent.com/static/fonts/sourcesanspro/v5/
> ODelI1aHBYDBqgeIAH2zlBM0YzuT7MdOe03otPbuUS0.woff; img-src 'self' data:
> https://*.i.lithium.com https://www.google-analytics.com
> https://www.gravatar.com; object-src 'none'; report-uri
> https://csp-service.stage.aws.lcloud.com/csp-report/community/mozilla.stage/
> report; script-src 'self' data: 'unsafe-inline' 'unsafe-eval'
> https://*.i.lithium.com/ https://www.google-analytics.com/; style-src 'self'
> 'unsafe-inline'; 
> Pragma: no-cache
> Expires: Thu, 01 Jan 1970 00:00:00 GMT
> Cache-Control: no-cache, no-store, must-revalidate, private
> X-Frame-Options: SAMEORIGIN
> Vary: Accept-Encoding
> Connection: close
> Transfer-Encoding: chunked
> Content-Type: text/html;charset=UTF-8

Speedy and very helpful thanks Jonathan!

Jonathan just to be clear as mud :-) :
1. 100% ok to go live with these CSP and HSTS headers (i'll check but i don't know much), right?
2. what do you mean "but using the entire range (63.245.214.128/26) is a safer bet." do you mean
 Lithium should whitelist 63.245.214.128, 63.245.214.129, ... 63.245.214.162 inclusive or do you mean something else?

Thanks again!

...Roland

Comment 7

[Jonathan Claudius [:claudijd] (use NEEDINFO)]

Roland:

1.) I can confirm the HSTS and CSP policies are implemented as we discussed.  I cannot (and should not) be the deciding person whether it's ok for production use or not, I would defer to you or the service owner to make that decision.

2.) Traffic from the scanner I tested sourced from 63.245.214.162, but Mozilla owns this entire range (63.245.214.128/26).  Either would likely work, but I would prefer them white-listing 63.245.214.128/26 to avoid any back and forth if one of the other scanners comes from a different IP in that range.

Comment 8

[Roland Tanglao needinfo please :rolandtanglao, :mohnkuchen, :adobo, :sinigang, :roland]

(In reply to Jonathan Claudius [:claudijd] (use NEEDINFO) from comment #7)
> Roland:
> 
> 1.) I can confirm the HSTS and CSP policies are implemented as we discussed.
> I cannot (and should not) be the deciding person whether it's ok for
> production use or not, I would defer to you or the service owner to make
> that decision.
> 
> 2.) Traffic from the scanner I tested sourced from 63.245.214.162, but
> Mozilla owns this entire range (63.245.214.128/26).  Either would likely
> work, but I would prefer them white-listing 63.245.214.128/26 to avoid any
> back and forth if one of the other scanners comes from a different IP in
> that range.

thanks Jonathan again!

re: 2. i did some googleing and i understand (finally :-) !) what "63.245.214.128/26" means. thanks for your patience! I'll get Lithium to whitelist those IPs

re: 1. I showed this to MoFo colleague, :pomax and he questioned the use of "'unsafe-eval'"
Do we need unsafe-eval for google analytics? :pomax doesn't use 'unsafe-eval' for any of the MoFo websites.

Finally, the service owner is Patrick McClard, my manager but neither he nor I are security savvy enough to feel comfortable approving security stuff like CSP, is there somebody else we we should consult, jonathan?

I hope this is the last :needinfo for you Jonathan! Again thanks for your patience, this process is new to us!

Cheers!
...Roland

Comment 9

[Jonathan Claudius [:claudijd] (use NEEDINFO)]

Roland: You can get my "OK" for the CSP bits, but what I meant is that I'm not the service owner so I shouldn't be approving prod deployments.  I'm comfortable with the CSP bits if you're comfortable with the deploy.

As for the unsafe-eval for GA, I thought that was a requirement based on what the site was showing us.  I would defer to :april to comment on the GA unsafe-eval part.  If :pomax has GA running with CSP and doesn't use unsafe-eval, I suspect we can entertain a policy without it if that's what you'd like.

Comment 10

[Roland Tanglao needinfo please :rolandtanglao, :mohnkuchen, :adobo, :sinigang, :roland]

(In reply to Jonathan Claudius [:claudijd] (use NEEDINFO) from comment #9)
> Roland: You can get my "OK" for the CSP bits, but what I meant is that I'm
> not the service owner so I shouldn't be approving prod deployments.  I'm
> comfortable with the CSP bits if you're comfortable with the deploy.
> 
> As for the unsafe-eval for GA, I thought that was a requirement based on
> what the site was showing us.  I would defer to :april to comment on the GA
> unsafe-eval part.  If :pomax has GA running with CSP and doesn't use
> unsafe-eval, I suspect we can entertain a policy without it if that's what
> you'd like.

Thanks Jonathan yet again

April do we need 'unsafe-eval' in the CSP for Google Analytics?

Comment 11

[April King [:April]]

I didn't think it was needed for Google Analytics, just Google Tag Manager.  You can remove it from your CSP and see if you get errors about it in your browser console.

Comment 12

[Jonathan Claudius [:claudijd] (use NEEDINFO)]

Roland:  I did some digging the unsafe-eval is not coming from GA, it's coming from a Lithium lia-scripts-angularjs-min.js requirement, which includes an unsafe-eval.

I also consulted with April on this to see if it was possible to isolate the two (eg. can we give unsafe eval to lithium, but not GA) and it sounds like it's an all or nothing thing.

I also noticed a slight bug in the CSP policy you have above (default_src, which should be default-src) and also a duplicate directive, which I've resolved in the following update...

Content-Security-Policy: connect-src 'self' https://pushy-live-stage-aws-us-west-1.stage.aws.lcloud.com wss://pushy-live-stage-aws-us-west-1.stage.aws.lcloud.com; default-src 'none'; font-src 'self' https://themes.googleusercontent.com/static/fonts/sourcesanspro/v5/ODelI1aHBYDBqgeIAH2zlBM0YzuT7MdOe03otPbuUS0.woff; img-src 'self' data: https://*.i.lithium.com https://www.google-analytics.com https://www.gravatar.com; object-src 'none'; script-src 'self' data: 'unsafe-inline' 'unsafe-eval' https://*.i.lithium.com/ https://www.google-analytics.com/; style-src 'self' 'unsafe-inline'

Please let us know if you have any additional questions about this.

Comment 13

[April King [:April]]

Does there need to be 'unsafe-inline' and data: in script-src?  Those two together basically defeat the entire purpose of CSP, which is to prevent XSS attacks.

> font-src 'self' https://themes.googleusercontent.com/static/fonts/sourcesanspro/v5/ODelI1aHBYDBqgeIAH2zlBM0YzuT7MdOe03otPbuUS0.woff

Could probably be trimmed down to something like:
font-src 'self' https://themes.googleusercontent.com/static/fonts/

Also, I notice that Lithium seems to be running a very old version of AngularJS (1.4.8), which has a handful of security issues.  Is there a reason it needs to be running such a dated version?

Comment 14

[Jonathan Claudius [:claudijd] (use NEEDINFO)]

Updated CSP policy, based on feedback in comment 13...

Content-Security-Policy: connect-src 'self' https://pushy-live-stage-aws-us-west-1.stage.aws.lcloud.com wss://pushy-live-stage-aws-us-west-1.stage.aws.lcloud.com; default-src 'none'; font-src 'self' https://themes.googleusercontent.com/static/fonts/; img-src 'self' data: https://*.i.lithium.com https://www.google-analytics.com https://www.gravatar.com; object-src 'none'; script-src 'self' data: 'unsafe-inline' 'unsafe-eval' https://*.i.lithium.com/ https://www.google-analytics.com/; style-src 'self' 'unsafe-inline'

Roland: I'll leave the angular security issues comment to you to raise with the vendor.

Comment 15

[Roland Tanglao needinfo please :rolandtanglao, :mohnkuchen, :adobo, :sinigang, :roland]

(In reply to Jonathan Claudius [:claudijd] (use NEEDINFO) from comment #14)
> Updated CSP policy, based on feedback in comment 13...
> 
> Content-Security-Policy: connect-src 'self'
> https://pushy-live-stage-aws-us-west-1.stage.aws.lcloud.com
> wss://pushy-live-stage-aws-us-west-1.stage.aws.lcloud.com; default-src
> 'none'; font-src 'self' https://themes.googleusercontent.com/static/fonts/;
> img-src 'self' data: https://*.i.lithium.com
> https://www.google-analytics.com https://www.gravatar.com; object-src
> 'none'; script-src 'self' data: 'unsafe-inline' 'unsafe-eval'
> https://*.i.lithium.com/ https://www.google-analytics.com/; style-src 'self'
> 'unsafe-inline'
> 
> Roland: I'll leave the angular security issues comment to you to raise with
> the vendor.

i've raised the angular security issues with and proposed the new CSP from comment 14 to Lithium. Now awaiting their feedback!

Comment 16

[Roland Tanglao needinfo please :rolandtanglao, :mohnkuchen, :adobo, :sinigang, :roland]

(In reply to April King [:April] from comment #13)
> Does there need to be 'unsafe-inline' and data: in script-src?  Those two
> together basically defeat the entire purpose of CSP, which is to prevent XSS
> attacks.
> 
> > font-src 'self' https://themes.googleusercontent.com/static/fonts/sourcesanspro/v5/ODelI1aHBYDBqgeIAH2zlBM0YzuT7MdOe03otPbuUS0.woff
> 
> Could probably be trimmed down to something like:
> font-src 'self' https://themes.googleusercontent.com/static/fonts/
> 
> Also, I notice that Lithium seems to be running a very old version of
> AngularJS (1.4.8), which has a handful of security issues.  Is there a
> reason it needs to be running such a dated version?

hi april and jonathan:
here's the reply ( https://supportcases.lithium.com/50061000009MCTs )  from lithium on upgrading angular.js from 1.4.8 (November 2015):

"Are there any specific issues you can point me to that are caused by the version of angular we're currently using?
" 
April and Jonathan: Other than being over a year old anything specific you are worried about in angular.js 1.4.8? It seems from my googling that an upgrade to 1.5 would be pragmatic but an upgrade all the way to 1.6 might be in order ( https://docs.angularjs.org/guide/migration#migrating-from-1-4-to-1-5 )  but I know nothing :-) about angular!

Comment 17

[Jonathan Claudius [:claudijd] (use NEEDINFO)]

Roland: I'm not as familiar with angular.js and I did a briefing poking around (as much as I can spare near end of quarter) and didn't find anything immediately alarming.  What I will say is that keeping dependent libraries updated is a good practice here.

Comment 18

[Roland Tanglao needinfo please :rolandtanglao, :mohnkuchen, :adobo, :sinigang, :roland]

Let the record show :-) that HSTS was fixed on March 15, 2017:

From the case 
BEGIN
Created By: Kris Stewart (3/15/2017 8:49 AM)
[Recipients: Patrick McClard, Scott Riley, Ryan Ausano, Lisa Hern, [e-mail]]

Hi all,

HSTS - this was enabled on production during last night's maintenance window and now passes the Mozilla scanner test: https://observatory.mozilla.org/analyze.html?host=support.mozilla.org 
END

Comment 19

[Roland Tanglao needinfo please :rolandtanglao, :mohnkuchen, :adobo, :sinigang, :roland]

closing this bug, cancelling april's needinfo
:april if you want to chime in on the angular.js stuff please chime in on the angular.js bug, 1350880