Aanbevelingen Mozilla Observatory implementeren

[afraca]

Ik kwam onlangs weer Mozilla Observatory tegen, een tool die dingen als SSL instellingen test, maar daarnaast ook cookie settings en dergelijke. Hierbij report voor tweakers.net :

https://observatory.mozil...ze.html?host=tweakers.net

Score: 40/100

Content Security Policy	-20	Content Security Policy (CSP) implemented, but allows 'unsafe-inline' inside script-src
Cookies	-5	Cookies set without using the Secure flag, but transmission over HTTP prevented by HSTS
Cross-origin Resource Sharing	0	Content is visible via cross-origin resource sharing (CORS) files or headers, but is restricted to specific domains
HTTP Public Key Pinning	0	HTTP Public Key Pinning (HPKP) header not implemented (optional)
HTTP Strict Transport Security	+5	Preloaded via the HTTP Strict Transport Security (HSTS) preloading process
Redirection	0	Initial redirection is to https on same host, final destination is https
Subresource Integrity	-5	Subresource Integrity (SRI) not implemented, but all external scripts are loaded over https
X-Content-Type-Options	-5	X-Content-Type-Options header not implemented
X-Frame-Options	-20	X-Frame-Options (XFO) header not implemented
X-XSS-Protection	-10	X-XSS-Protection header not implemented

k vind het leuk onder de indruk te zijn van de technische kwaliteit van de tweakers staff, dus het zou leuk zijn als we hier een mooie A+ konden krijgen

[ACM]

Dat zou op zich leuk zijn, maar ik zie het niet gebeuren. We hebben er al eerder naar gekeken en het heeft best wat lastige side-effects om op te lossen

Content Security Policy (CSP) implemented, but allows 'unsafe-inline' inside script-src

Dit veranderen betekent dat we alle inline javascript-snippets moeten voorzien van een nonce. En - nog wat lastiger - ook alle inline events (zoals onclick=...) moeten we dan vervangen door stukjes javascript-snippet met zo'n nonce.
Dan hebben we het al gauw over een stuk of 1000 plekken in onze code die dan anders moeten.

Cookies set without using the Secure flag, but transmission over HTTP prevented by HSTS

Die zouden we eventueel kunnen doen. Ik geloof niet dat die nu nog side-effects zou mogen hebben.

Subresource Integrity (SRI) not implemented, but all external scripts are loaded over https

Zolang we banners (vanaf externe hosts) draaien, denk ik niet dat het reeel is om dit te implementeren.

X-Content-Type-Options header not implemented

Dat is blijkbaar vooral relevant voor IE8, die vrij aggresief probeert mimetypes probeert te sniffen. Ik heb geen idee of alle data die wij versturen de juiste content-type heeft. Hoewel ik vermoed van wel, is het wel lastig te bepalen wat voor side-effects dit kan hebben.

X-Frame-Options (XFO) header not implemented

