Security audit

Foxtable 移动开发文档

Security checks across malware telemetry and agentic risk

Overview

This is a documentation-only Foxtable skill, but its examples repeatedly show unsafe web server, credential, file-handling, and data-exposure patterns that users should review before copying.

Install only if you need Foxtable reference documentation and will treat the snippets as legacy examples, not production-ready templates. Before using any code, replace hardcoded secrets, avoid password cookies, require HTTPS and authentication, bind services narrowly, validate uploads and paths, sanitize browser output, and review any data-service or third-party API examples for privacy and access-control requirements.

SkillSpector

By NVIDIA

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 (35)

Intent-Code Divergence

Medium

Confidence: 92% confidence
Finding: The 'more secure' login example still relies on client-stored authentication tokens in cookies and does not consistently clear them, including an apparent case mismatch between 'userid' and 'UserID'. This can leave stale authentication state, enable session confusion, and weakens the claimed security model because the server still trusts bearer-style client tokens without robust session protections.

Intent-Code Divergence

High

Confidence: 98% confidence
Finding: The example deletes server files based on client-submitted filenames from the hidden '*_deleted' field, then transforms that value into a filesystem path with minimal validation. An attacker can tamper with the submitted value to target unintended files, leading to arbitrary file deletion or path traversal within the server's accessible paths.

Intent-Code Divergence

Medium

Confidence: 92% confidence
Finding: The documentation explicitly suggests that authenticity verification is unnecessary in secure mode and then shows POST handling that accepts any successfully decryptable message. Even with encryption, omitting signature/timestamp/nonce validation weakens origin verification and increases risk from replayed or improperly routed messages if keys are exposed or transport assumptions fail.

Intent-Code Divergence

High

Confidence: 98% confidence
Finding: The token broker example claims to protect access to callback credentials, but the shown endpoint reads posted username/password values and returns the access token without actually validating them. An attacker who can reach this endpoint could retrieve the token and then invoke privileged WeChat APIs as the application.

Context-Inappropriate Capability

Medium

Confidence: 95% confidence
Finding: The documentation mixes a web-reporting workflow with concrete FTP remote-image configuration, including host, username, and password. Even if presented as an example, embedded live-looking credentials can be copied, reused, or normalized into production practice, increasing the chance of credential leakage and insecure remote file handling.

Missing User Warnings

Medium

Confidence: 96% confidence
Finding: The document explicitly recommends binding the HTTP server to all interfaces using patterns like `http://*/` and discusses exposing the service via LAN and public IPs without meaningful warnings about authentication, firewall scope, or attack-surface expansion. This increases the likelihood that users will unintentionally publish a locally intended service to untrusted networks.

Missing User Warnings

Medium

Confidence: 90% confidence
Finding: The tutorial states that Foxtable must be run as administrator to start the HTTP service, but does not warn that running the full application elevated magnifies the impact of any bug or malicious input handled by the service. If the server code is later exposed or abused, compromise would occur with higher privileges than necessary.

Missing User Warnings

Medium

Confidence: 94% confidence
Finding: The upload example saves user-supplied files directly to a server path with no warnings or controls for file type validation, content inspection, path safety, storage isolation, or execution risk. This teaches unsafe handling of untrusted files and can lead to malware storage, disk abuse, or later execution/serving of dangerous content.

Missing User Warnings

High

Confidence: 99% confidence
Finding: The authentication example stores plaintext usernames and passwords in client cookies and then reuses them for authentication. Cookies are client-controlled and can be stolen, replayed, or read by local users/software; storing raw credentials in them creates direct credential disclosure and session compromise risk.

Missing User Warnings

Medium

Confidence: 94% confidence
Finding: The documentation instructs users to start an HTTP service bound to 'http://*/', exposing it on all interfaces without any security guidance. In practice this can unintentionally publish development pages or administrative functionality to untrusted networks, increasing attack surface and enabling unauthorized access.

Missing User Warnings

Medium

Confidence: 90% confidence
Finding: The file upload examples save user-supplied files directly to server paths and do not discuss validation, storage isolation, naming controls, or content restrictions. This can lead to overwriting files, storing malicious content, or later code execution if uploaded files are served or processed unsafely.

Missing User Warnings

High

Confidence: 99% confidence
Finding: This example encourages deleting backend files based on values returned from the client without a strong warning, normalization, or authorization check. Because hidden fields are attacker-controlled, the pattern makes arbitrary file deletion much more likely when copied into real applications.

