Web based family history software

Idea Security enhancement by implementing CSP-policy

  • Lars1963
  • Topic Author
  • Offline
  • Junior Member
  • Junior Member
More
3 years 6 months ago #1 by Lars1963
This is a duplicate of github.com/fisharebest/webtrees/issues/3519 for the sake of asking support for this enhancement through the forum.


Because the data in webtrees are sensitiv, I've been experimenting with CSP-rules and other security-headers on my genealogy-website. On the same server I've also installed my private cloud (Nextcloud). This web-software implements a set of CORS-rules and other security-policies out of the box, so even a unexperienced user gets a secure environment.

First, I would like to see that webtrees brings its own set of strong security-policies too. This way all users of webtrees can fairly simple achive a grade A+ on the moz://a Observatory and/or Qualys SSL Labs.

Secondly, I would suggest moving style attributes into external stylesheets. This makes the 'unsafe-inline' attribute inside of style-src no longer necessary. As mozilla states, this makes webtrees not only safer, but also makes the code easier to maintain.

Lars van Ravenzwaaij - see my family tree at www.ravenzwaaij.info

Please Log in or Create an account to join the conversation.

More
3 years 6 months ago #2 by ric2015
I think in general it is a good idea to use a Content Security Policy (CSP). Even if webtrees itself doesn't have any XSS or similar vulnerabilities (which may or may not be the case), custom modules may have them.

At the same time custom modules make it hard for webtrees to define the CSP, as suggested - For example, what if there is a custom module with additional analytics? The respective URL would have to be added to the CSP - how? Custom modules now have to implement an additional interface, in order to report their requirements with regard to the CSP?

In any case, I think the risk is largely theoretical. First, there has to be a actual vulnerability somewhere in webtrees, then there has to be an attacker exploiting it by targeting your specific webtrees site (what is the motivation here? I'd expect attackers to go after bigger fish), and then there has to be a user on your site triggering the exploit, e.g. via a phishing link. How likely is all this?

Richard

webtrees 2.1.17 at cissee.de/webtrees2
Vesta custom modules (Classic Look & Feel, Gov4webtrees, Shared Places, Extended Relationships) available at cissee.de

Please Log in or Create an account to join the conversation.

More
3 years 6 months ago - 3 years 6 months ago #3 by fisharebest
Replied by fisharebest on topic Security enhancement by implementing CSP-policy
> First, I would like to see that webtrees brings its own set of strong security-policies

webtrees already sends a number of HTTP security headers.
See: github.com/fisharebest/webtrees/blob/2.0...yHeaders.php#L32-L37

This sets all the common security headers except CSP and features-policy.

You give NextCloud as an example of an application that uses CSP. (I use NextCloud myself).

A big difference between NextCloud and webtrees is that webtrees users will frequently modify the code, add features and customise it. There is even a built-in module to allow you to add inline CSS and JS.

A typical webtrees user knows a little about PHP/HTML/CSS/JS, and can make simple modifications.
A typical webtrees user will not know about CSP, let alone be able to write a CSP policy.

If we added a strict CSP policy, it would prevent most user-customisations from working.

Also, we have the problem that many of our third-party libraries use inline scripts and styles. As you discovered in issue #3505, the font-awesome package uses them. The bootstrap library also uses them to position menus and popups.

Without CSP, webtrees only scores a "B" rating on the Mozilla Observatory site - but it passes all the other tests.

Major sites such bbc.co.uk and twitter.com only score B - so we are in good company.
Apple scores B-
Facebook scores D+
Amazon and Microsoft score F

I could add a CSP header (allowing inline styles and scripts) and we may well get an A.
But it wouldn't add anything to security.

> Qualys SSL Labs.

The SSL config is nothing to do with the application - it is entirely down to the webserver configuration.

> Secondly, I would suggest moving style attributes into external stylesheets.

I have been removing inline styles slowly over the last couple of years (as part of the 2.0 rewrite) for this exact reason.

There aren't many left. Mostly in the timeline and lifespan charts. These would probably need to be converted from PHP to JS.

Greg Roach - greg@subaqua.co.uk - @fisharebest@phpc.social - fisharebest.webtrees.net
Last edit: 3 years 6 months ago by fisharebest. Reason: Wrong abbreviation

Please Log in or Create an account to join the conversation.

Powered by Kunena Forum
}