Cloudron makes it easy to run web apps like WordPress, Nextcloud, GitLab on your server. Find out more or install now.


    Cloudron Forum

    • Register
    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular

    Solved Referrer-Policy header is overwritten

    Feature Requests
    3
    5
    157
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • G
      gerben last edited by

      It looks like Cloudron hides apps’ Referrer-Policy HTTP header (in this line), replacing it with the rather lax value “no-referrer-when-downgrade”, which can result in private URLs leaking to third parties.

      Example case that led to this discovery: We run HedgeDoc (which adds a “same-origin” policy); and just this week we found that, without us having published our pad’s URL anywhere, somebody had edited the pad after finding the URL in their server logs.

      I am not sure what the ideal solution would be. Perhaps you may want to add your referrer policy only if the application did not already specify one?

      girish 1 Reply Last reply Reply Quote 0
      • nebulon
        nebulon Staff last edited by

        Moved this from support to feature request section.

        I agree, I think it makes sense to only set the header if not sent from downstream (ie the app already)

        Are there any other ideas how to maybe better control this behavior?

        1 Reply Last reply Reply Quote 0
        • girish
          girish Staff @gerben last edited by girish

          @gerben thanks for reporting, I have fixed the default policy to same-origin now.

          That said, I think we have to report this as a security issue upstream in HedgeDoc. I see that a locked mode doc should not be editable by guests but it is. A private mode doc should not be editable by other logged in users but it is. I will report this upstream and put a link here, but looks pretty serious.

          1 Reply Last reply Reply Quote 1
          • girish
            girish Staff last edited by

            I seem to have imagined things, the permissions work perfectly.

            @gerben Can you clarify how an anonymous user ended up editing a doc based on a link? Was it a "freely" permission ? BTW, you can disable anonymous entirely by editing /app/data/config.json and setting allowAnonymous to false.

            b9bc0e8d-91d4-47d3-ac80-013e28da1891-image.png

            G 1 Reply Last reply Reply Quote 0
            • G
              gerben @girish last edited by

              @girish Indeed, the pad had ‘freely’ permission; but that should mean freely editable only to people knowing the URL. By clicking a link in the pad, the pad’s URL was made available to the owner of the linked website.

              1 Reply Last reply Reply Quote 0
              • First post
                Last post
              Powered by NodeBB