An application layer firewall intelligent interception method and system based on AI fusion

Abstract

The application provides a kind of fusion AI's application layer firewall intelligent interception method and system, method includes: collecting the original byte stream corresponding to application access request, request header field, uniform resource locator path, request parameter, payload content, connection state and session state, generate protocol state marker sequence;According to protocol state marker sequence constructs protocol ownership account book, determines core frozen byte segment according to ownership confirmation state and freeze condition library, executes two-way isolation analysis using pre-switch parser and post-switch parser, generates protocol ownership gap set;Extract request risk feature vector, generate hierarchical interception strategy in combination with artificial intelligence model and rule engine;According to the interception execution result, build candidate feedback sample set, form candidate strategy parameter set;Strategy optimization is completed in shadow strategy space using bat algorithm, and contaminated sample is identified using strategy boundary echo verification.

Description

Technical Field

[0001] This invention relates to the field of network security technology, and in particular to an application-layer firewall intelligent interception method and system that integrates AI. Background Technology

[0002] With the development of cloud-based business platforms and open interface services, application-layer attacks are characterized by complex request structures and increasingly covert attack methods. Existing application-layer firewalls typically inspect request header fields, Uniform Resource Locator (URL) paths, payload content, and session state. They combine rule engines or artificial intelligence models to identify attack behaviors such as Structured Query Language (SCL) injection, command execution, and interface abuse. Upon identifying abnormal requests, they perform rate limiting, isolation, blocking, or alerting.

[0003] In practical applications, access requests typically pass through reverse proxies, application gateways, and backend servers. Due to differences in protocol versions, request boundary identification methods, and parsing orders used by different nodes, the same byte data might be interpreted as a normal request in the front-end application layer firewall, but as an additional request, remaining payload content, or the start of a new request in the backend server. Existing application layer firewalls usually only inspect already parsed request fields, making it difficult to detect parsing differences arising from protocol upgrades, tunnel establishment, connection reuse, or proxy forwarding in a timely manner. This poses a risk that attack requests can bypass front-end detection and reach the backend server.

[0004] Therefore, this invention proposes an application-layer firewall intelligent interception method and system that integrates AI. The information disclosed in the background section is only for enhancing understanding of the background of this disclosure and may therefore contain prior art information that is not common knowledge to those skilled in the art. Summary of the Invention

[0005] The purpose of this invention is to address the shortcomings of existing technologies by providing an application-layer firewall intelligent interception method and system that integrates AI, thereby solving the technical problems mentioned in the background section.

[0006] To achieve the above objectives, the present invention provides the following technical solution: An application-layer firewall intelligent interception method integrating AI includes the following steps: S1. Collect the raw byte stream, request header fields, Uniform Resource Locator path, request parameters, payload content, connection status, session status and historical interception records corresponding to the application access request, and generate a protocol status tag sequence; S2. Construct a protocol ownership ledger based on the protocol status mark sequence, determine the core frozen byte segments based on the ownership confirmation status and the freeze condition library, form a frozen byte segment set, and use the pre-switch parser and post-switch parser to generate isolation parsing results; S3. Compare the isolation resolution results, generate a set of protocol ownership gaps, extract the request risk feature vector, input it into the artificial intelligence model and combine it with the rule engine to generate a hierarchical interception strategy; S4. Execute the hierarchical interception strategy, generate interception execution results, construct a candidate feedback sample set based on the protocol ownership gap set, request risk feature vector, and interception execution results, filter the candidate update sample subset, and generate a candidate strategy parameter set. S5. In the shadow policy space, the bat algorithm is used to optimize the candidate policy parameter set, generate optimized candidate policies, locate the contaminated sample set based on policy boundary echo verification, and update the current stable policy version and the freeze condition library.

[0007] S1 specifically includes: after decryption at the transport layer, collecting the connection status, session status, proxy forwarding link record, backend response status, and valid data fragments corresponding to the application access request; sorting, deduplicating, and concatenating them according to the connection identifier, transmission sequence number, and payload length to form the original byte stream and standardized request record; dividing byte segments according to protocol type, connection status, request boundary, and protocol parsing progress; establishing a candidate home set and determining the home confirmation status to form the original byte segment sequence; identifying protocol upgrades, tunnel establishment, connection reuse, or proxy forwarding status changes; generating status change events; forming a protocol status mark sequence according to the byte segment number; and outputting it to step S2 for subsequent processing.

[0008] S2 specifically includes: constructing a protocol ownership ledger based on the original byte segment sequence, candidate ownership set, ownership confirmation status, status change events, and protocol status marker sequence, according to the connection identifier and byte segment number, and writing the protocol ownership, protocol processing stage, request number, freeze status, and parsing version number; determining the core frozen byte segments based on the status change events and freeze condition library, expanding the range of frozen bytes by combining the parsing context configuration table, merging them to form a frozen byte segment set, and pausing data transmission; selecting the pre-switch parser and post-switch parser from the protocol parser configuration library, performing dual-path parsing on the frozen byte segment set in the isolated parsing environment, and generating pre-switch isolated parsing results and post-switch isolated parsing results.

[0009] S3 specifically includes: comparing the isolation parsing results before and after the handover to identify differences in request quantity, message boundaries, request header field ownership, payload ownership, session state, parsing end position or parsing completion status, forming a protocol ownership gap set; based on standardized request records, historical interception records, state change events and the protocol ownership gap set, extracting malicious payload features, abnormal call features, access frequency features, context association features and protocol gap features, and normalizing them to form a request risk feature vector; inputting the request risk feature vector into the artificial intelligence model, combining it with the rule engine to calculate a comprehensive risk score, determining the request risk level and generating a graded interception strategy.

[0010] S4 specifically includes: based on the hierarchical interception strategy and execution configuration table, performing request allowance, continuous monitoring, rate limiting, connection freezing, isolation, blocking, or alarm, forming an interception execution result; associating the protocol ownership gap set, request risk feature vector, model risk score, comprehensive risk score, attack type identification result, rule matching result, and interception execution result to form a candidate feedback sample set; filtering candidate update sample subsets based on evidence direction value and sample credibility; generating candidate model update packages, candidate risk threshold combinations, candidate rule entry combinations, and candidate freezing condition combinations based on the candidate update sample subsets to form a candidate strategy parameter set, and outputting it to step S5 for strategy optimization.

[0011] S5 specifically includes: writing the candidate policy parameter set into the shadow policy space; using the bat algorithm to perform counterfactual replay and fitness evaluation in combination with a pre-set trusted sample set, mirror traffic sample set, and protocol ambiguity sample set to obtain optimized candidate policies; performing risk identification on the evaluation samples using the current stable policy version and the optimized candidate policies respectively, generating policy boundary echoes, calculating boundary displacement, and locating contaminated sample sets when the preset boundary conditions are not met; updating the current stable policy version and writing it into the freeze condition library when the preset boundary conditions are met; isolating contaminated samples when the preset boundary conditions are not met, extracting the corresponding protocol state position, byte segment features, and parsing difference patterns to form new freeze conditions.

