File uploading attack interception method based on semantic entropy enhancement

Abstract

The invention provides a file uploading attack interception method based on semantic entropy enhancement, and aims at overcoming the defects of an existing file uploading security protection technology in the face of complex attacks. The method specifically comprises the steps that S1, file format analysis and content extraction are conducted, hidden scripts are mined through nested content recognition, and intermediate representation is generated through grammar cleaning and coding specifications; s2, constructing an abstract syntax tree and semantic entropy calculation, tracking a pollution chain, analyzing a high-risk function, identifying a high-entropy character string, modeling and controlling flow complexity, and generating a semantic entropy vector; s3, dynamic scoring and decision making are carried out, and accurate judgment is carried out in combination with white list perception, feature comparison, multi-modal model scoring, adaptive threshold and sandbox observation; and S4, carrying out real-time interception and feature synchronization, blocking malicious file landing, generating an attack log and synchronizing an attack fingerprint. The method takes the semantic entropy vector as a core, breaks through the limitation of static features, remarkably improves the recognition rate of complex attacks, reduces missed judgment, and guarantees the safety of Web applications.

Description

Technical Field

[0001] This invention relates to the field of network security technology, and in particular to a method for intercepting file upload attacks based on semantic entropy enhancement. Background Technology

[0002] File upload, as a core data interaction method in modern web applications, is widely used in scenarios such as content management, user registration, and online office work. However, it is also a high-risk entry point for attackers to carry out malicious activities such as code injection, remote command execution, and WebShell implantation. To prevent such attacks, most current mainstream protection solutions rely on static rules such as file extension whitelists, MIME type verification, magic number detection, blacklist keyword filtering, and static feature matching.

[0003] However, with the evolution of attack techniques, traditional static detection is struggling to cope with complex attack methods. For example, attackers use semantic mutation techniques such as file content encryption, encoding obfuscation, dynamic string concatenation, malicious instruction fragmentation, and script nesting to change the surface form of malicious code while keeping the underlying attack logic unchanged, easily bypassing fixed rule detection and leading to frequent false positives and false negatives. Furthermore, attackers often use conditionally triggered code, such as timed execution or user-specific behavior triggers, to hide their attack intent, further increasing the difficulty of detection. Although existing technologies have introduced enhancement strategies such as regular expressions and basic syntax analysis, they still cannot systematically capture the semantic features of attack code, especially when facing encrypted, obfuscated, and nested file upload attacks, resulting in severely inadequate protection capabilities. Summary of the Invention

[0004] To address the aforementioned technical problems, this invention proposes a file upload security detection method based on semantic entropy enhancement analysis, the specific steps of which are as follows:

[0005] S1. File format parsing and content extraction; specifically including the following sub-steps: S11: File type identification and detection; After the uploaded file enters the detection system, the file type is determined through MIME type detection, extension analysis, and magic number characteristics to identify whether it is a potentially executable script file. If it is a potentially executable script, it proceeds to the next step of processing.

[0006] S12: Identification and processing of nested content; The program parses hidden scripts within nested compressed files or rich text documents, loads specialized tools to read the internal file list and content. If the file is a nestable vector file, it extracts the content recursively, calculating the MD5 hash value to avoid circular nesting; if the file is not a nestable vector file, it extracts the content to a temporary directory and re-identifies the file type. S13: Syntax cleaning and optimization; Perform syntax cleaning on potential executable script files, removing comments, whitespace characters, and indentation, while retaining functional content; S14: Encoding standard processing; Identify the original file encoding (through BOM header and character distribution), remove redundant BOM headers, and uniformly convert them to UTF-8 encoding; S15: Construct intermediate representation; The cleaned code is converted into an intermediate representation (IR), and core logical elements such as variable definitions, function calls, and control statements are extracted, converted into a unified JSON format, stripped of syntactic differences, and the logical semantics are preserved.

[0007] S2. Abstract syntax tree construction and semantic entropy calculation; specifically including the following sub-steps: S21: Construct an abstract syntax tree; Generate an abstract syntax tree (AST) based on the intermediate representation to restore the code structure and capture logical elements such as variable declarations, function calls, and control statements; S22: Contamination chain tracing; Analyze whether user input variables flow into dangerous functions and construct a contamination propagation path. Define a list of contamination sources and high-risk functions, record the contamination status of variables, and generate a visual path diagram; S23: High-risk function analysis; Recursively traverse the function call nodes in the AST, extract the function name, parameters and call location, count the number and density of dangerous function calls, and analyze the context safety in combination with the pollution status. S24: High-entropy string recognition; Extract static strings and concatenation chains from the code, calculate Shannon entropy and compression ratio, mark suspicious nodes and calculate average string entropy; S25: Control flow complexity modeling; The code logic complexity is calculated using cyclomatic complexity algorithms and AST traversal, and the result is corrected by combining the nesting depth. S26: Semantic entropy vector generation; Six key indicators were extracted from the pollution propagation length, number of high-risk function calls, number of suspicious nodes, average string entropy value, logical complexity, and nesting depth, and then standardized to generate a 6-dimensional semantic entropy vector.

[0008] S3. Dynamic scoring and decision-making; specifically including the following sub-steps: S31: Business whitelist awareness mechanism; Set semantic whitelist rules for business scripts. If a high-risk function call meets the following conditions: the parameters are not contaminated, the context is the specified business function, and the number of calls is ≤5, then it is marked as a whitelist sample and allowed to pass. S32: Feature similarity comparison; Calculate the cosine similarity between the semantic entropy vector of the current sample and the typical attack features in the attack sample library, and take the highest value as the feature similarity score; S33: Maliciousness Confidence Score; The neural network model is used to comprehensively evaluate the AST path, function call chain, semantic entropy vector and feature similarity, and output a malicious confidence score (the closer to 1, the higher the probability of maliciousness). S34: Adaptive threshold adjustment; The dynamic threshold is adjusted based on system security level, abnormal user upload frequency, and attack trends. If the malicious confidence score exceeds the dynamic threshold, the file is determined to be malicious. S35: Prediction of Malicious Behavior; Match the high-risk behavior pattern library. If a sample matches any pattern, a high-risk behavior warning is triggered, and the file is identified as malicious. S36: Low-confidence behavior caching mechanism; Samples with malicious confidence scores within the range of ±0.1 of the dynamic threshold are stored in the sandbox pool for judgment, and whether to block them is determined by combining sandbox behavior observations.

[0009] S4. Real-time interception and threat signature synchronization; specifically including the following sub-steps: S41: Upload behavior interception; The file is analyzed in real time during the streaming process, and the upload is blocked immediately once the malicious conditions are met to prevent malicious files from being stored on the ground. S42: Attack log generation; Record detailed information of upload requests, generate structured logs containing attack profiles, integrate basic information, judgment criteria and technical details, and synchronize them to the log system and auditing platform in JSON format; S43: Attack fingerprint extraction; Extract AST path, high-risk call chain, high-entropy string features and semantic entropy vector, generate unique fingerprint hash and store it in local feature library; S44: Deduplication and de-duplication mechanism; Deduplication is achieved through MD5 hashing and distributed caching, and a sliding window mechanism is used to avoid duplicate synchronization. Throttling synchronization is triggered for unchanged samples. S45: Feature synchronization and policy distribution; The attack fingerprints and types are encapsulated into threat intelligence entries, synchronized to the global threat protection platform through an encrypted channel, and incremental updates are pushed to the detection nodes and the local signature database is updated.

[0010] The beneficial effects of the file upload attack interception method based on semantic entropy enhancement of this invention are as follows: From the perspective of semantic complexity modeling and abnormal behavior recognition, the detection system improves its ability to perceive malicious files, filling the technical gaps in existing detection methods. It can effectively identify hidden, obfuscated, or encrypted malicious script code, breaking through the technical bottleneck of traditional static feature detection being easily bypassed. Compared with existing technologies that rely solely on file extensions, keyword matching, or static signatures, this invention introduces a "semantic entropy vector" as the core detection basis for the first time. It extracts behavioral features from multiple dimensions, including variable pollution paths, function call density, high-entropy string distribution, and control flow complexity, and combines these features into a unified vector to form a precise model of file-level semantic behavior. Attached Figure Description

[0011] Figure 1 This is a schematic diagram of the overall workflow of a file upload attack interception method based on semantic entropy enhancement according to the present invention; Figure 2 This is a flowchart illustrating steps S33-S36 of a file upload attack interception method based on semantic entropy enhancement according to the present invention. Detailed Implementation

[0012] To provide a further understanding of the purpose, structure, features, and functions of the present invention, detailed descriptions are provided below with reference to specific embodiments.

[0013] like Figure 1-2 As shown, a file upload attack interception method based on semantic entropy enhancement includes the following steps:

[0014] S1. File format parsing and content extraction. This includes the following sub-steps:

[0015] S11: File type identification and detection.

[0016] After uploaded files are integrated into the detection system, they are first subjected to MIME type checking, extension identification, and magic number feature analysis to determine whether they belong to potentially executable script files (such as PHP, JSP, ASP, JS, etc.). This initial screening identifies potentially dangerous script files, while non-potentially executable script files are not further tested, narrowing down the scope of subsequent key detection. For example, attackers might disguise malicious PHP scripts as images or other harmless files. File type identification can quickly identify such disguised files, preventing them from entering the subsequent detection process, improving detection efficiency, and reducing the risk of missed detections. The specific judgment logic and processing methods are as follows: File extension identification: This method uses the filename extension to initially determine the file type. It's a simple and quick method, but it's easily affected by filename tampering.

[0017] MIME type detection: This involves reading the content of a file and analyzing its format to determine its MIME type. For example, analyzing the structure of an HTML file, the style rules of a CSS file, and the code logic of a JavaScript file can identify the corresponding MIME type, such as text / html, text / css, application / javascript, etc.

[0018] Magic number analysis: Examining a specific sequence of bytes at the beginning of a file, known as the magic number, to determine the file's actual type. The magic number is a set of bytes defined in the file format specification to identify the file type; for example, the magic number of a ZIP file is 50 4B03 04.

[0019] Specifically, upon receiving an uploaded file, the system synchronously extracts the file's extension, MIME type, and magic number. This involves using regular expressions to extract the file extension from the filename; extracting the Content-Type header from the uploaded file's HTTP request and analyzing the MIME type of the file content; reading the binary content of the file header, matching its magic number characteristics, and using a known magic number table to determine the file's true type.

[0020] Furthermore, the characteristics across the three dimensions are compared for consistency. If they are inconsistent, the magic number is used as the core criterion for judgment. Through triple verification of MIME, file extension, and magic number, the true file type is accurately identified, and potentially executable script files are initially screened out. Harmless non-script files are quickly excluded, narrowing the scope of subsequent detection and improving efficiency; it also overcomes "extension spoofing" attacks, preventing attackers from bypassing the initial detection.

[0021] By employing triple verification of MIME type, file extension, and magic number, the system accurately identifies the true file type and initially filters out potentially executable script files. It quickly eliminates harmless non-script files, narrowing down the scope of subsequent detection and improving efficiency; it also overcomes "extension spoofing" attacks, preventing attackers from bypassing the initial detection.

[0022] S12: Recognition and processing of nested content.

[0023] File nesting structure processing, increasing the ability to identify and process hidden scripts in nested compressed files or rich text documents.

[0024] Attackers often use file nesting techniques to hide malicious scripts, and uploaded files may use formats such as ZIP, RAR, and DOCX to conceal script content. This step can delve deeper into these hidden contents and prevent malicious scripts from escaping detection.

[0025] For compressed file types: ZIP files have a header of 50 4B 03 04 and support ".zip", ".docx", ".xlsx", and ".pptx"; RAR files have a header of 52 61 72 21 and correspond to the ".rar" extension; 7Z files have a header of 37 7A BC AF 27 1C and correspond to the ".7z" extension.

