mirror of
https://github.com/dani-garcia/vaultwarden.git
synced 2025-12-09 17:23:04 +03:00
Sends filename validation doesn't work with forward slashes #204
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @KyleKaniecki on GitHub.
Vaultwarden Support String
Your environment (Generated via diagnostics page)
Config & Details (Generated via diagnostics page)
Show Config & Details
Config:
Vaultwarden Build Version
v1.33.2
Deployment method
Official Container Image
Custom deployment method
Deployed on a self-hosted kube cluster
Reverse Proxy
traefik v2
Host/Server Operating System
Linux
Operating System Version
Debian 12
Clients
Browser Extension, CLI
Client Version
cli 2025.1.3
Steps To Reproduce
bw send template send.fileecho '<json>' | base64bw send create <base64content>Expected Result
I expect the server to accept send file names who's base64 version contains forward slashes
Actual Result
The server incorrectly parses the send filename, splitting by forward slashes instead of taking the entire filename and doing the comparison
I believe the issue stems from this block
Logs
Screenshots or Videos
No response
Additional Context
My usecase is I often have to send many files to team members within my organization, and use python + the bitwarden cli to do so. This makes that almost impossible without manual intervention
@stefan0xC commented on GitHub:
@BlackDex that's what the command expects, isn't it? https://bitwarden.com/help/send-cli/#create
@BlackDex commented on GitHub:
Not sure why you are base64 encoding it though?
@stefan0xC commented on GitHub:
btw: the problem is not a forward slash in the filename that is send (that seems to work just fine, is just an indication of a directory, etc.) but with how it's processed by the server (if the encrypted name includes a
/)which is why this sometimes fails and sometimes doesn't.
@stefan0xC commented on GitHub:
Well, it seems to work just fine with the web-vault so it might be a client side issue? Not sure how to check what request the cli is sending but it might not provide the proper filename?
@BlackDex commented on GitHub:
I wonder what happens when just using
--file, and why it doesn't fail on other clients (as far as we know).I have not tested it though. And cli file uploads didn't worked for a long time anyways, so we weren't able to check that scenario.
It also might be something changed in general, and we haven't noticed it yet.
@BlackDex commented on GitHub:
So, probably a bug in the cli client then hehe.
@KyleKaniecki commented on GitHub:
I've actually been going down this path as well. I believe the cli creates the object here, but I am still grepping how / where the client itself sends the data to the server
I tried to use the file flag for a bit, but I kept getting
Error parsing the encoded request data.with any permutation that didn't include thefilekey in the object, unfortunately@stefan0xC commented on GitHub:
As far as I've tested it the web-vault sends the same
fileNameboth in/api/sends/file/v2:"2.Xoqh62MG8wjAKFc9M9ak5Q==|hAx3z34rbQdHxJNXLYe8HQ==|i0QdhPF/GWLRn76NkiAmoOL/9nI/BF13QaR8VIr8Epg="as it does when sending the file to/api/sends/<send_id>/file/<file_id>:Content-Disposition: form-data; name="data"; filename="2.Xoqh62MG8wjAKFc9M9ak5Q==|hAx3z34rbQdHxJNXLYe8HQ==|i0QdhPF/GWLRn76NkiAmoOL/9nI/BF13QaR8VIr8Epg="while I suspect the CLI request would appear to only send something likeContent-Disposition: form-data; name="data"; filename="BF13QaR8VIr8Epg="instead.@stefan0xC commented on GitHub:
Yeah, well I mean that's just my guess, that this happens here which might even be caused by
form-data.Cf. https://github.com/form-data/form-data/issues/570
I think this is because they should use
filepathinstead offilenameif I understand the code correctly.But I have not tested it, so might be wrong. 😅
@KyleKaniecki commented on GitHub:
sigh I'm starting to see the reports...
https://github.com/bitwarden/clients/issues/5876
^ In that report, you can see the headers being truncated as well
Looks like I will take a stab at my own python client. Cheers 🍻
@stefan0xC commented on GitHub:
@BlackDex should we fix this by being less strict about the filename? I.e. instead of only accepting
raw_file_name.dangerous_unsafe_unsanitized_raw() == send_data.fileNamealso allow something likesend_data.fileName.ends_with(raw_file_name.dangerous_unsafe_unsanitized_raw().as_str())to account for truncated paths.@BlackDex commented on GitHub:
It does look like it shouldn't be having any impact indeed.
But there was something about it in some way. But i can't find the report about it anymore.
@stefan0xC commented on GitHub:
How so? I mean I think it makes sense to validate it but If I wrote a malicious client I could still send whatever custom name I wanted for both fields, wouldn't I? Also I don't think that we are even using the raw name for send files anyway and even if we did store it in the database somewhere, wouldn't this comment from the legacy file attachments API also apply?
3baffeee9a/src/api/core/ciphers.rs (L1256-L1259)@BlackDex commented on GitHub:
@stefan0xC that might be a good idea. Maybe we could check if it's the cli client and allow lesser strict checks?
Because we do need to validate it to prevent custom names as a security precaution.