[0012] An application-layer firewall intelligent interception system integrating AI includes: The request collection module is used to collect the connection status, session status, proxy forwarding link records, backend response status, and valid data fragments corresponding to application access requests. The protocol ownership processing module is used to construct a protocol ownership ledger based on the original byte segment sequence, candidate ownership set, ownership confirmation status, status change events, and protocol status flag sequence. The dual-path isolation parsing module is used to select the pre-switch parser and post-switch parser from the protocol parser configuration library and perform dual-path parsing on the frozen byte segment set in the isolation parsing environment; The risk identification and interception module compares the isolation analysis results before and after the handover to generate a protocol ownership gap set; it extracts request risk feature vectors based on standardized request records, historical interception records, state change events, and the protocol ownership gap set. The candidate strategy generation module is used to associate the ownership gap set of the related agreement, the request risk feature vector, the output of the artificial intelligence model, the rule matching result, and the interception execution result to form a candidate feedback sample set; The strategy optimization and update module is used to optimize the candidate strategy parameter set in the shadow policy space using the bat algorithm to generate optimized candidate strategies.

[0013] The beneficial effects of this invention are as follows: This invention constructs a protocol ownership ledger to confirm the ownership of byte segments in the original byte stream segment by segment, and freezes byte segments with unclear ownership during protocol upgrades, tunnel establishment, connection reuse, or proxy forwarding. It can identify parsing differences before the request enters the backend server and reduce the risk of protocol parsing bypass.

[0014] This invention employs a pre-switch parser and a post-switch parser to perform dual-path isolated parsing on the frozen byte segment set, and generates a protocol ownership gap set based on request quantity, message boundaries, payload ownership relationships, and session state changes, thereby improving the accuracy of identifying covert attack requests. By inputting protocol ownership gaps, malicious payload characteristics, abnormal call characteristics, access frequency characteristics, and contextual association characteristics into an artificial intelligence model, and combining this with a rule engine to generate a tiered interception strategy, it can balance attack identification capabilities with the efficiency of normal request passage.

[0015] This invention optimizes candidate model update packets, candidate risk threshold combinations, candidate rule entry combinations, and candidate freeze condition combinations using the bat algorithm in the shadow policy space, avoiding unverified policy updates from directly affecting online requests. It identifies contaminated samples through policy boundary echo verification and writes recurring protocol state positions, byte segment characteristics, and parsing difference patterns into a freeze condition library, enabling identified risks to generate advance freeze conditions for subsequent connections, thus achieving closed-loop updates for the application layer firewall. Attached Figure Description

[0016] Figure 1 This is a schematic diagram of an application-layer firewall intelligent interception method integrating AI according to the present invention; Figure 2 This is a schematic diagram of the intelligent interception system framework of an application-layer firewall that integrates AI, according to the present invention. Detailed Implementation

[0017] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0018] Example 1: As Figure 1 As shown, this embodiment provides an application-layer firewall intelligent interception method integrating AI, including the following steps: S1. Collect the raw byte stream, request header fields, Uniform Resource Locator path, request parameters, payload content, connection status, session status and historical interception records corresponding to the application access request, and generate a protocol status tag sequence; S2. Construct a protocol ownership ledger based on the protocol status mark sequence, determine the core frozen byte segments based on the ownership confirmation status and the freeze condition library, form a frozen byte segment set, and use the pre-switch parser and post-switch parser to generate isolation parsing results; S3. Compare the isolation resolution results, generate a set of protocol ownership gaps, extract the request risk feature vector, input it into the artificial intelligence model and combine it with the rule engine to generate a hierarchical interception strategy; S4. Execute the hierarchical interception strategy, generate interception execution results, construct a candidate feedback sample set based on the protocol ownership gap set, request risk feature vector, and interception execution results, filter the candidate update sample subset, and generate a candidate strategy parameter set. S5. In the shadow policy space, the bat algorithm is used to optimize the candidate policy parameter set, generate optimized candidate policies, locate the contaminated sample set based on policy boundary echo verification, and update the current stable policy version and the freeze condition library.

[0019] S1 specifically includes the following sub-steps: S110. Deploy the application-layer firewall after the reverse proxy, application gateway, or transport layer security protocol termination node, enabling it to receive application-layer data that has been decrypted at the transport layer but has not yet been split into request lines, request header fields, and payload content according to the application-layer protocol. For each network connection, the application-layer firewall collects the source network address, source port, destination network address, destination port, transport protocol type, connection establishment time, connection state, request reception time, session identifier, session state, proxy forwarding node identifier, target service identifier, backend response status, and historical interception records.

[0020] The connection status is read from the connection session table; the proxy forwarding node identifier and target service identifier are read from the proxy forwarding link record of the reverse proxy or application gateway; the historical interception record is read from the interception log library of the application layer firewall, including historical risk level, attack type identification result, rule matching result, interception action and interception execution result.

[0021] A connection identifier is generated based on the source network address, source port, destination network address, destination port, transport protocol type, and connection establishment time. ; Where 'c' represents the connection identifier; This represents the function for calculating the summary. Indicates the source network address; Indicates the source port; Indicates the destination network address; Indicates the destination port; Indicates the type of transport protocol; This indicates the connection establishment time. The digest calculation function is used to generate the connection-level index, not for performing encryption authentication.

[0022] The application-layer firewall sorts and deduplicates received valid data segments according to connection identifier, transmission sequence number, and payload length; for data with missing positions, it waits for retransmission until a preset waiting time is reached; then, it concatenates the data according to byte position order to form the original byte stream. ; in, This indicates the raw byte stream with the connection identifier 'c'. This represents the j-th valid data segment after sorting and deduplication; j represents the sequence number of the valid data segment; n represents the number of valid data segments; symbol This indicates concatenation according to byte position order.

[0023] Based on the preliminary parsing results of the raw byte stream, standardized request records are generated for application access requests with clearly defined request boundaries. Each standardized request record includes at least the request number, connection identifier, request reception time, byte start position, byte end position, request header fields, Uniform Resource Locator (URL) path, request parameters, payload content index, payload content summary, session identifier, session state, proxy forwarding node identifier, target service identifier, and historical interception record index. The payload content index is used to read the payload content from the controlled request content storage area, and the payload content summary is used to perform correlation comparison. Data with unclear request boundaries is temporarily stored as a pending confirmation record and is not forcibly included in any complete request.

[0024] For example, if valid data segments numbered 2, 1, and 3 are received sequentially on the same connection, the application layer firewall first adjusts the order according to the transmission sequence number and then performs the splicing. If segment 2 is received repeatedly, only one valid data segment is retained and is not written to the original byte stream again.

[0025] S120. For the raw byte stream obtained in step S110, record the byte positions according to the byte order, and divide the byte segments according to the protocol type, connection state, request boundary, and protocol parsing progress. The protocol processing stage includes the request start confirmation stage, request line parsing stage, request header field parsing stage, request header field end confirmation stage, payload parsing stage, request end confirmation stage, protocol upgrade confirmation stage, tunnel establishment confirmation stage, connection multiplexing confirmation stage, and proxy forwarding confirmation stage. The application layer firewall determines the transition position of the protocol processing stage based on the delimiter, request length field, chunk transmission end indicator, protocol upgrade instruction, tunnel establishment request, backend response status, and proxy forwarding link record.