Missing User Warnings

High

Confidence: 99% confidence
Finding: The login example writes usernames and passwords directly into cookies and only later discusses that this is unsafe. Developers copying the earlier example may deploy credential storage in client-side cookies, exposing credentials to theft, replay, or disclosure via browser access and insecure transport.

Missing User Warnings

Medium

Confidence: 95% confidence
Finding: The example transmits username and password directly in cookies over HTTP without any warning about transport security or secure cookie handling. This exposes credentials to interception, replay, logging, and theft by any party able to observe the traffic, and the example may normalize insecure authentication patterns for users copying the code.

Missing User Warnings

Medium

Confidence: 93% confidence
Finding: The upload example places username and password in form fields and sends them to the server, again without warning about credential exposure. In the surrounding documentation, examples frequently use plain HTTP endpoints, which makes this pattern more dangerous because developers may reuse it verbatim and leak credentials through network capture, logs, proxies, or application traces.

Missing User Warnings

Medium

Confidence: 93% confidence
Finding: The documentation embeds realistic personal and logistics data, including names, phone numbers, account numbers, tracking numbers, and message identifiers, without any privacy warning or indication that the values are sanitized. Even in an educational context, publishing such examples can normalize unsafe handling of personal data and may expose real individuals or identifiers if the samples were sourced from production data.

Missing User Warnings

High

Confidence: 99% confidence
Finding: The document embeds real-looking AppId/AppSecret values directly in example code, and similar hard-coded credentials recur throughout the file. Readers may copy these patterns into production or accidentally disclose working secrets through source control, logs, or redistributed documentation.

Missing User Warnings

Medium

Confidence: 87% confidence
Finding: The web authorization examples store OpenID values directly in browser cookies without discussing integrity, confidentiality, expiration, or secure cookie attributes. If cookies are tampered with, exposed, or replayed, the application may make authorization decisions on attacker-controlled identity data or leak user identifiers.

Missing User Warnings

Medium

Confidence: 86% confidence
Finding: The documentation recommends writing user geolocation data and timestamps to local text files without privacy, retention, or access-control guidance. This can create sensitive location logs that are easy to overcollect, improperly expose, or retain indefinitely.

Missing User Warnings

Medium

Confidence: 98% confidence
Finding: The documentation embeds a live AppCode credential directly in sample code and instructs users to send shipment-tracking queries to a third-party API without any warning about credential handling or data disclosure. Even if the token is only an example, publishing real-looking authorization material encourages insecure copy-paste use and can expose shipment numbers and related logistics data to an external service.

Missing User Warnings

Medium

Confidence: 99% confidence
Finding: The examples make live external requests over plain HTTP rather than HTTPS, exposing authorization headers and shipment-query contents to interception or modification in transit. Because the requests include an APPCODE bearer-style credential, a network attacker could steal the credential, tamper with responses, or observe sensitive logistics lookups.

Missing User Warnings

High

Confidence: 99% confidence
Finding: The markdown exposes explicit FTP connection details, including server address, account name, and password, with no warning that they are placeholders. Publishing credentials in documentation is a direct secret exposure risk and may enable unauthorized access if the values are real or reused elsewhere.

Missing User Warnings

Medium

Confidence: 82% confidence
Finding: The document provides instructions to start an HTTP server bound to all interfaces (for example, http://*/ and a non-localhost IP example) and later discusses uploads, but it does not warn users about network exposure, unauthenticated access, unsafe file handling, or the risks of serving static content from local disk. In documentation, this omission can lead users to deploy an internet- or LAN-exposed service with insecure defaults, increasing the chance of unauthorized access or malicious uploads.

Missing User Warnings

Medium

Confidence: 94% confidence
Finding: The documentation shows how to expose a local data source over HTTP and publish it through a request handler, but does not warn about authentication, authorization, TLS, input validation, or data exposure risks. Readers may deploy a database-backed endpoint directly to the network, enabling unauthorized access, data leakage, or abuse of backend operations.

Missing User Warnings

High

Confidence: 98% confidence
Finding: The document explicitly states that if authentication is not needed, the service can be reduced to a one-line call that exposes the data source. Publishing a database-like service without authentication creates a direct path for anonymous access to read or modify data, especially because the surrounding text emphasizes that clients can use it much like a normal data source.

VirusTotal

64/64 vendors flagged this skill as clean.

View on VirusTotal

Static analysis

No suspicious patterns detected.