If characters are entered into the URL field of an entry that are not supported (e.g. Space, <, >) those characters are successfully displayed anywhere in KeePass as given instead of using an encoded form (e.g. %20 for Space).
I noticed this issue when I was evaluating a privacy threat via hidden characters in bookmarks (e.g. whitespaces and zero-width characters) that might be generated and hidden into an URL and providing probably enough entropy to uniquely identify an user. While I could not confirm this threat in Firefox's bookmark system (URL's are always encoded) I was also curious if this is an issue with Keepass 2.49 and could confirm this.
But this is probably only a low threat since:
But if such an URL should make it into the users KeePass database the worst that can happen is that opening such an entries URL could immediately uniquely identify the user without them noticing.
IMO, KeePass correctly uses the data you have entered without modification.
Imagine an FTP URL with server parameters etc. This must leave the spaces "as is".
cheers, Paul
Sadly I'm not an expert with URL's and was just evaluating a privacy issue related to the theoretical possibility of websites hiding characters in URL's to add entropy via them and had to look up the URL information. I also can't find any information what a server parameter in a FTP URL would look like but instead that the FTP URL path can be encoded as well. Besides that the information I found earlier that spaces in URL's must be encoded in general to be valid. But also the RFC's changed several times in the past and I can't tell what precisely is correct here - the information about URL's I have given might be taken with care as well and need further validation.
But first it needs to be evaluated if this is actual a privacy threat for KeePass (as I think it is) and if so how it can be solved the best way.
Last edit: Sworddragon 2021-12-28
The URL field can contain all sorts of things, even a DOS command, so it is not possible for KeePass to weed out invalid characters.
Like all things internet, it's up to the user to validate data and ensure they stay safe.
cheers, Paul
KeePass' URL field supports more than just RFC 3986 URIs (local paths, UNC paths,
cmd://command lines, placeholders, ...):https://keepass.info/help/base/autourl.html
Therefore, the field must support all characters.
It's not a security issue, because the user is responsible for checking the data that he enters/runs.
https://keepass.info/help/base/security.html#secmaldata
However, I could imagine KeePass trying to validate certain URIs. There are unclear cases (for example, the URI could contain a placeholder referencing the value of an environment variable, which may change at any time), but at least simple URIs could be validated. So, I'm moving this to the open feature requests.
Thanks and best regards,
Dominik
Ticket moved from /p/keepass/bugs/2124/