[0026] When there are changes in protocol type, protocol processing stage, request number, or home confirmation status between adjacent bytes, or when there are changes in protocol upgrade, tunnel establishment, connection multiplexing, or proxy forwarding status, a new byte segment boundary is established at the corresponding position. The i-th byte segment is represented as: ; in, This represents the i-th byte segment; i represents the byte segment number. Indicates the starting byte position of the i-th byte segment; This indicates the position of the terminating byte of the i-th byte segment. Byte segments are concatenated consecutively according to their byte positions, ensuring that no valid bytes are omitted or repeated from the original byte stream.

[0027] Establish a candidate attribution set for each byte segment. This is used to record the request number, protocol type, and protocol processing stage that may correspond to the i-th byte segment. The ownership confirmation status of the i-th byte segment is recorded as... And determined according to the following rules: ; in, This indicates the ownership confirmation status of the i-th byte segment; This represents the candidate set of the i-th byte segment; Indicates the number of candidate affiliations. When When, mark the corresponding byte segment as confirmed; when When this happens, the corresponding byte segment will be marked as unacknowledged.

[0028] For example, a byte segment might be interpreted as either the remaining payload content requested before the protocol switch or the starting content of the data after the protocol switch. In this case, the byte segment has two candidate assignments and should be marked as unconfirmed. The divided byte segments are then arranged in byte position order to form the original byte segment sequence.

[0029] S130. Based on the connection status, request header field, proxy forwarding link record, and backend response status obtained in step S110, and the raw byte segment sequence obtained in step S120, identify protocol upgrade, tunnel establishment, connection reuse, and proxy forwarding status changes. Protocol upgrade status changes are determined based on the protocol upgrade instruction in the request header field and the upgrade confirmation response in the backend response status; tunnel establishment status changes are determined based on the tunnel establishment request and the corresponding success response; connection reuse status changes are determined based on the addition of a new logical request channel, concurrent request number, or request boundary reuse relationship within the same connection; proxy forwarding status changes are determined based on changes in the proxy forwarding node identifier, target service identifier, or proxy forwarding link record.

[0030] When any state change is detected, a state change event is generated. Each state change event includes at least the state change event number, connection identifier, state change type, state change occurrence time, state change start byte position, protocol type before state change, protocol type after state change, and set of affected byte segment numbers.

[0031] A protocol status flag is generated for each byte segment. The protocol status flag includes at least the connection identifier, byte segment number, start byte position, end byte position, protocol type, protocol processing stage, ownership confirmation status, and associated status change event number. If no associated status change event exists, the associated status change event number is recorded as null. The protocol status flags are arranged according to the byte segment number to form a protocol status flag sequence.

[0032] For example, in a certain raw byte stream, byte positions 721 to byte positions 800 can be classified as either the remaining payload content requested before the protocol switch or the starting content of the data after the protocol switch. In this case, the corresponding byte segment will be marked as unconfirmed and associated with the protocol upgrade status change event.

[0033] The standardized request record, raw byte stream, raw byte segment sequence, candidate ownership set, ownership confirmation status, status change event, and protocol status flag sequence are output to step S210. The standardized request record is used for subsequent extraction of request risk features; the raw byte stream is used for subsequent truncation of the frozen byte range; and the status change event and protocol status flag sequence are used to construct the protocol ownership ledger.

[0034] S2 specifically includes the following sub-steps: S210: Read the original byte segment sequence, candidate ownership set, and ownership confirmation status output in step S120, as well as the status change events and protocol status flag sequence output in step S130. The application layer firewall establishes a protocol ownership ledger according to the connection identifier and byte segment number. The protocol ownership ledger is a set of structured records maintained by the application layer firewall to store the ownership judgment results of each byte segment in the original byte stream; the protocol ownership ledger is neither a blockchain ledger nor a financial ledger.

[0035] Each byte segment corresponds to one protocol ownership record. The protocol ownership record includes at least the connection identifier, byte segment number, start byte position, end byte position, candidate ownership set, protocol ownership, protocol processing stage, request number, ownership confirmation status, associated status change event number, freeze status, freeze reason, parsing version number, and record update time.

[0036] When the ownership confirmation status is confirmed, a unique candidate ownership is read from the candidate ownership set, and the protocol type, protocol processing stage, and request number are written to the corresponding fields. When the ownership confirmation status is unconfirmed, the protocol ownership, protocol processing stage, and request number are recorded as pending confirmation, and the complete candidate ownership set is retained. The initial freeze status is set to unfrozen, and the initial resolution version number is set to 1. When updating the protocol ownership record subsequently based on the isolation resolution result, the resolution version number is incremented by 1, and the record before the update is retained for subsequent tracing of byte segment ownership changes.

[0037] For example, if the 12th byte segment only corresponds to "request number 4, Hypertext Transfer Protocol, payload parsing stage", then the candidate ownership will be written into the protocol ownership record; if the 13th byte segment may belong to the remaining payload content of the previous request or the data start content after the protocol switch, then it will remain in a pending confirmation state and will not be directly assigned a unique protocol ownership.

[0038] S220: Read the status change event output in step S130, and locate the corresponding protocol ownership record in the protocol ownership ledger based on the connection identifier, the starting byte position of the status change, and the set of affected byte segment numbers. When there are byte segments within the affected area whose ownership confirmation status is unconfirmed, each byte segment that meets the above conditions is identified as a core frozen byte segment. The core frozen byte segment is a byte segment within the scope of protocol switching influence that cannot yet have its protocol ownership uniquely determined.

[0039] Simultaneously, the freeze conditions already in effect are read from the freeze condition database. This database is pre-configured by the application layer firewall and continuously updated in step S530. The current connection's corresponding state change type, protocol state position, and byte segment characteristics are matched against the freeze conditions in the database. When a match is successful, the corresponding byte segment is directly identified as the core frozen byte segment; when a match fails but the corresponding byte segment's ownership confirmation status is unconfirmed, the core frozen byte segment is still determined according to the ownership confirmation status.

[0040] Read the forward context byte length, backward context byte length, maximum frozen byte length, and maximum frozen duration corresponding to the current protocol type from the application layer firewall's pre-configured resolution context table. For the k-th core frozen byte segment, determine the frozen byte range according to the following formula: ; in, This indicates the range of frozen bytes corresponding to the k-th core frozen byte segment; This represents the raw byte stream formed in step S110; and These represent the starting and ending byte positions of the k-th core frozen byte segment, respectively. This indicates the protocol type corresponding to the k-th core frozen byte segment; Indicates the protocol type is The length of the forward context bytes at that time; Indicates the protocol type is The length of the backward context bytes at that time; Indicates the total length of the original byte stream in bytes.

[0041] When multiple frozen byte ranges overlap, they are merged into a frozen byte segment set. The application layer firewall sets a pause flag for the frozen byte segment set in the proxy forwarding queue and writes the frozen byte segment set into the connection-level buffer divided according to the connection identifier. For connections requiring sequential resolution, subsequent byte data transmission for the corresponding connection is paused starting from the core frozen byte segment. If the freeze duration exceeds the maximum freeze duration, or the total length of frozen bytes exceeds the maximum frozen byte length, the current connection is terminated, and a freeze exception flag is generated. Freeze exception flags include a freeze timeout flag and a buffer overflow flag.

[0042] For example, if the 13th byte segment covers byte positions 721 to byte position 800, and the forward context byte length and backward context byte length are both 160 bytes, then the frozen byte segment set covers byte positions 561 to byte position 960.

