asiasea-bi
SuspiciousAudited by ClawScan on May 10, 2026.
Overview
This BI skill is purpose-aligned overall, but its code handles enterprise tokens and appears to persist and obfuscate API headers into generated reports that can be uploaded or published.
Review this skill carefully before installing. It may be legitimate for an internal BI gateway, but it should not be used unless the publisher proves that tokens are user-scoped, not written into HTML reports, not persisted in plain files, and not exposed through published snapshot URLs.
Findings (5)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
A user or agent could obtain or reuse broad enterprise API authority beyond what they expected from the registry metadata.
The skill fetches a system token based on system_id and stores system auth headers, while the registry declares no primary credential or required environment variables. The artifacts do not show clear user-scoped authorization boundaries.
def api_get_system_token(system_id: int) -> dict:
resp = requests.get(f"https://o.yayuit.cn/dw/api/auth/system-token?system_id={system_id}", timeout=5).json()
...
"system_auth_headers": {}Declare the credential model and scopes, require user-scoped Feishu/OAuth authorization, avoid system-wide tokens where possible, and enforce server-side permission checks for every query and publish action.
Sensitive session data or tokens may remain on disk and be reused, read, or modified across later runs.
Per-user session files are written in the skill directory and can contain phone identifiers, API registry metadata, and authentication headers. The provided artifacts do not show encryption, TTL, file-permission hardening, or cleanup.
return os.path.join(BASE_DIR, f".session_{safe_user_id}.json")
...
"user_phone": None,
"system_auth_headers": {},
"api_registry": [],
...
json.dump(data, f, ensure_ascii=False, indent=2)Do not persist auth headers in plain JSON. Use the platform secret/session store, short-lived tokens, strict file permissions, per-user isolation, and explicit cleanup.
If a generated report is uploaded or shared, embedded API headers could be decoded and used to access business systems, spreading one report mistake into a wider credential and data exposure.
The report generator prepares a Base64-encoded payload containing API URL and headers, explicitly mentioning tokens, and the skill includes upload/publish functions for generated HTML. Base64 is obfuscation, not credential isolation.
# 混淆 API 配置，防止非技术人员直接读取明文 Token
config_payload = json.dumps({"url": api_url, "headers": headers_dict, "metric": metric_key})
config_b64 = base64.b64encode(config_payload.encode('utf-8')).decode('utf-8')
...
def api_upload_html_to_oss(html_content: str) -> str:
...
def api_publish_report(url: str, title: str) -> tuple:Never place API headers or tokens in static HTML. Render reports server-side or use a backend proxy with short-lived, scoped, non-reusable signed URLs.
Users may trust the generated reports as safe to publish even though the implementation suggests credentials may be embedded or persisted.
The documentation makes an absolute credential-isolation and safety claim, but the code shown above prepares Base64-obfuscated API headers for the HTML report and stores auth headers in session files.
系统生成的纯静态 DOM 快照严格落实凭证隔离，确保核心物理数据的绝对安全。
Remove absolute safety claims, document the real data and credential handling behavior, and prove that generated reports contain no secrets before publishing.
It may be harder to know exactly which package version is being reviewed or installed.
The registry metadata lists version 1.0.3, while the packaged skill.json says 1.0.4. This mismatch is a provenance/version consistency issue, though not direct evidence of malicious behavior.
"version": "1.0.4"
Align registry and package versions and provide a clear source URL or release provenance.