Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Spacenames should be validated/sanitized #4925

Closed
kobergj opened this issue Oct 27, 2022 · 10 comments
Closed

Spacenames should be validated/sanitized #4925

kobergj opened this issue Oct 27, 2022 · 10 comments
Assignees
Labels
Priority:p2-high Escalation, on top of current planning, release blocker Type:Bug

Comments

@kobergj
Copy link
Collaborator

kobergj commented Oct 27, 2022

Right now spacenames are not validated in any way. However having certain characters in a space name can break or heavily influence clients. Proposed sanitization includes:

  • sane length, doesn't need to be 255. I was able to enter 2k characters, at some point the web ui silently failed.
  • I don't think we should support leading or trailing spaces.
  • Path elements.
  • Evil characters.

Still to be decided: Should the server sanitize or return BAD REQUEST?

@kobergj
Copy link
Collaborator Author

kobergj commented Oct 27, 2022

@TheOneRing

  • I consider path elements "/", "\" and ".". Anything I forgot?
  • Could you specify evil characters?

@TheOneRing
Copy link
Contributor

For windows we also have:
QLatin1Char('\\'), QLatin1Char(':'), QLatin1Char('?'), QLatin1Char('*'), QLatin1Char('"'), QLatin1Char('>'), QLatin1Char('<'), QLatin1Char('|')
But we already replace them by a _

@TheOneRing
Copy link
Contributor

Trailing spaces as often provided by mac for filenames are another unrelated huge toppic.

@kobergj
Copy link
Collaborator Author

kobergj commented Oct 27, 2022

Ok great. Will do so. Any suggestion for the max length?

@TheOneRing
Copy link
Contributor

250-255 should work, on mostly any platform but would probably always be trimmed.

@micbar
Copy link
Contributor

micbar commented Oct 28, 2022

@kulmann please see the full thread. We have the question if ownCloud web could do some client side validation before submitting the Create Space Request. We would prefer not to introduce "automatic" sanitation of the posted data on the server side and prefer server and client side validation of the space name.

@kulmann
Copy link
Contributor

kulmann commented Oct 28, 2022

As of now web doesn't validate space names (except for forbidding empty strings), but I'd like to add that. For file- and folder-names there is some basic validation in place, see https://github.com/owncloud/web/blob/3b34cc1e87022dffce176a6cfd6c75f5bb040f3d/packages/web-app-files/src/components/AppBar/CreateAndUpload.vue#L463 (code is ugly and old, but works for now). I can apply whatever validation we agree upon here.

@mbarz I told you in a call today, that there is a capability in place, but I remembered that incorrectly. There is a capability for a file extension blacklist in oc10 - that forbids .htaccess, because that's a file name that can harm oc10 instances. Not forbidden in uploads though, so weird anyway. Nothing that would be helpful for cross-client validation schemas.

@kulmann
Copy link
Contributor

kulmann commented Oct 28, 2022

for the record, clarified in chat that the linked validation is only for folder names, not for space names. Space name validation is coming in owncloud/web#7890

@micbar micbar added this to the 2.0.0 General Availability milestone Oct 28, 2022
@micbar micbar added the Priority:p2-high Escalation, on top of current planning, release blocker label Oct 28, 2022
@kobergj
Copy link
Collaborator Author

kobergj commented Nov 2, 2022

comes with this: #4955

@kobergj
Copy link
Collaborator Author

kobergj commented Nov 3, 2022

fixed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Priority:p2-high Escalation, on top of current planning, release blocker Type:Bug
Projects
Archived in project
Development

No branches or pull requests

4 participants