[0043] Output the frozen byte segment set, connection identifier, state change event, request number mapping relationship, protocol type before state change, protocol type after state change, initial session state, and freeze exception flag to step S230.

[0044] S230: Read the set of frozen byte segments output in step S220, the protocol type before the state change, the protocol type after the state change, the initial session state, and the freeze anomaly flag. Select the pre-switch resolver and the post-switch resolver from the application layer firewall's pre-configured protocol resolver configuration library. The protocol resolver configuration library must at least record the protocol type, protocol version, target service identifier, resolution rule version, resolver call address, forward context byte length, backward context byte length, and maximum resolution time.

[0045] Before the switchover, the parser is selected based on the protocol type before the state change; after the switchover, the parser is selected based on the protocol type after the state change. For proxy forwarding state changes, the parsing rules before proxy forwarding and the parsing rules corresponding to the target service are used respectively. The same set of frozen byte segments, connection identifier, state change event, request number mapping relationship, and initial session state are input into the parser before and after the switchover respectively, and parsing is performed in the isolated parsing environment.

[0046] The isolated resolution environment is a read-only resolution environment set up inside the application layer firewall. It is only used to perform byte stream splitting, request boundary identification, request header field identification, payload attribution judgment, and session state simulation. It does not write data to the real backend server, call the database, access external interfaces, execute commands in the payload content, or change the actual connection state.

[0047] Each set of isolated resolution results should include at least the resolver type, resolution rule version, number of requests, message boundary set, request header field attribution, payload attribution, session state change, resolution end position, resolution completion status, resolution exception type, and resolution duration. Resolution completion status includes completed, incomplete, failed, and timeout. When the freeze exception flag is not null, the freeze exception flag is written to both sets of isolated resolution results.

[0048] For example, if the parser identifies one request before the switch and two requests after the switch, and the second request starts from byte position 781, then both sets of isolation parsing results should completely record the number of requests and the message boundary set, and output them to step S310.

[0049] Output the agreement ownership ledger, the isolation resolution result before the switchover, and the isolation resolution result after the switchover to step S310.

[0050] S3 specifically includes the following sub-steps: S310. Read the isolation resolution results before and after the handover output in step S230, as well as the protocol ownership ledger output in step S210. The application layer firewall establishes a correspondence between the two sets of isolation resolution results from the same set of frozen byte segments according to the connection identifier, frozen byte segment set number, frozen byte start position, and frozen byte end position.

[0051] For each set of results, the following are compared sequentially: number of requests, message boundary set, request header field attribution, payload attribution, session state change, parsing end position, and parsing completion status. Specifically, request header field attribution and payload attribution are compared according to field name, byte range, and corresponding request number; session state changes are compared according to the state before the change, the state after the change, and the position where the change occurred.

[0052] Inconsistent results for the same set of frozen byte segments under two parsing rules are defined as protocol ownership gaps. For each protocol ownership gap, the following are recorded: gap number, connection identifier, frozen byte segment set number, associated state change event number, affected byte segment set, gap type, range of differing bytes, parsed content before the switch, and parsed content after the switch. Gap types include differences in the number of requests, message boundaries, request header field ownership, payload ownership, session state change, parsing end position, and parsing completion status.

[0053] The severity of the ownership gap in the agreement is calculated using the following formula: ; in, This indicates the severity of the protocol ownership gap corresponding to the x-th frozen byte segment set; m represents the comparison item number; This represents the preset weight corresponding to the m-th comparison item, and the sum of all preset weights is 1; This represents a judgment function, which takes the value 1 when there is a difference between the comparison items, and takes the value 0 otherwise. This indicates, in turn, whether there are differences in the number of requests, message boundary set, request header field attribution, payload attribution, session state changes, parsing end position, and parsing completion status.

[0054] In one specific embodiment, the preset weights are... The values ​​can be set as follows: Request quantity difference weight is 0.3, message boundary set difference weight is 0.25, request header field attribution difference weight is 0.1, payload attribution difference weight is 0.1, session state change difference weight is 0.1, parsing end position difference weight is 0.05, and parsing completion status difference weight is 0.1.

[0055] When one parser completes parsing while the other parser is incomplete, fails, or times out, a parsing completion status difference is generated; when neither parser completes parsing, a dual-path parsing exception flag is generated; when both parsers complete parsing and all comparison items are consistent, no protocol ownership gap is generated.

[0056] For example, before the switch, the parser interprets byte positions 561 to byte position 960 as one request, and after the switch, the parser interprets it as two requests, with the second request starting from byte position 781. The parser then records the difference in the number of requests and the difference in message boundaries, and records byte positions 781 to byte position 960 as the range of differing bytes.

[0057] S320: Read the standardized request records and historical interception records output in step S110, the status change events output in step S130, and the protocol ownership gap set output in step S310. The application layer firewall reads feature extraction rules from the pre-configured dangerous character pattern library, the normal call baseline library, and the pre-configured feature dictionary.

[0058] The dangerous character pattern library records the character combinations corresponding to Structured Query Language injection, cross-site scripting, and command execution; the normal call baseline library is formed by historical requests that have been confirmed to be normal and whose backend response status code, response duration, and response body length are all within the preset normal range; the preset feature dictionary records the feature name, feature number, data source, calculation rules, and normalization parameters.

[0059] Five types of features are extracted in a fixed order from the pre-defined feature dictionary: malicious payload features are extracted based on request header fields, Uniform Resource Locator (URL) paths, request parameters, and payload content, including the number of dangerous character combinations hit, encoding nesting levels, and abnormal parameter length ratios; abnormal call features are extracted based on URL paths, request methods, target service identifiers, and session states, including interface redirection abnormal markers, request method abnormal markers, and session state abnormal markers.

[0060] Access frequency features are extracted based on connection identifier, session identifier, and request reception time, including the number of requests within a preset statistical time window, the average time interval between adjacent requests, and the number of consecutive calls to the same path; context association features are extracted based on historical interception records, including the number of historical alarms, the number of historical isolations, and the path similarity with historically blocked requests; protocol gap features are extracted based on the protocol ownership gap set, including the number of protocol ownership gaps, the severity of protocol ownership gaps, the total length of difference bytes, and the Boolean value corresponding to each gap type.

[0061] Path similarity is determined by the ratio of the number of identical path segments to the number of the union of two path segment sets; the abnormal parameter length ratio is determined by the ratio of the number of parameters exceeding the parameter length range of the normal call baseline library to the total number of current request parameters; the encoding nesting level is determined by the number of encoding layers that are identified and restored layer by layer.

[0062] Perform normalization on numerical features: ; in, This represents the h-th eigenvalue after normalization. This represents the h-th eigenvalue before normalization; and represents the minimum and maximum values ​​of the h-th feature in the normal call baseline library, respectively, and y represents the application access request sequence number. When the calculation result is less than 0, the normalized feature value is set to 0; when the calculation result is greater than 1, the normalized feature value is set to 1; when... At that time, the normalized feature values ​​are set to 0. The five normalized features are then combined in a fixed order according to the preset feature dictionary to form the request risk feature vector.

