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


  • Categories
  • Recent
  • Tags
  • Popular
  • Bookmarks
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse

Cloudron Forum

Apps | Demo | Docs | Install

Referrer-Policy header is overwritten

Scheduled Pinned Locked Moved Solved Feature Requests
5 Posts 3 Posters 260 Views
    • 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 Offline
    G Offline
    gerben
    wrote on last edited by
    #1

    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?

    girishG 1 Reply Last reply
    0
  • nebulonN Offline
    nebulonN Offline
    nebulon Staff
    wrote on last edited by
    #2

    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
    0
  • girishG Offline
    girishG Offline
    girish Staff
    replied to gerben on last edited by girish
    #3

    @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
    1
  • girishG Offline
    girishG Offline
    girish Staff
    wrote on last edited by
    #4

    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
    0
  • G Offline
    G Offline
    gerben
    replied to girish on last edited by
    #5

    @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
    0
  • girishG girish referenced this topic on

  • Login

  • Don't have an account? Register

  • Login or register to search.
  • First post
    Last post
0
  • Categories
  • Recent
  • Tags
  • Popular
  • Bookmarks
  • Login

  • Don't have an account? Register

  • Login or register to search.