Content Security Policy?

[sesquipedalianman]

I’ve recently been trying to implement a Content Security Policy header on my site. USo far the only policy I’ve been able to get to work is one that includes “unsafe-inline” scripts. Is this something that is potentially solvable through configuration to make more strict?

Here’s what I’ve gotten going
default-src ‘none’; connect-src ‘self’; img-src ‘self’ data:; script-src ‘self’ ‘unsafe-inline’; style-src ‘self’ ‘unsafe-inline’

[JustAMacUser]

https://tt-rss.org/oldforum/viewtopic.php?f=1&t=3872&p=22852#p22852

e: Original post quoted for easier reference.

@fox

i guess i’ll elaborate on the subject of CSP in tt-rss because this isn’t the first time this has been requested.

1. i’m not going to change the way i’m coding things so ‘unsafe-inline’ is going to be required

(btw i like how the attributes are prefixed unsafe- as to force the authors’ mentality on everyone, it nicely shows how people involved in this standard are a bunch of condescending spergs using tumblr’esque debate tactics)

2. unsafe-eval seems to be required by Dojo which i have no control over. i don’t think CSP allows to relax limits for specific scopes within origin URL.

3. tt-rss strips loading of external stylesheets and any other imaginable potentially harmful crap from RSS feeds so adding bandaid headers would have limited, iif any, effect.

of course, if won’t hurt if something somehow slips through the cracks, but that would likely involve a compromised plugin or something else on your server which is a situation where you are completely fucked already anyway.

so, to resume, while i can commit something like the following code-block, other than making a bunch of sperglords feel a bit safer, it is unlikely to have any effect on tt-rss security.

header("Content-Security-Policy: script-src 'self' 'unsafe-inline' 'unsafe-eval'");

should i? idk

[sesquipedalianman]

Thank you for the note. I do appreciate the commentary in the old post. I get the point of the CSP, but based on your reply, screw csp (for tt-rss).

[JustAMacUser]

Security is done in layers. CSP is a layer. You’re not going to suffer without it using a well-designed site but it certainly is nice to have. I build my sites now with CSP in mind and try to grant only what’s necessary.

Nevertheless, fox is right in that script elements are removed (both HTML tags and inline) from subscribed content. I have yet to see the current filter circumvented, but if someone finds a way, by all means notify fox responsibly so it can be addressed in an update.

Keep in mind that the only content you’re seeing is content you subscribe to. While there should be a measure of trust here we cannot be certain a site is not hacked so there is a sanitize method that cleans the content.

There are so many attack vectors these days I’m not sure CSP would even be enough (but again, it’s not an all-inclusive measure but rather a layer). I’ve seen carefully crafted images trigger arbitrary code execution in browsers; certainly CSP wouldn’t stop that. Probably for TT-RSS users the biggest thing is JavaScript and as near as I can tell, that is properly removed.

You can add a CSP policy. I would do it in the web server conf files along with the cross-origin, sniffing, etc. headers. With TT-RSS you are going to have to make it somewhat relaxed because of the way it has been designed.

[sesquipedalianman]

Frankly, with what TT-RSS does for tags & scripting already I’m happy it was my Google Reader replacement. Nothing is ever perfect, but knowing that the development of this is done with security at least thought of is nice. It does play well with all my other tags (apache)

Header always set Strict-Transport-Security “max-age=63072000; includeSubdomains; preload”
Header set X-Content-Type-Options nosniff
Header set X-XSS-Protection: “1; mode=block”
Header set X-Robots-Tag: none
Header set X-Frame-Options: SAMEORIGIN
Header set Referrer-Policy: no-referrer

[JustAMacUser]

There is benefit to using CSP, for sure.

That being said, the largest threat is execution of JavaScript, which is stripped from the source content anyway. A CSP policy that limits JavaScript to self and prevents unsafe-inline would undoubtably make things more secure but would also break TT-RSS’s UI; so unsafe-inline would have to be allowed, which then brings us right back to square one: the largest threat.

It is my opinion that things like CSP should be handled at the web server level (e.g. Nginx, Apache, etc.). Leave the application layer out of picture to further separate things and make compromising more difficult (e.g. if someone managed to get PHP code to run they could just modify the CSP header anyway; whereas if it’s in the Nginx conf file, they’d have to compromise another application, which makes things more complex). This brings us to the real point: You can just add a CSP header yourself in your web server.

[fox]

@clarcharr

But I guess that you don’t want to think about that case, as evidenced by your response.

i’m not adding placebo headers in case a sudden exploit in libxml would prevent proper sanitization or any other equally unlikely apocalyptic scenarios

@clarcharr

immediate dismissiveness seems to show a fundamental lack of understanding about both what CSP does and what kind of security is necessary.

oh boy, another condescending sperg is here to show us the light of CSP, again.

[SleeperService]

@clarcharr

But I guess that you don’t want to think about that case, as evidenced by your response.

And yet, here you are, harping into the wind.

[nodiscc]

This is the CSP header for tt-rss I have come up with (example for apache)

Header always set Content-Security-Policy "script-src 'self' 'unsafe-inline' 'unsafe-eval'; frame-ancestors 'self'"

frame-ancestors 'self' is only required if you have a more restrictive global CSP/frame-ancestor directive (mine is set to none by default in the server config). Setting to none breaks some stuff (for example the OPML Import dialog embeds an iframe to self).

frame-ancestors replaces the X-Frame-Options for modern browsers so it’s unnecessary to set both (Firefox will throw a console warning Ignoring 'x-frame-options' because of 'frame-ancestors' directive).

[sesquipedalianman]

Thanks. I added a few of these to tweak my CSP. Appreciate the help.