[Bug]: Topology functions do not require a trusted context for unimpersonated tokens
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 45/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- java
- Domain
- authorization
Research direction
Reproduce by calling getTokenVBL(getSelected) from a player client on a token the player does not own, as the report describes. Compare the topology lookup functions with the other token lookups, which already require a trusted context, and find where the check is missing. Done when an untrusted player is refused for unimpersonated tokens they do not own, while the GM and owners still succeed.
Written by the indexing model from the issue text.
Description
Describe the Bug
The token topology functions (e.g., getTokenVBL()) allow getting the topology from another token by provide the token's ID. Unlike most other look ups, this does not require a trusted context, meaning any player get the information regardless of whether they own the token.
To Reproduce
- Start a new campaign, and start a server as a GM.
- Join the server with a player client.
- Drop a token on the map. Make sure it is not owned by the player, and add some VBL to it.
- On the GM client (host):
- Select the token.
- Get the token's VBL:
[r: getTokenVBL(getSelected)] - This should rightfully succeed since GMs can do anything.
- On the player client:
- Select the token.
- Get the token's VBL:
[r: getTokenVBL(getSelected)] - This will succeed despite the player not having necessary permissions..
Expected Behaviour
It should not be possible to get another unimpersonated token's topology from an untrusted context.
Screenshots
No response
MapTool Info
MapTool 1.18.8
Desktop
Linux 22.3
Additional Context
I believe this behaviour goes back a long ways, it's not new in 1.18.
- Dominant language
- Java
- Stars
- 927
- Forks
- 286
- Avg merge
- 3d 17h
- Merged PRs (30d)
- 94
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from RPTools/maptool
-
[Bug]: An initiative list with no current entry logs an error on every changePossibly taken @dwizard0 claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Maintainers usually reply within 1 day
-
[Maintenance]: Migrate gradle dependency submission to modern alternativePossibly taken @VelpulaGangavardhan claimed this 18 days ago. Opencode-maintenance
Difficulty 2/5 1-3 hours Newbie friendliness 77/100
RPTools/maptool#6156 · 2 comments · 1 assignee ·
Maintainers usually reply within 1 day
-
code-maintenance
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
Maintainers usually reply within 1 day
-
feature
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Maintainers usually reply within 1 day
Similar issues
-
Cleanup: restore the interrupt flag in AiFailureAnalyzerPossibly taken @Rishankgupta08 claimed this today. Opengood first issue
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
seleniumboot/selenium-boot#258 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
johanhaleby/occurrent#1505 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
FasterXML/jackson-databind#6443 ·
Maintainers usually reply within 1 day
-
Docs: 2 broken linksOpen
Difficulty 1/5 Under an hour Newbie friendliness 78/100
Maintainers usually reply within 1 day