T05 · Unauthorized Access and Privilege Escalation
- Location
references/cli.md:54- Finding
Overbroad Chrome Profile Replication and Cross-Site Credential Access
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This skill is review-needed because it can use logged-in browser sessions across many sites and handles authentication data more broadly than a single-site action needs.
Install only if you are comfortable with a tool that can operate through your logged-in browser sessions. Prefer a dedicated low-privilege browser profile or test accounts, keep write/delete permissions at prompt or deny, avoid finance and primary personal accounts, and treat capture folders, temp output files, and token caches as sensitive secrets.
references/cli.md:54Overbroad Chrome Profile Replication and Cross-Site Credential Access
add-site/capture.md:58Authentication Secrets Are Intentionally Persisted in Raw Captures and Replayed Through Shell Commands
Referenced artifact was not completely inspected
nly `DOC.md`, specs, manifest, examples, and adapters are guaranteed. Per-site `SKILL.md` and `PROGRESS.md` are source-tree docs and are not shipped into `$OPEN
Referenced artifact was not completely inspected
| `add-site/verify.md` | Verify: runtime + spec + doc loop |
Referenced artifact was not completely inspected
| `add-site/document.md` | Document: per-site SKILL.md + DOC.md + PROGRESS.md, knowledge updates |
Referenced artifact was not completely inspected
| `knowledge/adapter-recipes.md` | Adapter patterns, code templates, pitfalls |
YARA rule matched a known malware signature (reverse shell, backdoor, ransomware, C2 framework, or info stealer).
inary protocols, or other site-specific logic that spec cannot express.
>
> When you do write a runner, the contract is `run(ctx: PreparedContext)` — a single function. Adapters can optionally define `warmReady?(page)` to probe per-site readiness during warm-up — runtime polls it until true or `warmTimeoutMs` (default 15000ms) elapses. Use for SPAs whose hydration the runtime can't detect via cookies (Telegram webpack chunks, IndexedDB-backed sessions). The runtime's PagePlan handles general initialization; auth resolution happens before `run(ctx)`. See `doc/main/adapters.md` for the current CustomRunner interface. `PreparedContext` provides `{ page, operation, params, helpers, auth, serverUrl }` — destructure what you need at the top of `run()`.
## Raw-API Principle (read first)
OpenWeb exposes the **wire shape** the upstream returns. Response schemas describe what the server actually sends — not a prettified projection. Agents compose multi-step workflows themselves using t
The webpack-walk section states that internal bundled code may be used to extract API URLs, auth tokens, or persisted query hashes from module closures. That crosses from normal scraping guidance into credential/session-material extraction, which is dangerous because such values can be reused to invoke privileged requests not otherwise exposed through safe interfaces.
The appendix provides step-by-step instructions for harvesting a page nonce, setting verification headers, scraping per-form authenticity tokens, and replaying authenticated mutation requests. This is effectively a playbook for bypassing higher-level safety controls and directly issuing privileged actions with a user's live session on third-party services.
This documentation explicitly describes extracting cookies or initial tokens from a browser, exchanging them for bearer/access tokens, and then using those tokens in Authorization headers. In the context of a skill that can interact with third-party sites, this is credential-handling guidance that could enable unauthorized API access or account actions if misused or insufficiently constrained.
**Common signals:**
- Step 1: Extract cookie or initial token from browser
- Step 2: POST to token endpoint -> receive bearer/access token
- Step 3: Use token in Authorization header
**Examples:**
The examples normalize obtaining access tokens from live browser sessions for social or chat platforms, including handling anti-bot/User-Agent binding to preserve access. That increases risk because it documents techniques for reusing authenticated web sessions outside intended interfaces, which could facilitate account takeover-like behavior, data access, or action execution across many supported sites.
**Examples:**
- e.g. some social sites: cookie CSRF -> POST token endpoint -> bearer JWT -> API
- e.g. some AI chat apps: GET session endpoint -> access token (Cloudflare User-Agent binding)
**Gotchas:**
- **Multi-step chains:** Some sites have 2+ exchange steps (e.g., cookie -> intermediate token -> bearer JWT).
This documentation explicitly describes snapshotting a user's Chrome profile, including highly sensitive authentication stores such as Cookies, Local/Session Storage, IndexedDB, Account Web Data, and Sync Data, in order to preserve logged-in state. In the context of a skill that can interact with many third-party sites, this materially enables bulk credential/session extraction and replay if the copied profile data is exposed, over-collected, or reused beyond the minimum necessary scope.
an PASS, the diagnosis was always wrong. Update both the site DOC.md and any op-level `auth_check` rule so the next agent sees the real signature, not the cascade output.
## Profile-Snapshot Coverage (`copyProfileSelective`)
`browser start` snapshots the user's Chrome profile into `mkdtemp` so it can launch a clean instance with the same auth state. Earlier the snapshot used a tight allowlist (`Cookies`, `Web Data`, `Preferences`, `Local/Session Storage`, `IndexedDB`). That missed several files Chrome consults during sign-in propagation:
- `Account Web Data` — GAIA account metadata for signed-in profiles.
- `Sync Data/` — account sync state; Chrome can mark the profile as signed-out without it.
- `Trust Tokens`, `TransportSecurity`, `Network Persistent State` — TLS/origin-state Chrome expects to be present for an established profile.
- Root-level `First Run` / `Last Version` — without these Chrome treats the user-data-dir as a fresh install and may re-initialise GAIA, droppi
YARA rule matched a known malware signature (reverse shell, backdoor, ransomware, C2 framework, or info stealer).
rfaces compound -- passing one layer's challenge does not satisfy the other. Even `page.evaluate(fetch)` may fail because each system fingerprints different aspects of the request.
- **Transport impact:** Assume page transport mandatory. Node transport and `page.evaluate(fetch)` are both unreliable.
- **Warm-up requirement:** The browser warm-up phase must trigger all sensors. Wait for all vendor cookies to be set before executing operations.
- **Action:** Document all detected layers in the site's DOC.md. Don't attempt node transport unless probe evidence contradicts.
### Custom Signing Spectrum
Detection of client-side request signing via monkey-patched browser APIs.
- **Detection signal:** `window.fetch.toString().length > 100` in browser console means `fetch` has been monkey-patched (native `fetch.toString()` is short). This indicates the site injects custom signing logic into every fetch call.
- **Impact:** `page.evaluate(fetch(...))` inherits the signing because it runs throug
Remote code is downloaded and executed. This bypasses code review and could introduce malicious code.
| "GraphQL requires introspection to model" | Send malformed queries and read error suggestions | Error-message reversal reveals field names and types incrementally |
| "No JSON API exists" | Inspect SSR page source for embedded JSON (`__NEXT_DATA__`, LD+JSON, `window.*`) | Data is in the HTML — no separate API needed, just parse the page |
| "Headers are decorative" | Remove custom headers one at a time, check which cause 403 | Often only 1-2 headers are enforced; the rest are noise from the browser |
| "CORS means node can't call it" | CORS is browser-enforced only — node/curl ignores CORS headers entirely | Node fetch has no CORS restriction; the API works fine from server-side |
| "Rate limiting blocks automation" | Test with reasonable intervals (1-2s between requests) | Most rate limits target burst traffic (>10 req/s), not sequential single requests |
**Verification protocol:** Before accepting any "can't upgrade" conclusion, run the [Node Feasibility Quick-Check](#node-feasibility-quick-check) and document the actual response codes and headers. Assumptions without evidence belong in a probe doc, not a site package.
The documented behavior matches credential-access patterns because it copies cookies and browser storage from the user's default Chrome profile into a temp directory and uses them to operate as the logged-in user. In this skill's context, that may be a product feature rather than overt malware, but it is still security-sensitive and dangerous because it centralizes reusable authentication artifacts that could be stolen or abused if the environment, temp storage, or debugging interface is exposed.
wser Management
The CLI auto-starts a managed headless Chrome when an operation requires browser access. No manual setup needed — exec, browser-backed auth/transport flows, and capture start all launch Chrome on demand and connect automatically. verify --browser just pre-starts and keeps the managed browser alive for the duration of the verify run.
Auto-start copies auth-relevant files (Cookies, Local Storage, Session Storage, Web Data, Preferences) from the user's default Chrome profile to a temp directory, then launches Chrome with --remote-debugging-port. Concurrent auto-start calls are serialized via a filesystem lock. A background watchdog kills idle browsers after 5 minutes.
For manual control:
openweb browser start [--headless] [--port 9222] [--profile <dir>]
openweb browser stop
openweb browser restart
openweb browser status
start — Pre-launch with specific options. Reports existing instance if already runningstop — Kill managed CTool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).
### Cache Location / Manual Clear
Token cache lives at `~/.openweb/tokens/<site>/vault.json` (encrypted AES-256-GCM, key derived via PBKDF2). To force-clear a single site without restarting the browser: `rm -rf ~/.openweb/tokens/<site>`.
### Cross-Site Token Conflict
Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).
### Cache Location / Manual Clear
Token cache lives at `~/.openweb/tokens/<site>/vault.json` (encrypted AES-256-GCM, key derived via PBKDF2). To force-clear a single site without restarting the browser: `rm -rf ~/.openweb/tokens/<site>`.
### Cross-Site Token Conflict
Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).
### Cache Location / Manual Clear
Token cache lives at `~/.openweb/tokens/<site>/vault.json` (encrypted AES-256-GCM, key derived via PBKDF2). To force-clear a single site without restarting the browser: `rm -rf ~/.openweb/tokens/<site>`.
### Cross-Site Token Conflict
The skill explicitly promotes interacting with real third-party websites, including posting, commenting, messaging, and other write-capable actions, but does not provide an upfront safety warning about account, privacy, reputational, or irreversible effects. In an agent context, this increases the risk that a user or downstream agent invokes real-world actions without appreciating that the skill can act through authenticated sessions on live services.
The documented auto-spill behavior writes large website responses to temporary local files without any user-facing warning about local persistence, retention, or sensitivity of scraped/account data. Because this skill accesses real websites and may return private or authenticated content, silently persisting responses can increase the chance of unintended disclosure through local filesystem access, logs, backups, or multi-user environments.
The instructions tell users to perform live write actions such as like/unlike and follow/unfollow to capture CSRF tokens and write endpoints, but do not prominently warn that these mutate real third-party account state. In the context of an automation skill that can post, comment, message, and otherwise interact with live services, this can lead to unintended account actions, policy violations, or abuse of user identities.
The guide explicitly instructs operators to extract authentication tokens from localStorage or page globals and inject them into API requests. In a skill designed to interact with 90+ real websites, this creates a meaningful credential-handling risk: tokens may be exposed in scripts, logs, captures, or reused beyond the minimum necessary scope, enabling account takeover or unauthorized API use if mishandled.
The file explicitly instructs users to test write operations against live sites using commands like liking and unliking posts, but it does not prominently warn that these actions can modify real third-party accounts or content. In an agent skill that can interact with 90+ real websites, this omission increases the chance of unintended live mutations, policy violations, spam-like behavior, or changes to user data during verification or manual testing.
This documentation explicitly teaches operators how to extract API URLs, auth tokens, nonces, and replay authenticated mutation requests against third-party sites. In the context of a skill that can read, post, comment, message, and otherwise act on behalf of a logged-in user across many websites, these instructions materially increase the capability to bypass normal abstractions and perform sensitive state-changing actions using harvested session-bound material.
The appendix gives a concrete recipe for sending authenticated POST requests using per-page nonces and verification headers, but provides no warning that these are state-changing actions that can subscribe, star, message, or otherwise modify account state. In an agent skill designed to interact with real user accounts on external sites, omission of such warnings and controls makes misuse and unsafe automation significantly more likely.
This guidance enumerates high-risk write operations such as follow/unfollow, block/unblock, hide replies, and especially send/delete private messages without any safety gating, confirmation requirements, or warning about account and privacy consequences. In the context of an agent skill explicitly designed to interact with real third-party sites, normalizing these operations as standard actions increases the chance of unauthorized social actions, harassment, deletion of user content, or covert messaging if another part of the system invokes them too freely.
The file describes transactional and account-impacting operations across commerce, travel, food delivery, finance, email, and storage domains with minimal cautionary framing, even where placeholders mention future support. Because this skill targets real websites and user accounts, documenting such operations without explicit warnings and policy constraints can encourage unsafe implementation or invocation of purchases, bookings, transfers, message sending, uploads, and deletions that have financial, operational, or privacy consequences.
No suspicious patterns detected.