[0063] S330. Input the request risk feature vector output in step S320 into the artificial intelligence model corresponding to the current stable policy version. The artificial intelligence model adopts a supervised training multi-task feedforward neural network, including an input layer, a shared hidden layer, a risk score output layer, and an attack type output layer.

[0064] In a preferred embodiment of the present invention, the number of nodes in the input layer is consistent with the dimension of the normalized request risk feature vector; the shared hidden layer adopts a two-layer structure, with the first hidden layer containing 256 neurons and the second hidden layer containing 128 neurons, both using the ReLU function; the risk score output layer contains 1 neuron, using the Sigmoid activation function to output continuous probability values ​​from 0 to 1; the attack type output layer contains 5 neurons, using the Softmax activation function to output the probability distribution corresponding to 5 attack types.

[0065] The training samples are derived from historical normal pass requests, historical attack requests that have been manually verified, attack requests that have been confirmed to be abnormal in the isolation verification environment, and requests corresponding to protocol ownership gaps; the training labels include normal request labels, attack request labels, and attack type labels.

[0066] The AI ​​model outputs a model risk score and attack type identification results. Attack types include Structured Query Language injection, Cross-Site Scripting, Command Execution, API abuse, and Protocol Parsing Bypass. The model risk score ranges from 0 to 1.

[0067] Read the rule entries, fusion weights, and risk thresholds from the official interception policy corresponding to the current stable policy version. For each matched rule entry, read the corresponding rule matching weight; sum the rule matching weights and limit the sum to the range of 0 to 1 to obtain the rule matching score. Calculate the comprehensive risk score according to the following formula: ; in, This represents the overall risk score; y represents the application access request sequence number. This represents the model's risk score; Indicate the severity of the ownership gap in the agreement; This indicates the score for matching the rule. , and This represents the preset fusion weights, and the sum of all preset fusion weights is 1. Preferably, the preset fusion weights... , and The values ​​are set to 0.4, 0.4, and 0.2 respectively. The severity of the protocol ownership gap and the rule matching score both range from 0 to 1.

[0068] The request risk level is determined based on a first risk threshold, a second risk threshold, and a third risk threshold, where the first risk threshold is less than the second risk threshold, and the second risk threshold is less than the third risk threshold. In a specific implementation scenario, the first risk threshold is set to 0.4, the second risk threshold is set to 0.7, and the third risk threshold is set to 0.9.

[0069] When the overall risk score is below the first risk threshold, it is determined to be low risk, and the request is allowed. When it reaches the first risk threshold but is below the second risk threshold, it is determined to be medium risk, and continuous monitoring or rate limiting is implemented. When it reaches the second risk threshold but is below the third risk threshold, it is determined to be high risk, and connection freezing, isolation, and alarms are implemented. When it reaches the third risk threshold, it is determined to be severe risk, and the current connection is blocked and an alarm is issued. When there are differences in the number of requests, differences in message boundaries, or dual-path parsing anomalies, it is directly determined to be severe risk regardless of whether the model risk score reaches the third risk threshold.

[0070] The model risk score, attack type identification result, comprehensive risk score, request risk level, rule matching result and hierarchical interception strategy are output to step S410, and the protocol ownership gap set and request risk feature vector are output to step S420.

[0071] S4 specifically includes the following sub-steps: S410. Read the hierarchical interception policy, request risk level, model risk score, comprehensive risk score, attack type identification result, and rule matching result output in step S330, and read the execution configuration table from the official interception policy corresponding to the current stable policy version. The execution configuration table includes at least the request risk level, interception action, execution object, rate limiting rate, freeze duration, isolation verification environment call address, blocking response code, and execution timeout duration. The execution object is at least one of the following: application access request, connection identifier, session identifier, or Uniform Resource Locator path.

[0072] When the tiered interception policy is to allow requests, the corresponding application access request is written to the backend sending queue, and the status code, response duration, and response body length returned by the backend server are recorded. When the tiered interception policy is to continuously monitor, a continuous monitoring flag is written to the corresponding connection identifier, and subsequent application access requests corresponding to the connection are collected after the request is allowed. When the tiered interception policy is to rate limit, application access requests exceeding the allowed rate are written to the waiting queue according to the rate limiting rate in the execution configuration table, and are transferred to the rejection queue after the waiting time reaches the execution timeout duration. When the tiered interception policy is to freeze connections, a pause sending flag is set in the proxy forwarding queue, and subsequent byte data is written to the connection-level buffer.

[0073] When the tiered blocking policy is isolation, a copy of the corresponding application access request is sent to the isolation verification environment, and no data is written to the real backend server; when the risk is only associated with a single application access request, the request to be sent is deleted; when the risk is associated with a protocol ownership gap or a change in connection state, the corresponding connection is closed and a blocking response code is returned; when the tiered blocking policy includes alarms, the connection identifier, request number, request risk level, and blocking action are sent to the application layer firewall management end.

[0074] An isolated verification environment is a verification environment isolated from the real backend server. It is used to receive copies of access requests from high-risk applications and verify whether the corresponding requests can trigger an abnormal state. The isolated verification environment must not access the real database, real business interfaces, or external network resources.

[0075] For each application access request, an interception execution result is generated. The interception execution result includes at least the request number, connection identifier, interception action, execution object, execution time, execution status, backend response result, isolation verification result, and alarm sending result. Execution status includes execution success, execution failure, and execution timeout. For requests that do not reach the actual backend server, the backend response result is recorded as an empty value, and the action receipt generated by the application layer firewall is also recorded.

[0076] S420: Read the protocol ownership gap set output in step S310, the request risk feature vector output in step S320, the model risk score, comprehensive risk score, attack type identification result, and rule matching result output in step S330, and the interception execution result output in step S410. Establish a correlation based on the request number, connection identifier, request reception time, and protocol ownership gap number. For application access requests without a protocol ownership gap, record the protocol ownership gap number as a null value.

[0077] The associated data is used to form candidate feedback samples. These candidate feedback samples are records to be verified by the application-layer firewall and cannot be directly written into the AI ​​model training set or formal blocking policies. Each candidate feedback sample must include at least the request number, connection identifier, set of associated protocol ownership gap records, request risk feature vector, model risk score, comprehensive risk score, attack type identification result, rule matching result, blocking execution result, evidence direction value, sample credibility, and sample verification status.

[0078] Regarding the first For each candidate feedback sample, the evidence direction value is calculated using the following formula: ; in, Indicates the first Evidence direction values ​​for each candidate feedback sample; Indicates the candidate feedback sample number; g indicates the evidence type number; This represents the preset weight corresponding to the g-th type of evidence, and the sum of all preset weights is 1; This indicates the evidence direction of the g-th type of evidence. It takes the value 1 when an anomaly is confirmed, -1 when a normal result is confirmed, and 0 when no confirmation is possible.

[0079] The sample confidence level is calculated using the following formula: in, Indicates the first The sample credibility of each candidate feedback sample; symbol This indicates taking the absolute value.

[0080] The five types of evidence are as follows: whether there are differences in the number of requests or message boundaries; whether the isolated verification environment is confirmed to be abnormal; whether the backend response result is normal; whether it hits a fixed rule that has been manually confirmed; and whether there is a manual review result. The manual review result is entered by the application layer firewall management terminal, including the reviewer's identification, review time, and review conclusion. The model risk score is only used as a recording field for candidate feedback samples and is not directly used to determine the sample verification status.