[0026] For rich text document types: Although DOCX / XLSX / PPTX are ZIP files, their root directory contains [Content_Types].xml, and DOCX has a word / directory, XLSX has an xl / directory, and PPTX has a ppt / directory. Regular ZIP files can be distinguished by detecting [Content_Types].xml and its corresponding directory characteristics. PDF files have the header "%PDF" (hexadecimal 25 50 44 46), and if they contain embedded files, they can be identified through the EmbeddedFiles naming tree in the / Names tree of the Catalog dictionary.

[0027] If a non-binary file contains a "file characteristic string" encoded in Base64 / URL (such as a Base64 encoded ZIP header UEsDBBQACAAIA), it is determined to be an encoded nested carrier.

[0028] Dedicated parsing tools are loaded for different media types. For example, for ZIP / DOCX / XLSX, a cross-platform library is used to support reading the internal file list and content; for RAR, the unrar library is integrated to support decompression and encryption; for PDF, Apache PDFBox (Java) or PyPDF2 (Python) is used to extract embedded files from the EmbeddedFiles dictionary; for encoded content, a Base64 / URL decoder is integrated to support automatic identification of the encoding type, such as by judging it through the "=" padding character of Base64.

[0029] The content is extracted layer by layer using a depth-first recursive strategy: For the current carrier file, use the corresponding tool to parse and obtain the list of internal files, and traverse the internal files to determine whether it is a nestable carrier file: if it is a nestable carrier file, use that file as the new carrier and recursively execute the extraction process; if it is not a nestable carrier file, directly extract the content to the temporary directory. To prevent attackers from causing infinite recursion through "circular references" (such as A containing B, B containing A), it is also necessary to maintain a "processed file hash list". MD5 hash is calculated for each extracted nestable carrier file. Then, before recursion, it is checked whether the current nestable carrier hash is already in the list: if it exists, it is determined to be "circular nesting" and extraction is stopped; if it does not exist, it is added to the list and processing continues.

[0030] Finally, for all non-nested carrier files (such as .php, .js, .vbs, etc.) extracted to the temporary directory, the type of the extracted files is re-identified to ensure that hidden malicious scripts are detected; It covers mainstream nested scenarios such as ZIP, DOCX, and PDF, and extracts hidden scripts from nested carriers layer by layer to prevent malicious code from escaping detection through multiple layers of nesting; in addition, depth-first recursion and MD5 hash deduplication can avoid system resource exhaustion caused by circular nesting.

[0031] S13: Syntax cleaning and optimization.

[0032] For uploaded objects identified as potentially executable script files, the detection system performs syntax cleaning operations, including removing redundant comments, whitespace characters, standardizing variable / function definition styles, indentation formats, etc., and stripping away non-functional information.

[0033] Based on the file type identification results from step S11, syntax cleaning is performed on uploaded objects identified as script files. The specific steps are as follows: The script file is split into code snippets line by line, and the start position of each line is marked. Based on the script file type (such as PHP, JS, Python), the corresponding language's syntax rule library (such as comment symbols, keyword lists, and variable naming conventions) is loaded.

[0034] For single-line comment symbols in different languages ​​(such as " / / " in PHP / JS and "#" in Python), use regular expressions to match and remove "comment symbol + subsequent content". However, comment symbols contained in strings must be excluded. Distinguish between the "code section" and the "string section" (switch states when encountering quotation marks). Only perform single-line comment removal in the "code section". For multi-line comments (such as / *... * / ), use regular expressions to match content that starts with " / *" and ends with "* / " and remove it directly. If the multi-line comment contains nested comments (such as " / * a / * b * / c * / "), it needs to be processed recursively to avoid omissions by simple regular expressions.

[0035] Replace multiple spaces, newlines (\n\n), and tabs (\t\t) with a single one; remove leading and trailing whitespace characters and consecutive blank lines (keeping only one blank line to separate logical blocks).

[0036] Extract all variable names and function names; convert them to a default style (e.g., all lowercase + underscores: such as "user_name", "get_user_info"); also ensure that there are no naming conflicts after conversion (e.g., "user_name" and "user_name" are the same after conversion, and need to be distinguished by suffix: such as "user_name_1").

[0037] Force 4 spaces of indentation to be added to code blocks (such as the content within "{}" after "if", "else", or "for"), and the "{" must be on the same line as the keyword. This makes the hierarchical relationship of code blocks visible, facilitating subsequent analysis of control statements.

[0038] This step reduces distracting information in the code, allowing subsequent analysis to focus more on its logical structure and functionality. Attackers might intentionally add numerous meaningless comments or whitespace characters to malicious code, or use inconsistent variable naming and indentation formats to obfuscate the code logic and increase the difficulty of detection. Syntax cleaning and structural standardization can eliminate these distracting factors, restoring the code's essential structure.

[0039] S14: Coding standard processing.

[0040] Address syntax parsing failures caused by various encodings (such as GBK, ISO-8859-1, UTF-16) by ensuring conversion to a unified encoding before analysis. Consider also performing unified stripping of the BOM header.

[0041] The Bill of Materials (BOM) header of a file is a marker used to determine the Unicode encoding of a text file. It is itself a Unicode character located at the beginning of the text file. Although the BOM header helps identify the file encoding, it is not part of the file content. Therefore, in some cases, the BOM header can cause problems, such as affecting the parsing or display of the file content. In front-end development, especially when using scripting languages ​​such as JavaScript to process text files, the BOM header may cause code execution errors or unpredictable behavior. Therefore, to avoid problems caused by the BOM header, it may be necessary to detect and remove the BOM header before processing text files.

[0042] To resolve parsing failures caused by encoding differences, a unified encoding format is implemented, which includes three core steps: identifying the file encoding by using the BOM header and character distribution characteristics (e.g., GBK / GB2312: Chinese characters occupy 2 bytes (high byte range 0x81-0xFE, low byte 0x40-0xFE excluding 0x7F), no NULL bytes (0x00)). Then, cross-platform scripting tools (such as Python's codecs or Java's BOMInputStream) are used to detect and remove the BOM, thus stripping the BOM header. All files are then converted to the universally compatible UTF-8 encoding. Specifically, a mature encoding conversion library is used to preload common encoding sets to ensure coverage of mainstream encoding types. The file byte stream is read using the identified encoding, and finally re-encoded to UTF-8 to generate a new byte stream. This processed new byte stream is then written to a new UTF-8 normalized file to obtain the sample. This addresses parsing errors caused by inconsistent encoding, ensuring the accuracy and reliability of the analysis. Different detection systems and users may use different encoding formats, which can lead to garbled characters or parsing errors during file transmission and parsing, affecting detection results. Encoding standard conversion ensures that all file content is processed in a unified encoding format, preventing the omission of potentially malicious content due to encoding issues.

[0043] S15: Construct intermediate representations.

[0044] The processed code is then converted into a standard intermediate representation (IR), preserving the logical semantics while stripping away the syntactic shell, providing consistent input for abstract syntactic structure analysis. The core of intermediate representation construction is "stripping away syntactic differences while retaining the logical essence," by converting the cleaned code into a language-neutral structured representation, focusing on the core logic of variable relationships, function calls, and control statements. The specific implementation process is as follows: For standardized code text (such as PHP, JS, and Python scripts) after step S13 syntax cleaning and step S14 encoding conversion, load the corresponding language's variable identification rules, function call format (such as "function name (parameters)", ignoring language-specific differences in parentheses and semicolons) and control statement keywords according to the code type.

[0045] By using regular expressions and text traversal, the core elements that constitute the logic are extracted from the code.

[0046] Specifically, use regular expressions to match variable definitions, record variable names, and remove prefixes such as "$" to unify them as plain names; then analyze the variable assignment content and mark the source type: If the value assigned is user input, it is uniformly marked as "user input" due to the different user input formats in different languages, and the original format is preserved in the source field; if the value assigned is a constant, it is marked as "constant"; if the value assigned is a function return value, it is marked as "dependent function f".

[0047] Then, the parameter association of the function call is processed. The function call is matched with regular expressions to identify and record the function name, and the parameters in the function parentheses (such as "$x" in "system($x)") are parsed, associated with the variable element library, the source of the parameters is marked, and recorded in the format of "function call: [function name], parameters: [parameter list and source]".

