Security audit

狐表(Foxtable) 移动端开发

Security checks for vulnerabilities and agentic risk

Overview

This is a documentation-only Foxtable mobile development skill, but several examples could lead users to deploy exposed, weakly protected web services or mishandle credentials and sensitive data.

Review before installing if your agent may generate production code from these docs. Treat the skill as legacy reference material, not secure-by-default guidance: prefer localhost binding, non-admin execution where possible, HTTPS, authentication and authorization, parameterized queries, safe upload storage, server-side sessions, secret placeholders or secret managers, and explicit privacy/retention controls for WeChat data, location data, reports, and files.

SkillSpector

Vulnerability Patterns

Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access

Findings (28)

Context-Inappropriate Capability

Medium

Confidence: 88% confidence
Finding: The document explicitly instructs users to run Foxtable as administrator in order to host HTTP services. Running a network-facing service with elevated privileges increases the blast radius of any bug, misconfiguration, or malicious request, potentially turning a minor flaw into full system compromise.

Context-Inappropriate Capability

High

Confidence: 96% confidence
Finding: The examples recommend listening on all interfaces (http://*/) and discuss exposing the service to LAN and public IPs. This materially increases exposure to untrusted networks, and in this document the service examples lack authentication, transport security, and robust input/file handling, making accidental deployment dangerous.

Context-Inappropriate Capability

Medium

Confidence: 93% confidence
Finding: The file includes upload handling that saves user-supplied files directly to server disk using client-provided names. Without size limits, content validation, path sanitization guarantees, malware scanning, and safe storage conventions, this can enable disk exhaustion, malicious content hosting, or overwrite/abuse scenarios.

Context-Inappropriate Capability

High

Confidence: 99% confidence
Finding: The authentication example stores usernames and passwords directly in cookies and uses them for subsequent verification. This is insecure because cookies can be stolen, replayed, or exposed by other weaknesses, and storing raw credentials client-side violates basic authentication hygiene.

Context-Inappropriate Capability

Medium

Confidence: 96% confidence
Finding: The documentation includes a login example that stores usernames and passwords directly in client-side cookies. Cookies are retrievable by the client and may be exposed via theft, insecure transport, browser compromise, or misconfiguration, making this an unsafe authentication pattern even in sample code.

Context-Inappropriate Capability

Medium

Confidence: 85% confidence
Finding: The uploader example documents server-side deletion of files based on client-submitted deletion metadata and path manipulation. If implemented as shown, an attacker may tamper with submitted filenames or hidden fields to trigger unauthorized deletion of arbitrary files within reachable paths.

Intent-Code Divergence

Medium

Confidence: 94% confidence
Finding: The section claims to improve login security but still demonstrates a weak design: hard-coded encryption keys, client-stored identity material, and ad hoc session tracking. This can mislead developers into deploying a fragile authentication scheme that is easier to predict, steal, or bypass than standard session management.

Intent-Code Divergence

Critical

Confidence: 99% confidence
Finding: The token service example claims to validate username and password, but the code immediately returns an access token without performing any authentication or authorization. This creates an unauthenticated token oracle that can expose the WeChat access token to anyone who can reach the endpoint, enabling full API abuse under the account's privileges.

Context-Inappropriate Capability

Medium

Confidence: 97% confidence
Finding: The documentation includes explicit FTP server details and plaintext credentials embedded directly in sample code. Even if intended as an example, publishing reusable credential patterns normalizes insecure secret handling and may expose real infrastructure if the values are not fictitious; it also encourages unencrypted FTP for remote image retrieval.

Missing User Warnings

Medium

Confidence: 94% confidence
Finding: The markdown tells users to expose the HTTP service on all IPs or public networks without pairing that advice with strong warnings or safeguards. In context, the surrounding examples are intentionally minimal and would be unsafe if copied into a real deployment exposed beyond localhost.

Missing User Warnings

Medium

Confidence: 90% confidence
Finding: The document instructs users to open inbound firewall rules for the HTTP service, which directly increases reachability from other hosts. Without concurrent guidance on narrowing source ranges, required ports only, and service hardening, this can expose an insecure example service to unintended attackers.

Missing User Warnings

Medium

Confidence: 91% confidence
Finding: The example persists uploaded files to disk without explicit disclosure or security guardrails. Users may unknowingly create a server-side file repository that stores untrusted content, increasing privacy, compliance, and malware-handling risks.

Missing User Warnings

Medium

Confidence: 91% confidence
Finding: The employee creation example saves uploaded photo files to disk and records filenames, again without prominent warning or security controls. This can lead to untrusted file persistence, sensitive image collection, and file-handling abuse if copied into production unchanged.

Missing User Warnings

High

Confidence: 97% confidence
Finding: The examples include plaintext AppId/AppSecret and similar credential material without strong warnings against real-use reuse or secret exposure. Readers may copy these patterns into production, leading to credential leakage, account compromise, or unauthorized API access.

Missing User Warnings

Medium

Confidence: 90% confidence
Finding: The documentation stores user identifiers and message content persistently without discussing minimization, retention, consent, or access controls. This can lead to privacy violations, unnecessary data accumulation, and exposure of sensitive communications if the backing store is compromised.

Missing User Warnings

High

Confidence: 96% confidence
Finding: The examples log precise user location data to local files without prominent warnings about sensitivity, retention, or access protection. Location history is highly sensitive and can enable tracking, profiling, or physical-safety harms if leaked or misused.

Missing User Warnings

Medium

Confidence: 88% confidence
Finding: The web auth examples cache identity information in cookies but do not discuss secure cookie flags, integrity protection, expiration, or session management. This can lead to session theft, impersonation, or misuse if cookies are exposed over insecure transport or accessible to client-side scripts.

Missing User Warnings

High

Confidence: 98% confidence
Finding: The middle-control token endpoint is shown over plaintext HTTP and returns a privileged access token, with no prominent transport-security warning. Even if authentication were later added, plaintext transport would allow interception or replay of credentials and tokens by network attackers.

Missing User Warnings

High

Confidence: 99% confidence
Finding: The documentation includes a live-looking hard-coded AppCode credential directly in sample code and instructs users to place it in the Authorization header. Even if intended as a demo value, embedding secrets in documentation encourages credential reuse, leaks paid API access, and normalizes insecure secret handling practices that can lead to unauthorized use and billing abuse.

Missing User Warnings

Medium

Confidence: 91% confidence
Finding: The example sends shipment tracking numbers to a third-party logistics API over plain HTTP and without any privacy notice or data-handling warning. Tracking numbers can be sensitive operational or personal data, so transmitting them externally without disclosure or transport security can expose user information and shipment metadata to interception or unauthorized third parties.

Missing User Warnings

Medium

Confidence: 99% confidence
Finding: The snippet shows plaintext FTP credentials in documentation without any warning about secret exposure, credential reuse, or transport insecurity. This is dangerous because readers may copy the pattern directly into production code, leading to credential leakage, unauthorized file access, and interception over insecure FTP.

Missing User Warnings

Medium

Confidence: 88% confidence
Finding: The documentation presents HTTP endpoints that generate and return backend-derived reports to clients but omits any discussion of authentication, authorization, request validation, or rate limiting. In practice, this can lead to unauthorized exposure of internal business data and abuse of report-generation endpoints for resource exhaustion.

Missing User Warnings

Medium

Confidence: 95% confidence
Finding: This section describes exposing backend-driven report-to-HTML/PDF conversion over web routes and includes an example that concatenates a query parameter directly into a SQL-like statement. That creates both data-disclosure risk from public report endpoints and likely injection risk if user-supplied values are not parameterized and access-controlled.

Missing User Warnings

Medium

Confidence: 92% confidence
Finding: The documentation shows starting an HTTP server bound to "http://*/" and even demonstrates access via a LAN IP, which exposes the service on all interfaces without warning about network reachability, firewalling, or authentication. In a mobile-development skill, this is risky because users may copy the example directly and unintentionally publish local files or endpoints to their network.

Missing User Warnings

Medium

Confidence: 88% confidence
Finding: The file-upload guidance advertises SaveFile and uploaded file handling but does not warn that uploaded content is untrusted and may be malicious, oversized, or dangerous if stored in web-accessible locations. Given the surrounding HTTP server context, readers could implement upload handling that enables malware hosting, disk exhaustion, or unsafe processing of attacker-controlled files.

Static analysis

No suspicious patterns detected.