Hi all. I’ve been having some problems keeping fedia.io running - at the moment, either the message workers or the php web server processes are dying after an hour or so and I have to restart everything. I have been working with the mbin team and installed some updates that we hoped would fix the problems, but no luck. I am going to work on a cron job to automatically restart things once an hour. The down side, is that you’ll likely see some error 500’s if you happen to hit it when the processes are restarting, but it should happen quickly and refreshing the page should make it work again.

  • melroy@kbin.melroy.org
    link
    fedilink
    arrow-up
    2
    ·
    2 months ago

    FYI. Reading: https://symfony.com/doc/7.2/security/csrf.html#installation

    The tokens used for CSRF protection are meant to be different for every user and they are stored in the session. That’s why a session is started automatically as soon as you render a form with CSRF protection.

    Moreover, this means that you cannot fully cache pages that include CSRF protected forms. As an alternative, you can:

    • Embed the form inside an uncached ESI fragment and cache the rest of the page contents;
    • Cache the entire page and load the form via an uncached AJAX request;
    • Cache the entire page and use hinclude.js to load the CSRF token with an uncached AJAX request and replace the form field value with it.
      • melroy@kbin.melroy.org
        link
        fedilink
        arrow-up
        1
        ·
        2 months ago

        Or remove… CSRF protection and keep the cache… It’s a trade-off… @jerry@fedia.io How much protection does CSRF on these forms really gives the user? I’m “just” the software engineer, you are the SecOps expert here… I mean how likely is it really that sites are doing a Cross-Site Request Forgery …

        • jerry@fedia.ioOPM
          link
          fedilink
          arrow-up
          3
          ·
          2 months ago

          it’s hard to make a blanket statement, because it depends on the details of the application. CSRF attacks are definitely real and common, but using csrf tokens isn’t critical in every application. For example, I think we have CORS headers enabled, I don’t think we have functionality that allows embedded iframes, but we do allow links - if we have administrative functions that can be triggered solely with GET parameters, then someone could trick an administrator into doing something that caused damage by clicking on a link in a post. The only one that would obviously work that I can see is “logout”, which would be annoying, but not world ending, and would work for everyone, not just administrators.

          • melroy@kbin.melroy.org
            link
            fedilink
            arrow-up
            1
            ·
            2 months ago

            Thanks. I see. I do see the importance for login & logout forms having CSRF. But it does seems a bit overkill to have it on upvotes, boost and alike… I could be wrong.