Could SSP do better on observatory.mozilla.org?

[Jason Haar]

Hi there

I was just running a few of our sites through observatory.mozilla.org and discovered our SSP IdP gets a fairly bad score. 

It's marked down for lack of CSP, CORS, SRI, X-Content-Type-Options, X-Frame-Options as well as lack of Pinning - but I don't care about that :-)

Anyway, I was thinking that as our SSP IdP relies on no other websites, I can probably looks at installing the appropriate headers/etc to make all those "negative" comments disappear, but then I thought this might be something that should be built in? I appreciate a lot of this is context-sensitive: people doing wild things within their IdP plus such default security settings could make for disaster - but it would probably be absolutely fine for the majority of sites using SSP?

Thoughts?

--

Cheers

Jason Haar

Information Security Manager, Trimble Navigation Ltd.

Phone: +1 408 481 8171

PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1

[Thijs Kinkhorst]

Hi Jason,

On 15-11-16 07:42, Jason Haar wrote:
> I was just running a few of our sites through observatory.mozilla.org

> <http://observatory.mozilla.org> and discovered our SSP IdP gets a

> fairly bad score.
>
> It's marked down for lack of CSP, CORS,
> SRI, X-Content-Type-Options, X-Frame-Options as well as lack of Pinning
> - but I don't care about that :-)
>
> Anyway, I was thinking that as our SSP IdP relies on no other websites,
> I can probably looks at installing the appropriate headers/etc to make
> all those "negative" comments disappear, but then I thought this might
> be something that should be built in? I appreciate a lot of this is
> context-sensitive: people doing wild things within their IdP plus such
> default security settings could make for disaster - but it would
> probably be absolutely fine for the majority of sites using SSP?

I think indeed a good IdP should have a high score on this test.

SSP already does some things in regard to thse tests, e.g. default to
secure, httponly cookies, and send X-Frame-Options.

But at least in our environment, we now currently tend to consider this
a webserver configuration mostly, not an application configuration. Just
like SSP the application itself will not give you a high SSLLabs score.
Different sites can have differerent requirements and just setting
Strict-Transport-Security unconditionally is unpractical at least.

Of course we could build then all into SSP, and add options to control
whether or not these headers will be sent. And what values SSP will
send. But we already have a highly configurable part of our stack in
this regard, which is the web server. It's trivial to add these headers
in Apache or nginx. And you have all the flexibility that you want to
pick and choose what to support.

So maybe we should just document to consider doing this there, or add
some examples even.


What do you think?


Cheers,
Thijs

[Thijs Kinkhorst]

On 15-11-16 08:40, Thijs Kinkhorst wrote:
> So maybe we should just document to consider doing this there, or add
> some examples even.

To make a start I've added a reference to the Mozilla Observatory checks
in the post-installation configuration checklist in the docs.


Cheers,
Thijs

[Jason Haar]

On Tue, Nov 15, 2016 at 8:40 PM, Thijs Kinkhorst <thijs.k...@surfnet.nl> wrote:

Of course we could build then all into SSP, and add options to control
whether or not these headers will be sent. And what values SSP will
send. But we already have a highly configurable part of our stack in
this regard, which is the web server. It's trivial to add these headers
in Apache or nginx. And you have all the flexibility that you want to
pick and choose what to support.

So maybe we should just document to consider doing this there, or add
some examples even.

How about just documenting what SSP would score as an IdP/SP that was 'purely' SSP. That way dumb admins like me would know they can then create the appropriate Apache/etc headers without needing to intimately know the SSP code. And those people who have used SSP as a library within their application would know how adding that library potentially affects their ability to declare such security "tags". 

eg if your complex web application was currently able to declare CORS headers, but adding SSP broke that, you'd want to know before implementing it. Conversely, if SSP works well with CORS, then even mentioning it in documentation might make web app developers think "what could I do to define CORS across my entire application", and world peace would result!!!

In any case I see your point, SSP is simply a chunk of code that is added to a website, so these security header settings are out of scope really. But documenting what SSP is capable of within itself would be cool