[0081] When the evidence direction value is greater than or equal to the preset confidence threshold, the sample verification status is set to confirmed abnormal; when the evidence direction value is less than or equal to the negative of the preset confidence threshold, the sample verification status is set to confirmed normal; the verification status of other samples is set to pending verification. Only candidate feedback samples that have been confirmed abnormal or confirmed normal are written into the candidate update sample subset; samples pending verification are kept in the candidate feedback sample set and do not participate in incremental training.

[0082] S430: Read the candidate update sample subset output in step S420, and read the base model version number, sample confidence lower limit, incremental training rounds, learning rate, and batch size from the model update configuration table pre-configured by the application layer firewall. Copy the AI ​​model corresponding to the current stable policy version to the isolated training environment, and perform incremental training using the candidate update sample subset and different training parameter combinations to generate multiple candidate model update packages. Each candidate model update package includes at least the candidate model update package number, base model version number, training sample index, training parameters, updated model parameters, and training completion status. The candidate model update package cannot directly replace the AI ​​model corresponding to the current stable policy version.

[0083] Centered on the first, second, and third risk thresholds in the current stable strategy version, adjust them upwards or downwards according to the preset adjustment step size to form candidate risk threshold combinations. Only retain combinations that satisfy the condition that the first risk threshold is less than the second risk threshold and the second risk threshold is less than the third risk threshold.

[0084] The preset repetition count, rule validity period, and freeze condition validity period are read from the rule generation configuration table pre-configured in the application layer firewall. Based on the confirmed abnormal samples that have reached the preset repetition count in the candidate update sample subset, the attack type, vulnerability type, and protocol processing stage are extracted to generate candidate rule entry combinations. Based on the confirmed abnormal samples associated with protocol ownership vulnerabilities, the state change type, protocol state location, byte segment characteristics, and parsing difference pattern are extracted, and candidate freeze condition combinations are generated in conjunction with the parsing context configuration table used in step S220.

[0085] Protocol state position refers to the protocol processing stage and the starting byte position of the state change corresponding to the state change event; byte segment characteristics include byte segment length, number of candidate attribution, distribution of separator identifiers, field boundary positions, and payload content summary; parsing difference pattern is a combination of repeated differences between the parser before and after the switch in terms of the number of requests, message boundary set, request header field attribution relationship, payload attribution relationship, session state change, parsing end position, or parsing completion status.

[0086] Each candidate strategy parameter combination includes a candidate model update package, a candidate risk threshold combination, a candidate rule entry combination, and a candidate freeze condition combination. Multiple candidate strategy parameter combinations are combined to form a candidate strategy parameter set, which is then output to step S510.

[0087] S5 specifically includes the following sub-steps: S510. Read the candidate strategy parameter set output in step S430, and read the number of individual bats, minimum search frequency, maximum search frequency, initial loudness, initial pulse emission probability, loudness attenuation coefficient, pulse emission probability growth coefficient, local search step size, maximum number of iterations, fitness convergence threshold, and longest duration of a single strategy optimization from the bat algorithm configuration table pre-configured by the application layer firewall.

[0088] As an example, the specific configuration parameters of the bat algorithm can be set as follows: the number of individual bats is 50, the minimum search frequency is 0, the maximum search frequency is 2, the initial loudness is 0.5, the initial pulse emission probability is 0.5, the loudness attenuation coefficient is 0.9, the pulse emission probability growth coefficient is 0.9, the maximum number of iterations is 100, and the fitness convergence threshold is 0.001.

[0089] The shadow policy space is an isolation policy verification environment set up inside the application layer firewall. It is used to load candidate model update packages, candidate risk threshold combinations, candidate rule entry combinations, and candidate freeze condition combinations, and to simulate risk identification and blocking actions. The shadow policy space does not replace the official blocking policy, does not send application access requests to the real backend server, does not change the real connection state, and does not write data to the official protocol ownership ledger or freeze condition database.

[0090] Evaluation samples for counterfactual replay are read from a pre-set trusted sample set, a mirrored traffic sample set, and a protocol ambiguity sample set. The pre-set trusted sample set includes manually verified normal requests, manually verified attack requests, and attack requests confirmed as abnormal by the isolation verification environment. The mirrored traffic sample set is formed by the application layer firewall replicating recent real access traffic according to a preset sampling ratio, with user identity information anonymized and replaced with irreversible indexes, while retaining the correlation between application access requests within the same session. The protocol ambiguity sample set is formed based on the protocol ownership gap set output in step S310, including a frozen byte segment set, pre-switch isolation resolution results, post-switch isolation resolution results, protocol ownership gap records, and sample verification status. These three sample sets and the candidate update sample subset are stored separately.

[0091] Each candidate strategy parameter combination is mapped to a single bat individual. The bat algorithm does not directly modify all parameters in the AI ​​model; instead, it searches within the candidate strategy parameter set for combinations suitable for inclusion in the formal interception strategy. For the b-th bat individual, in the t-th iteration, the search frequency, velocity vector, and position vector are updated according to the following formula: ; Where b represents the individual bat number; t represents the number of iterations; This represents the search frequency of the b-th bat individual in the t-th iteration; and These represent the minimum search frequency and the maximum search frequency, respectively. This represents a random number whose value ranges from 0 to 1. Represents the velocity vector; Represents a position vector; This indicates the location of the bat individual with the best current fitness.

[0092] For candidate model update package number, candidate rule entry combination number, and candidate freeze condition combination number, the corresponding positional components are rounded and mapped to the candidate strategy parameter set; for candidate risk threshold, it is restricted to the range of 0 to 1, and combinations that do not meet the condition of increasing risk threshold are deleted.

[0093] For each individual bat, a local search is performed based on its pulse emission probability. When the random number is greater than the pulse emission probability of the corresponding bat, a new position vector is generated centered on the position of the bat with the best current fitness, using the local search step size. A candidate strategy parameter combination is accepted only if the fitness of the candidate strategy parameter combination corresponding to the new position vector is less than the fitness before the update, and the random number is less than the loudness of the corresponding bat. After each acceptance of a candidate strategy parameter combination, the loudness of the corresponding bat is reduced, and its pulse emission probability is increased.

[0094] For each individual bat, counterfactual replay is performed in the shadow policy space, and fitness is calculated according to the following formula: ; in, This represents the fitness of the b-th bat individual; a smaller value indicates a better candidate strategy. Indicates the attack false negative rate; This indicates the false blocking rate of legitimate requests; This represents the normalized average request processing time. This indicates the decrease in the average risk score of samples with protocol ambiguity. Indicates a penalty term for invalid combinations; to This represents the preset fitness weights, and the sum of all preset fitness weights is 1.

[0095] In one embodiment of the present invention, since the primary focus of security protection is on preventing missed detections and false positives, a preset fitness weight is used. to These can be set as: attack false negative rate weights Weight of false blocking rate for normal requests Average request processing time weight Weighting of the magnitude of the decrease in risk of ambiguous samples in the protocol Invalid combination penalty term weight .

[0096] When the maximum number of iterations is reached, the fitness change is less than the fitness convergence threshold, or the longest duration of a single policy optimization is reached, policy optimization is stopped, the candidate policy parameter combination with the smallest fitness is determined as the optimization candidate policy, and the optimization candidate policy, the optimal fitness, and the counterfactual replay results are output to step S520.