[0048] Next, match "if\s*\((.*?)\)", extract the conditional expression (e.g., "$x>5"), record the variables that the condition depends on, and locate the execution block after the condition is evaluated by indentation or curly braces "{}", recording the variable assignments and function calls contained within the block; for execution blocks without curly braces, such as if(x>5) eval(x), locate the execution block scope by "semicolon" or "newline", and mark the execution block [eval(x)]; "echo 'error'" within "\(x)" and "else" blocks, when there are no curly braces, define the execution block scope by "semicolon" or "newline"; for for loops, extract the initialization expression (e.g., "let For loops, extract the loop condition (e.g., "i<10"), iterate the expression (e.g., "i++"), locate the loop body and record its internal logic elements, and mark the variables that the loop depends on (e.g., "i"). For while loops, extract the loop condition (e.g., "x>0"), locate the loop body and record its content. For do-while loops, extract the loop body and loop condition, and clarify the execution order characteristics. For switch statements, evaluate the expression, extract the branch condition, locate the execution block of each branch, and record the logic within the block and the order relationship between branches. For jump statements, identify break statements and mark their associated loops or switch structures. Identify continue statements and record the associated loop structure and loop counter (e.g., "associated with while loop (x>0), dependent variable x"). Identify goto statements, extract the target label, and record the label definition location and the source location of the goto statement. For exception handling statements, extract the try block content, then extract the exception parameters of catch and the catch block content, and mark the type of exception parameters and the logical elements within the block. For nested control statements, such as if(a){ if(b) { eval(x);} The parent structure of the inner if statement needs to be marked as "condition a (when satisfied) to condition b (when satisfied)" to reflect the hierarchical relationship.

[0049] Add a "Syntax Markup" field to the IR's attributes to record language-specific syntax details (such as keywords for variable declarations and the position of parentheses in function calls). For example, the syntax markup for variable definition is { "declaration keyword": "let", "assignment symbol": "="}; the syntax markup for function calls is { "parentheses type": "()", "parameter separator": ","}; the syntax markup for control statements is distinguished by type: if-else is { "keyword": ["if", "else"],"execution block symbol": "{}"}; for is { "keyword": "for", "parentheses type": "()", "separator": ";"}; while is { "keyword": "while", "execution block symbol": "{}"}; do-while is { "keyword": ["do", "while"], "execution block symbol": "{}"}; switch is { "keyword": ["switch", "case", "default"], "execution block symbol": "{}", "branch separator": ":"}; the jump statement: break is { `{"keyword": "break", "terminator": ";"}`; `continue` is `{"keyword": "continue", "terminator": ";"}`; `goto` is `{"keyword": "goto", "label separator": ""," terminator":";"}`; `try-catch` is `{"keyword": ["try","catch"]," execution block symbol":"{}"," parameter brackets":"()"}`.

[0050] Intermediate representations can more clearly show the logical structure of code, providing a foundation for subsequent semantic analysis. They can convert code from different languages ​​and styles into a unified representation, enabling analysis tools to process various types of code in the same way, improving the universality and accuracy of analysis. At the same time, they help to mask surface differences in code, focusing on semantic features and resolving detection blind spots caused by syntactic differences.

[0051] S2. Abstract syntax tree construction and semantic entropy calculation. This includes the following sub-steps:

[0052] S21: Construct an abstract syntax tree.

[0053] An abstract syntax tree (AST) is generated based on the intermediate representation, capturing all structural elements in the code, including variable declarations, function definitions, call relationships, control statements, etc.

[0054] The core of AST construction is to reconstruct the syntax tree structure of the code from the logical and syntactic information of IR. This is achieved by mapping IR elements to AST nodes, filling in syntactic details, and building hierarchical relationships to generate a tree structure consistent with the original code syntax, fully capturing the structural elements of variable declarations, function calls, and control statements. The specific implementation process is as follows: First, based on the code type (e.g., JS, PHP, Python), define AST node types that cover all syntactic structures, ensuring that each node corresponds to a syntactic component in the code. The core node types and their descriptions are as follows: For nodes of type Program, the corresponding syntax component is the program root node, and the core attributes (based on IR's "syntax tags" and "attributes") are "body (list of child nodes)"; for nodes of type VariableDeclaration, the corresponding syntax component is variable declaration (such as let x = ...), and the core attributes are "kind (declaration keyword); declarations (list of variable declaration child nodes)". For nodes of type VariableDeclarator, the corresponding syntax is a single variable declaration (e.g., x = request.query.data), and the core attributes are "id (variable name node Identifier); init (initialization expression node)"; For nodes of type CallExpression, the corresponding syntax is a function call (e.g., atob(x)), and the core properties are "callee(function name node I); arguments(parameter expression node list, e.g., the Identifier corresponding to x)"; For nodes of type IfStatement, the corresponding syntax is conditional statements (e.g., if (x.length>5){ ...}, with the core attributes being "test (conditional expression node); consequent (execution block that satisfies the condition)"). For nodes of type ForStatement, the corresponding syntax is a for loop (e.g., for (let i=0; i<10; i++) { ...}), and the core attributes are "init (initialization expression node, such as variable declaration); test (loop condition expression node); update (iteration expression node); body (loop body execution block)"; For nodes of type WhileStatement, the corresponding syntax is a while loop (e.g., while (x>0){ ...}), and the core attributes are "test (loop condition expression node); body (loop body execution block)"; For nodes of type DoWhileStatement, the corresponding syntax is a do-while loop (e.g., do{ ...} while (x>0)), and the core attributes are "body (loop body execution block); test (loop condition expression node)"; For nodes of type SwitchStatement, the corresponding syntax is a switch statement (e.g., switch(x) { case 1: ...; case 2: ...; default: ...}), and the core attributes are "discriminant (discriminant expression node, such as the Identifier corresponding to x); cases (a list of case child nodes, each of which is a SwitchCase node)"; For nodes of type SwitchCase, the corresponding syntax is the case branch in switch, and the core attributes are "test (case condition expression node, such as Literal corresponding to 1); consequent (branch execution block, containing a list of statement nodes)"; For nodes of type BreakStatement, the corresponding syntax is a break jump statement (such as break), and the core attribute is "label (optional, target label node Identifier, null if there is no label)"; For nodes of type ContinueStatement, the corresponding syntax is a continue jump statement (e.g., continue), and the core attribute is "label (optional, target label node Identifier, null if there is no label)"; For nodes of type GotoStatement, the corresponding syntax is the goto jump statement (e.g., gotolabel1), and the core attribute is "label(target label node Identifier)"; For nodes of type TryStatement, the corresponding syntax is a try exception handling statement (e.g., try{ ...} catch (e) { ...}), and the core attributes are "block (try block execution node BlockStatement); handlers (catch child node list, each is a CatchClause node); finalizer (optional, finally block node BlockStatement, null if there is no finally)"; For nodes of type CatchClause, the corresponding syntax is the catch exception handling branch (e.g., catch(e) { ...}), and the core attributes are "param (exception parameter node Identifier, such as the Identifier corresponding to e); body (catch block execution node BlockStatement)"; For nodes of type BinaryExpression, the corresponding syntax is a binary expression, and the core properties are "operator (operator), left (left operand node) and right (right operand node)".

[0055] Other AST node types will not be discussed further here; Next, based on the IR constructed in step S15, different types of IR features are mapped to corresponding AST nodes, and node attributes are populated using the IR's "attributes" and "syntax tags". The main mapping rules are as follows: For IR feature types defined as variables, the mapped AST node type is VariableDeclaration, and the node attribute population logic (based on IR fields) is "kind = IR.attributes.syntactic tags.declaration keywords; declarations = contains 1 VariableDeclarator child node, where: id = Identifier node, init = initialization expression node"; For IR features of type function call, the mapped AST node type is CallExpression, and the node attribute population logic is "callee= Identifier node, arguments= parameter expression node list"; For IR features of conditional type, the mapped AST node type is IfStatement, and the node attribute filling logic is "test = conditional expression node, consequent = BlockStatement node, if there is an else branch, alternate = BlockStatement node"; For IR features of type for loop, the mapped AST node type is ForStatement, and the node attribute population logic is "init= IR.attributes. Node corresponding to the initialization expression, test= Node of the loop condition expression, update= Node of the iteration expression, body= Node of the BlockStatement"; For IR features of type while loop, the mapped AST node type is WhileStatement, and the node attribute population logic is "test = loop condition expression node, body = BlockStatement node"; For IR features of type do-while loop, the mapped AST node type is DoWhileStatement, and the node attribute population logic is "body = BlockStatement node, test = loop condition expression node"; For IR feature types of switch statement, the mapped AST node type is SwitchStatement, and the node attribute population logic is "discriminant = discriminant expression node, cases = list of SwitchCase nodes corresponding to each case branch, where test = case condition expression node, consequent = list of branch execution block nodes"; For IR features of type break statement, the mapped AST node type is BreakStatement, and the node attribute filling logic is "label= if the IR contains associated labels, then it is an Identifier node, otherwise it is null"; For IR features of type continue statement, the mapped AST node type is ContinueStatement, and the node attribute population logic is "label= if the IR has associated labels, then it is an Identifier node, otherwise it is null"; For IR features of type goto statement, the mapped AST node type is GotoStatement, and the node attribute population logic is "label=Identifier node (corresponding to the target label of IR)"; For IR elements of type try statement, the mapped AST node type is TryStatement, and the node attribute filling logic is: "block = BlockStatement node (corresponding to the IR try block), handlers = contains 1 CatchClause child node, where param = Identifier node (corresponding to the IR catch parameter), body = BlockStatement node (corresponding to the IR catch block), finalizer = if the IR has a finally branch, it is a BlockStatement node, otherwise it is null"; For IR elements of type catch statement, the mapped AST node type is CatchClause, and the node attribute filling logic is "param= Identifier node (corresponding to the catch parameter of IR), body= BlockStatement node (corresponding to the catch block of IR)".

[0056] Then, expressions such as "conditions", "parameters", "loop initialization / iteration", and "switch statements" in the IR (e.g., x.length>5, i++, request.query.data, x) need to be converted into corresponding AST expression nodes. The specific steps are as follows: For member access expressions (such as x.length), the expression is split by "." (e.g., request.query.data is split into request, query, and data); then nested MemberExpression nodes are constructed from left to right: the first level is object: Identifier (name="request"), property: Identifier (name="query"), the second level is object: the first level node, property: Identifier (name="data"); For a binary expression (e.g., x.length>5), first extract the operator and the left and right operands; the left operand is constructed as a MemberExpression node (x.length), and the right operand is constructed as a Literal node (value=5); combine them into a BinaryExpression node (operator=">", left = left node, right = right node). For increment / decrement expressions (such as i++), construct an UpdateExpression node with the attributes "operator="++", argument= Identifier (name="i"), prefix=false"; For function call parameters, they are directly mapped to Identifier nodes (name = parameter name).

[0057] Finally, based on the relationships between "parent structure," "dependent elements," and "execution blocks" in the IR, a tree-like hierarchy of the AST is constructed to ensure that the node nesting and order are consistent with the original code: For the root node and top-level elements, all IR elements without a parent structure are arranged in the order of "location information.startLine" and used as the body attribute of the Program node; for control statements and execution blocks, the elements in the "execution block" of the IR condition judgment are constructed as nodes in the order of "position within the block" and used as the body of the BlockStatement. This BlockStatement serves as the consequent attribute of IfStatement, the body attribute of ForStatement / WhileStatement / DoWhileStatement, and the block attribute of TryStatement; for switch statements, the "execution block" of each case branch is arranged in order of... The sequence of nodes is used to construct the `consequent` property of the `SwitchCase` node. All `SwitchCase` nodes are arranged in the order of `case` in the IR and are used as the `cases` property of `SwitchStatement`. For jump statements, `break` / `continue` statements are used as child nodes of the execution block of their associated loop or `switch` (e.g., a `BreakStatement` node is contained in the body of a `for` loop). `goto` statements are used as child nodes of the execution block of the parent structure according to their position in the IR. For exception handling statements, `CatchClause` nodes are used as the list of `handlers` properties of `TryStatement`, and if a `finally` block is contained, they are used as the `finalizer` property. For nested relationships, if the "parent structure" of an IR element is another element (e.g., an `if` condition in a loop body, a function call in an `if` block, a `while` loop in a `try` block, or a `break` in a `catch` block), then the node corresponding to that element is used as a child node of the parent structure node.

[0058] An Abstract Syntax Tree (AST) is a tree-like data structure representing code structure, where nodes represent variables, statements, functions, etc. It can be used to analyze control statements and dependencies. ASTs visually represent the syntactic structure of code, providing a foundation for subsequent semantic analysis. By decomposing code into its syntactic components, it enables analysis tools to accurately identify the individual parts of the code and the relationships between them, which is crucial for identifying malicious code patterns and understanding code behavior.

[0059] S22: Contamination chain tracing.

[0060] Analyze whether user-controllable input variables flow into dangerous functions and construct a "contamination propagation path diagram" to determine whether there is a risk of command execution.

[0061] The core of contamination chain tracing is to start from user-controllable input, track the propagation path of variables, determine whether they ultimately flow into dangerous functions, and construct a complete "contamination propagation path graph" by marking "contamination states," tracing propagation relationships, and detecting dangerous calls, thereby identifying potential command execution risks. The specific implementation process is as follows: First, we define the following core concepts and basic data structures: the pollution source is a variable that can be controlled by the user, such as from request.query, $_POST, Cookie, etc., which is represented in the AST as a variable whose initialization source is user input (such as x's init is request.query.data). Pollution variables are variables that are directly or indirectly assigned values ​​by the pollution source. For example, if x pollutes y, then y is a pollution variable. A pre-defined list of high-risk functions is provided, initially including the functions eval, system, exec, atob, passthru, base64_decode, unescape, and create_function, and can be configured via a configuration file; functions in the high-risk function list are defined as dangerous functions.

[0062] The contamination status table (dictionary) is used to record whether a variable is contaminated and the source of the contamination. The format is "{variable name:{isTainted: true / false, source: contamination source variable name}}". A contamination path diagram (list) is used to record the complete propagation path, in the format of "[{from: source variable, to: target variable, type: propagation type (assignment / function parameter)}]"; The Dangerous Call Record (list) is used to record the call relationships of contaminated variables flowing into dangerous functions. The format is "[{function name: "eval", parameter: "y", path: "x→y→eval"}]".

[0063] Then, based on the initialization information of the variables in the AST, all pollution source variables are located and the initial pollution state is marked. Specifically, the variable declaration nodes of the AST are traversed first, and the init attribute (initialization expression) of the variables is checked. If init is an expression related to user input (such as MemberExpression corresponding to request.query.data, $_POST['x']), then this variable is the source of pollution; then mark it as "{variable name: {isTainted: true, source: "user input"}}" in the pollution status table; add an initial record "{from: "user input", to: variable name, type: "direct assignment"}" in the pollution path graph.

[0064] Next, all nodes of the AST are traversed in execution order to trace the propagation relationships of pollution variables, update the pollution state and path graph, and specifically divide into the following scenarios: For scenarios involving direct assignment propagation (such as `let y = x;`, where x is a polluted variable), the `AssignmentExpression` or `VariableDeclarator` node is first identified. If the variable to the right of the assignment symbol is a polluted variable (such as x), then the variable to the left (such as y) is marked as a polluted variable, i.e., the pollution status table is updated to `{y: {isTainted: true,source:"x"}}`. A record `{from: "x", to: "y", type: "direct assignment"}` is added to the pollution path graph.

[0065] For scenarios involving passing function parameters (e.g., func(x); where x is a polluting variable), first identify the CallExpression node. If the function parameter is a polluting variable (e.g., x), and the function assigns the parameter to other variables (e.g., function func(a) { let b = a;}), then mark b as a polluting variable, source = "x"; and add the following record to the pollution path graph: [{from: "x", to: "a", type: "Function parameter passing"}, {from: "a", to: "b", type: "Direct assignment"}].

[0066] For scenarios involving function return value propagation (e.g., let z = func(x);, where x is a polluting variable and func returns x), first identify the init of CallExpression as an assignment expression (e.g., the init of z is func(x)); if the function return value depends on the polluting parameter (e.g., func returns x), then mark z as a polluting variable and source = "x"; add records "[{from: "x", to: "func return value", type: "function return"}" and "{from: "func return value", to:"z", type: "direct assignment"}] to the pollution path graph.

[0067] For nested call propagation scenarios (such as let m = func1(func2(x));, where x is a pollution variable), trace the call hierarchy sequentially: x → func2 parameter → func2 return value → func1 parameter → func1 return value → m; then mark the pollution status layer by layer and record the complete nested relationship in the path graph.

[0068] Then, it checks whether contaminated variables flow into dangerous functions. It traverses the CallExpression nodes (function calls) of the AST, checks whether the parameters are contaminated variables, and whether the function is in the preset high-risk function list. Specifically: First, for each CallExpression node, extract the function name (callee.name) and parameter list (arguments). If the function name is in the preset high-risk function list, check whether the parameter is a polluted variable (by checking whether isTainted is true in the pollution status table). If it is a polluted variable, add an entry to the dangerous call record, including the function name, parameter variable, and complete pollution path (by tracing through the pollution path graph).

[0069] Finally, based on the pollution path diagram and dangerous call records, a visual path diagram is generated, such as "user input → x → y → eval".

[0070] This step identifies potential command execution risks, preventing attackers from injecting malicious code through variable poisoning. User-controlled input variables are common entry points for attackers to inject malicious data; if these variables are passed to dangerous functions, they can lead to serious security vulnerabilities. By tracing variable poisoning chains, we can accurately identify which variables have been poisoned and how the poisoning spreads, thus enabling timely detection of potential attacks.

[0071] S23: High-risk function analysis.

[0072] Traverse the AST nodes and identify the call count and density of dangerous functions in the preset high-risk function list in step S22.

[0073] Specifically, based on the AST generated in step S21, all CallExpression nodes (function calls) are recursively traversed, key information is extracted and recorded, including the extracted fields, function name, call position (start.line, recording line number), parameter list (arguments, associated variable name or expression), parent node type (such as the execution block of IfStatement, the loop body of ForStatement, to determine the call scenario), and nesting depth (such as the nesting depth of atob in eval(atob(x)) is 1, and that of eval is 2).

[0074] Then, a function call record table is constructed to store the data. The function call record table includes the function name, line number, parameters, parent node type, and nesting depth. Then, based on the function call record table, statistical indicators are categorized by function: Group and count by function name to determine the number of function calls;

[0075] Total lines of code = AST root node end.line; Density = Number of function calls / Total lines of code; This step determines whether dangerous functions are used to process user-controlled input by counting the number of calls and computational density, thereby identifying attack risks.

[0076] S24: High-entropy string recognition.

[0077] Extract static strings, variable values, and concatenation chains from the code and calculate their Shannon entropy values. If high entropy features are found (such as encrypted payloads or obfuscated fragments), they are marked as suspicious nodes. In addition to Shannon entropy, other indicators can be introduced, such as compression ratio (the ratio of the compressed length to the original length using gzip compression), or detecting the existence of Unicode / HTML escaping, double encoding (such as \x41\x42\x43), and other escape methods.

[0078] The core of high-entropy string recognition is to extract various types of string information from the code and use multi-dimensional indicators to determine whether it contains suspicious features, providing supplementary evidence for malicious code detection. In practice, the first step is to comprehensively extract string-related elements from the Abstract Syntax Tree (AST), including static strings, string values ​​assigned to variables, and string concatenation chains. During extraction, the Literal nodes (static strings), AssignmentExpression nodes (strings assigned to variables), and BinaryExpression nodes (concatenation chains connected by addition operators) of the AST must be traversed, and the concatenation chains must be restored to complete strings (e.g., "a" + "b" restored to "ab").

[0079] After extraction, the Shannon entropy value is calculated for each string, which is the core indicator for determining the randomness of the string. The formula for calculating Shannon entropy is: ,in Shannon entropy is the probability of each character appearing in a string. Generally, random or encrypted strings have higher entropy values, while normal semantic strings have lower entropy values. After calculating the Shannon entropy value for each string, the arithmetic mean of the Shannon entropy values ​​for all strings is calculated.

[0080] Preferably, in addition to entropy value, the compression ratio and detection of special encoding patterns are used as auxiliary indicators. After compressing a string with gzip, if the ratio of the compressed length to the original length is less than 0.5, it indicates that the string has low redundancy and may contain encrypted content, thus increasing its suspiciousness. Detecting special encoding patterns, such as Unicode escaping ("\u0061"), hexadecimal escaping ("\x41"), and double encoding (such as Base64 followed by URL encoding), are escape methods that are often used to hide malicious content.

[0081] In the comprehensive judgment stage, the core logic of each indicator is to use Shannon entropy as the core indicator (which must be met), and compression rate and coding features as auxiliary indicators. The three together constitute the judgment conditions, and if they are met, the node is marked as suspicious.

[0082] Specifically, if the Shannon entropy value is ≥5, it indicates that the string is very likely to be encrypted or obfuscated; if the compression rate is ≤0.5, it indicates that the string has low redundancy and meets the encryption characteristics; if the string has "single encoding" or "double or more encoding", it is considered to have special encoding characteristics. A string is marked as a suspicious node when it has a Shannon entropy value ≥ 5 and a compression rate ≤ 0.5, or when it has a Shannon entropy value ≥ 5 and exhibits special encoding characteristics.

[0083] High-entropy strings refer to strings with disordered and unpredictable character distribution. They are typically used to hide data (such as encryption, Base64 encoding, and shellcode) and are often associated with encryption and obfuscation techniques. They are a key characteristic for identifying malicious code. Attackers frequently encrypt or obfuscate malicious code to evade detection systems based on keywords or simple pattern matching. High-entropy string identification can discover these hidden malicious contents by calculating the complexity of the string, providing strong support for detecting encrypted or obfuscated malicious code. Through this multi-indicator approach, high-entropy string identification can effectively capture encrypted and obfuscated malicious content, compensating for the shortcomings of simple syntax analysis. It is particularly effective in detecting attack payloads hidden through string concatenation and encoding conversion, providing a more comprehensive basis for overall malicious code detection.

[0084] S25: Control flow complexity modeling.

[0085] For samples containing a large number of jump statements, deeply nested if / else, and switch structures, the logical complexity score is calculated using a cyclomatic complexity algorithm and AST traversal technique.

[0086] The core of control flow complexity modeling is to assess the complexity of code by quantifying its logical branches, jumps, and nested structures—the higher the complexity, the more likely it is to hide malicious logic (such as evading detection through chaotic structures). The specific implementation is based on the AST generated in step S21, combining cyclomatic complexity algorithms and AST traversal techniques to complete the modeling in stages.

[0087] First, control flow-related nodes need to be extracted from the AST. All syntax structures that may affect the execution path are traversed, including conditional statements (IfStatement), switch statements (SwitchStatement), loops (ForStatement / WhileStatement / DoWhileStatement), jump statements (BreakStatement / ContinueStatement / GotoStatement), and exception handling (TryStatement / CatchClause). These nodes are the core source of control flow branches.

[0088] Preferably, the "decision node counting method" is used as the cyclomatic complexity algorithm to calculate the basic complexity score. The core logic is: control flow complexity = number of decision nodes + 1, where "decision node" refers to all syntactic structures that can generate branches. The specific implementation is based on the AST in step S21.

[0089] First, accurately identify all decision nodes from the AST, as these nodes are the sources of control flow branches. Specifically, this includes the following statements: if statement: Each if statement corresponds to one decision node, regardless of whether there is an else statement; Loop statements: for, while, and do-while each count as 1, because the loop condition will generate "enter / skip" branches; switch statement: Each case branch counts as 1, and the default branch is also counted, because each case corresponds to a different execution path; In jump statements, each `goto` statement counts as one, because the jump breaks the linear execution flow.

[0090] When traversing the AST, it is necessary to recursively check all node types and count the nodes determined above one by one to avoid missing nested structures.

[0091] Next, the cyclomatic complexity is calculated using the "decision node counting method": the total number of decision nodes counted is incremented by 1 to obtain the base complexity value. For example, a switch statement containing one if, one for, and two case statements has a total of 1+1+2=4 decision nodes, and a cyclomatic complexity of 4+1=5. Simultaneously, to more accurately reflect the degree of logical chaos, it needs to be corrected by incorporating nesting depth: the maximum nesting level of control flow nodes is calculated (e.g., if nested within an if, then nested within a for, with a maximum depth of 3), the nesting depth is multiplied by 0.3, and then added to the cyclomatic complexity multiplied by 0.7 to obtain the logical complexity score. This is because deep nesting significantly increases the difficulty of understanding the code, and malicious code often uses this method to hide attack logic.

[0092] Complex control flow can be a means for attackers to hide malicious logic. Modeling and analysis can identify potential complex malicious behaviors. Overly complex control flow can make code difficult to understand and analyze, and may also hide complex attack logic, such as conditionally triggered malicious behavior or malicious operations executed through multiple paths. By modeling control flow complexity, the complexity of the code can be quantified, providing a reference for identifying potential malicious behaviors.

[0093] S26: Semantic entropy vector generation.

[0094] The core of semantic entropy vector generation is to integrate the various feature indicators extracted in steps S22 to S25 into a multi-dimensional vector (such as call density entropy, string entropy, and control complexity entropy). By quantifying the semantic behavior features of the code, it provides standardized input for subsequent model judgment. Specifically, the selection and standardization rules of the feature indicators must first be clearly defined, and then they are combined into vectors according to fixed dimensions, ultimately forming a file-level semantic profile for model judgment.

[0095] From the results of steps S22 to S25, key feature indicators are selected, covering four dimensions: contamination propagation, high-risk function usage, string features, and control flow complexity, ensuring that each indicator reflects different semantic dimensions of the code. Specifically, the following six indicators are obtained: 1. Propagation length of pollution variables: Taken from the pollution path diagram in S22, the number of variable transmissions from the pollution source to the final hazard function is counted. For example, the propagation length of "user input → x → y → eval" is 3. 2. High-risk function call count: Taken from the statistics in S23, that is, the total number of calls to a certain type of high-risk function; 3. Number of high-entropy strings: Taken from the number of suspicious node markers in S24, the total number of high-entropy strings is counted; 4. Average entropy: Taken from the Shannon entropy calculation result of S24, it is the arithmetic mean of the entropy values ​​of all strings; 5. Logical complexity score: Taken from the calculation result of S25, it is the result of adding the nesting depth multiplied by 0.3 to the cyclomatic complexity multiplied by 0.7; 6. Nesting Depth: Taken from the nesting depth statistics of S25, which is the deepest level of the control flow node.

[0096] Furthermore, the above indicators are then standardized to eliminate the influence of different units and uniformly map them to the [0,1] interval. For each indicator, min-max normalization is used, and the boundary is set based on the reasonable range of sample statistics. The formula is "Standardized value = (original value - minimum value) / (maximum value - minimum value)".

[0097] After standardization, the indicators are combined into a 6-dimensional semantic entropy vector in a fixed dimensional order: [propagation length of contamination variables, number of high-risk function calls, number of high-entropy strings, average entropy value, logical complexity score, maximum nesting depth]. Each dimension is filled with a standardized value to form a unique semantic entropy vector representation.

[0098] In this way, semantic entropy vectors transform scattered feature indicators into structured digital representations, preserving semantic information across dimensions while enabling comparability between different samples, thus providing comprehensive feature basis for subsequent risk assessment. It integrates various independent feature indicators to form a multi-dimensional profile that comprehensively describes file behavior and characteristics, allowing the detection system to evaluate files from multiple perspectives and improving the accuracy and comprehensiveness of risk assessment.

[0099] S3. Dynamic Scoring and Decision-Making; This stage uses semantic vectors to intelligently assess the risk of uploaded files and makes adaptive handling decisions accordingly. It includes the following sub-steps:

[0100] S31: Business whitelist awareness mechanism.

[0101] Some business systems may use custom, highly complex scripts (such as dynamic workflow scripts in OA systems). You can set "semantic whitelist rules" to avoid false positives.

[0102] Business scripts often need to call high-risk functions such as `eval` (e.g., to parse dynamic form templates). The rules verify the legality of the calling scenario through preceding features. The core verification logic is as follows: The list of high-risk functions that can be called is based on business scenario presets and is associated with the "high-risk function list" in S22 to ensure that it covers the legal high-risk functions that are necessary for the business. Verify that the parameters of high-risk functions are "non-pollution variables" through S22 "Pollution Status Table" (e.g., the parameter of eval is marked as isTainted: false), and verify that high-risk functions are only called within the specified business function through S21 "AST Parent Node Type" (e.g., eval must be located in the execution block of FunctionDeclaration(name='parseFormTemplate')). Furthermore, verify that the number of calls is ≤5 through S23 "Function Call Record Table" to avoid abnormal scenarios of dense calls. A high-risk function call is considered legitimate only if it meets the following conditions: the function is in the allowed list, the parameters are not contaminated, the context is a specified business function, and the number of calls does not exceed 5.

[0103] In addition, by reverse verification of the preceding features, it is ensured that the script has no trace of malicious behavior. The core logic is: there is no propagation record of "user input → variable → high-risk function" in the "pollution path graph" of S22 (i.e., the propagation length of the pollution variable = 0), which prevents attackers from injecting malicious input through business scripts, and the count of "suspicious nodes" in S24 is ≤1, otherwise the current sample does not meet the semantic whitelist rules. The specified business function is determined through business configuration, and the specific process is as follows: The business operations or development team needs to provide a list containing "function name, function description, high-risk functions allowed to be called, and parameter source" based on the function; then, extract the FunctionDeclaration node (function definition) of the historical normal business script from the S21 AST, count the functions with a frequency of ≥90%, and after manual review and confirmation, enter the function name into the specified business function of the semantic whitelist rule.

[0104] If the current sample meets all the above rules, it is marked as a "whitelisted sample" and allowed to pass directly, skipping the subsequent detection process.

[0105] The semantic whitelist rule allows business scripts to legally call high-risk functions without affecting normal business operations; and the multi-factor verification based on prior features prevents the whitelist from being abused.

[0106] S32: Feature similarity comparison.

[0107] The semantic entropy vector of the current sample is compared with the typical attack features (such as WebShell, botnet scripts, and backdoors) already modeled in the attack sample library using cosine similarity calculation, and a similarity score is output. The specific process is as follows: When a sample enters S32, the semantic entropy vector output from step S26 is extracted from the current sample. Then, the average vectors of all typical attack feature categories in the attack sample library are traversed, and the cosine similarity is calculated for each. Taking the comparison with the average vector of the WebShell class as an example, the calculation process is as follows: first, the dot product of the semantic entropy vector of the current sample and the average vector of the WebShell class is calculated; then, the magnitudes of the two vectors are calculated respectively; finally, the cosine similarity is obtained by substituting into the cosine similarity calculation formula to obtain the cosine similarity between the semantic entropy vector of the current sample and the WebShell class vector.

[0108] After traversing all categories, the cosine similarity between the semantic entropy vector of the current sample and the average vector of all typical attack feature categories is obtained. The highest cosine similarity value is taken as the feature similarity score, and the corresponding attack type is recorded according to the category of the average vector. For example, if the calculated cosine similarity between the semantic entropy vector of the current sample and the average vector of the WebShell class is the highest, which is 0.9, then the similarity score of the current sample is 0.9, and the corresponding attack type is recorded as WebShell class.

[0109] By comparing the sample with known attack characteristics, the potential risk of the current sample can be quickly assessed. The similarity score can intuitively reflect how close the current sample is to known attack patterns, helping the detection system to quickly identify possible attack behaviors, improve detection efficiency, and also serve as an important reference indicator for subsequent decision-making.

[0110] S33: Malicious Confidence Score.

[0111] Using a neural network model, the algorithm comprehensively evaluates the AST path, function call chain, semantic entropy vector, and feature similarity scoring dimension, outputting a comprehensive maliciousness score (a floating-point value between 0 and 1). The specific implementation is as follows: The model employs a multimodal feature fusion architecture, with the input layer containing the following four types of features: 1. AST path features: From the AST of S21, traverse all CallExpression nodes (function calls), filter out the nodes whose function names are in the "high-risk function list" of S22, extract the complete path from the Program root node to the node, and serialize it into a string in order of node type.

[0112] If multiple high-risk function call paths exist, the longest path is taken (malicious scripts often contain deeply nested paths); if there are no high-risk function calls, the sequence of the top 3 nodes of the AST is taken.

[0113] Next, a pre-trained Word2Vec model (trained based on the AST paths of 100,000 normal / malicious scripts) is used to map each node type in the serialized string to a 128-dimensional vector. If the node type is not in the pre-trained dictionary, it is filled with a zero vector.

[0114] After concatenating the vectors of the path sequence according to their positions, they are compressed into a fixed 128-dimensional vector using mean pooling (to address differences in path length). The calculation formula is: AST vector = [avg(vᵢ), avg(v2), ..., avg(vᵢ)]. 128 )] , where vᵢ represents the mean of the i-th dimension of all node vectors in the path.

[0115] 2. Function call chain characteristics: From the "Function Call Record Table" in S23, filter call chains containing high-risk functions (such as atob(x)→eval(y)) and encode them into an integer sequence according to the execution order: assign a unique ID to each high-risk function, such as atob=1, eval=2, system=3, and the chain atob→eval is encoded as [1,2]; if there are multiple levels of nesting, such as base64_decode(atob(x))→eval(y), it is encoded as [4,1,2] (base64_decode=4).

[0116] Furthermore, the sequence length is uniformly set to 10 (padded with 0s if insufficient, truncated to the first 10 if excessive) to ensure a fixed input dimension. For example, a short chain [1,2] is padded to [1,2,0,0,0,0,0,0,0,0]. A bidirectional LSTM network is used, with an input of a 10×64 matrix (sequence length 10, each ID is converted into a 64-dimensional vector through the embedding layer). The hidden layer dimensions of both the forward and backward LSTMs are 64, and the output is a 2×64-dimensional vector (64 dimensions each in both directions). After concatenation, a 128-dimensional function call chain vector is obtained. 3. Semantic entropy vector features: The 6-dimensional normalized vector from step S26 is directly reused to preserve global semantic features.

[0117] 4. Feature similarity score: The feature similarity score is taken from S31, which is the cosine similarity value between the current sample and the most similar category in the attack feature library. It is directly used as the input of 1-dimensional numerical features.

[0118] The intermediate layers of the model employ a feature fusion strategy. Specifically, the AST path vector and function call chain vector are fused through an attention mechanism to obtain a 128-dimensional attention fusion vector. The function call chain vector is obtained by processing the encoded high-risk function call sequence (uniform length 10) through a BiLSTM layer. The attention fusion vector is then concatenated with semantic entropy vector features and feature similarity scores to form a 135-dimensional fusion feature. The features are compressed through a three-layer fully connected network (135→160→80→40) and the ReLU activation function. Specifically, the first fully connected layer (135→160 dimensions) initially extracts higher-order associations from the fusion features; the second fully connected layer (160→80 dimensions) further compresses the feature dimensions, focusing on core malicious features; and the third fully connected layer (80→40 dimensions) finally compresses the features to a low-dimensional feature space, preparing for the output layer. Finally, the 40-dimensional features are mapped to a malicious confidence score of 0~1 using the Sigmoid activation function, quantifying the malicious risk. The closer the value is to 1, the higher the probability of the sample being malicious.

[0119] By comprehensively considering multiple dimensions of features, an accurate malicious confidence score is provided, offering crucial support for decision-making. The malicious confidence score takes into account various aspects of information, enabling a more comprehensive reflection of the potential maliciousness of a file.

[0120] S34: Adaptive threshold adjustment An adaptive threshold adjustment mechanism dynamically adjusts the confidence threshold based on parameters such as the current security level of the detection system environment, user upload frequency, and recent attack trends. This ensures accurate identification of high-risk code and avoids excessive false positives for low-risk files. The specific process is as follows: First, three types of core influencing parameters need to be defined, and quantitative standards and weighting systems need to be established: System environment security level: Every 10 minutes, check whether the permissions of the following two core directories are abnormal: The executable directory permission should be 755. If it changes to 777, it is considered abnormal; the configuration file directory permission should be 644, and the owner should be root / apache. If they do not match, it is considered abnormal. It automatically checks the open status of the following three sensitive ports every 10 minutes using the netstat command: 22 is SSH, opening it unnecessarily will cause an anomaly; 3389 is Remote Desktop, opening it unnecessarily will cause an anomaly; 4444 is a common backdoor port, opening it will cause an anomaly.

[0121] If the core directory permissions are normal and the sensitive ports are not abnormally open, the security level is determined to be high, with a quantified value of 0; if the core directory permissions are abnormal or the sensitive ports are open, the security level is determined to be medium, with a quantified value of 0.1; if the core directory permissions are abnormal and the sensitive ports are open, the security level is determined to be low, with a quantified value of 0.3. 2. User Upload Frequency Anomaly: Based on the user's historical behavior baseline (e.g., ordinary users upload an average of 2 times per day, developer users upload an average of 10 times per day), calculate the deviation rate between the current upload frequency and the baseline (deviation rate = If the deviation rate is ≥200%, the upload anomaly score is recorded as 0.2; if the deviation rate is between 100% and 200%, the upload anomaly score is recorded as 0.1; if the deviation rate is <100%, the upload anomaly score is recorded as 0; user upload frequency is statistically analyzed in real time (sliding window for 1 hour). 3. Recent Attack Trend Intensity: The number of occurrences of various attack types in the attack signature database is updated every 24 hours, and the growth rate is calculated (growth rate = ...). If the growth rate is ≥150%, the attack trend strength is recorded as 0.3; if the growth rate is between 50% and 150%, the attack trend strength is recorded as 0.15; if the growth rate is <50%, the attack trend strength is recorded as 0.

[0122] Furthermore, the current threshold for judging malicious confidence is set at 0.9. The threshold adjustment coefficient is calculated by weighted summation, specifically as follows: Threshold adjustment coefficient = (security level quantification value × 30%) + (upload anomaly degree × 30%) + (attack trend strength × 40%); the final dynamic threshold = current judgment threshold - threshold adjustment coefficient. If the malicious confidence score of the current sample output exceeds the final dynamic threshold, it indicates that the sample has a high probability of being malicious, and the uploaded file is determined to be a malicious file, directly proceeding to step S41.

[0123] For example, when the system detects that "WebShell attacks have increased by 180% in the past 24 hours (trend strength 0.3), a regular user uploaded 8 times in 1 hour (baseline 2 times, deviation rate 300%, anomaly 0.2), and the system environment security level is "low" (0.3), the threshold adjustment coefficient = 0.3×30%+0.2×30%+0.3×40%=0.27, and the final dynamic threshold = 0.9-0.27=0.63, then in step S32, any sample that meets the malicious confidence score ≥0.63 is judged as a malicious file.

[0124] Specifically, the final dynamic threshold is essentially the minimum criterion for determining malicious intent: a lower final dynamic threshold means more samples with lower scores will be judged as malicious, reducing false negatives; a higher final dynamic threshold means only samples with higher scores will be considered malicious, reducing false positives. Therefore, when the security situation is severe, it is necessary to expand the detection range by lowering the threshold to ensure that potential threats are not overlooked.

[0125] S35: Predicting Malicious Behavior.

[0126] If patterns such as concatenation-type functions (e.g., concatenating to generate `eval($code)`), dynamic variable name construction, and string escape combination exist, an alert mechanism will be triggered even if the score is slightly low. The specific process is as follows: First, a high-risk behavior pattern library is built, which includes the covert techniques commonly used by attackers. The core patterns and rules are as follows: 1. High-risk function calls involving string concatenation: Identify scenarios where strings are concatenated and then directly passed to high-risk functions (e.g., eval("sy"+"stem('id')")). The identification rule is "traverse the Binary Expression node in S21 (with the operator +). If the left and right operands are strings / Literal nodes, and the concatenation result is used as the parameter of the high-risk function in S23". 2. Dynamic variable name construction and calling: Identify scenarios where function names are dynamically generated and called through variables (e.g., var funcName = "eval"). The identification rule is "in the CallExpression node of S21, callee is MemberExpression (e.g., window[funcName]), and property is a variable node, with the variable value corresponding to a high-risk function name"; 3. Multi-level encoding escape combination: Identify scenarios where strings are passed to high-risk functions after being encoded in multiple layers. The identification rule is "S24 detects that the string contains two or more encodings, and the encoded content is used as a parameter of the high-risk function".

[0127] After the sample completes the S32 malicious confidence score and the S33 threshold adaptive adjustment, the high-risk behavior pattern library is then traversed. The sample is matched with the patterns in the high-risk behavior pattern library one by one. If any pattern is matched, regardless of whether the malicious confidence is lower than the final dynamic threshold, the high-risk behavior warning of the corresponding behavior is triggered, the uploaded file is determined to be a malicious file, and the process proceeds directly to step S41. For highly covert malicious behavior patterns, early warnings of high-risk behaviors can be issued to enhance the defense capabilities of the detection system. These patterns are often characteristic of advanced attack techniques that traditional detection methods may struggle to identify. However, the malicious behavior prediction engine can detect potential threats in advance based on behavioral characteristics, allowing for timely preventative measures and avoiding damage to the detection system.

[0128] S36: Low-confidence behavior caching mechanism.

[0129] For ambiguous samples with confidence levels close to the final dynamic threshold, they are entered into a "sandbox pool" for further observation of their subsequent behavior, combined with a behavioral sandbox. Accuracy is improved through isolated environment observation and delayed decision-making. This relies on a linkage mechanism between the sandbox environment and dynamic scoring, as detailed below: First, a low-confidence range is defined, whereby the malicious confidence score of sample S33 falls within the range of "final dynamic threshold - 0.1" (i.e., if the final dynamic threshold is 0.8, then the low-confidence range is 0.7-0.8). This sample is then marked as a low-confidence sample. For low-confidence samples, the interception system does not immediately intercept or allow them, but triggers a "dual-track processing": on the one hand, the sample metadata (filename, hash value, uploader) is stored in the "sandbox waiting pool"; on the other hand, the sample is automatically delivered to the isolated sandbox environment. The sandbox needs to simulate a real business execution environment (such as the PHP / JS runtime of a web server, system library version) and be configured with a behavior monitoring module to record key behavioral indicators during sample execution: file operations (such as writing to the / tmp directory, modifying configuration files), network behavior (such as connecting to overseas IPs, sending data to specific ports), system calls (such as the number of times execve is called), and memory operations (such as dynamically loading suspicious code segments). The "sandbox waiting pool" uses Redis caching with a 2-hour expiration time to avoid long-term resource occupation.

[0130] Furthermore, the sandbox observation lasts for 30 minutes, generating a sandbox behavior score. The sandbox behavior score is accumulated from different dimensions and according to different risk levels. The specific scoring dimensions and rules are as follows: 1. File operation dimension: 0.2 points for reading files in sensitive directories each time; 0.15 points for writing files in sensitive directories each time; 0.2 points for deleting files each time; 0.5 points for deleting system files (such as / bin / ls) each time.

[0131] 2. Network behavior dimension: 0.3 points for each connection to an unknown external IP address; 0.5 points for each connection to a known malicious IP address; 0.5 points for each use of abnormal ports (such as 3389, 4444, non-business ports 80 / 443).

[0132] 3. System call dimension: 0.3 points for each process management call; 0.4 points for each command execution call; 0.4 points for each privilege escalation call.

[0133] 4. Memory operation dimension: Loading unknown libraries 0.3 points; Dynamically generating and executing memory code (such as mmap + mprotect + jump execution) 0.5 points; Encryption / obfuscation string decryption behavior in memory 0.6 points.

[0134] During the sandbox operation, the above behaviors are monitored and recorded in real time. For each triggered sandbox behavior score, the corresponding score is accumulated. After the observation period ends, the sandbox behavior score and the malicious confidence score in S32 are weighted and combined to obtain the final score, with the sandbox behavior score accounting for 60% and the malicious confidence score in S32 accounting for 40%.

[0135] If the final score is greater than the final dynamic threshold, the uploaded file is determined to be a malicious file, and the process proceeds directly to step S41; otherwise, it is determined to be normal and allowed to be written to the production environment.

[0136] For samples that are difficult to judge immediately, this step improves the accuracy of the judgment and reduces false positives through further observation and analysis. The sandbox environment provides an isolated execution environment, allowing the behavioral characteristics of the file to be observed and more judgment information to be obtained without affecting the actual detection system, thereby making more accurate decisions.

[0137] S4. Real-time interception and threat signature synchronization; This stage executes attack response actions, generates a structured security fingerprint, and synchronizes it to the global detection system to form a closed-loop protection. Specifically, it includes the following sub-steps:

[0138] S41: Upload behavior interception.

[0139] This step involves determining whether a file is malicious based on the malicious confidence score obtained in step S33 during the file upload process. Specifically, in step S34, the malicious confidence score is checked to see if it exceeds the final dynamic threshold; in step S35, a high-risk behavior warning is triggered; or in step S36, the merged score exceeds the final dynamic threshold. If the file is determined to be malicious, this step blocks its landing in real time. The defense detection system automatically terminates the upload process, blocks file writing operations, and revokes its execution permissions, ensuring that the attack sample cannot be written to the file.

[0140] Intercepting attack samples before they enter the detection system effectively protects the system's security. By promptly blocking the upload process, malicious files can be prevented from being stored on the server, avoiding subsequent access or execution, thereby preventing potential attacks and protecting the detection system's resources and data security.

[0141] When a file upload request is initiated, the detection system first obtains the initial data of the file through streaming processing (the first 2KB is used for fast hash calculation and type identification), and simultaneously triggers the analysis process from S2 to S3. During file transfer, the results of the malicious confidence score in S33, the comparison of the malicious confidence score in S34 to see if it exceeds the final dynamic threshold, the result of whether a high-risk behavior warning is triggered in S35, and the result of whether the merged score in step S36 exceeds the final dynamic threshold are continuously synchronized to the monitoring system: if the malicious confidence score exceeds the final dynamic threshold, or a high-risk behavior warning is triggered in S35, or the merged score in step S36 exceeds the final dynamic threshold, the detection system immediately performs a level-three blocking operation.

[0142] First, at the transport layer, the write channel is closed by calling the operating system's `shutdown` function, sending an HTTP 403 status code to the client, and terminating the TCP connection to prevent further data transmission. Second, for file fragments already written to the temporary directory, forced deletion is performed using the `unlink` system call. Simultaneously, the file descriptor table is traversed, and all associated file handles are closed to prevent processes from holding residual data. Finally, if a file has been partially written to the target path (due to a brief delay caused by concurrency), its permissions are immediately set to 000 (no permissions) using `chmod`, and the `immutable` attribute is added to prevent tampering. A background cleanup thread then completely removes the file within 5 seconds. The entire process uses a distributed lock mechanism to handle multi-threaded upload scenarios, ensuring that the interception operation for the same file is executed uniquely and avoiding interception failures caused by race conditions.

[0143] For malicious files identified in the previous steps, the detection system immediately halts the upload process, blocks the file from being written to the disk, and revokes its execution permissions, ensuring that the file cannot be executed in the detection system. S42: Attack log generation.

[0144] Record detailed information about upload requests, generate corresponding attack logs, and write them to the local log detection system and auditing platform.

[0145] Attack log generation requires integrating all feature data from previous steps to generate a structured log containing an "attack profile." When the local log detection system receives an interception notification from S41, it automatically extracts key information and assembles it according to preset fields, specifically including the following: The basic information includes timestamps, uploader IPs, a list of high-entropy strings extracted in S24, and a semantic entropy vector in S26; the judgment criteria include the malicious confidence score in S33, the final dynamic threshold in S34, and the behavior corresponding to the high-risk behavior warning in S35; the technical details record the location of high-risk functions in the AST, the contamination propagation path in S22, and the high-risk function call chain in S23.

[0146] This information is encapsulated in JSON format and sent to the local log detection system and auditing platform via the syslog protocol. At the same time, it is synchronized to the enterprise-level SIEM platform via a message queue for correlation analysis with logs from devices such as firewalls and WAFs to generate an attack source map.

[0147] Attack logs provide detailed records for subsequent security analysis and auditing, facilitating the tracing and analysis of attack incidents. Detailed attack logs help security teams quickly understand key information such as the time, source, method, and target of an attack, enabling timely countermeasures, patching security vulnerabilities, preventing similar attacks from recurring, and providing evidentiary support for potential legal proceedings.

[0148] S43: Attack fingerprint extraction.

[0149] Attack fingerprint extraction involves condensing the key semantic features of malicious samples identified in previous steps into uniquely identifiable semantic fingerprints, calculating unique fingerprint hashes, and achieving rapid matching of similar attacks for subsequent feature database matching. Specifically, this requires integrating the most distinctive features from S21 to S26, structuring them according to fixed rules, and generating hash values. The specific process is as follows: First, determine the core components of the attack fingerprint and standardize these components: (1) The core path of the AST structure, taken from S21, extracts the shortest path from the root node to the high-risk function call, such as Program→BlockStatement→CallExpression(eval), ignores irrelevant nodes, retains the syntax structure features of the attack to enhance the anti-deformation ability; and converts the AST path into a string separated by "→"; (2) Semantic entropy vector, taken from S26, fully retains the 6-dimensional standardized value; the semantic entropy vector retains 3 decimal places and is serialized into a JSON array; (3) High-risk function call chain, taken from S23, arranged in the execution order, such as atob→eval→system, containing the function name and parameter pollution status; the call chain is converted into a function name separated by "|" + pollution mark string, such as atob[T]|eval[T], where T indicates that the parameter is polluted; (4) High-entropy string features, taken from S24, take the string hash of the first 3 highest entropy values, rather than the original content, to avoid sensitive information leakage; The high-entropy string feature is taken from the first 16 bits of the SHA256 hash.

[0150] The processed elements are concatenated into the original fingerprint string according to the format "AST path | semantic vector | call chain | high entropy feature", and then a 256-bit hash value is calculated using the SHA256 algorithm. The calculated attack fingerprint hash serves as the unique identifier of the malicious sample. The extracted attack fingerprint is associated with the attack type (such as WebShell) recorded in S32 and stored in a local feature database. At the same time, a deduplication mechanism (comparing hash values) is used to prevent duplicate entries into the database.

[0151] Generating unique attack fingerprints facilitates rapid identification and matching of similar attacks. Attack fingerprints accurately describe the key characteristics of attack samples. By calculating unique fingerprint hashes, attack samples can be quickly classified and retrieved, improving the efficiency of threat intelligence processing and providing strong support for attack attribution and attack pattern analysis.

[0152] S44: Deduplication and de-duplication mechanism.

[0153] In the detection system, edge detection units, also known as nodes, are deployed near the user upload entry point. Each node has a unique identifier, node ID. If multiple nodes detect the same fingerprint within a short period, the detection system should automatically aggregate and deduplicate, while simultaneously caching unchanged samples for synchronization. The throttling and deduplication mechanism aims to eliminate feature redundancy in the distributed detection system and improve efficiency through fingerprint aggregation and synchronization control. The specific process is as follows: The detection system constructs an "attack fingerprint deduplication layer" between the global threat protection platform and the nodes of the detection system. This layer relies heavily on a distributed cache (such as a Redis cluster) and a time window counter. When a node at the edge of the detection system generates a new attack fingerprint (output by S43), it first calculates the MD5 hash of the attack fingerprint and uses it as a unique key to query the distributed cache. If the key exists in the cache and has not expired (default 1 hour), it is determined to be a duplicate fingerprint, and synchronization is abandoned. If it does not exist or has expired, the next step of verification is initiated.

[0154] To handle the simultaneous detection of identical attack fingerprints by multiple nodes within a short period, the detection system employs a 5-minute sliding window mechanism: Before synchronizing attack fingerprints, each node sends a "pre-synchronization request" to the central global threat protection platform, containing the attack fingerprint hash and node ID. The central global threat protection platform records the number of times the attack fingerprint is received within the window using a counter. When the number exceeds 5, aggregation is automatically triggered, retaining only the complete attack fingerprint information received the first time. Subsequent requests return an "aggregated" response, and the node no longer resends the fingerprint. Simultaneously, the central global threat protection platform marks the aggregated attack fingerprints as "synchronized" and sets a 12-hour cache, during which it no longer accepts synchronization requests for the same attack fingerprint, reducing the processing pressure of high-frequency, repetitive attack fingerprints.

[0155] For samples whose content remains unchanged (such as the same malicious file being uploaded multiple times), the detection system compares the file hash with the last synchronization record. If the hashes match and the interval is less than 24 hours, "throttling synchronization" is triggered, updating only the upload time and source IP, without repeatedly pushing complete features. For example, if the attack fingerprint hash "a1b2c3" of a malicious script is detected by 3 nodes within 5 minutes, the first node successfully synchronizes, and the pre-synchronization requests of the latter two nodes are marked as "aggregated" by the central platform. Ultimately, only one complete record is stored in the global database, avoiding two redundant transmissions.

[0156] Reducing the transmission and processing of redundant data improves the efficiency of the detection system and avoids resource waste. In large-scale detection systems, multiple nodes may detect the same attack samples within a short period of time. Without deduplication, this leads to a large amount of repetitive data transmission and processing, consuming valuable network bandwidth and computing resources. By using synchronous throttling and redundancy deduplication mechanisms, resource utilization can be optimized, improving the overall performance of the detection system.

[0157] S45: Feature synchronization and policy distribution.

[0158] The newly generated attack fingerprints are synchronized to the global threat protection platform in real time and pushed to other nodes connected to the detection system to achieve cross-detection system sharing and joint prevention and control.

[0159] Feature synchronization and policy distribution are crucial for building a real-time and reliable threat intelligence sharing mechanism. The specific process is as follows: After S43 extracts an attack fingerprint, it encapsulates the attack fingerprint, attack type, and timestamp obtained from the attack log into a standardized threat intelligence entry, and sends it to the "new_fingerprints" topic in the message queue via an encrypted channel. The global threat protection platform, acting as a consumer, subscribes to this topic and, upon receiving it, writes it into the distributed signature database according to the attack type and timestamp index.

[0160] The distributed signature database is a distributed storage system in the detection system used for centralized storage, indexing, and management of attack fingerprints. It establishes a secondary index based on attack type and timestamp. The core data stored is the attack fingerprint hash generated by S43, and the associated data includes attack type and generation timestamp.

[0161] The global threat protection platform simultaneously initiates policy distribution, pushing incremental update notifications to nodes of all connected detection systems. Upon receiving the notification, nodes retrieve new attack fingerprints via HTTPS requests and update their local signature databases (using an LRU caching mechanism to retain active attack fingerprints from the last three months). To ensure consistency, each attack fingerprint is accompanied by a timestamp and attack fingerprint hash. After updating, nodes must return a confirmation message. The platform checks the node synchronization status hourly, retrying or issuing alerts for nodes that have not completed synchronization. This enables cross-detection system threat intelligence sharing, enhancing overall protection capabilities. By timely synchronizing attack fingerprints, nodes in each detection system can update their own threat intelligence databases promptly, thereby enabling rapid response to new attacks and forming a collaborative defense system to effectively resist large-scale attack activities.

[0162] The present invention has been described in the above-described embodiments; however, these embodiments are merely examples for implementing the present invention. It must be noted that the disclosed embodiments do not limit the scope of the present invention. Conversely, any modifications and refinements made without departing from the spirit and scope of the present invention are within the scope of patent protection of the present invention.

Claims

1. A method for intercepting file upload attacks based on semantic entropy enhancement, characterized in that, Includes the following steps: S1. File format parsing and content extraction; specifically including the following sub-steps: S11: File type identification and detection; After the uploaded file is connected to the detection system, MIME type detection, file extension recognition, and magic number feature analysis are performed on the file to determine whether the uploaded file is a potentially executable script file; only if the uploaded file is a potentially executable script file will further judgment be made. S12: Identification and processing of nested content; Further, hidden scripts in nested compressed packages or rich text documents are identified and processed. Dedicated parsing tools are loaded for different types to read the internal file list and content, and the internal files are traversed to determine whether they are nestable carrier files. If the file is a nestable carrier file, then the extraction process is executed recursively using that file as the new carrier. Before recursive processing, the MD5 hash value is calculated for each extracted nestable carrier file; if the hash value already exists in the list, further extraction stops and it is determined to be "circular nesting"; if it does not exist, the hash value is added to the list and processing continues. If it is not a nestable carrier file, the content is directly extracted to a temporary directory, and the type of the extracted file is re-identified for all non-nestable carrier files extracted to the temporary directory. S13: Syntax cleaning and optimization; For uploaded objects identified as potentially executable script files, the detection system performs syntax cleaning operations, including removing redundant comments, whitespace characters, and indentation formatting, and stripping away non-functional information through syntax cleaning; S14: Encoding standard processing; First, the original file encoding is identified by the BOM header and character distribution characteristics; then, redundant BOM headers are removed, and the file is uniformly converted to UTF-8 encoding. S15: Construct intermediate representation; The processed code is converted into a standard intermediate representation, preserving the logical semantics but stripping away the syntactic shell, providing a consistent input for abstract syntactic structure analysis. Intermediate representation (IR) is the process of converting source code into a well-structured, syntax-neutral code format, which facilitates subsequent static or dynamic analysis. The intermediate representation is constructed by loading the corresponding language rules based on the code type, and the core logical elements, including variable definitions, function calls, and control statements, are extracted through regular expressions and text traversal. The process involves removing language-specific prefixes from variables and marking their origins, recording the names and parameter origins of function calls, and specifying conditions, execution blocks, and nesting relationships in control statements. These core logical elements are then converted into a unified JSON format of "type-attribute-relationship," with language-specific syntax markers added, ultimately generating an intermediate representation that strips away syntactic differences while preserving the logical essence. S2. Abstract syntax tree construction and semantic entropy calculation; specifically including the following sub-steps: S21: Construct an abstract syntax tree; An abstract syntax tree is generated based on an intermediate representation, capturing all structural elements in the code and realizing the restoration of core logical elements into a structured syntax tree; Abstract Syntax Tree (AST) is a tree-like data structure that represents code structure and is used to analyze control flow and dependencies. First, define the core node type of the AST according to the code type, and then map the IR elements to the corresponding AST nodes according to the rules, as follows: Based on the IR generated by S15, different types of IR elements are mapped to corresponding AST nodes, and node attributes are filled through the "attributes" of the IR; expressions in the IR are converted into nested AST expression nodes; according to the "parent structure" and "execution block" relationship in the IR, an AST tree hierarchy is constructed in positional order, so that IR elements without parent structure become child nodes of the Program root node, and the execution block elements of the control statement form BlockStatement nodes and are associated with the corresponding control nodes, generating an AST of complete capture code structure elements; S22: Contamination chain tracing; Analyze whether user-controllable input variables flow into dangerous functions, construct the complete propagation path of variable contamination, and determine whether there is a safety risk; first, define the contamination source and contamination variable and preset a list of high-risk functions, record the variable contamination status and source by constructing a contamination status table, and construct a contamination path graph to track the propagation relationship; Then, the AST nodes are traversed, the pollution status is updated according to the execution order, and finally, it is checked whether the pollution variables flow into the dangerous function to generate a visual path graph. The pollution source is a variable that can be controlled and input by the user, and in the AST, it is represented as a variable whose initialization source is user input; the pollution variable is a variable that is directly or indirectly assigned a value by the pollution source. S23: High-risk function analysis; By recursively traversing the CallExpression node in the AST, the function name, call location, parameter list, parent node type, and nesting depth are extracted to construct a function call record table; Based on this, the number and density of calls to dangerous functions are statistically analyzed, and the context safety is analyzed in conjunction with the pollution status table of S22. The density refers to the ratio of the number of dangerous function calls to the total number of lines of code; S24: High-entropy string recognition; Extract static strings, variable values, and concatenation chains from the code, and calculate their Shannon entropy values. In addition to Shannon entropy, compression ratio and special encoding patterns are introduced as auxiliary indicators. The three together constitute the judgment conditions. If the conditions are met, the string is marked as a suspicious node. After calculating the Shannon entropy value for each string, the arithmetic mean of the Shannon entropy values ​​of all strings is calculated to obtain the average entropy value of the string. S25: Control flow complexity modeling; For samples containing a large number of jump statements and deeply nested structures, the cyclomatic complexity algorithm and AST traversal technique are used to calculate their logical complexity score; First, recursively extract control statement related nodes from the AST, identify decision nodes that can generate branches, and calculate the basic score of cyclomatic complexity according to "cyclomatic complexity = total number of decision nodes + 1". Then, taking into account the maximum nesting level of the control statement nodes, the result is corrected by "Logical Complexity Score = Cyclomatic Complexity Base Score × 0.7 + Nesting Depth × 0.3"; S26: Semantic entropy vector generation; Six key indicators were selected from the features extracted from S22 to S25: the propagation length of the contaminated variable in S22; the number of high-risk function calls in S23; the number of suspicious nodes and the average entropy value of the string in S24; and the logical complexity score and nesting depth in S25. After standardizing each indicator, they are combined in a fixed order to form a 6-dimensional vector, which ultimately forms a structured semantic entropy vector. S3. Dynamic scoring and decision-making; specifically including the following sub-steps: S31: Business whitelist awareness mechanism; Some business detection systems may use custom, highly complex scripts. You can set "semantic whitelist rules" to avoid false positives. If a high-risk function from the "High-Risk Function List" is called, the high-risk function parameter is confirmed to be a non-polluted variable using the "Pollution Status Table" in S22. The function is verified to be called only within the specified business function using the "AST Parent Node Type" in S21. The number of calls is ensured to be ≤5 using the "Function Call Record Table" in S23. The high-risk function call is considered legal only if the above conditions are met: the function is in the allowed list, the parameter is non-polluted, the context is the specified business function, and the number of calls does not exceed 5. In addition, it must be ensured that the propagation length of the polluted variable in the "Pollution Path Graph" in S22 is 0, and the count of the "Suspicious Nodes" in S24 is ≤1. Otherwise, the current sample does not meet the semantic whitelist rules. The specified business functions are customized based on business requirements. Specifically, the business operations or development team needs to provide a list containing "function name, function description, allowed high-risk functions, and parameter source" according to the function. Then, extract the FunctionDeclaration node of the historical normal business script from the S21 AST, count the functions with a frequency of ≥90%, and after manual review and confirmation, enter the function name into the specified business functions of the semantic whitelist rule. If a sample meets all the above conditions, it is marked as a "whitelist sample", and is allowed to pass directly without subsequent testing. S32: Feature similarity comparison; Extract the semantic entropy vector of the current sample output by S26, traverse the average vector of the typical attack features that have been modeled in the attack sample library, calculate the cosine similarity between the semantic entropy vector and the average vector one by one, and take the highest similarity value as the feature similarity score, and record the attack type corresponding to the current sample. S33: Maliciousness Confidence Score; Using a neural network model, the system comprehensively evaluates the AST path, function call chain, semantic entropy vector, and feature similarity scoring dimension to output a malicious confidence score; the closer the malicious confidence score is to 1, the higher the probability of the sample being malicious. S34: Adaptive threshold adjustment; Three quantitative parameters are defined: system environment security level, abnormality of user upload frequency, and intensity of recent attack trends. The adjustment value is calculated by using the threshold adjustment coefficient = the sum of the quantitative values ​​of each parameter × the weights. The final dynamic threshold is obtained by subtracting the threshold adjustment coefficient from the current judgment threshold of the malicious confidence score. The current judgment threshold is initialized to 0.

9. If the malicious confidence score of the current sample output exceeds the final dynamic threshold, it indicates that the sample has a high probability of being malicious, and the uploaded file is determined to be a malicious file, and the process proceeds directly to step S41. S35: Prediction of Malicious Behavior; Malicious behavior prediction is a supplementary screening for covert attack patterns. Even if the S33's malicious confidence score does not exceed the final dynamic threshold, potential threats can still be captured through behavioral characteristics. By building a high-risk behavior pattern library, it includes the covert technical characteristics commonly used by attackers. After the sample completes the calculation of the malicious confidence score in S32 and the adaptive adjustment of the threshold in S33, the high-risk behavior pattern library is traversed. The sample is matched with the pattern in the high-risk behavior pattern library one by one. If any pattern is matched, regardless of whether the malicious confidence score is lower than the final dynamic threshold, the high-risk behavior warning of the corresponding behavior is triggered, the uploaded file is determined to be a malicious file, and the process proceeds directly to step S41. S36: Low-confidence behavior caching mechanism; For samples with ambiguous scores, that is, samples whose malicious confidence scores fall within the range of -0.1 of the final dynamic threshold, they are marked as low-confidence samples and stored in the "sandbox pending judgment pool". The subsequent behavior of the samples is observed in the sandbox to determine whether to block the upload behavior. S4. Real-time interception and threat signature synchronization; specifically including the following sub-steps: S41: Upload behavior interception; If the previous steps determine that the current sample is malicious, this step will intercept the file upload process. Interception does not wait for the file to be fully uploaded; instead, it receives the results of the previous analysis synchronously during the streaming process, and immediately blocks the upload once the triggering conditions are met. S42: Attack log generation; Upon receiving the interception notification from S41, record the detailed information of the upload request, generate the corresponding attack log, and write it to the local log detection system and auditing platform; Attack log generation integrates all feature data from previous steps to generate structured logs containing "attack profiles"; The basic information includes timestamp, uploader's IP, S24 list of high-entropy strings, and S26 semantic entropy vector; the judgment criteria include S33 score, S34 dynamic threshold, and S35 warning behavior; the technical details record the location of high-risk functions in AST, S22 contamination propagation path, and S23 high-risk call chain; this information is encapsulated in JSON format and sent to the local log system and auditing platform via the syslog protocol. S43: Attack fingerprint extraction; The semantic fingerprint is composed of features such as the AST structure path, entropy vector combination, and high-risk call chain of the malicious sample. A unique fingerprint hash is calculated for subsequent feature library matching. Extract the shortest path from the root node to the high-risk function call in S21, obtain the chain of high-risk function calls arranged in execution order from S23, extract the first 16 bits of the SHA256 hash of the top 3 highest entropy strings from S24, and fully reuse the semantic entropy vector of S26. These elements are then standardized to obtain the original string, and a 256-bit unique hash is generated using the SHA256 algorithm as the attack fingerprint. The attack fingerprint is then associated with the attack type recorded in S32 and stored in the local feature database. S44: Deduplication and de-duplication mechanism; In the detection system, edge detection units, also known as nodes, are deployed near the user upload entry point. Each node has a unique identifier, Node ID. After a node generates an S43 attack fingerprint, it first calculates the MD5 hash of the attack fingerprint as a unique key to query the cache. The cache expires in 1 hour by default. If an expired key exists in the cache, it is considered a duplicate and synchronization is abandoned. If the cache is not hit, a pre-synchronization request containing the attack fingerprint hash and node ID is sent to the global platform. A 5-minute sliding window is used for counting. If the same fingerprint is received more than 5 times, only the first one is retained and marked as "aggregated". In addition, samples with the same file hash within 24 hours trigger throttling synchronization, which only updates the upload time and source IP, and does not push complete features repeatedly. S45: Feature synchronization and policy distribution; The attack fingerprint, attack type, and timestamp from the attack log are encapsulated into standardized intelligence entries and sent to the message queue via an encrypted channel. The global threat protection platform receives the entries and writes them into the distributed signature database according to the attack type and timestamp index. Meanwhile, the global threat protection platform pushes incremental update notifications to all connected detection nodes. The nodes pull attack fingerprints via HTTPS and update their local signature database using an LRU caching mechanism.

2. The file upload attack interception method based on semantic entropy enhancement according to claim 1, characterized in that, In step S15, the extraction and source marking of variable definitions specifically include: using regular expressions to match variable definition statements, removing language-specific prefixes, and unifying variable names to plain names; analyzing the assignment content and marking the source type: marking "user input" and retaining the original format when assigning a user input value, marking "constant" when assigning a fixed value / string value, and marking "dependent function f" when assigning a function return value; the parameter association processing of function calls specifically includes using regular expressions to match function call statements to extract function names, parsing the parameters within parentheses and associating them with the variable element library; marking the source of parameters; uniformly omitting language-specific syntax symbols such as parentheses and semicolons, and recording them in the format of "function call: [function name], parameters: [parameter list and source]".

3. The file upload attack interception method based on semantic entropy enhancement according to claim 1, characterized in that, In step S26, the standardization specifically refers to using the min-max normalization algorithm to set the maximum and minimum values ​​of each indicator based on a reasonable range of historical statistics of the sample, and mapping all indicators to the [0,1] interval according to the formula "standardized value = (original value - minimum value) / (maximum value - minimum value)" to eliminate the dimensional differences of different indicators.

4. The file upload attack interception method based on semantic entropy enhancement according to claim 1, characterized in that, In step S33, the following four types of input features are processed by a multimodal feature fusion neural network model: high-risk function call paths are extracted from the AST in S21, and each node type in the serialized string is mapped to a 128-dimensional AST vector by a pre-trained Word2Vec model; high-risk function call chains are selected from S23, encoded into sequences, and a 128-dimensional high-risk function call chain vector is generated; the 6-dimensional semantic entropy vector in S26 and the feature similarity score in S32 are directly reused; subsequently, the AST vector and the high-risk function call chain vector are fused into a 128-dimensional vector through an attention mechanism, and then concatenated with the semantic entropy vector and the feature similarity score to form a 135-dimensional fused feature. This feature is compressed through a three-layer fully connected network and ReLU activation, and finally outputs a malicious confidence score of 0 to 1 through the Sigmoid function.

5. The file upload attack interception method based on semantic entropy enhancement according to claim 1, characterized in that, In step S34, the system environment security level is obtained by checking the core directory permissions and sensitive port openness every 10 minutes. Core directory permissions include executable directory and configuration file directory permissions, which should be 755 and 644 respectively; otherwise, an anomaly is determined. Sensitive ports 22, 3389, and 4444 being open is considered abnormally open. If there are no abnormalities in core directory permissions and no abnormally open sensitive ports, the system environment security level quantification value is 0; if only one is abnormal, the system environment security level quantification value is 0.1; if both are abnormal, the system environment security level quantification value is 0.

3. The user upload frequency anomaly is calculated based on the user's historical behavior baseline, by determining the deviation rate between the current upload frequency and the baseline. If the deviation rate is ≥200%, the upload anomaly score is recorded as 0.2; if the deviation rate is between 100% and 200%, the upload anomaly score is recorded as 0.

1. If the deviation rate is less than 100%, the upload anomaly is recorded as 0; the recent attack trend strength is calculated by statistically updating the number of occurrences of various types of attacks in the attack feature database every 24 hours, and then calculating the growth rate = If the growth rate is ≥150%, the attack trend strength is recorded as 0.3; If the growth rate is between 50% and 150%, the attack trend strength is recorded as 0.15; if the growth rate is less than 50%, the attack trend strength is recorded as 0. The threshold adjustment coefficient is calculated by weighted summation, specifically as follows: Threshold adjustment coefficient = security level quantification value × 30% + upload anomaly degree × 30% + attack trend strength × 40%; final dynamic threshold = current judgment threshold - threshold adjustment coefficient.

6. The file upload attack interception method based on semantic entropy enhancement according to claim 1, characterized in that, In step S35, the high-risk behavior pattern library specifically includes three types of rules: identifying spliced ​​high-risk function calls through the BinaryExpression node in the AST of S21, identifying dynamic variable name construction calls through the MemberExpression node in the AST, and combining the string detected in S24 containing two or more encodings and the encoded content as high-risk function parameters.

7. The file upload attack interception method based on semantic entropy enhancement according to claim 1, characterized in that, In step S36, for low-confidence samples, the sandbox simulates the real business environment and monitors four behavioral dimensions: file operations, network behavior, system calls, and memory operations. The sandbox behavior score is accumulated according to preset rules. The final score is obtained by weighting and merging the sandbox behavior score (60%) with the malicious confidence score (40%). If the final score is greater than the final dynamic threshold, the uploaded file is determined to be a malicious file, and the process proceeds directly to step S41. Otherwise, it is considered normal and can be written to the production environment.

8. The file upload attack interception method based on semantic entropy enhancement according to claim 1, characterized in that, In step S43, the standardization specifically involves: separating the AST path with "→", serializing the semantic vector with 3 decimal places, concatenating the function name and pollution marker in the call chain with "|", and then concatenating them into the original string according to the format "AST path|semantic vector|call chain|high entropy feature".

9. The file upload attack interception method based on semantic entropy enhancement according to claim 1, characterized in that, In step S45, the distributed signature database is a distributed storage system in the detection system used for centralized storage, indexing and management of attack fingerprints. A secondary index is established according to the attack type and timestamp. The core data stored is the attack fingerprint hash generated in S43, and the associated data includes the attack type and the generation timestamp. After the node pulls the new attack fingerprint to update the local signature database, it returns confirmation. The global threat protection platform checks the synchronization status every hour and retryes or alarms for nodes that have not completed the process.

Images