• Login
  • Register
  • Login Register
    Login
    Username/Email:
    Password:
    Or login with a social network below
  • Forum
  • Website
  • GitHub
  • Status
  • Translation
  • Features
  • Team
  • Rules
  • Help
  • Feeds
User Links
  • Login
  • Register
  • Login Register
    Login
    Username/Email:
    Password:
    Or login with a social network below

    Useful Links Forum Website GitHub Status Translation Features Team Rules Help Feeds
    Jellyfin Forum Support Troubleshooting Networking & Access CSP

     
    • 0 Vote(s) - 0 Average

    CSP

    How to: CSP + Traefik
    Partition
    Offline

    Junior Member

    Posts: 7
    Threads: 2
    Joined: 2024 Apr
    Reputation: 0
    #1
    2024-04-29, 06:19 PM
    Hey,
    I'm struggeling with a proper solution regarding Jellyfin's Content Security Policy.
    My current traefik setup follows the general recommendations from the official Traefik v2 guide , but it's missing a good csp header solution for an A+ website certificate.
    This topic also has 5 year old feature requests, but I doubt anything is planned at the moment:
    • https://features.jellyfin.org/posts/95/implement-a-safe-content-security-policy 
    • https://features.jellyfin.org/posts/155/csp-compatibility-some-websecurity-standards

    My current config looks like this:

    Code:
    contentsecuritypolicy: "  base-uri 'none';  connect-src 'self';  default-src 'none';  font-src 'self';  form-action 'self';  frame-ancestors 'none';  frame-src 'self';  img-src 'self';  media-src 'self' data:;  object-src 'none';  script-src 'self';  style-src 'self'"

    It accomplishes an A+ certificate ( otherwise it's only B ), but I'm unable to resolve the jellyfin subdomain from a browser and the mobile app. The webpage is completely broken, but some apps like the one for Windows and Android TV work.
    What should I change in my CSP header config to have a usable webpage untill / if the features get implemented?
    niels
    Offline

    Core Team

    Posts: 248
    Threads: 4
    Joined: 2023 Jun
    Reputation: 12
    Country:Netherlands
    #2
    2024-04-29, 07:02 PM
    This is the CSP I've configured on my own server (via nginx) and it works fine with both Android apps:


    content-security-policy: default-src https: data: blob:; style-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-inline' https://www.gstatic.com https://www.youtube.com blob:; worker-src 'self' blob:; connect-src 'self'; object-src 'none'; frame-ancestors 'self'


    Do note that this strictly disallows custom CSS/images loaded from other origins.
    [Image: GitHub%20Sponsors-grey?logo=github]
    Partition
    Offline

    Junior Member

    Posts: 7
    Threads: 2
    Joined: 2024 Apr
    Reputation: 0
    #3
    2024-04-29, 09:37 PM (This post was last modified: 2024-04-29, 09:40 PM by Partition. Edited 1 time in total.)
    (2024-04-29, 07:02 PM)niels Wrote:
    content-security-policy: default-src https: data: blob:; style-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-inline' https://www.gstatic.com https://www.youtube.com blob:; worker-src 'self' blob:; connect-src 'self'; object-src 'none'; frame-ancestors 'self'

    Thank you very much for your input. This solution worked for the mobile app and browser, but the csp config is still not safe enough for a valid A+ configuration. The certificate went from B ( no csp config ) to B+.
    Here is the output from Mozilla Observatory:

    Quote:Test: Content Security Policy
    Pass: No
    Score: -20
    Reason: Content Security Policy (CSP) implemented unsafely. This includes 'unsafe-inline' or data: inside script-src, overly broad sources such as https: inside object-src or script-src, or not restricting the sources for object-srcor script-src.

    Furthermore is a broad use of the default-src to "https:" and "data:" not the best option, because a load of other directives fetch the default-src value if you haven't specified them, like child-src, connect-src, frame-src, etc. Regarding the test from  https://csp-evaluator.withgoogle.com/?csp=YOURDOMAIN confirmed that the script-src is the most problematic:

    Quote:script-src - Host whitelists can frequently be bypassed. Consider using 'strict-dynamic' in combination with CSP nonces or hashes.

    'self'
    • 'self' can be problematic if you host JSONP, Angular or user uploaded files.

    error
    'unsafe-inline'
    • 'unsafe-inline' allows the execution of unsafe in-page scripts and event handlers.

    error
    https://www.gstatic.com
    • www.gstatic.com is known to host Angular libraries which allow to bypass this CSP.

    error
    https://www.youtube.com
    • www.youtube.com is known to host JSONP endpoints which allow to bypass this CSP.

    check
    blob:


    I removed the 'unsafe-inline', gstatic and youtube links and got an A+ certificate. The trailer won't load in the browser, but that's not a problem for me because the android based apps are using the external youtube app for this. The 'self' definition might also exploitable as a compromised account could upload malicious content over e.x. the profile picture uploader. I try to make my public jellyfin domain as tight as possible to avoid any future exploits, but it seems impossible without the use of 'unsafe-inline' or broader definitions...
    There has to be a way to avoid this, but I'm not familiar enough with csp headers (yet).
    niels
    Offline

    Core Team

    Posts: 248
    Threads: 4
    Joined: 2023 Jun
    Reputation: 12
    Country:Netherlands
    #4
    2024-04-30, 05:37 AM
    Those measure tools are just tools. The web frontend for Jellyfin requires inline scripts and data urls so you can't block them in the CSP.

    gstatic.com is for chromecast support
    youtube.com is for trailers
    [Image: GitHub%20Sponsors-grey?logo=github]
    Partition
    Offline

    Junior Member

    Posts: 7
    Threads: 2
    Joined: 2024 Apr
    Reputation: 0
    #5
    2024-04-30, 08:09 AM (This post was last modified: 2024-04-30, 08:14 AM by Partition. Edited 1 time in total.)
    (2024-04-30, 05:37 AM)niels Wrote: Those measure tools are just tools. The web frontend for Jellyfin requires inline scripts and data urls so you can't block them in the CSP.

    gstatic.com is for chromecast support
    youtube.com is for trailers

    Thank you for the clarification.
    I know that I can't block them in Jellyfins current state, but the goal is to make it as safe as possible without using broad directives that could potentially be abused.

    The main.jellyfin.bundle.js is the only file that is referenced in style-src errors while loading without unsafe-inline.
    Do you know if this is the only loaded file for the web frontend? Yesterday I was experimenting with the strict-dynamic directive and using hashes for verification, but couldn't get it to work. The strict-dynamic-directive of style-src-attr and style-src-elem in combination of a hash value should allow unsafe-inline, but only from the referenced file with the correct hash.
    The only downsite is I have to edit the traefik config when the *.js file gets updated.

    Any thoughts about that approach?

    Edit:  I just noticed you are one of the devs from the android tv app. Great work btw! I came from the Samsung Tizen build and it's a night and day difference to use an official app.
    niels
    Offline

    Core Team

    Posts: 248
    Threads: 4
    Joined: 2023 Jun
    Reputation: 12
    Country:Netherlands
    #6
    2024-04-30, 08:13 AM
    The JavaScript for the frontend is split into multiple files (chunks) and we cannot guarantee the code that needs unsafe-inline is in one specific file for each build.
    [Image: GitHub%20Sponsors-grey?logo=github]
    Partition
    Offline

    Junior Member

    Posts: 7
    Threads: 2
    Joined: 2024 Apr
    Reputation: 0
    #7
    2024-04-30, 08:39 AM
    (2024-04-30, 08:13 AM)niels Wrote: The JavaScript for the frontend is split into multiple files (chunks) and we cannot guarantee the code that needs unsafe-inline is in one specific file for each build.

    Okay I guess I have to check it after each update step by step to see what breaks.
    Do you know if there are any plans to reduce the inline scripts for jellyfin to specific files or to make it more transparent what resources are containing them?
    For example like the comment from "Shane Lord":
    Quote: Ultimately all inline resources need to be moved to their own javascript/style files. See here for easy guidance. This will need to be done by the Jellyfin developers I believe. https://csper.io/docs/guide-removing-inline
    This could potentially help a lot of users who expose jellyfin to the public and are unware of that issue.

    BTW if you didn't see my edit: Thanks for your contribution to the Jellyfin project! The AndroidTV app is a night and day difference to the unofficial Samsung Tizen build.
    niels
    Offline

    Core Team

    Posts: 248
    Threads: 4
    Joined: 2023 Jun
    Reputation: 12
    Country:Netherlands
    #8
    2024-04-30, 08:42 AM
    The frontend is slowly modernizing it's stack so inline scripts should disappear over time. Although I can't tell if they would be removed completely in the end.
    [Image: GitHub%20Sponsors-grey?logo=github]
    « Next Oldest | Next Newest »

    Users browsing this thread: 1 Guest(s)


    • View a Printable Version
    • Subscribe to this thread
    Forum Jump:

    Home · Team · Help · Contact
    © Designed by D&D - Powered by MyBB
    L


    Jellyfin

    The Free Software Media System

    Linear Mode
    Threaded Mode