[0097] S520: Using the current stable policy version and the optimized candidate policy output in step S510, risk identification is performed on the pre-set trusted sample set, mirrored traffic sample set, and protocol ambiguity sample set. Policy boundary echo is a structured record of the changes in model risk score, comprehensive risk score, and request risk level output by the current stable policy version and the optimized candidate policy for the same evaluation sample.

[0098] For the s-th evaluation sample, the boundary displacement is calculated according to the following formula: ; in, This represents the boundary displacement of the s-th evaluation sample; s represents the evaluation sample number. This represents the comprehensive risk score output by the optimized candidate strategy for the s-th evaluation sample; This represents the comprehensive risk score output by the current stable strategy version for the s-th evaluation sample.

[0099] The system reads the application-layer firewall's pre-configured boundary condition table and determines the allowed range for normal samples to float upwards, the allowed range for abnormal samples to fall downwards, the allowed range for samples with protocol ambiguity to fall downwards, the allowed increment for false positive rate blocking, the allowed increment for false negative rate, the allowed number of changes in request risk level, and the maximum processing time. If any indicator exceeds the allowed range, the system determines that the optimization candidate strategy does not meet the preset boundary conditions.

[0100] For optimization candidate strategies that do not meet the preset boundary conditions, candidate feedback samples that cause abnormal boundary changes are selected from the subset of candidate update samples output in step S420. For the first... For each candidate feedback sample, the counterfactual replay is performed again, with and without the sample, and the sample contamination contribution value is calculated according to the following formula: ; in, Indicates the first The sample contamination contribution value of each candidate feedback sample; Indicates that the first [number] is reserved. Fitness of candidate feedback samples; Indicates the removal of the first Fitness after 10 candidate feedback samples.

[0101] When a sample's contamination contribution value exceeds a preset contamination contribution threshold, and the decrease in the average risk score of ambiguous samples is mitigated after removing the sample, that sample is added to the contaminated sample set. For example, if retaining a sample causes the average risk score of ambiguous samples to decrease from 0.86 to 0.51, and removing the sample restores the average risk score to 0.82, then that sample is identified as a contaminated sample.

[0102] Output the strategy boundary echo, boundary displacement, boundary condition judgment result, contaminated sample set, and sample contamination contribution value to step S530.

[0103] S530. When step S520 determines that the optimized candidate strategy meets the preset boundary conditions, save the current stable strategy version before the update, sequentially write the new AI model version, risk threshold, and rule entries, and write the verified candidate freezing condition combination into the freezing condition library. After completing the consistency check of the model version, risk threshold, rule entries, and freezing condition library version, generate a new official interception strategy version number, and switch this official interception strategy version to the current stable strategy version. If any write or consistency check step fails, do not switch to a new version, and continue to use the current stable strategy version before the update.

[0104] The freeze condition library is a structured set of conditions persistently stored by the application layer firewall. It records the type of state change that can trigger the freezing of subsequent byte segments, the protocol state position, the byte segment characteristics, the parsing difference mode, the length of the forward context bytes, the length of the backward context bytes, the maximum length of the frozen bytes, and the maximum freeze duration.

[0105] When the optimized candidate strategy does not meet the preset boundary conditions, stop writing the optimized candidate strategy into the formal interception strategy and continue to use the current stable strategy version; at the same time, delete the contaminated sample set from the candidate update sample subset, write a contaminated isolation mark for each contaminated sample, and write the contaminated sample into the isolation sample library to prevent it from directly entering the subsequent incremental training of artificial intelligence models.

[0106] For contaminated samples, extract the corresponding request number, connection identifier, Uniform Resource Locator (URL) path, parameter structure, protocol state location, byte segment characteristics, and parsing difference patterns. When multiple contaminated samples repeatedly exhibit the same parsing difference pattern during the same protocol processing stage, a new freezing condition is formed. The new freezing condition is input into the shadow policy space, and counterfactual replay is performed using a pre-set trusted sample set; when the newly added freezing condition does not cause a concentrated freezing of normal requests, it is written into the freezing condition library.

[0107] In the next round of processing new application access requests, step S220 reads the already effective freeze conditions from the freeze condition library and matches the current connection's corresponding state change type, protocol state position, and byte segment characteristics with the freeze conditions. If a match is successful, the corresponding byte segment is directly identified as the core frozen byte segment. This forms a closed-loop protection process: application access request collection, protocol ownership verification, dual-path isolation parsing, AI risk identification, tiered interception execution, bat algorithm strategy optimization, policy boundary echo verification, contaminated sample isolation, and freeze condition library write-back.

[0108] Example 2: Figure 2 As shown, this embodiment provides an AI-integrated application-layer firewall intelligent interception system. The system is deployed at the IoT application entry point and includes a request collection module, a protocol ownership processing module, a dual-path isolation and parsing module, a risk identification and interception module, a candidate policy generation module, and a policy optimization and update module. The request collection module is used to collect the connection status, session status, proxy forwarding link record, backend response status and valid data fragments corresponding to application access requests. It sorts, deduplicates and concatenates the valid data fragments to form the raw byte stream and standardized request record. It divides byte segments according to protocol type, connection status, request boundary and protocol parsing progress, establishes a candidate attribution set and determines the attribution confirmation status, and generates the raw byte segment sequence, status change event and protocol status mark sequence. The protocol ownership processing module is used to construct a protocol ownership ledger based on the original byte segment sequence, candidate ownership set, ownership confirmation status, status change event and protocol status flag sequence, determine the core frozen byte segment based on the ownership confirmation status and the freeze condition library, expand the range of frozen bytes by combining the parsing context configuration table, form a frozen byte segment set and suspend the corresponding data transmission. The dual-path isolation parsing module is used to select the pre-switch parser and the post-switch parser from the protocol parser configuration library, perform dual-path parsing on the frozen byte segment set in the isolation parsing environment, and generate the pre-switch isolation parsing result and the post-switch isolation parsing result; The risk identification and interception module compares the isolation analysis results before and after the handover to generate a protocol ownership gap set. Based on standardized request records, historical interception records, state change events, and the protocol ownership gap set, it extracts request risk feature vectors, inputs these vectors into an artificial intelligence model, and combines them with a rule engine to generate a tiered interception strategy. Based on the tiered interception strategy, it executes request allowance, continuous monitoring, rate limiting, connection freezing, isolation, blocking, or alarms to form the interception execution result. The candidate strategy generation module is used to associate the ownership gap set of the related protocol, the request risk feature vector, the output results of the artificial intelligence model, the rule matching results, and the interception execution results to form a candidate feedback sample set; based on the evidence direction value and the sample credibility, a candidate update sample subset is selected, and based on the candidate update sample subset, a candidate model update package, a candidate risk threshold combination, a candidate rule entry combination, and a candidate freeze condition combination are generated to form a candidate strategy parameter set; The strategy optimization and update module is used to optimize the candidate strategy parameter set in the shadow strategy space using the bat algorithm to generate optimized candidate strategies; it performs risk identification on the evaluation samples using the current stable strategy version and the optimized candidate strategies respectively, generates strategy boundary echoes and calculates boundary displacements; when the preset boundary conditions are met, it updates the current stable strategy version and writes the verified candidate freezing condition combination into the freezing condition library; when the preset boundary conditions are not met, it locates the contaminated sample set, writes the contaminated sample set into the isolation sample library, and generates new freezing conditions based on the protocol state position, byte segment features and parsing difference patterns corresponding to the contaminated samples.

