[srobo-devel] securityheaders.io

[Jeremy Morse]

Hi,

Some new webserver analysis website has cropped up [0], and it flags up
srobo.org for a few potential security hazards. It looks like they're
all headers that we should be serving to reduce the scope of other
vulnerabilities, were they to happen.

I know nothing of these things; would someone be able to recommend some
values (and submit a patch)?

(Public key pinning seems like a great way to make webservers
inaccessible; lets not do that).

[0] https://securityheaders.io/?q=https://studentrobotics.org

--
Thanks,
Jeremy

[Peter Law]

Hi,

Post by Jeremy Morse
Some new webserver analysis website has cropped up [0], and it flags up
srobo.org for a few potential security hazards. It looks like they're
all headers that we should be serving to reduce the scope of other
vulnerabilities, were they to happen.

Indeed. The ones which seem interesting are:

* X-Frame-Options: Lets you control who can embed your site in a frame
* Content-Security-Policy: Lets you specify where resources can be loaded from
* X-Content-Type-Options (maybe): Lets you disable MIME sniffing in IE
and Chrome

The remaining one X-Xss-Protection, though this apparently causes its
own bugs in IE (making things worse) and is only otherwise supported
by Chrome. It also appears that Content-Security-Policy somewhat
supersedes it anyway.

I think that we should be safe to set X-Frame-Options to SAMEORIGIN.
The IDE uses frames, so we can't kill them entirely, but I'm not aware
of any valid cases of other people framing our website. I've patched
this in g:2603.

The linked info about Content-Security-Policy suggests that one of the
more interesting thing it can do is help block inline scripts, yet
there isn't an easy way to securely distinguish between our own ones
and ones added by an attacker.

We should probably look at how the /team/* pages would interact with
this as well (their posts can include their own external images I
think). I suspect that we would need to have a different policy for
the forums so that users could still embed images into their posts
too.

Setting this would likely require either re-hosting a bunch of things
we currently have external dependencies we currently have (I'm sure
some would argue in favour of this anyway), or performing a survey of
said dependencies to include them in the white-list.

As far as I can tell X-Content-Type-Options is primarily only
something to worry about if you let users upload things. I believe
this is disabled in the forums, leaving just the IDE as an upload
recipient (for team-status images). I believe the IDE is safe as the
images are all processed [1] as images before actually being saved.

Post by Jeremy Morse
(Public key pinning seems like a great way to make webservers
inaccessible; lets not do that).

I think that public key pinning is a good idea in general, though
something which the real world of MITM attacks becoming a normal part
of how proxies work will render unusable for a good number of hosts
(ourselves included).

In summary I think we're probably fine as we are for now (adding
X-Frame-Options feels like a quick win), though I'd welcome some input
from others about whether we feel the other headers need addressing.

Thanks,
Peter

[0] https://securityheaders.io/?q=https://studentrobotics.org
[1] All images are loaded, resized as needed then output to PNG with
well-defined names.
g:2603 https://www.studentrobotics.org/gerrit/2603

[Jeremy Morse]

Hi,

Most of this, as mentioned, I don't understand, but,

Post by Peter Law
Setting this would likely require either re-hosting a bunch of things
we currently have external dependencies we currently have (I'm sure
some would argue in favour of this anyway), or performing a survey of
said dependencies to include them in the white-list.

Voila:

https://www.studentrobotics.org/trac/ticket/2783

--
Thanks,
Jeremy