Bugzilla – Full Text Bug Listing
| Summary: | [server] User can grant self access to another user's data | ||
|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Mark Macdonald <mamacdon> |
| Component: | Server | Assignee: | John Arthorne <john.arthorne> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P2 | CC: | bokowski, john.arthorne, simon_kaegi |
| Version: | 0.2 | ||
| Target Milestone: | 0.4 M1 | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 334114 | ||
(In reply to comment #0) We also generate workspace ids in a predictable order, which makes this attack easier. For example, if Bob creates an account and finds his workspace id is "D", he knows right away that other people's workspace ids are A, B, C. making committer-only (for training purposes). Had to change the project for that since the checkbox isn't enabled for e4 yet. Mark, I would open a separate bug for workspace ids. This bug would be to address the issue from comment 0. Do we really need the security advisories group here? We know Orion is not yet secure, and nobody is deploying it in an environment where they are relying on its security. I thought we already had a bug for this (authorizing preference access) but can't find it now. I don't think modifying permissions using the preference service was ever possible. The preference servlet doesn't grant access to arbitrary preference scopes. The preference path must start with either "user", "project", or "workspace". In case of "user", the servlet then appends the name of the authenticated user, so a user can only access their own settings. So I don't see any way a client could access the user rights node at all, or even user-level settings of another user. In any case I have made a small change where requesting invalid paths now returns 405 rather than 404, and I added some JUnit tests to verify that a client cannot access the server metadata via the preference service: http://git.eclipse.org/c/orion/org.eclipse.orion.server.git/commit/?id=08e4207f80477f7382734d6ea1d94d3cd2bf1cd0 |
Build id: 2011-02-10 0200 Currently we store user permissions in a client-writable preference location (Users/<name>/UserRights). This makes it fairly simple for something like this to happen: 1. Alice creates a workspace, id: "A". 2. Bob crafts a UserRights string that grants him access to workspace A, eg: [{ Method: 15, Uri: "/workspace/A" }, { Method: 15, Uri: "/workspace/A/*" }] 3. Bob calls the preference API via REST and sets his UserRights to the above. 4. Bob goes to /workspace/A and can see Alice's data.