I guess I'll need to bring up a test instance of our IdP, start altering it will all these missing security tags and start testing to see what breaks. Five minutes tops ;-)

[Federatieve Services - GDI]

Perhaps we should come up with an overall hardening-howto that covers more than just webserver-configuration..

Tim

-----Oorspronkelijk bericht-----
Van: simple...@googlegroups.com [mailto:simple...@googlegroups.com] Namens Thijs Kinkhorst
Verzonden: dinsdag 15 november 2016 8:40
Aan: simple...@googlegroups.com
Onderwerp: Re: Could SSP do better on observatory.mozilla.org?

--
You received this message because you are subscribed to the Google Groups "SimpleSAMLphp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to simplesamlph...@googlegroups.com.
To post to this group, send email to simple...@googlegroups.com.
Visit this group at https://groups.google.com/group/simplesamlphp.
For more options, visit https://groups.google.com/d/optout.
________________________________

Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten.

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.

[Thijs Kinkhorst]

On 16-11-16 08:37, Federatieve Services - GDI wrote:
> Perhaps we should come up with an overall hardening-howto that covers more than just webserver-configuration..

Indeed, that would be a good addition to the documentation.

We've already created a wiki page for our customers which might serve as
a useful start:
https://wiki.surfnet.nl/display/surfconextdev/Securing+your+simpleSAMLphp+setup


Cheers,
Thijs

[Jaime Perez Crespo]

Hi guys!

We had indeed a brief talk about this a couple of days ago in our meeting in Valencia.

As Thijs pointed out, SimpleSAMLphp already does set some security mechanisms, some as default options, others enforced (like the restriction to avoid framing SimpleSAMLphp inside other pages). The problem we have today is that the options are a bit obscure and there’s no proper documentation about them, and the mechanisms enforced are enforced in the template’s header, meaning if you use your own template you effectively override those mechanisms.

In our discussion, we agreed that all this should be done in the web server itself. It’s possible, and it’s much more reasonable to do that server-wise rather than in a library like SSP. However, it is also true that more and more people are using it as a dependency on their projects nowadays, and with cloud computing SSP users won’t even have the possibility to tweak the web server configuration most of the time.

So, in my opinion, we should try to offer a solution for both cases. The stuff we do today in the template’s header should be moved away from there, probably to it’s own class where we could perform all kinds of security checks and settings, and at least we should allow the user to set the headers they like in there. That way, we can cover those using SSP in the cloud so they can secure their installation properly without access to the server. Apart from that, I think we definitely need a guide on how to secure your SSP installation, probably with specific examples for common setups. The wiki page at SURFnet is indeed a good start for that (thanks for sharing Thijs!), but I think we should go much further.

Jason/Tim, would you mind opening an issue in the issue tracker so that we keep this in our to-do list?

Thanks!

> --
> You received this message because you are subscribed to the Google Groups "SimpleSAMLphp" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to simplesamlph...@googlegroups.com.
> To post to this group, send email to simple...@googlegroups.com.
> Visit this group at https://groups.google.com/group/simplesamlphp.
> For more options, visit https://groups.google.com/d/optout.

--
Jaime Pérez
UNINETT / Feide

jaime...@uninett.no
jaime...@protonmail.com
9A08 EA20 E062 70B4 616B 43E3 562A FE3A 6293 62C2

"Two roads diverged in a wood, and I, I took the one less traveled by, and that has made all the difference."
- Robert Frost

[Jason Haar]

On Thu, Nov 17, 2016 at 9:22 PM, Jaime Perez Crespo <jaime...@uninett.no> wrote:

Jason/Tim, would you mind opening an issue in the issue tracker so that we keep this in our to-do list?

Done: #521

[Jaime Perez Crespo]

On 22 Nov 2016, at 08:55 AM, Jason Haar <Jason...@trimble.com> wrote:
> On Thu, Nov 17, 2016 at 9:22 PM, Jaime Perez Crespo <jaime...@uninett.no> wrote:
> Jason/Tim, would you mind opening an issue in the issue tracker so that we keep this in our to-do list?
>
> Done: #521

I’ve just replied in the issue itself, but in any case: thanks a lot Jason!