Dit is een deprecated header die vervangen is door CSP. Helaas is ie niet zo mooi instelbaar als wij zouden willen (zoals nodig voor o.a. het inloggen op de tweakblogs). Verder zijn we er nog niet helemaal over uit, maar we vinden het eigenlijk wel goed dat (pagina's van) Tweakers in een iframe geladen kunnen worden.
We onderdrukken dat alleen voor belangrijke formulieren, via CSP.

X-XSS-Protection header not implemented

Dat heeft blijkbaar een 'small risk of false positives'. Gezien onze grootte zit het er dik in dat we die tegenkomen Verder is het mij niet duidelijk wat die header nou precies voor bescherming toevoegt.

[afraca]

ACM schreef op dinsdag 06 september 2016 @ 13:48:

[...]

Die zouden we eventueel kunnen doen. Ik geloof niet dat die nu nog side-effects zou mogen hebben.

[...]

Dat is blijkbaar vooral relevant voor IE8, die vrij aggresief probeert mimetypes probeert te sniffen. Ik heb geen idee of alle data die wij versturen de juiste content-type heeft. Hoewel ik vermoed van wel, is het wel lastig te bepalen wat voor side-effects dit kan hebben.

Is het niet juist fijn om te weten dat je verkeerde content-type stuurt indien dit het geval is? Dat is natuurlijk eigenlijk gewoon een bug.

----

Verder snap ik je punten wel goed, je zit met een enorme codebase en externe boel enzo ja. Ook flauw van die deprecated en haast-niet-gedocumenteerde header als X-XSS-Protection.

[djwice]

@afraca , @ACM - zo, even een oud topic weer wakker maken

Sinds de topic start is de site in rank omhoog gegaan van D+ naar een B.
Dus als eerste natuurlijk: proficiat en dank jullie wel!

Er zijn inmiddels nieuwe tests toegevoegd aan de Observatory, en nieuwe browser features.
Dus we trekken hem weer even uit de kast:
https://observatory.mozil...ze.html?host=tweakers.net

Wat nog toegevoegd kan worden is bijvoorbeeld de referrer-policy header, en subresource integrity.

Kun je bij die externe resouces niet automatisch ook de hash ontvangen, op het moment dat jullie die banner hebben gescand dat er geen malisious gedrag in zit?

Ondersteuning van deze ciphers suites kan worden overwogen:

• ECDHE-ECDSA-CHACHA20-POLY1305
• ECDHE-RSA-CHACHA20-POLY1305

En een CAA record aan je DNS is wellicht ook iets leuks:
https://blog.qualys.com/s...ndated-by-cabrowser-forum

Een wijziging aan de content security policy voor zo'n grote site als tweakers, is voor mij te complex om snel de impact van in te schatten. Wat mij verder opvalt is dat de X-Frame-Options niet in jullie headers staat, maar wel wordt ondersteut in de CSP, aangezien Edge en MSIE nog geen CSP frame-ancestors ondersteunt, is dit wellicht ook het overwegen waard om voor die browsers X-Frame-Options toe te voegen in de response:
https://developer.mozilla...ty-Policy/frame-ancestors
https://developer.mozilla...P/Headers/X-Frame-Options

[ Voor 5% gewijzigd door djwice op 18-12-2017 13:10 ]

[ACM]

djwice schreef op maandag 18 december 2017 @ 13:02:
Wat nog toegevoegd kan worden is bijvoorbeeld de referrer-policy header,

Die hebben we al, maar 'te ruim' voor die test. Maar doordat we o.a. met webshops zitten en allerlei derden die zaken als foute deeplinks soms melden, willen we die eigenlijk niet nog verder aanpassen.

en subresource integrity.

Kun je bij die externe resouces niet automatisch ook de hash ontvangen, op het moment dat jullie die banner hebben gescand dat er geen malisious gedrag in zit?

Nee. Die javascript en de banners komen nooit op onze servers. Bovendien hebben wij ook niet de kennis of technologie om banners op malicious zaken te scannen; dat is toch echt wel een taak van de tussenpartij (doubleclick e.a.).

Ondersteuning van deze ciphers suites kan worden overwogen:

• ECDHE-ECDSA-CHACHA20-POLY1305
• ECDHE-RSA-CHACHA20-POLY1305

En een CAA record aan je DNS is wellicht ook iets leuks:
https://blog.qualys.com/s...ndated-by-cabrowser-forum

Daar mag @Kees naar kijken.

Een wijziging aan de content security policy voor zo'n grote site als tweakers, is voor mij te complex om snel de impact van in te schatten.

Klopt, hoewel hij al iets strakker is gezet pasgeleden ivm de framing. Je refereert neem ik aan naar o.a. de nonce's voor javascript? Dat op zich zou nog niet zo erg zijn dat kunnen we wel vrij eenvoudig automatiseren, maar alle inline events (onclick= etc) omzetten is inderdaad wel weer een klus van hele andere orde. Vooral ook omdat het ook op een hele andere manier opgezet moet worden

Wat mij verder opvalt is dat de X-Frame-Options niet in jullie headers staat, maar wel wordt ondersteut in de CSP, aangezien Edge en MSIE nog geen CSP frame-ancestors ondersteunt, is dit wellicht ook het overwegen waard om voor die browsers X-Frame-Options toe te voegen in de response:
https://developer.mozilla...ty-Policy/frame-ancestors
https://developer.mozilla...P/Headers/X-Frame-Options

X-Frame-Options is een alles-of-niets optie. Zoals we nu CSP hebben ingesteld is gewoon niet mogelijk daarbij. Op zich hebben we ook al variabele CSP-framing, maar we worden bij dat soort zaken nogal gehinderd door het feit dat we meerdere domeinnamen gebruiken (tweakers.net, gathering.tweakers.net en tweakblogs.net).

[Kees]

CAA records added. Voor de ciphersuites ben ik afhankelijk van de vendor en die ondersteunt deze nog niet.

[djwice]

Kees schreef op dinsdag 19 december 2017 @ 08:44:
CAA records added. Voor de ciphersuites ben ik afhankelijk van de vendor en die ondersteunt deze nog niet.

YES!
Ik zie hem nog niet terug in https://www.ssllabs.com/s...239.154.30&hideResults=on en https://www.ssllabs.com/s...0%3a80%3a1&hideResults=on

(ook niet via https://caatest.co.uk/tweakers.net https://caatest.co.uk/gathering.tweakers.net of https://caatest.co.uk/tweakblogs.net )

[Kees]

djwice schreef op dinsdag 19 december 2017 @ 15:28:
[...]

YES!
Ik zie hem nog niet terug in https://www.ssllabs.com/s...239.154.30&hideResults=on en https://www.ssllabs.com/s...0%3a80%3a1&hideResults=on

(ook niet via https://caatest.co.uk/tweakers.net https://caatest.co.uk/gathering.tweakers.net of https://caatest.co.uk/tweakblogs.net )

https://caatest.co.uk/tweakers.net

geeft bij mij:

✔ All looks good
---
0 issue "globalsign.org" 0 issue "letsencrypt.org"

[djwice]

Kees schreef op dinsdag 19 december 2017 @ 15:28:
[...]

https://caatest.co.uk/tweakers.net

geeft bij mij:

✔ All looks good
---
0 issue "globalsign.org" 0 issue "letsencrypt.org"

Hé bij mij nu ook
hmm... die site wisseld elke keer (nog een keer proberen geeft weer fout, hmm. en te vaak achter elkaar een 502 ...

Wellicht dat nog niet alle DNS servers zijn geupdate, ik zie bij cache legen bij ssllabs ook nog steeds oranje. De tijd (TTL?) zal het leren

[ Voor 14% gewijzigd door djwice op 19-12-2017 15:41 ]

[djwice]

Thanks @ACM voor je reacties!

ACM schreef op dinsdag 19 december 2017 @ 07:58:
[...]

Die hebben we al, maar 'te ruim' voor die test. Maar doordat we o.a. met webshops zitten en allerlei derden die zaken als foute deeplinks soms melden, willen we die eigenlijk niet nog verder aanpassen.

Zou je ook aan de hand van de timestamp en de landingspagina kunnen bepalen welke deeplink fout is? Is wellicht wel wat omslachtiger denk ik.

ACM schreef op dinsdag 19 december 2017 @ 07:58:
Nee. Die javascript en de banners komen nooit op onze servers. Bovendien hebben wij ook niet de kennis of technologie om banners op malicious zaken te scannen; dat is toch echt wel een taak van de tussenpartij (doubleclick e.a.).

Nu maar hopen dat je partijen blijft kiezen die dit op orde hebben en houden
Wellicht dat een banner in een iframe (brrr...) sandbox past?
https://www.html5rocks.co...curity/sandboxed-iframes/
Om zo de impact enigzinds te beperken.

ACM schreef op dinsdag 19 december 2017 @ 07:58:

[...]
maar alle inline events (onclick= etc) omzetten is inderdaad wel weer een klus van hele andere orde. Vooral ook omdat het ook op een hele andere manier opgezet moet worden

Wow, inderdaad, heel veel sterkte!

[ACM]

djwice schreef op dinsdag 19 december 2017 @ 15:40:
Zou je ook aan de hand van de timestamp en de landingspagina kunnen bepalen welke deeplink fout is? Is wellicht wel wat omslachtiger denk ik.

Voor clickouts uit de pricewatch vast wel, maar voor links in het forum naar derden kunnen die nu in ieder geval zien dat het hier is, ze zien alsnog alleen de hostname.

Nu maar hopen dat je partijen blijft kiezen die dit op orde hebben en houden

Ja, dat is wel lastig met banners. Het in huis halen is ook niet bepaald triviaal (niet alleen ivm techniek, ook organisatorisch met klanten), waardoor ik dat ook niet zo gauw zie gebeuren.

Wellicht dat een banner in een iframe (brrr...) sandbox past?
https://www.html5rocks.co...curity/sandboxed-iframes/
Om zo de impact enigzinds te beperken.

Ze staan al in iframes. Wellicht weet @crisp of dat hier toepasbaar is, met een beetje pech moeten ze zo ruim opengesteld worden dat het weinig toevoegt t.o.v. reguliere cross-origin iframes.

Wow, inderdaad, heel veel sterkte!

Die gaan we voorlopig niet doen hoor. Is domweg teveel werk. En ook hier maakt de bannering het weer moeilijker. Er komen aanpassingen in CSP3 waardoor je in ieder geval kan aangeven dat wij partij X vertrouwen, dus als partij X ook nog Y en Z nodig heeft, dan is dat goed.
Dat maakt het in ieder geval praktisch haalbaarder om met CSP te werken voor de dingen als script-src in combinatie met 3rd parties (banners, video-embeds, etc).

[crisp]

ACM schreef op dinsdag 19 december 2017 @ 17:06:
[...]

Ze staan al in iframes. Wellicht weet @crisp of dat hier toepasbaar is, met een beetje pech moeten ze zo ruim opengesteld worden dat het weinig toevoegt t.o.v. reguliere cross-origin iframes.

De iframes worden dynamisch aangemaakt door de DFP API, dus daar hebben wij geen invloed op. De iframes moeten sowieso via JS met de hoofdpagina kunnen communiceren, dus ik denk dat sandboxing dan al niet meer aan de orde is...