security - GamerDuck123/copyparty GitHub Wiki

there is a discord server with an @everyone for all important updates (at the lack of better ideas)

some notes on hardening

• set --rproxy 0 if your copyparty is directly facing the internet (not through a reverse-proxy)
  • cors doesn't work right otherwise
• if you allow anonymous uploads or otherwise don't trust the contents of a volume, you can prevent XSS with volflag nohtml
  • this returns html documents as plaintext, and also disables markdown rendering
• when running behind a reverse-proxy, listen on a unix-socket for tighter access control (and more performance); see reverse-proxy or --help-bind

safety profiles:

• option -s is a shortcut to set the following options:

  • --no-thumb disables thumbnails and audio transcoding to stop copyparty from running FFmpeg/Pillow/VIPS on uploaded files, which is a good idea if anonymous upload is enabled
  • --no-mtag-ff uses mutagen to grab music tags instead of FFmpeg, which is safer and faster but less accurate
  • --dotpart hides uploads from directory listings while they're still incoming
  • --no-robots and --force-js makes life harder for crawlers, see hiding from google

• option -ss is a shortcut for the above plus:

  • --unpost 0, --no-del, --no-mv disables all move/delete support
  • --hardlink creates hardlinks instead of symlinks when deduplicating uploads, which is less maintenance
    • however note if you edit one file it will also affect the other copies
  • --vague-403 returns a "404 not found" instead of "401 unauthorized" which is a common enterprise meme
  • -nih removes the server hostname from directory listings

• option -sss is a shortcut for the above plus:

  • --no-dav disables webdav support
  • --no-logues and --no-readme disables support for readme's and prologues / epilogues in directory listings, which otherwise lets people upload arbitrary (but sandboxed) <script> tags
  • -lo cpp-%Y-%m%d-%H%M%S.txt.xz enables logging to disk
  • -ls **,*,ln,p,r does a scan on startup for any dangerous symlinks

other misc notes:

• you can disable directory listings by giving permission g instead of r, only accepting direct URLs to files
  • you may want filekeys to prevent filename bruteforcing
  • permission h instead of r makes copyparty behave like a traditional webserver with directory listing/index disabled, returning index.html instead
    • compatibility with filekeys: index.html itself can be retrieved without the correct filekey, but all other files are protected

behavior that might be unexpected

• users without read-access to a folder can still see the .prologue.html / .epilogue.html / PREADME.md / README.md contents, for the purpose of showing a description on how to use the uploader for example
• users can submit <script>s which autorun (in a sandbox) for other visitors in a few ways;
  • uploading a README.md -- avoid with --no-readme
  • renaming some.html to .epilogue.html -- avoid with either --no-logues or --no-dot-ren
  • the directory-listing embed is sandboxed (so any malicious scripts can't do any damage) but the markdown editor is not 100% safe, see below
• markdown documents can contain html and <script>s; attempts are made to prevent scripts from executing (unless -emp is specified) but this is not 100% bulletproof, so setting the nohtml volflag is still the safest choice
  • or eliminate the problem entirely by only giving write-access to trustworthy people :^)

cross-site request config

by default, except for GET and HEAD operations, all requests must either:

• not contain an Origin header at all
• or have an Origin matching the server domain
• or the header PW with your password as value

cors can be configured with --acao and --acam, or the protections entirely disabled with --allow-csrf

prevent filename bruteforcing

volflag fk generates filekeys (per-file accesskeys) for all files; users which have full read-access (permission r) will then see URLs with the correct filekey ?k=... appended to the end, and g users must provide that URL including the correct key to avoid a 404

by default, filekeys are generated based on salt (--fk-salt) + filesystem-path + file-size + inode (if not windows); add volflag fka to generate slightly weaker filekeys which will not be invalidated if the file is edited (only salt + path)

permissions wG (write + upget) lets users upload files and receive their own filekeys, still without being able to see other uploads

share specific folders in a volume without giving away full read-access to the rest -- the visitor only needs the g (get) permission to view the link

volflag dk generates dirkeys (per-directory accesskeys) for all folders, granting read-access to that folder; by default only that folder itself, no subfolders

volflag dky disables the actual key-check, meaning anyone can see the contents of a folder where they have g access, but not its subdirectories

• dk + dky gives the same behavior as if all users with g access have full read-access, but subfolders are hidden files (as if their names start with a dot), so dky is an alternative to renaming all the folders for that purpose, maybe just for some users

volflag dks lets people enter subfolders as well, and also enables download-as-zip/tar

if you enable dirkeys, it is probably a good idea to enable filekeys too, otherwise it will be impossible to hotlink files from a folder which was accessed using a dirkey

dirkeys are generated based on another salt (--dk-salt) + filesystem-path and have a few limitations:

• the key does not change if the contents of the folder is modified
  • if you need a new dirkey, either change the salt or rename the folder
• linking to a textfile (so it opens in the textfile viewer) is not possible if recipient doesn't have read-access

you can hash passwords before putting them into config files / providing them as arguments; see --help-pwhash for all the details

--ah-alg argon2 enables it, and if you have any plaintext passwords then it'll print the hashed versions on startup so you can replace them

optionally also specify --ah-cli to enter an interactive mode where it will hash passwords without ever writing the plaintext ones to disk

the default configs take about 0.4 sec and 256 MiB RAM to process a new password on a decent laptop

both HTTP and HTTPS are accepted by default, but letting a reverse proxy handle the https/tls/ssl would be better (probably more secure by default)

copyparty doesn't speak HTTP/2 or QUIC, so using a reverse proxy would solve that as well -- but note that HTTP/1 is usually faster than both HTTP/2 and HTTP/3

if cfssl is installed, copyparty will automatically create a CA and server-cert on startup

• the certs are written to --crt-dir for distribution, see --help for the other --crt options
• this will be a self-signed certificate so you must install your ca.pem into all your browsers/devices
• if you want to avoid the hassle of distributing certs manually, please consider using a reverse proxy