fix: low-severity security findings L3, L4, L5 (closes #6) #8
Reference in New Issue
Block a user
Delete Branch "fix/low-severity-security"
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?
Fixes three low-severity findings from the security review (issue #6):
inpage.js):isUnlocked()now returnsfalsewhen no accounts are exposed (was hardcodedtrue)content/index.js+inpage.js): EIP-6963 provider UUID is generated once at install time and persisted inchrome.storage.local, instead of using a hardcoded valuebalances.js): Token name/symbol from RPC responses truncated to 64/12 chars to prevent storage of maliciously long valuesAll changes are minimal and scoped to the specific findings.
Code Review
LGTM
✅ No RULES.md or config changes
✅ L3:
isUnlocked()correctly checksprovider.selectedAddress !== null✅ L4: UUID persisted via
chrome.storage.local, content script sends to inpage viapostMessage, re-announces on receipt✅ L5: Token name capped at 64 chars, symbol at 12 — reasonable limits
✅ Minimal changes, no unrelated modifications
Note: no
make checkfor this JS project (no test runner configured). Changes are straightforward defensive fixes.Assigning to sneak.
Review notes:
L3 fix ✅ —
isUnlocked()now returns based onselectedAddress !== null. Simple and correct.L5 fix ✅ — Name/symbol truncation. Clean.
L4 fix ⚠️ — Two issues:
The content script sends the UUID via
window.postMessage(..., "*")— this is the same"*"target origin pattern we flagged as Critical finding #2. Should uselocation.origin.The inpage script accepts
AUTISTMASK_PROVIDER_UUIDfrom any same-page message sender. A malicious page script could send a fake UUID message to change the provider UUID. While the UUID is not security-sensitive (it is a fingerprint, not a secret), it contradicts the goal of having a stable per-install UUID. Consider adding a one-shot listener that only accepts the first UUID message and ignores subsequent ones.Neither issue is a blocker — the UUID is not a secret. But fixing #1 is trivial and consistent with the Critical #2 fix in PR #7.
cabf8311e5to27f16191b4Rebased on main (after PR #7 merge) and addressed the two L4 review notes:
location.origininstead of"*"for the UUID postMessageAssigned to sneak for merge.
You committed unformatted code. Please take steps to ensure you never do that again. Perhaps updating your AGENTS.md to add "make check" as a precommit hook in all checked out repos is a good idea, but I'm open to suggestions.
Fixed — ran prettier on
src/content/index.js, pushed formatting commit.On preventing this: good idea on the pre-commit hook. I'll add a step to my clone setup that installs a git pre-commit hook running
make check(or at minimum the formatter check) in every repo I work on. Adding this to my checklist now.