T03 · Remote Payload Retrieval and Execution
- Location
references/shared-local-sandbox.md:36- Finding
Mutable and Unsigned Sandbox Package Is Recommended for Local Execution
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This is a coherent Huifu payment-integration guide, but its local sandbox path tells users to run an unsigned mutable preview download, which needs review before use.
Install this only for Huifu payment-integration work. Do not run the preview local sandbox package unless you can verify the exact archive through a trusted source, and keep production secrets out of the sandbox. Treat exported sandbox credentials as secrets and keep them out of source control, logs, screenshots, and chat transcripts.
references/shared-local-sandbox.md:36Mutable and Unsigned Sandbox Package Is Recommended for Local Execution
references/aggregation-php-adapter.md:64PHP Payment SDK Archive Is Downloaded Without Authenticity or Integrity Verification
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
`--print-json` 会输出 `control_url`、`gateway_url`、`health_url`、`mode`、`credential_profile`、`signature_model`、`admin_token` 和 `csrf_token`。这些 token 只用于本机控制面,不要写入仓库、聊天记录或可分享报告。公开健康检查和页面状态接口不返回 `admin_token`、`csrf_token` 或 Webhook 端点密钥。
启动后可以直接在浏览器打开 `control_url`。首次进入控制台会展示本地沙箱服务使用声明;默认勾选“不再提示”,同意后继续使用,拒绝后停止本地沙箱服务并尝试关闭当前页面。本地控制台会自动刷新运行状态,展示接入信息、可复制的 `gateway_url`、支付/退款/关单/对账记录、事件流、Notify/Webhook 投递记录和安全发现。页面“项目接入配置”提供“导出凭证”、“复制配置”、“显示 Webhook Key”、“保存 Webhook”和“使用说明”;导出凭证和显示 Webhook Key 都需要输入启动输出中的 `admin_token`,浏览器会下载 `sandbox-credentials.json` 或在页面显示本次运行的 `webhook_endpoint_key`。托管支付记录可点击“模拟成功”,用于把本地预下单状态推进为支付成功并触发后续查单、Notify 或 Webhook 演练;手动 Notify/Webhook 只做投递测试,不直接改业务主记录。Webhook 目标可在页面输入本机接收地址并保存,本次运行内业务状态里的 Webhook 成功/失败按钮会变为可用;外部 Webhook 地址仍需启动时通过 `--notify-allow` 精确放行。生成报告或停止服务同样需要 `admin_token`;页面不会持久化保存 token,页面状态接口不返回 `admin_token`、`csrf_token`、完整私钥、Webhook 端点密钥或回调 URL query 明文。
控制台“接入信息”区域会从公开索引 `hf-payment-local-sandbox-latest.json` 检查更新。检查更新不需要 `admin_token`,不上传私钥、公钥、`sys_id`、`product_id`、`huifu_id`、请求日志、报告、Webhook 地址或 Notify 地址;只读取公开 JSON,并在有新版时展示当前平台下载地址、文件名、大小和 SHA256。沙箱不做静默自动安装,用户下载新版后手动解压并重新启动。
The documentation instructs users to export a sandbox-credentials.json containing a merchant signing private key and webhook secret in a flat config file intended for project integration. Even though these are sandbox credentials, packaging private key material into an easily copied file increases the chance of accidental leakage into source control, logs, screenshots, or reuse in non-sandbox environments.
控制台“接入信息”区域会从公开索引 `hf-payment-local-sandbox-latest.json` 检查更新。检查更新不需要 `admin_token`,不上传私钥、公钥、`sys_id`、`product_id`、`huifu_id`、请求日志、报告、Webhook 地址或 Notify 地址;只读取公开 JSON,并在有新版时展示当前平台下载地址、文件名、大小和 SHA256。沙箱不做静默自动安装,用户下载新版后手动解压并重新启动。
3. 查看或导出 `official-demo` Profile。普通用户优先通过页面“导出凭证”下载 `sandbox-credentials.json`;命令行导出只作为维护者排障能力。无论哪种方式,都不要在文档、日志和报告里回显完整私钥。
`official-demo` 用户可见字段固定为 `product_id`、`sys_id`、商户请求签名私钥、沙箱响应验签公钥和 Webhook 终端密钥。预览包不内置完整私钥;首次使用时会在本机生成或读取 `sandbox-data/credentials/official-demo-merchant-private.pem` 和 `sandbox-data/credentials/official-demo-sandbox-private.pem` 两套 RSA 私钥。本地沙箱模式下,请求签名使用导出的商户私钥;沙箱用本机保存的商户请求验签公钥验请求签名;响应和通知由本机沙箱私钥加签;客户项目优先用导出的 `merchant_public_key` 验响应和通知签名。页面导出的 `sandbox-credentials.json` 只面向商户项目配置,和“复制配置”保持同一套扁平英文 key:`gateway_url`、`sys_id`、`product_id`、`huifu_id`、`skill_source`、`merchant_private_key`、`merchant_public_key`、`webhook_endpoint_key`、`signature_model`、`usage`,不再包含重复的 `merchant_config`、`sandbox_config` 或说明型嵌套层。官方 SDK 优先字段为无 PEM 头尾、无换行的 PKCS8 Base64 `merchant_private_key` 和 X509 Base64 `merchant_public_key`;Webhook 验签使用 `webhook_endpoint_key` 计算大写 `MD5(raw_body + webhook_endpoint_key)`,业务代码可用大小写不敏感比较兼容历史实现;本地配置直接给出样例 `huifu_id = 6666000100000001`。本地沙箱模式下 `skill_source` 固定使用 `hfps/1.3.1;sandbox/1.0.1`;官方联调或生产环境使用 `hfps/1.3.5`,不要携带 `;sandbox/...` 后缀。报告中必须保留 `signature_model = dual_key_local_sandbox`。
The guidance normalizes injecting merchant_private_key and webhook_endpoint_key directly into application configuration for local mode. This can lead developers to hardcode secrets in code or config, blur separation between sandbox and production practices, and accidentally ship secret-bearing local-sandbox branches or copied configs into shared environments.
3. 查看或导出 `official-demo` Profile。普通用户优先通过页面“导出凭证”下载 `sandbox-credentials.json`;命令行导出只作为维护者排障能力。无论哪种方式,都不要在文档、日志和报告里回显完整私钥。
`official-demo` 用户可见字段固定为 `product_id`、`sys_id`、商户请求签名私钥、沙箱响应验签公钥和 Webhook 终端密钥。预览包不内置完整私钥;首次使用时会在本机生成或读取 `sandbox-data/credentials/official-demo-merchant-private.pem` 和 `sandbox-data/credentials/official-demo-sandbox-private.pem` 两套 RSA 私钥。本地沙箱模式下,请求签名使用导出的商户私钥;沙箱用本机保存的商户请求验签公钥验请求签名;响应和通知由本机沙箱私钥加签;客户项目优先用导出的 `merchant_public_key` 验响应和通知签名。页面导出的 `sandbox-credentials.json` 只面向商户项目配置,和“复制配置”保持同一套扁平英文 key:`gateway_url`、`sys_id`、`product_id`、`huifu_id`、`skill_source`、`merchant_private_key`、`merchant_public_key`、`webhook_endpoint_key`、`signature_model`、`usage`,不再包含重复的 `merchant_config`、`sandbox_config` 或说明型嵌套层。官方 SDK 优先字段为无 PEM 头尾、无换行的 PKCS8 Base64 `merchant_private_key` 和 X509 Base64 `merchant_public_key`;Webhook 验签使用 `webhook_endpoint_key` 计算大写 `MD5(raw_body + webhook_endpoint_key)`,业务代码可用大小写不敏感比较兼容历史实现;本地配置直接给出样例 `huifu_id = 6666000100000001`。本地沙箱模式下 `skill_source` 固定使用 `hfps/1.3.1;sandbox/1.0.1`;官方联调或生产环境使用 `hfps/1.3.5`,不要携带 `;sandbox/...` 后缀。报告中必须保留 `signature_model = dual_key_local_sandbox`。
4. 已有项目使用本地沙箱时,不是另写一套“SDK 接入指南”,而是在项目现有支付出口层增加仅本地启用的 `local-sandbox` 运行模式。先尝试把官方 SDK 的网关基础地址、base URL、endpoint 或 HTTP client 配置为 `gateway_url`;如果 SDK 没有暴露这类配置项,则保留生产路径继续走官方 SDK,只在项目自己的支付网关封装层增加本地分支:复用原有订单组装、字段校验、幂等键和请求对象,发送阶段按汇付 envelope POST 到 `gateway_url + 接口路径`,响应再转换回项目原有业务服务接口。不要改官方 SDK 源码,不要用 hosts 劫持官方域名到本机,也不要让本地分支在生产环境默认启用。
The entire skill manifest and operating instructions are written to require behavior in Chinese, and there is no statement offering users a language choice or documenting a justified locale restriction. Under the policy, forcing a specific language without user opt-in is a natural-language policy violation.
The manifest enables implicit invocation for a payment-integration skill without any trigger constraints or scope limits. Because this skill can influence payment architecture, notifications, signing, and go-live guidance, it may be invoked in broader contexts than intended, causing unreviewed steering of sensitive workflows or accidental use when the user did not explicitly request it.
This markdown file is natural-language documentation, and all headings and instructions are presented only in Chinese. Under the policy rule, forcing a specific language without user opt-in or a documented justification is a natural-language policy violation.
The manifest explicitly says this skill is not for enterprise/personal merchant onboarding and that such tasks belong to huifu-merchant-onboarding. However, this FAQ directs users to a merchant onboarding-related interface, '微信支付宝入驻信息修改', which is outside the declared payment-integration scope.
The manifest excludes merchant onboarding tasks, including application/status-related merchant setup flows, yet this file instructs use of '微信实名认证' to resolve transaction issues. Real-name authentication is part of merchant onboarding/compliance setup rather than the declared payment transaction integration scope.
The manifest says merchant onboarding and related merchant configuration tasks are handled by a separate skill, but this FAQ points users to '微信商户配置' for resolving appid binding issues. That broadens the skill's apparent scope from transaction integration into merchant account configuration.
This line again recommends '微信支付宝入驻信息修改', which is an onboarding/merchant-information management capability. That conflicts with the manifest's explicit statement that merchant onboarding-related tasks are not part of this skill.
The file advises calling '支付宝实名申请提交', which is an onboarding/compliance application capability. This conflicts with the manifest's stated boundary that merchant onboarding tasks are handled by another skill, not this payment integration skill.
This markdown file describes obtaining and processing sensitive identifiers such as buyer_id/Alipay user_id, and later includes personal fields like name, mobile number, and certificate number. Under SQP-2 for markdown files, descriptions that affect user data or privacy should include warnings or handling cautions, but the file provides implementation notes only and no user-facing privacy warning.
This section documents highly sensitive identity fields such as name, mobile, cert_type, and cert_no, and only notes encryption for cert_no without warning against insecure logging, storage, or transmission of the broader identity payload. In a payment integration skill, implementers may copy these fields directly into systems and logs, so omission of handling guidance increases the chance of PII exposure and compliance failures.
This markdown file describes handling of auth_code as a user payment code, and elsewhere documents user identifiers such as openid and sub_openid, but it does not include any warning about the privacy or sensitive nature of these values. For markdown files, SQP-2 applies when descriptions omit warnings about behaviors affecting user data or privacy, and these fields are clearly sensitive payment/user data.
This markdown file describes request fields including device IP, MAC, IMEI, IMSI, ICCID, GPS, precise location, and other device identifiers, but does not include any warning that these values are sensitive or may affect user privacy. Under the markdown-specific SQP-2 criteria, documentation should warn when the skill behavior could affect user data or privacy.
The file forces a single language for all instructions and examples, and there is no indication that users can opt into another language or that the skill is restricted to a Chinese-speaking or region-specific audience. This can violate a language/locale policy when skills should not impose a language without user choice or clear justification.
The title and throughout the document present the skill guidance exclusively in Chinese, and L109 further prescribes a fixed behavior pattern without offering any language choice. Under the policy criteria, forcing a specific language or locale without user opt-in is a natural-language policy violation unless clearly justified as region-specific, which is not stated here.
This markdown file is written entirely in Chinese and presents the skill guidance in that language with no indication that users may choose another language or locale. Under the policy, forcing a specific language without user opt-in is a natural-language policy violation.
This markdown file documents operational flows for closing orders, issuing refunds, and querying billing data, all of which can affect user funds or expose sensitive financial records. While the scenarios describe what the APIs do, they do not include a clear caution that these actions should be used only with validated business authorization and may have irreversible or sensitive consequences.
The entire skill documentation is written in Chinese and provides no indication that other languages are supported or that the language choice is optional. Under the policy, forcing a specific language without user opt-in is a natural-language policy violation unless the locale constraint is documented and justified.
This markdown file contains all operational instructions in Chinese and does not indicate that the skill is region-specific or that users may choose another language. That can violate a language/locale policy when users are not explicitly opted into Chinese-only guidance.
This markdown file contains all user-facing prompts and instructions in Chinese, and nowhere indicates that users may choose another language or that the skill is intentionally limited to a Chinese-speaking audience. Under the policy rule, forcing a specific language without opt-in is a natural-language policy violation.
The instruction "最终回答最短结论必须包含" and the entire document content prescribe a fixed Chinese response format, but do not indicate that language selection is optional or region-specific. Under the policy, forcing a specific language without user opt-in is a natural-language locale violation.
This markdown file contains all user-facing instructions in Chinese, and there is no indication that the skill is region-specific or that users can opt into another language. Under the language/locale policy, forcing a specific language without user choice can be a natural-language policy violation.
This markdown file presents all onboarding instructions exclusively in Chinese, which effectively forces a specific language/locale for users of the skill. The policy allows locale constraints only when documented and justified or when users are offered a choice, neither of which appears here.
No suspicious patterns detected.