Summary

Like the title says, i know this isnt really a security vuln its more on the sysadmin side (https://owasp.org/Top10/A05_2021-Security_Misconfiguration/) but read the details (it is a common misconfig) me and my friend ren found

Details

The endpoint /api/check is called when the user starts to enter a username on the register page and when they click continue. The frontend page says "Someone with this username already exists" but the response from the api says "no code" through this check

if (config.features.invites && !code) return res.badRequest('no code')

This is expected behaviour if no code is specified in the url.

But the register endpoint does not have this check, well it does

else if (config.features.invites && !config.features.user_registration && !user?.administrator)
    return res.badRequest('Bad invite');

and it doesnt respond with "no code" it responds with "Bad invite" but this is only if invites are enabled AND user_registration is disabled if both of these options are enabled it registers the user anyway even with invites enabled this is the misconfiguration that me and others made:

- FEATURES_USER_REGISTRATION=true
- FEATURES_INVITES=true

when i was self hosting zipline i thought this would be the proper configuration but i guess not, me and my friend found out we can either drop the /api/check request or simply just send a post request to register to register a user most importantly i also had people come to me before i found the proper configuration

#- FEATURES_USER_REGISTRATION=true
- FEATURES_INVITES=true

saying they had managed to register without an invite through the frontend not through the api and they didnt run into the "no code" on /api/check like i did. My bad guess is that their internet is so bad they couldnt perform the /api/check request so it never responded with "no code" but idk.

PoC

just make a post request to the register api endpoint with no invite code ({"username":"lmao", "password":"lmao"}) and it will register even if the invite feature is enabled heres the shitty python script

import requests

# invite = input('Invite: ')
username = input("Username: ")
password = input("Password: ")

r = requests.post("https://104.168.64.254/api/auth/register", json={"username": username, "password": password}, verify=False)
if r.status_code == 200:
    print(f"Successfully created account {username}:{password} | {r.status_code}")
else:
    print(f"Error while creating account | {r.status_code}\n -> {r.text}")

Impact

This well let the new user see stats (if enabled, normally is on the servers i tested) and fill storage by uploading many (i mean alot) of images through the site and not through sharex.
Using a censys query

services.http.response.body = "*https://zipline.diced.sh/*" and services.http.response.body = "*\"user_registration\":true*"

you can find zipline instances that have registration enabled and its not alot of results but all of these results have invites enabled (i would add "invites":true,"user_registration":true to the query but it times out on censys) you can compare this to the proper configuration

services.http.response.body = "*https://zipline.diced.sh/*" and services.http.response.body = "*\"invites\":true,\"user_registration\":false*"

which doesnt timeout for some reason and u get 12/22 results that have invites enabled (out of 210 hosts using zipline) being misconfigured that are public (obviously)

Advisory

The fix is in the pr and ik its dumb as fuck that its one statement but honestly this is a skill issue on sysadmins part but u can change it if u want or u can put it in ur docs and risk people not seeing it up to you but i dont see the downside of changing it tbh.