Comments (36)
Implement built in authentication for uploading.
That would indeed be great for private instances.
I'm speculating here, but wouldn't authentication have fixed the original problem with malware on Mozilla's hosted version? If users are authenticated, that fixes the security hole.
Mozilla did implement this with Firefox Accounts, but Send was shut down before it reached the public due to other reasons.
I currently don't have the bandwidth to implement this, sadly. If there's someone that would like to give it a go, please do.
On a technical level, the password must be validated on the websocket before uploading. It doesn't affect end-to-end encryption on uploads so it shouldn't requite too significant changes. A password check on the upload page itself would probably be desirable as well.
from send.
Ah cool, didn't realize there was existing work to remove the old system. My proposed approach definitely wont work if the ANON_
values are totally removed, so scratch that path.
I think a minimalist login page -> cookie set -> header passed to unlock websocket as you originally suggested makes sense. We can tiptoe around the old auth code and leave the task of removing it for later.
from send.
Feel free to use my commit -> https://github.com/dylangerdaly/send/tree/password_protect
I've re-jigged the 'password' prompt to be used for authentication, it's super hacky and shouldn't be considered 'good'
from send.
@TheGITofTeo997 You can find here the full project. Feel free to ask if you need help.
from send.
If anyone is interested, I managed to setup an authentication portal which allows only some authenticated users to upload files using Caddy and Authelia. It supports Basic Authentication for uploading with ffsend.
Caddyfile
<DOMAIN> {
# Authentication Portal
handle /auth/* {
reverse_proxy auth:9091
}
@basicauth {
header Authorization Basic*
}
# Send via BasicAuth
handle @basicauth {
forward_auth auth:9091 {
uri /auth/api/verify?auth=basic
copy_headers Remote-User Remote-Groups Remote-Name Remote-Email
}
reverse_proxy send:1443
}
# Send via Authentication Portal
handle {
forward_auth auth:9091 {
uri /auth/api/verify?rd=https://<DOMAIN>/auth/
copy_headers Remote-User Remote-Groups Remote-Name Remote-Email
}
reverse_proxy send:1443
}
}
authelia_configuration.yml
# ........
server:
path: "auth"
# ........
access_control:
default_policy: deny
rules:
- domain: '<DOMAIN>'
policy: bypass
resources:
- '^(\/api)?\/download\/'
- '^\/api\/metadata\/'
- '\.(js|css|jpg|png|svg|woff2|txt)$'
methods:
- GET
- HEAD
- domain: '<DOMAIN>'
policy: one_factor
subject:
- ['group:admins']
# ........
from send.
is this feature added now?
from send.
@rcaillon-Iliad I got the setup working now, thank you so much for sharing! Unfortunately i didn't know authelia so they were all new tools for me
from send.
I moved to https://github.com/psi-4ward/psitransfer/ which supports a simple password protection prior uploading as well as password protection on downloads, so it cannot be abused and shared links are protected.
from send.
From reading through the code just now, it looks like a pretty decent auth system is actually already implemented in Send.
It's designed to use Mozilla's open-source FXA (Firefox Accounts) service (which speaks OAuth 2.0 among other auth protocols):
- https://github.com/mozilla/fxa
- https://github.com/mozilla/fxa-auth-server/blob/master/docs/api.md
- https://mozilla.github.io/ecosystem-platform/docs/features/firefox-accounts/fxa-overview
- https://mozilla-services.readthedocs.io/en/latest/howtos/run-fxa.html
- https://github.com/michielbdejong/fxa-self-hosting (old instructions)
- https://github.com/jackyzy823/fxa-selfhosting (more recent instructions as of 2020)
To set up auth with Send + FXA, you should first run an FXA server in Docker, then point Send to it by configuring FXA_URL=https://url-of-fxa.example.com
and the other FXA options here: https://github.com/timvisee/send/blob/master/server/config.js#L143.
I'm not sure if Send uses plain OAuth 2.0, or if it uses one of FXA's other hand-rolled auth protocols, that's something you'd have to dig into. The login()
method here looks like plain OAuth 2.0 but I cant tell if there is more beyond that. If it just uses OAuth 2.0, then with some small tweaks you could point FXA_URL
to any other OAuth 2.0 provider and use that instead (e.g. Auth0, CloudFlare Access, etc., many companies already have a compatible SAML provider).
You can find the existing auth flow and user account code in Send here:
- https://github.com/timvisee/send/blob/master/app/user.js
- https://github.com/timvisee/send/blob/master/app/fxa.js
- https://github.com/timvisee/send/blob/master/app/ui/account.js
If you want to re-implement auth to be simpler (e.g. password only instead of user accounts), I'd try to do so by reusing as much of the https://github.com/timvisee/send/blob/master/app/ui/account.js and https://github.com/timvisee/send/blob/master/app/user.js code as possible and just swapping out the API calls that Send makes to FXA methods https://github.com/timvisee/send/blob/master/app/fxa.js, instead of writing it completely from scratch.
Proposed implementation for simple hardcoded password re-using most of the existing Auth code:
- Add a hard-codable config var
UI_PASSWORD
to https://github.com/timvisee/send/blob/master/server/config.js (default is empty/null) - Create a simple password entry form page
ui/login.js
that saves the password in a cookie on the frontend (no POST request needed) - stub out the FXA/OAuth methods in https://github.com/timvisee/send/blob/master/app/ui/account.js used to cryptographically verify the OAuth 2.0
Bearer header
in the old implementation, and have them check the cookie value against the staticUI_PASSWORD
config val instead - Re-use the existing https://github.com/timvisee/send/blob/master/app/user.js User object and initialize it with dummy values for all authed users, that way the existing frontend https://github.com/timvisee/send/blob/master/app/ui/account.js UI shows them as a logged in user and provides a logout button
- Direct users to configure
ANON_MAX_FILE_SIZE=0
if they want non-authed users to not be able to upload at all, otherwise they can keep it and have separate upload limits for anon users and users that have put the correctUI_PASSWORD
on the/login
page first
I don't have time to implement this myself, but maybe you or someone else can take a crack at it @AliMickey.
from send.
CC @pirate
Thanks for taking a look into it. I do have some comments though.
From reading through the code just now, it looks like a pretty decent auth system is actually already implemented in Send.
Mozilla did indeed implement this. I am not sure if it was ever fully finished, and we're actually in the progress of fully removing it (see https://gitlab.com/timvisee/send/-/issues/3).
I'm not sure if Send uses plain OAuth 2.0, or if it uses one of FXA's other hand-rolled auth protocols, that's something you'd have to dig into.
It has been a while since I inspected their implementation, but I believe it was OAuth 2.0 with some hand rolled additions.
Direct users to configure ANON_MAX_FILE_SIZE=0 if they want non-authed users to not be able to upload at all, (...)
The ANON_MAX_FILE_SIZE
variable has actually been removed.
Your proposed implementation seems like a valid approach. Thanks for writing it down!
from send.
Is there any progress on this issue? Uploading requires password verification while downloading not is a very practical feature. Is there any way to implement this function through nginx configuration files? 😄
from send.
I agree. I originally tired using htaccess to protect the main page, but on the mobile site after the download succeeds, /download
offers to let you try the service and upload without auth.
from send.
I'm speculating here, but wouldn't authentication have fixed the original problem with malware on Mozilla's hosted version? If users are authenticated, that fixes the security hole. So with this in place, this tool becomes secure (or just running it behind a VPN).
from send.
I'm speculating here, but wouldn't authentication have fixed the original problem with malware on Mozilla's hosted version? If users are authenticated, that fixes the security hole. So with this in place, this tool becomes secure (or just running it behind a VPN).
Mozilla has been trying to cut costs recently, that could just be an excuse for shutting down this free service. Wouldn't have been cheap to run all that storage and traffic.
from send.
Well, sure, but I mean it could have solved the malware problems.
from send.
I currently don't have the bandwidth to implement this, sadly. If there's someone that would like to give it a go, please do.
I'm happy to try, but i have never done anything with a project this 'big'. Is it possible if you could point towards the main files where uploading is done.
from send.
Feel free to use my commit -> https://github.com/dylangerdaly/send/tree/password_protect
I've re-jigged the 'password' prompt to be used for authentication, it's super hacky and shouldn't be considered 'good'
Nice work. At this moment your changes assume there always is a password to authenticate with, right? Meaning, this implementation doesn't make it optional.
from send.
Currently it's shoved in there, I'll try add a new UI element based on a config conditional time permitting.
from send.
Currently it's shoved in there, I'll try add a new UI element based on a config conditional time permitting.
That would be awesome. I'd be happy to merge.
from send.
I agree. I originally tired using htaccess to protect the main page, but on the mobile site after the download succeeds,
/download
offers to let you try the service and upload without auth.
We did the same, using htaccess, but there are some tricky problems.
One thing, that might help to hide the "try the service ..." button, to introduce a boolean ENV variable for this button (true ... show, false ...hide
from send.
This suggestion seems to be exactly what Send needs at the moment. Seems like it would solve a lot of abuse of service situations!
from send.
Feel free to use my commit -> https://github.com/dylangerdaly/send/tree/password_protect
I've re-jigged the 'password' prompt to be used for authentication, it's super hacky and shouldn't be considered 'good'
@dylangerdaly Your commit works great, thanks. Unfortunately ffsend (https://github.com/timvisee/ffsend) somehow does not work with it.
from send.
@timvisee Could we potentially get this merged and pushed to docker registry?
from send.
That would be fantastic, also the environment for docker would be "AUTH_PASSWORD=xxxxx" correct?
from send.
This would also solve #72. I would welcome this feature a lot.
from send.
I would like to see an optional password feature which is requires to upload files to an instance. This can allow the owner of the instance to use their instance for themselves only or with a group of friends they trust by sharing the password with.
from send.
Also like this feature to be added. Since my server has limited storage space and bandwidth, I would only want the one with the password to use my server.
from send.
from send.
from send.
If this is added, would be nice for the admin to add multiple password (accounts). This way you and let say a friend can only upload to the send instance and the admin has his own password while your friend has their own password for uploading files.
from send.
would love to have it added too
from send.
If this issue is still open, it's not, I cannot spot it. @timvisee is probably too busy to tackle this and I have him rather maintain this in peace. I'm pretty sure he is open for PRs though.
from send.
@rcaillon-Iliad Hello,
I've been trying the whole day to achieve your setup but unfortunately without success. I am very interested in it, could you please provide more detail or is it possible to contact you? Thanks
from send.
Would like this more than any other feature.
from send.
I moved to https://github.com/psi-4ward/psitransfer/ which supports a simple password protection prior uploading as well as password protection on downloads, so it cannot be abused and shared links are protected.
To clarify. Had a look on psitransfer and it looks like you dont can password protect the upload, but like Send you can protect the download with a password.
We would like to password protect access to the upload.
from send.
@thmmsn That's not true:
![Screenshot 2023-06-25 at 12 04 32](https://private-user-images.githubusercontent.com/24259245/248546709-3d97a673-3d68-4e49-af5d-9f6e557c1f6a.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjEyMzI2MjksIm5iZiI6MTcyMTIzMjMyOSwicGF0aCI6Ii8yNDI1OTI0NS8yNDg1NDY3MDktM2Q5N2E2NzMtM2Q2OC00ZTQ5LWFmNWQtOWY2ZTU1N2MxZjZhLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDA3MTclMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwNzE3VDE2MDUyOVomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTM2ZjczOGEzMjhlYzliNTU2NzhhZTAyZGM5NTUxODhiZGZlNmNlOWZiMDk4NDkyZDcyMzU0NjRlOTM2ZDlmNGQmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.DQ-XgVPTeqmRC5eMr6wVmx4DABWyL_rDa8WDy6oXuAg)
It's off by default, but can be turned on in the configs.
You can also password protect the downloads:
![Screenshot 2023-06-25 at 12 06 28](https://private-user-images.githubusercontent.com/24259245/248546821-28e72547-d8e6-4b34-b706-392f3f12f2ea.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjEyMzI2MjksIm5iZiI6MTcyMTIzMjMyOSwicGF0aCI6Ii8yNDI1OTI0NS8yNDg1NDY4MjEtMjhlNzI1NDctZDhlNi00YjM0LWI3MDYtMzkyZjNmMTJmMmVhLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDA3MTclMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwNzE3VDE2MDUyOVomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPWJkNjg5NjUxYzJmY2QxNTQzMmNiYjNkMWVmMWRkY2ZkMzExZGY5ZWNmNTVhZjc0NGQ0OGU2NTk2ZTlkNzEzYTgmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.8MblWoxwCwZKqKVJzczg63wuS6xN4PrwoR5raHkKrQw)
The unprotected hotlink is long and random and cannot be guessed, it can only be accessed when knowing the download password. So it serves me well, actually.
from send.
Related Issues (20)
- Any way to make the upload accessible only for internal users and download for external? HOT 2
- If you click the logo then you're redirected to the homepage. How can I turn this off? HOT 2
- Logo reverse back after npm run build
- Error with redirection because of the # in the last part of the link url
- Add `unlimited` as an option for max downloads when sharing a file
- Uploading a folder not working HOT 2
- CUSTOM_DESCRIPTION does not seem to work
- Using send with password behind apache reverse proxy failed HOT 2
- Uploads fail after Send has been running for a extended period fo time HOT 1
- Can`t install Send
- Is it possible to recover an expired link data? HOT 1
- customizing the text under Simple, private file sharing HOT 2
- Is there a possibility to keep the unexpired send-archive always visible? HOT 1
- [FEATURE REQUEST] Add folder picker option like WeTransfer HOT 3
- [Request] ARM64 Support HOT 1
- Download URL accessible but files won't download. HOT 3
- Docker Compose Install - Customization HOT 1
- Feature Request: View-Only Mode HOT 2
- [Security issue]: Password bruteforcing HOT 4
- Is this project still mentained? HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from send.