SQL injection and storage type XSS detection defense system and method
By adding multi-level identifiers to SQL statements and pre-computing computational expressions, the problem of insufficient detection of complex SQL statements in existing technologies is solved. This enables accurate detection and defense against SQL injection and stored XSS, improving the accuracy and consistency of detection, and is suitable for synchronous protection in cross-layer attack scenarios.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-08
- Publication Date
- 2026-04-03
AI Technical Summary
Existing technologies have insufficient detection capabilities when dealing with SQL injection and stored XSS attacks in complex SQL statements. In particular, they cannot accurately identify potential attacks when faced with arithmetic expressions and function calls, and lack a joint analysis mechanism, resulting in high false positive and false negative rates.
By combining static analysis with dynamic detection, and adding multiple layers of identifiers (header identifier HT, variable identifier VT, and operation identifier AT) to the source code, the SQL statement is structurally parsed and the operation expression is pre-calculated, thereby identifying and defending against SQL injection and stored XSS attacks caused by operation expressions.
It achieves accurate detection and defense against arithmetic or functional expressions in SQL statements, improving detection accuracy and reducing false positive rate. It can establish semantic mapping at the source code level and maintain consistency verification at runtime. It integrates unified detection rules for SQL injection and stored XSS, and achieves synchronous protection for cross-layer attack scenarios.
Smart Images
Figure CN121786828A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of web application security technology, and in particular to a SQL injection and stored XSS detection and defense system and method. Background Technology
[0002] Structured Query Language (SQL) and Cross-Site Scripting (XSS) are two major threats that have long existed in the field of web application security. According to statistics continuously released by the Common Weakness Enumeration (CWE) and the Open Web Application Security Project (OWASP), SQL injection and XSS vulnerabilities consistently rank at the top of the list of high-risk web security threats, becoming the main root causes of user information leaks, system intrusions, and data corruption. SQL injection attacks inject malicious commands into input parameters, causing the database to execute queries constructed by the attacker during parsing, thereby achieving the purpose of illegally accessing, modifying, or deleting database content. XSS attacks, on the other hand, inject executable scripts into web page content, causing the browser to execute malicious code when loading the page, resulting in serious consequences such as user privacy data leaks, session hijacking, or phishing redirects.
[0003] Traditional methods to combat SQL injection primarily include secure coding practices (such as using prepared statements, parameter binding mechanisms, or ORM frameworks), static source code auditing (using taint propagation analysis, data flow analysis, or regular expression matching to detect potential injection points), runtime detection based on proxies or database interception, and perimeter defense layers such as Web Application Firewalls (WAF), Intrusion Detection Systems (IDS), and Intrusion Prevention Systems (IPS). These methods are effective in dealing with typical first-order injection scenarios, but they still have significant shortcomings in complex semantic scenarios. On the one hand, static analysis can only detect based on source code text or abstract syntactic structures, and cannot simulate the actual semantic execution process of a program at runtime. It lacks the ability to accurately judge complex SQL statements involving multi-level function calls, dynamic concatenation, type conversion, and arithmetic operations. On the other hand, dynamic interception and rule-matching defenses rely on preset keywords or feature patterns, and their detection capabilities are insufficient when facing multiple encodings, nested functions, and semantic obfuscation, making them prone to bypassing or misjudgment. Similarly, XSS attacks, as a security issue at the front-end script level, are also showing a continuous trend of increasing complexity in modern web architectures. XSS is generally classified into three types: reflected, stored, and DOM-based. Among them, stored XSS is the most serious. Its typical attack path is as follows: attackers inject malicious scripts into the backend database through forms, comments, or APIs. After the malicious content is persistently stored, it is displayed as normal data on the front end during the page rendering stage, thus automatically executing when the user visits. Stored XSS is often closely related to SQL injection. Attackers can trigger database writes by inserting input values containing script tags, event attributes, or bypassed encoding, and then indirectly display the data through page templates or API calls, thus achieving a cross-stage attack chain of "write—store—display—execution".
[0004] However, in today's web systems, the structure of SQL statements is becoming increasingly complex, with many statements containing arithmetic expressions such as pagination, aggregation, weighted calculations, statistical analysis, string concatenation, and function calls. Attackers can exploit the evaluation characteristics of these expressions to embed malicious payloads into arithmetic operators or function parameters. For example, they can construct statements like `id=3+'1=1'`, `WHERE name=CONCAT(user,'admin')`, and `score=(base+delta*factor)`, causing the database to evaluate the expressions before execution and form the actual semantics. This bypasses defense mechanisms based solely on string matching, keyword filtering, or syntax keyword detection. Such attack methods not only evade conventional SQL injection detection but can also embed encoded or concatenated malicious scripts during the database write phase, triggering stored XSS in subsequent page echoes. Existing static analysis methods lack the ability to analyze computational semantics, making it impossible to accurately reconstruct the actual execution logic of arithmetic expressions or function calls in SQL statements, resulting in incomplete identification of potential attack locations. Dynamic detection, without an expression pre-execution mechanism, struggles to ensure semantic consistency between the detection and database execution phases, often failing to detect covert injection or script execution risks caused by expression computation. As for rule-based protection measures such as WAF and IDS / IPS, their maintenance costs are extremely high when dealing with complex encoding, cross-layer data flows, and polymorphic semantics, and their detection capabilities for new and hybrid attack methods are limited. Furthermore, in traditional security strategies, SQL injection and XSS attacks are typically handled by separate detection systems, lacking a joint analysis mechanism. This means that when attack payloads are written to the database via SQL and displayed on the front end, the defense system often fails to form a unified response, creating a gap in protection.
[0005] Existing patent CN113901449A, "A Second-Order SQL Injection Defense and Detection Method Based on Static and Dynamic Execution," proposes a detection method that adds identifiers during the static analysis phase and analyzes these identifiers in the dynamic execution module to identify potential injection points. However, this method only targets SQL injection and does not involve static AST analysis or pre-computation mechanisms for computational expressions, thus it cannot detect injections caused by function calls and arithmetic expressions.
[0006] Therefore, existing technologies have significant gaps in addressing SQL injection and stored XSS issues caused by arithmetic expressions. Summary of the Invention
[0007] The technical problem to be solved by this invention is to provide a SQL injection and stored XSS detection and defense system and method. It is a SQL injection and stored XSS detection and defense system based on the analysis of SQL statement operation expressions. By combining static analysis with dynamic detection and defense, it can accurately detect and defend against SQL statements containing arithmetic or function operation expressions, thereby improving detection accuracy and reducing false alarm rate.
[0008] In a first aspect, embodiments of the present invention provide a method for detecting and defending against SQL injection and stored XSS, comprising the following steps: Step S1, Static Analysis: Scan the web application source code, locate the SQL statements in the source code, identify and add the header identifier HT, variable identifier VT, and operation identifier AT in the SQL statements that participate in arithmetic or functional operations; Step S2, Dynamic Detection and Defense: Parse the identifiers added to the SQL statement, perform pre-computation processing on the arithmetic expression with the arithmetic identifier AT, and identify SQL injection and stored XSS attacks caused by the arithmetic expression before the SQL statement reaches the database; when an attack is detected, defend against malicious characters by character escaping or input truncation. Step S3: After the defense is completed, remove the identifiers in the SQL, restore the standard SQL statement, and submit it to the database for execution.
[0009] As one possible implementation, step S1 specifically includes the following steps: Step S11: Scan the Web application source code and locate the SQL statements in the source code by parsing the Web application source code Abstract Syntax Tree (AST); Step S12: Extract variables from the SQL statement based on the Abstract Syntax Tree (AST), and determine the variable source identifier using user input characteristics, Session / Cookie sources, and database readback information. ψ ; Step S13: Using preset plaintext θ and variable source identifier ψ and file location FL Generate the header identifier HT of the SQL statement and add it to the SQL statement; Step S14: Using the preset plaintext θ and private key pKey Variable identifiers are generated through a hash algorithm and an XOR operation. VT and variable identifier VT Add to both sides of the variable; Step S15: Obtain the SQL statement structure by parsing the SQL statement's abstract syntax tree (SQL-AST), locate the expressions in the SQL statement that participate in arithmetic or function operations, identify the expression positions and add operation identifiers (AT) to them for pre-computation in the dynamic phase.
[0010] As one possible implementation, the variable source identifier ψ in step S12 may take the following values: ψ =0 indicates a constant; ψ =1 indicates user input; ψ =2 indicates non-user input.
[0011] As one possible implementation, the formula for the header identifier HT of the SQL statement in step S13 is as follows: HT = [exist_FL_ψ1_ψ2 ...ψn_θ].
[0012] As one possible implementation, the variable identifier in the SQL statement in step S14 VT The formula is as follows: VT = MD5(θ) ⊕ pKey .
[0013] As one possible implementation, the SQL statement's operation identifier AT formula in step S15 is as follows: AT = [Arith_pKey_Arith].
[0014] As one possible implementation, the specific steps of step S2 are as follows: Step S21: Intercept SQL statements containing identifiers through a proxy, parse and extract the header identifier HT, variable identifier VT, operation identifier AT, and variable source identifier from the SQL statement. ψ Information in the middle; Step S22: Identify the operation expression part according to the operation identifier AT, perform pre-calculation operations on it, including arithmetic calculation, string concatenation and function evaluation, and replace the original expression with the calculation result; Step S23: Perform SQL injection and XSS detection on the replaced SQL statement; Step S24: When an attack is detected, execute the corresponding defense based on the variable type; As one possible implementation, in step S23, it is determined whether there are malicious XSS scripts and malicious SQL statements in the variables; if there are malicious XSS scripts, it is determined whether the SQL statement type is INSERT or UPDATE. If so, it is a stored XSS attack, and then the input value is subjected to four types of XSS detection based on event type, tag type, encoding type and keyword type.
[0015] As one possible implementation, in step S24, when the input is detected to contain malicious characters used for SQL injection, defense operations are performed according to the variable type: if it is a character variable, character escaping defense is used; if it is a numeric variable, truncation defense is used; finally, the identifier is removed and the execution of a safe SQL statement is restored; when the input is detected to contain malicious characters used for XSS, it is first determined whether the input appears in encoded form; if it is encoded, it is first uniformly decoded to restore the original payload, and then blocked based on the keyword; if it is not encoded, it is directly blocked based on the keyword.
[0016] Secondly, an embodiment of the present invention provides an SQL injection and stored XSS detection and defense system, comprising a static analysis module and a dynamic detection and defense module; the static analysis module is used to scan the source code of a web application, locate SQL statements in the source code, identify and add header identifiers HT, variable identifiers VT, and operation identifiers in arithmetic or functional expressions in the SQL statements. AT The dynamic detection and defense module is deployed between the web application and the database. It is used to parse the identifiers added to the SQL statement in the static analysis module, perform pre-calculation processing on the operation expression with operation identifier AT, and identify SQL injection and stored XSS attacks caused by operation expression before the SQL statement reaches the database. When an attack is detected, malicious characters are defended by character escaping or input truncation.
[0017] The technological advancements achieved by this invention due to the adoption of the above technical solutions are as follows: 1. This invention achieves precise analysis and monitoring of arithmetic or functional expressions in SQL statements through a detection method combining static identification and dynamic pre-computation. It effectively identifies potential injection points, overcoming the shortcomings of traditional methods that rely solely on keyword matching or regular expression rules and cannot perceive the semantics of operations. This method not only establishes a complete semantic mapping at the source code level but also performs synchronous verification during runtime in conjunction with the actual evaluation process, ensuring a high degree of consistency between the detection process and the database execution logic. This fundamentally solves the problem of false positives and false negatives caused by semantic inconsistencies. 2. The multi-layered identifier system introduced in this invention (including header identifier HT, variable identifier VT, and operation identifier AT) forms a unified SQL semantic tracing framework. The HT identifier allows for precise location of the context and type of SQL statements; the VT identifier allows for tracing the true source and dependencies of variables; and the AT identifier allows for capturing and defining the boundaries of operational expressions, thereby achieving end-to-end traceability and verifiability from the statement layer, variable layer, to the operation layer. The establishment of this system enables the system not only to detect potential vulnerabilities but also to provide semantic-level evidence support in attack tracing and behavior auditing. 3. In the dynamic phase, this invention uses a proxy mechanism to pre-calculate and reconstruct the operational expressions, ensuring complete alignment between the detection logic and the actual execution semantics of the database. During pre-execution, the system accurately reconstructs the calculation results, function return values, and concatenation logic, guaranteeing the rigor and consistency of the detection judgment. Compared to traditional string-rule-based detection methods, this invention significantly improves the semantic accuracy and context awareness of the detection, thereby significantly enhancing the accuracy and robustness of vulnerability detection. 4. This invention integrates unified detection rules for SQL injection and stored XSS within its detection framework. The system, within the same security engine, can identify logical injection risks at the database layer and detect script execution vulnerabilities during the front-end display phase, achieving a joint defense mode of "detection upon writing and defense before execution." This mode is particularly suitable for cross-layer attack scenarios, effectively preventing stored XSS attacks triggered during the display phase after user input is persisted in the database, thus achieving simultaneous protection for SQL security and front-end security. Attached Figure Description
[0018] Figure 1 This is a schematic diagram of the overall system structure and process of the present invention; Figure 2 This is a schematic diagram of the operation of the static analysis module of the present invention; Figure 3 This is a flowchart of the dynamic detection and defense module of the present invention; Figure 4 This is a flowchart of the computation pre-execution mechanism of the present invention. Detailed Implementation
[0019] The present invention will be further described in detail below with reference to embodiments: like Figure 1 As shown, a SQL injection and stored XSS detection and defense system includes a static analysis module and a dynamic detection and defense module. The static analysis module is located at the source code level and is used to scan the source code of a web application, locate SQL statements in the source code, identify and add header identifiers HT, variable identifiers VT, and operation identifiers in arithmetic or functional expressions in the SQL statements. AT The dynamic detection and defense module is deployed between the web application and the database. It is used to parse the identifiers added to the SQL statement in the static analysis module, perform pre-calculation processing on the operation expression with operation identifier AT, and identify SQL injection and stored XSS attacks caused by operation expression before the SQL statement reaches the database. When an attack is detected, malicious characters are defended by character escaping or input truncation.
[0020] A method for detecting and defending against SQL injection and stored XSS using the above system includes the following steps: Step S1, as follows Figure 2 As shown, static analysis involves scanning the web application source code, locating SQL statements within the source code, identifying and adding header identifiers HT, variable identifiers VT, and operation identifiers AT in the SQL statements that participate in arithmetic or functional operations. Specifically, the steps include the following: Step S11: Scan the web application source code and analyze it according to the abstract syntax tree (API) of the web application source code. AST Identify SQL execution functions (e.g.) mysqli_query , PDO::query (etc.), analyze the statement structure, and locate the SQL statements in the source code; Step S12: Based on the abstract syntax tree ( AST Extract variables from the SQL statement and use user input characteristics, Session / Cookie sources, and database readback information to determine the variable source identifiers. ψ, Where ψ=0 represents a constant, ψ =1 indicates a user-input value (such as $_GET, $_POST, etc.). ψ =2 indicates a non-user input value (such as Session, Cookie, or database readback value), and records the correspondence between variables and statement types to distinguish the risk of first-order injection from second-order injection. Step S13: Using preset plaintext θ and variable source identifier ψ and file location FL Generate a header identifier HT for the SQL statement and add it to the SQL statement to achieve traceable statement embedding. The formula for the SQL statement header identifier HT is: HT = [exist_FL_ψ1_ψ2 ...ψn_θ] (1); Step S14: Using the preset plaintext θ and private key pKey Variable identifiers are generated through a hash algorithm and an XOR operation. VT and variable identifier VT Adding it to both sides of the variable and hashing and obfuscating it with the preset plaintext and private key pKey can ensure the uniqueness and anti-counterfeiting of the identifier; Variable identifier VT The formula is as follows: VT = MD5 (θ) ⊕ pKey (2); Step S15: Obtain the SQL statement structure by parsing the SQL statement's abstract syntax tree (SQL-AST). Distinguish between ordinary string concatenation and arithmetic or function operation expressions by traversing function call nodes, string encapsulation nodes, and binary operation nodes. Locate the expressions involved in arithmetic or function operations within the SQL statement, identify their positions, and analyze the arithmetic operators (+, -, *, / ) and function calls (...) appearing in the SQL statement. CONCAT , SUBSTR , COALESCE (etc.), and add an operation identifier AT to it. The operation identifier AT is wrapped by a fixed prefix and suffix. The fixed prefix and suffix are used to intercept the start and end positions of the operation expression in dynamic detection and defense and indicate that the expression needs to be pre-calculated.
[0021] Using preset operation labels Arith With private key pKey generate AT . AT The formula for generating it is as follows: AT = [Arith_pKey_Arith] (3).
[0022] The multi-layered identifier system introduced in this invention (including header identifier HT, variable identifier VT, and operation identifier AT) forms a unified SQL semantic tracing framework. The HT identifier allows for precise location of the context and type of SQL statements; the VT identifier allows for tracing the true source and dependencies of variables; and the AT identifier allows for capturing and defining the boundaries of operational expressions, thereby achieving end-to-end traceability and verifiability from the statement layer, variable layer, to the operation layer. The establishment of this system enables the system not only to detect potential vulnerabilities but also to provide semantic-level evidence support in attack tracing and behavior auditing.
[0023] Step S2, as follows Figure 3 As shown, dynamic detection and defense: the identifiers added to the SQL statement are parsed, the operation expression with the operation identifier AT is pre-computed, and the SQL injection and stored XSS attacks caused by the operation expression are identified before the SQL statement reaches the database; when an attack is detected, malicious characters are defended by character escaping or input truncation. The specific steps are as follows: Step S21: Intercept SQL statements containing identifiers through a proxy, parse and extract the header identifier HT, variable identifier VT, operation identifier AT, and variable source identifier from the SQL statement. ψ Information in the middle; Step S22: Identify the arithmetic expression based on the arithmetic identifier AT, perform pre-computation operations on it, call the controlled computation engine to perform numerical calculations on the arithmetic expression; run SQL standard function calls through the lightweight database execution engine to obtain the function return value; execute host language (e.g., PHP) function calls through the controlled interpreter or subprocess to obtain the running result, and replace the original expression with the calculation result, such as... Figure 4 As shown; in this process, the proxy ensures consistency between the computational logic and the database; in the dynamic phase, this invention performs pre-computation and structural reconstruction of the computational expression through the proxy mechanism, making the detection logic completely aligned with the actual execution semantics of the database. During the pre-execution process, the system can accurately reconstruct the computation results, function return values, and concatenation logic, ensuring the rigor and consistency of the detection judgment. Compared with traditional string-rule-based detection methods, this invention significantly improves the semantic accuracy and context awareness of the detection, thereby significantly improving the accuracy and robustness of vulnerability detection.
[0024] Step S23: Perform SQL injection and XSS detection on the replaced SQL statement; determine whether there are malicious XSS scripts and malicious SQL characters in the variables; if there are malicious XSS scripts, determine whether the SQL statement type is INSERT or UPDATE. If so, it is a stored XSS attack, and then perform four types of XSS detection based on event type, tag type, encoding type and keyword type on the input value. Step S24: When an attack is detected, execute the corresponding defense based on the variable type. When the input contains malicious characters used for SQL injection, execute the defense operation based on the variable type: if it is a character variable, use character escaping defense; if it is a numeric variable, use truncation defense. Finally, remove the identifier and restore the execution of a safe SQL statement. When the input contains malicious characters used for XSS (Cross-Site Scripting), first determine whether the input appears in an encoded form (e.g., percent sign encoding, HTML entity encoding, Base64, etc.); if it is encoded, first decode it uniformly to restore the original payload, and then block it based on the keyword; if it is not encoded, block it directly based on the keyword.
[0025] This invention integrates unified detection rules for SQL injection and stored XSS within its detection framework. The system, operating within the same security engine, can identify both logical injection risks at the database layer and script execution vulnerabilities during the front-end display phase, achieving a joint defense mode of "detection upon write, defense before execution." This mode is particularly suitable for cross-layer attack scenarios, effectively preventing stored XSS attacks triggered during the display phase after user input is persisted in the database, thus achieving simultaneous protection for SQL security and front-end security.
[0026] Step S3: After the defense is completed, remove the identifiers in the SQL, restore the standard SQL statement, and submit it to the database for execution.
[0027] Through the above steps, the present invention can identify potential injection points caused by operational expressions or functions before SQL execution, thus achieving integrated detection and defense.
[0028] This invention can perform structured parsing and computational annotation of SQL statements through a static analysis module, identifying and recording expression boundaries and variable sources. It can also perform pre-execution analysis of computational expressions through a dynamic detection and defense module combined with a proxy mechanism, ensuring consistency between the detection logic and database semantics. Simultaneously, it integrates a unified XSS detection rule system during the detection process, providing multi-dimensional defense against INSERT and UPDATE operations. By combining static annotation with dynamic execution, this method can not only accurately identify hidden injections caused by computational expressions but also effectively block stored XSS attacks before they occur, constructing a universal defense framework that combines accuracy, real-time performance, and scalability.
[0029] This invention achieves precise analysis and monitoring of arithmetic or functional expressions in SQL statements through a detection method combining static identification and dynamic pre-computation. It effectively identifies potential injection points, overcoming the shortcomings of traditional methods that rely solely on keyword matching or regular expression rules and cannot perceive the semantics of operations. This method not only establishes a complete semantic mapping at the source code level but also performs synchronous verification during runtime in conjunction with the actual evaluation process, ensuring a high degree of consistency between the detection process and the database execution logic. This fundamentally solves the problem of false positives and false negatives caused by semantic inconsistencies.
[0030] Example description: Example SQL statement: $sql = "UPDATE user SET name = ABS('$username') WHERE id = $id + 1"; For example.
[0031] Static analysis process: Step S11: Based on the abstract syntax tree of the Web application source code ( AST Identify the SQL execution function and obtain the initial SQL statement of the source code as shown above through the SQL statement execution function.
[0032] Step S12: Based on the abstract syntax tree ( AST Extract variables from SQL statements $username and $id Use context analysis to determine its origin ψ ,in ψ 1 =2 and ψ 2 =1.
[0033] Step S13, Preset plaintext θ=' SQLI ', will plaintext θ= SQLI, ψ and file location FL = a.php Combination HT= [exits_a.php_2_1_SQLI] Add to the SQL statement.
[0034] Step S14: Preset private key pKey ='DVWA', encryption formula (2) generates variable markers. VT = 9d80700280fda0 331ad9bd8d3984cfbf And add it to both ends of the variable.
[0035] Step S15: Based on the private key pKey ='DVWA' generates arithmetic expression tags AT = [Arith_DVWA_Arith] Through the abstract syntax tree of SQL statements ( SQL-AST The SQL statement contains two potential operands: ABS() and $id + 1. The AT identifier is inserted before and after each of these operands. HT, VT, AT The SQL statement after the tag becomes $sql = " [exits_a.php_2_1_SQLI]UPDATE user SET name =[Arith_DVWA_Arith]ABS('9d8070028 0fda0331ad9bd8d3984cfbf$username9d80700280fda0331ad9bd8d3984cfbf')[Arith_ Dynamic detection and defense process: Step S21: The proxy intercepts SQL statement parsing header identifiers containing identifiers. DVWA_Arith]WHERE id = [Arith_DVWA_Arith]9d80700 Extract statement type, variable source ψ, and operation expression identifier. .
[0036] Step S22, when input = , = 1 ,according to and Identifier, extract variable set V={1'); DROP TABLE, 1} operation expression set A={ABS('1'); DROP TABLE'), 1+1}, after execution A={1; DROP TABLE'), 2}, replace variable set V={1; DROP TABLE'), 2}.
[0037] Step S23, for variables V The detection was performed, and the variables were... v 1 The message "DROP TABLE" contains malicious characters and has been detected as an SQL injection vulnerability. 1 =2, then it meansv 1 This can lead to second-order SQL injection, and v 2 It is a normal string and will not be processed in any way.
[0038] Step S24 v 1 Since it is a malicious string and belongs to the character type, it can be defended against using character escaping techniques.
[0039] Step S3: Remove the identifiers from the SQL statement and restore it to its original state. And submit it to the database.
Claims
1. A method for detecting and defending against SQL injection and stored XSS, characterized in that: Includes the following steps: Step S1, Static Analysis: Scan the web application source code, locate the SQL statements in the source code, identify and add the header identifier HT, variable identifier VT, and operation identifier AT in the SQL statements that participate in arithmetic or functional operations; Step S2, Dynamic Detection and Defense: Parse the identifiers added to the SQL statement, perform pre-computation processing on the arithmetic expression with the arithmetic identifier AT, and identify SQL injection and stored XSS attacks caused by the arithmetic expression before the SQL statement reaches the database; when an attack is detected, defend against malicious characters by character escaping or input truncation. Step S3: After the defense is completed, remove the identifiers in the SQL, restore the standard SQL statement, and submit it to the database for execution.
2. The SQL injection and stored XSS detection and defense method according to claim 1, characterized in that: Step S1 specifically includes the following steps: Step S11: Scan the Web application source code and locate the SQL statements in the source code by parsing the Web application source code Abstract Syntax Tree (AST); Step S12: Extract variables from the SQL statement based on the Abstract Syntax Tree (AST), and determine the variable source identifier using user input characteristics, Session / Cookie sources, and database readback information. ψ ; Step S13: Using preset plaintext θ and variable source identifier ψ and file location FL Generate the header identifier HT of the SQL statement and add it to the SQL statement; Step S14: Using the preset plaintext θ and private key pKey Variable identifiers are generated through a hash algorithm and an XOR operation. VT and variable identifier VT Add to both sides of the variable; Step S15: Obtain the SQL statement structure by parsing the SQL statement's abstract syntax tree (SQL-AST), locate the expressions in the SQL statement that participate in arithmetic or function operations, identify the expression positions and add operation identifiers (AT) to them for pre-computation in the dynamic phase.
3. The SQL injection and stored XSS detection and defense method according to claim 2, characterized in that: The variable source identifier ψ in step S12 includes the following values: ψ =0 indicates a constant; ψ =1 indicates user input; ψ =2 indicates non-user input.
4. The SQL injection and stored XSS detection and defense method according to claim 2, characterized in that: The formula for the header identifier HT of the SQL statement in step S13 is as follows: HT = [exist_FL_ψ1_ψ2 ...ψn_θ] .
5. The SQL injection and stored XSS detection and defense method according to claim 2, characterized in that: The variable identifier of the SQL statement in step S14 VT The formula is as follows: VT = MD5(θ) ⊕ pKey 。 6. The SQL injection and stored XSS detection and defense method according to claim 2, characterized in that: The SQL statement's operation identifier AT formula in step S15 is as follows: AT = [Arith_pKey_Arith].
7. The SQL injection and stored XSS detection and defense method according to claim 1, characterized in that: The specific steps of step S2 are as follows: Step S21: Intercept SQL statements containing identifiers through a proxy, parse and extract the header identifier HT, variable identifier VT, operation identifier AT, and variable source identifier from the SQL statement. ψ Information in the middle; Step S22: Identify the operation expression part according to the operation identifier AT, perform pre-calculation operations on it, including arithmetic calculation, string concatenation and function evaluation, and replace the original expression with the calculation result; Step S23: Perform SQL injection and XSS detection on the replaced SQL statement; Step S24: When an attack is detected, execute the corresponding defense based on the variable type.
8. The SQL injection and stored XSS detection and defense method according to claim 6, characterized in that: In step S23, it is determined whether there are malicious XSS scripts and malicious SQL characters in the variables; if there are malicious XSS scripts, it is determined whether the SQL statement type is INSERT or UPDATE. If so, it is a stored XSS attack, and then the input value is subjected to four types of XSS detection based on event type, tag type, encoding type and keyword type.
9. A method for detecting and defending against SQL injection and stored XSS according to claim 6, characterized in that: In step S24, when the input is detected to contain malicious characters used for SQL injection, a defense operation is performed according to the variable type: if it is a character variable, character escaping defense is used; if it is a numeric variable, truncation defense is used; finally, the identifier is removed and the execution of the SQL statement is restored to a safe state; when the input is detected to contain malicious characters used for XSS, it is first determined whether the input appears in encoded form. If it is an encoded type, it is first decoded uniformly to restore the original payload, and then the blocking is implemented based on the keyword; if it is not an encoded type, the blocking is implemented directly based on the keyword.
10. A SQL injection and stored XSS detection and defense system, characterized in that: The SQL injection and stored XSS detection and defense method described in claim 1 includes a static analysis module and a dynamic detection and defense module; the static analysis module is used to scan the source code of a web application, locate SQL statements in the source code, identify and add header identifiers HT, variable identifiers VT, and operation identifiers in arithmetic or functional expressions in the SQL statements. AT The dynamic detection and defense module is deployed between the web application and the database. It is used to parse the identifiers added to the SQL statement in the static analysis module, perform pre-calculation processing on the operation expression with operation identifier AT, and identify SQL injection and stored XSS attacks caused by operation expression before the SQL statement reaches the database. When an attack is detected, malicious characters are defended by character escaping or input truncation.