[0109] All the above formulas are performed using dimensionless numerical calculations; the relevant formulas are based on empirical models that approximate the real situation, obtained through extensive data collection and software simulation fitting. The preset parameters and thresholds involved in the formulas can be conventionally set and adjusted by those skilled in the art according to the physical constraints of the actual application scenario.

[0110] Those skilled in the art will recognize that the modules and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0111] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0112] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A smart interception method for application-layer firewalls integrating AI, characterized in that, Includes the following steps: S1. Collect the raw byte stream, request header fields, Uniform Resource Locator path, request parameters, payload content, connection status, session status and historical interception records corresponding to the application access request, and generate a protocol status tag sequence; S2. Construct a protocol ownership ledger based on the protocol status mark sequence, determine the core frozen byte segments based on the ownership confirmation status and the freeze condition library, form a frozen byte segment set, and use the pre-switch parser and post-switch parser to generate isolation parsing results; S3. Compare the isolation resolution results, generate a set of protocol ownership gaps, extract the request risk feature vector, input it into the artificial intelligence model and combine it with the rule engine to generate a hierarchical interception strategy; S4. Execute the hierarchical interception strategy to form the interception execution result. Based on the protocol ownership gap set, the request risk feature vector, and the interception execution result, construct a candidate feedback sample set, filter the candidate update sample subset, and generate a candidate strategy parameter set.

2. The application-layer firewall intelligent interception method integrating AI according to claim 1, characterized in that, Also includes: S5. In the shadow policy space, the bat algorithm is used to optimize the candidate policy parameter set, generate optimized candidate policies, locate the contaminated sample set based on policy boundary echo verification, and update the current stable policy version and the freeze condition library.

3. The application-layer firewall intelligent interception method integrating AI according to claim 1, characterized in that, S1 specifically includes: After decryption at the transport layer, the connection status, session status, proxy forwarding link record, backend response status and valid data fragments corresponding to the application access request are collected. The data fragments are sorted, deduplicated and concatenated according to the connection identifier, transmission sequence number and payload length to form the original byte stream and standardized request record. The byte segments are divided according to the protocol type, connection status, request boundary and protocol parsing progress. A candidate attribution set is established and the attribution confirmation status is determined to form the original byte segment sequence. Identify changes in protocol upgrade, tunnel establishment, connection reuse, or proxy forwarding status, generate status change events, and form a protocol status tag sequence according to byte segment numbers, which is then output to step S2 for subsequent processing.

4. The application-layer firewall intelligent interception method integrating AI according to claim 1, characterized in that, S2 specifically includes: Based on the original byte segment sequence, candidate ownership set, ownership confirmation status, status change event, and protocol status mark sequence, construct a protocol ownership ledger according to the connection identifier and byte segment number, and write the protocol ownership, protocol processing stage, request number, freeze status, and parsing version number. The core frozen byte segment is determined based on the state change event and the freeze condition library. The range of frozen bytes is expanded by combining the parsing context configuration table, and the frozen byte segment set is formed by merging them. Data transmission is then paused.

5. The application-layer firewall intelligent interception method integrating AI according to claim 4, characterized in that, Also includes: Select the pre-switch parser and post-switch parser from the protocol parser configuration library, perform dual-path parsing on the frozen byte segment set in the isolation parsing environment, and generate the pre-switch isolation parsing result and the post-switch isolation parsing result.

6. The intelligent interception method for an application-layer firewall integrating AI according to claim 1, characterized in that, S3 specifically includes: Compare the isolation parsing results before and after the handover to identify differences in the number of requests, message boundaries, request header field ownership, payload ownership, session status, parsing end position or parsing completion status, and form a set of protocol ownership gaps. Based on standardized request records, historical interception records, state change events, and protocol ownership gap sets, malicious payload features, abnormal call features, access frequency features, context association features, and protocol gap features are extracted and normalized to form a request risk feature vector.

7. The intelligent interception method for an application-layer firewall integrating AI according to claim 6, characterized in that, Also includes: The request risk feature vector is input into the artificial intelligence model, and combined with the rule engine to calculate a comprehensive risk score, determine the request risk level, and generate a graded interception strategy.

8. The intelligent interception method for an application-layer firewall integrating AI according to claim 1, characterized in that, S4 specifically includes: Based on the tiered interception strategy and execution configuration table, the system performs actions such as request allowance, continuous monitoring, rate limiting, connection freezing, isolation, blocking, or alarm, resulting in an interception execution outcome. The associated protocol ownership gap set, request risk feature vector, model risk score, comprehensive risk score, attack type identification result, rule matching result and interception execution result form a candidate feedback sample set, and the candidate update sample subset is selected based on the evidence direction value and sample credibility; Based on the candidate update sample subset, candidate model update packages, candidate risk threshold combinations, candidate rule entry combinations, and candidate freeze condition combinations are generated to form a candidate strategy parameter set, which is then output to step S5 for strategy optimization.

9. The intelligent interception method for an application-layer firewall integrating AI according to claim 2, characterized in that, S5 specifically includes: The candidate policy parameter set is written into the shadow policy space. The bat algorithm is used to combine a pre-set trusted sample set, a mirror traffic sample set and a protocol ambiguity sample set to perform counterfactual replay and fitness evaluation to obtain the optimized candidate policy. Risk identification is performed on the evaluation samples using the current stable strategy version and the optimized candidate strategy, respectively. Strategy boundary echoes are generated, boundary displacements are calculated, and contaminated sample sets are located when preset boundary conditions are not met. When the preset boundary conditions are met, the current stable policy version is updated and written to the freeze condition library. When the preset boundary conditions are not met, the contaminated sample is isolated, and the corresponding protocol state position, byte segment features and parsing difference patterns are extracted to form new freeze conditions.

10. An AI-integrated application-layer firewall intelligent interception system, employing the AI-integrated application-layer firewall intelligent interception method as described in any one of claims 1 to 9, characterized in that, include: The request collection module is used to collect the connection status, session status, proxy forwarding link records, backend response status, and valid data fragments corresponding to application access requests. The protocol ownership processing module is used to construct a protocol ownership ledger based on the original byte segment sequence, candidate ownership set, ownership confirmation status, status change events, and protocol status flag sequence. The dual-path isolation parsing module is used to select the pre-switch parser and post-switch parser from the protocol parser configuration library and perform dual-path parsing on the frozen byte segment set in the isolation parsing environment; The risk identification and interception module compares the isolation analysis results before and after the handover to generate a protocol ownership gap set; it extracts request risk feature vectors based on standardized request records, historical interception records, state change events, and the protocol ownership gap set. The candidate strategy generation module is used to associate the ownership gap set of the related agreement, the request risk feature vector, the output of the artificial intelligence model, the rule matching result, and the interception execution result to form a candidate feedback sample set; The strategy optimization and update module is used to optimize the candidate strategy parameter set in the shadow policy space using the bat algorithm to generate optimized candidate strategies.

Images