CN116781314A - Method, device and storage medium for verifying system access request - Google Patents
Method, device and storage medium for verifying system access request Download PDFInfo
- Publication number
- CN116781314A CN116781314A CN202310032955.4A CN202310032955A CN116781314A CN 116781314 A CN116781314 A CN 116781314A CN 202310032955 A CN202310032955 A CN 202310032955A CN 116781314 A CN116781314 A CN 116781314A
- Authority
- CN
- China
- Prior art keywords
- verification
- request
- verified
- rule
- module
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 47
- 238000012795 verification Methods 0.000 claims abstract description 301
- 239000000284 extract Substances 0.000 claims description 8
- 238000007670 refining Methods 0.000 claims description 4
- 238000003012 network analysis Methods 0.000 claims description 2
- 239000003795 chemical substances by application Substances 0.000 description 18
- 230000007547 defect Effects 0.000 description 10
- 238000010586 diagram Methods 0.000 description 6
- 238000010200 validation analysis Methods 0.000 description 5
- 238000010606 normalization Methods 0.000 description 4
- 230000018109 developmental process Effects 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 3
- 230000003287 optical effect Effects 0.000 description 3
- 238000012360 testing method Methods 0.000 description 3
- 238000011161 development Methods 0.000 description 2
- 230000006870 function Effects 0.000 description 2
- 238000013507 mapping Methods 0.000 description 2
- 239000013307 optical fiber Substances 0.000 description 2
- 230000000644 propagated effect Effects 0.000 description 2
- 239000008186 active pharmaceutical agent Substances 0.000 description 1
- 230000002411 adverse Effects 0.000 description 1
- 238000004458 analytical method Methods 0.000 description 1
- 230000006399 behavior Effects 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000002347 injection Methods 0.000 description 1
- 239000007924 injection Substances 0.000 description 1
- 238000010801 machine learning Methods 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 239000000243 solution Substances 0.000 description 1
- 230000033772 system development Effects 0.000 description 1
- 238000012549 training Methods 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
- H04L63/1441—Countermeasures against malicious traffic
- H04L63/1466—Active attacks involving interception, injection, modification, spoofing of data unit addresses, e.g. hijacking, packet injection or TCP sequence number attacks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Debugging And Monitoring (AREA)
Abstract
The application discloses a method, a device and a storage medium for verifying a system access request. According to the method, a request to be verified is intercepted through an agent module, the request to be verified is an access request initiated to a target system, and the agent module analyzes the request to be verified. And then the agent module sends the parsed request to be verified to a verification module, wherein the verification module comprises a verification engine, and the verification engine supports the customization of the verification rules. And the verification engine verifies the standardability of the request to be verified according to a self-defined verification rule to obtain a verification result, and sends the verification result to the proxy module, and the proxy module performs corresponding operation according to the verification result. The application also discloses a device and a storage medium for verifying the system access request. In the embodiment of the application, the definition of the rule is realized, the expandability is realized, and the verification of the request to be verified is completed.
Description
Technical Field
The present disclosure relates to the field of computer technologies, and in particular, to a method, an apparatus, and a storage medium for verifying a system access request.
Background
With the development of computer and internet technologies, a request to be verified of a Web system is an essential feature of the system. The request to be checked can be normalized to the data format input into the system on the one hand, and can avoid potential attack on the other hand. However, the user input verification characteristic of the existing Web system has defects, when the system development is completed, the built-in input verification logic is fixed, and under the condition that the verification requirement of some users exceeds the fixed verification logic in the system, the system cannot meet the verification requirement of the users.
Therefore, how to realize the verification of the request to be verified by the user becomes a technical problem to be solved when the fixed verification logic in the system cannot meet the verification requirement of the user.
Disclosure of Invention
In view of this, the embodiments of the present disclosure provide a method, an apparatus, and a storage medium for verifying a system access request, which aim to complete verification of a request to be verified by a user when fixed verification logic in the system cannot meet a user verification requirement.
In a first aspect, an embodiment of the present disclosure provides a method for verifying a system access request, where the method includes:
the agent module intercepts a request to be checked, wherein the request to be checked is an access request initiated to a target system;
the proxy module analyzes the request to be verified;
the agent module sends the parsed request to be verified to a verification module, wherein the verification module comprises a verification engine, and the verification engine supports the customization of verification rules;
the verification engine verifies the standardability of the request to be verified according to a self-defined verification rule to obtain a verification result, and sends the verification result to the proxy module;
and the proxy module performs corresponding operation according to the verification result.
In a second aspect, an embodiment of the present disclosure provides an apparatus for verifying a system access request, where the apparatus includes:
the system comprises an agent module and a verification module; the verification module comprises a verification engine, and the verification engine supports the customization of verification rules;
the agent module is used for intercepting a request to be verified, analyzing the request to be verified and sending the analyzed request to be verified to the verification module;
the verification module is used for verifying the standardability of the request to be verified according to a self-defined verification rule through the verification engine and sending a verification result to the proxy module;
the agent module is also used for carrying out corresponding operation according to the verification result obtained by the verification sub-module.
In a third aspect, embodiments of the present disclosure provide a computer storage medium having code stored therein, which when executed, causes an apparatus running the code to implement the method of any one of the preceding aspects.
When the method is executed, a user uses an address after the proxy module is proxy to access a target system and initiate a request, the proxy module firstly needs to intercept and analyze the request to be checked, then the proxy module sends the analyzed request to be checked to the check module, a check engine in the check module self-defines a check rule, the request to be checked is checked according to the self-defined check rule, whether the request to be checked meets the specification is judged, and corresponding operation is carried out according to a judgment result. Therefore, the verification engine in the verification module realizes the customization of rules and has expandability, and when the fixed verification logic in the system can not meet the user verification requirement, the verification of the request to be verified of the user is completed.
Drawings
The above and other features, advantages, and aspects of embodiments of the present disclosure will become more apparent by reference to the following detailed description when taken in conjunction with the accompanying drawings. The same or similar reference numbers will be used throughout the drawings to refer to the same or like elements. It should be understood that the figures are schematic and that elements and components are not necessarily drawn to scale.
FIG. 1 is a flow chart of a method for verifying a system access request provided by an embodiment of the present disclosure;
FIG. 1a is a flow chart of the operation of an actuator;
FIG. 2 is a flow chart of a custom check rule;
FIG. 3 is a flow chart for verifying the normalization of the request to be verified;
FIG. 4a is a diagram of the cooperative relationship of an actuator, a verification rule, and a verification term;
FIG. 4b is a collaborative flow diagram of an actuator, a validation rule, and a validation term;
fig. 5 is a schematic diagram of an apparatus for verifying a system access request.
Detailed Description
Embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. While certain embodiments of the present disclosure have been shown in the accompanying drawings, it is to be understood that the present disclosure may be embodied in various forms and should not be construed as limited to the embodiments set forth herein, but are provided to provide a more thorough and complete understanding of the present disclosure. It should be understood that the drawings and embodiments of the present disclosure are for illustration purposes only and are not intended to limit the scope of the present disclosure.
The term "including" and variations thereof as used herein are intended to be open-ended, i.e., including, but not limited to. The term "based on" is based at least in part on. The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments. Related definitions of other terms will be given in the description below.
It should be noted that references to "one", "a plurality" and "a plurality" in this disclosure are intended to be illustrative rather than limiting, and those of ordinary skill in the art will appreciate that "one or more" is intended to be understood as "one or more" unless the context clearly indicates otherwise.
In the prior art, a request to be verified of a Web system can also be understood as user input verification, which is an essential characteristic of the system. The request to be checked can normalize the data format input into the system on the one hand, and can avoid potential attack behaviors such as: SQL injection attacks, xss attacks, etc. However, the user input verification feature of the current Web system has the following drawbacks: after the development of some Web systems is finished, the built-in input check logic is fixed, and if a user wants to add a custom check rule with finer granularity on the basis of the existing check logic, the system cannot meet the check requirement.
Based on this, the present disclosure proposes a method for verifying a system access request, which can implement verification of a request to be verified by a user when fixed verification logic in the system cannot meet a user verification requirement, and the specific method includes:
intercepting and analyzing a request to be checked through an agent module, then carrying out self-defined check rules on the request to be checked by using a check engine in a check module, checking the request to be checked according to the self-defined check rules, judging whether the request to be checked meets the specification or not, and then carrying out corresponding operation according to a judgment result. Therefore, the self definition of rules and expandability are realized through the verification engine in the verification module, and when verification requirements cannot be met due to inherent verification logic in the system, verification of the request to be verified is realized.
Fig. 1 is a flowchart of a method for verifying a system access request according to an embodiment of the present disclosure. Referring to fig. 1, the implementation of the present application comprises the steps of:
step 101: the agent module intercepts a request to be verified, wherein the request to be verified is an access request initiated to a target system.
The proxy module can be a proxy program written by using a network programming API, and intercepts a specified request to be verified according to an interception rule. The interception rules are obtained by analyzing a target system in advance by an agent module developer, the developer captures a network request corresponding to a submitting operation on the target system interface through a network analysis tool, the URL types of the corresponding requests when a user submits different business data are obtained, the corresponding interception rules are generated according to the URL types, and the interception rules can form a fixed table with a mapping relationship of URL-interception rules and are stored in the agent module. When the agent module captures a request to be verified, the URL of the request to be verified is analyzed, an interception rule with a mapping relation with the ULR is found in the table, and the interception of the request to be verified is realized by using the interception rule.
Step 102: and the proxy module analyzes the request to be verified.
Step 103: the agent module sends the parsed request to be verified to a verification module, wherein the verification module comprises a verification engine, and the verification engine supports the customization of verification rules.
The verification module comprises: and (5) checking an engine. The verification engine comprises an actuator and a verification rule base, fig. 1a is a workflow diagram of the actuator, as shown in fig. 1a, wherein the specific workflow of the actuator is as follows:
1101: receiving reqData, wherein the reqData encapsulates information of a request to be verified, including a URL and request data; 1102: selecting a corresponding check rule according to the URL in reqData; 1103: analyzing the check rule and loading the related check items; 1104: concurrently executing the check items; 1105: summarizing the execution results of each check item, performing logic operation according to the check rule to obtain a check result, and judging whether the check is passed or not.
The concurrent execution of the check items can save resources, and when the check items are more, if the check is not executed concurrently, the single check is executed sequentially, so that the calculation force is wasted, and the check speed is reduced. It is understood that the verification may be performed concurrently, sequentially, and concurrently and sequentially in combination, and the specific implementation manner may be set by those skilled in the art according to actual situations and application scenarios, which is not limited herein.
The verification result can be obtained through logic operation, for example, the verification rule has three verification terms, and if the verification result is found to be correct through verification, the output verification result is assigned to be logic 1; if the verification result is found to be wrong through verification, the output verification result is assigned to be logic 0. The three output verification results are logically operated, and operation may be performed, or operation may be performed, and a specific operation mode may be set by those skilled in the art according to actual situations and application scenarios, and is not limited herein. In the above example, if the and operation mode is adopted, it can be indicated that if and only if the check results of the three check items are all logic 1, the check passes, otherwise the check does not pass.
The specific functions of the verification module are as follows: and identifying a system access request, carrying out rule customization on the access request, and checking the access request by utilizing a customized check rule to obtain a check result.
Step 104: and the verification engine verifies the standardability of the request to be verified according to a self-defined verification rule to obtain a verification result, and sends the verification result to the proxy module.
The check rule is a logic expression formed by a plurality of check items and logic operators, each check rule corresponds to one check type, and the check rule can be configured in a storage component of the check module, such as SQLite, a file and the like. The verification rule may be stored in a table form, or may be stored in a separate code form, and a specific storage form may be set by those skilled in the art according to a specific scenario and actual situation of an actual application, which is not limited herein. The verification rule can be preconfigured before the system operates, can be expanded infinitely in theory, and can adopt different rule combinations for different application scenes, so that the verification rule has self-defining and expandable characteristics.
Step 105: and the proxy module performs corresponding operation according to the verification result.
The verification result can be obtained through the verification of the request to be verified of the system, and the verification result can be: the request to be checked accords with the check rule and the request to be checked does not accord with the check rule. When the verification result is that the request to be verified accords with the verification rule, the proxy module forwards the request to be verified to the target system; when the verification result is that the request to be verified does not accord with the verification rule, the proxy module refuses to refuse the request to be verified, the proxy module redirects the request to be verified to a verification failure prompt page, and a verification failure information list is displayed on the verification failure prompt page.
In this embodiment, a user uses an address after the proxy module proxies to access a target system and initiate a request, first the proxy module intercepts and analyzes a request to be verified, then the proxy module sends the analyzed request to be verified to a verification module, a verification engine in the verification module self-defines a verification rule, verifies the request to be verified according to the self-defined verification rule, determines whether the request to be verified meets a specification, and performs corresponding operation according to a determination result. Therefore, the interception and the verification of the request to be verified of the system realize that the input of a user is strongly restrained, and the request data which does not pass the verification cannot be submitted to a target system, meanwhile, the request to be verified can realize that the verification rule is added, and the verification of the request to be verified is completed by adding the customized verification rule with finer granularity on the basis of the existing input verification logic of the system.
The application provides a further embodiment of a method for verifying a system access request, and fig. 2 is a flow chart of a custom verification rule. As shown in fig. 2, the customization of the verification rule mentioned in step 103 in the method provided in the foregoing embodiment may be implemented by the following steps:
step 201: the purpose of the validation rule is determined.
The proxy module mentioned in step 103 sends the parsed request to be verified to the verification module, where the request to be verified may include some service data that the user accesses the target system through the configured proxy address and submits during operation, for example: forms, rich text content, etc. Intercepting and analyzing a request to be checked through an agent module, solving and separating out URL and request data from the request to be checked, and sending the URL and the request data to a check module, wherein the check module needs to configure corresponding check rules according to the request data, and the check rules are determined firstly, for example, the check rules can be determined: "whether the form contents in the check document are filled in the specification", "whether the filling content of a certain field in the form accords with the specification", "checking compliance of defect type descriptive information filled in by software testers", and the like.
Step 202: and refining the verification rule according to the purpose.
The verification purpose can be understood as a central idea of the verification rule relative to the verification rule, the verification rule takes the verification purpose as a task, and the user definition of the verification rule to be completed needs to be further disassembled and refined for the verification purpose until each verification rule becomes each step for completing the verification purpose, so that the verification rule has the realizability and has the property of finer granularity.
Step 203: writing the refined check rules into different check item classes and adding the check item classes into a check rule table.
Aiming at the thinned check rule, the check rule needs to be written into different check item classes, then the check item classes are compiled into byte code files, and the byte code files are placed under a contracted directory. Records can be added in the check rule table by a manager of the system, so that the validation of the custom check rule can be realized. Specific recorded contents may include: numbering, URL prefix of intercepted request to be checked, check rule content and concrete description of request data corresponding to the request to be checked. The recorded content can be freely set by those skilled in the art according to the actual situation and application scenario, and is not limited herein. Wherein the check rule is formed by arranging one or more check items.
For example, when the compiling language is Java, a custom verification rule is added to a defect management system in a software development process, and the rule is used for verifying compliance of defect description information filled by a software tester. The verification purpose at this time is: and checking compliance of defect description information filled by software testers. The verification rule for the verification purpose can be refined as follows: 1) The defect description information of a defect tracking list must contain descriptive words; 2) The defect description information of a defect tracking ticket must contain a screenshot. At this time, two corresponding check item classes need to be written for the thinned check rule: 1) DefectDespMustContainTxt.java 2) DefectDespMustContainImg.java. Both classes implement the following check interface: public CheckResult check (ReqData reqData). At this time, the pseudo codes corresponding to the two classes are:
and compiling the two check item classes into byte code files, and putting the byte code files into a contracted directory. Finally, the following records are added in the check rule table: the intercepted URL prefix: per issue/bug/addBug; the corresponding request data check rule content: defectDespMustContainTxt & & DefectDespMustContainImg; description: and checking whether the description field of the defect tracking list submitted by the user contains text and pictures at the same time. Thus, the validation of the custom check rule can be realized.
In this embodiment, the purpose of the verification rule is determined, the verification rule is refined according to the verification purpose, and finally the refined verification rule is written into different verification item classes and added into the verification rule table. By utilizing the method, the customization of the check rule can be realized, so that a user can add the customized check rule with finer granularity on the basis of the existing input check logic of the system.
The application provides a further embodiment of a method for verifying a system access request, and fig. 3 is a flowchart for verifying the normalization of the request to be verified. As shown in fig. 3, the verification of the normalization of the request to be verified mentioned in step 104 in the method provided in the foregoing embodiment may be implemented by the following steps:
step 301: the verification rule library carries out configuration of verification rules for the request to be verified according to the request to be verified;
the check rule base can be a database or a file and the like which are configured in a storage component of the check module, the check rule base contains check rules, the check rules can be preconfigured before the system operates, can be infinitely expanded in theory, and can be combined by different rules in different application scenes, so that the check rules have the characteristics of being customizable and expandable.
Step 302: and the executor reads the configured verification rule, extracts the name of the verification term and verifies the request to be verified.
The verification process of the request to be verified can be understood as a process of matching with the verification rule, if the request to be verified meets the requirement, if the request to be verified does not meet the requirement, the request to be verified does not meet the requirement.
In this embodiment, the configuration of the verification rule is performed for the request to be verified according to the request to be verified through the verification rule library, then the executor reads the configured verification rule, extracts the name of the verification item, and verifies the request to be verified. In this way, verification of the request to be verified is achieved.
The verification engine is composed of an executor, a verification rule and a verification term, wherein fig. 4a and fig. 4b show the operation mechanism of the verification engine together, fig. 4a is a collaborative relation diagram of the executor, the verification rule and the verification term, and the programming language is Java as an example, wherein 1 and 2 refer to that the executor reads the configured verification rule, and the verification term name is extracted through grammar analysis. Wherein 3, 4, 5, 6 and 7 refer to that the executor loads the corresponding check-term bytecode file from the appointed system directory by using the class loader according to the check-term name, and finds out the public CheckResult check (ReqData) method in the corresponding check-term bytecode file by using the reflection mechanism of the Java language. FIG. 4b is a flow chart of collaboration among an actuator, a verification rule, and a verification term, as shown in FIG. 4b, where the collaboration among the actuator, the verification rule, and the verification term may be implemented by:
step 401: writing a check item source file.
The verification term source file can be written in a programming language such as Java, python, C, C ++. Each check item is a separate class. For example, taking the programming language as Java as an example, each check term is a compiled Java class file, and the following interfaces are implemented: public CheckResult check (ReqData); the parameter reqData of the interface encapsulates the request information, including the URL and the request data.
The return value of the interface CheckResult has two properties: respectively of the Boolean type and of the String type. And the Boolean type test result is valued as true or false, which indicates that the test passes or fails. The String type test results indicate message, and when result is false, the reason for the failure is pointed out.
All check items are placed in a specified system directory in the form of Java class files for the check engine to load and execute check (reqData) methods therein through the Java reflection mechanism. The core of the Java reflection mechanism is to dynamically load the class and acquire detailed information of the class when the program runs, so as to operate the attribute and the method of the class or the object. The essence is that after the JVM obtains the class object, decompilation is performed through the class object, so that various information of the object is obtained.
Step 402: the check item source code is compiled into a bytecode file.
Compiling the compiled check item Java program source file (Java suffix) into a Java class file (class suffix) through a Java command, wherein the Java class file is the check item which can be loaded and executed by the check engine.
Step 403: the bytecode file is placed into a specified system directory.
Step 404: and configuring a check rule.
The check rules may be stored in a tbl_check_rule table within the SQLite database built into the check module.
Step 405: the executor reads the configured check rule and extracts the check item name.
When the executor executes the executeCheck (reqData) method (executeCheck (reqData) method refers to resolving a request to be verified), the tbl_check_rule table is accessed through JDBC, and the verification rule content corresponding to the URL in reqData is queried.
Step 406: and the executor loads the corresponding byte code file according to the name of the check item to execute check.
Step 407: and summarizing the result of the verification.
In this embodiment, an operation mechanism of a verification engine is described, the verification engine is composed of an executor, a verification rule, and a verification term, and each verification on a request to be verified is implemented by the verification rule. Each verification rule needs to be configured, the configured main body can be a system administrator, an operating system or program codes, and the selection of the main body can be set by a person skilled in the art according to application scenes and actual conditions, and the main body is not set here.
The verification rule is formed by arranging one or more verification items, the arrangement mode can be free combination, ordered combination or unordered combination, and the like, and the arrangement sequence of the verification items does not have adverse effect on verification, so the verification rule is not limited. The verification term may be generated by a developer through programming, or may be generated by a system through machine learning training, which is not limited herein.
The executor, the check rule and the check item cooperate with each other, a check item source code is compiled into a byte code file through writing the check item source file, the byte code file is put into a specified system catalog, the check rule is configured, the executor reads the configured check rule, the check item name is extracted, the executor loads the corresponding byte code file according to the check item name to execute check, and the check result of the execution check is summarized to finish the check on the request to be checked, and meanwhile, the custom check rule with finer granularity is added on the basis of the existing input check logic of the system.
Although operations are depicted in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order. In certain circumstances, multitasking and parallel processing may be advantageous.
It should be understood that the various steps recited in the method embodiments of the present disclosure may be performed in a different order and/or performed in parallel. Furthermore, method embodiments may include additional steps and/or omit performing the illustrated steps. The scope of the present disclosure is not limited in this respect.
Fig. 5 is a schematic structural diagram of an apparatus for verifying a system access request, and as shown in fig. 5, the disclosure further provides an apparatus for verifying a system access request, which includes: a proxy module 100 and a verification module 200; the verification module 200 comprises a verification engine 300, wherein the verification engine 300 supports the customization of verification rules;
the proxy module 100 is configured to intercept a request to be verified, parse the request to be verified, and send the parsed request to be verified to a verification module;
the verification module 200 is configured to verify, by using the verification engine 300 according to a user-defined verification rule, the normalization of the request to be verified, and send a verification result to the proxy module;
the proxy module 100 is further configured to perform corresponding operations according to the verification result obtained by the verification engine 300.
The check rule base 500 in the check engine 300 includes: a purpose determination submodule 501 for determining the purpose of the verification rule;
a rule refinement sub-module 502, configured to refine the verification rule according to the purpose;
the rule adding sub-module 503 is configured to write the refined verification rule into different verification term classes and add the verification term classes to a verification rule table, so as to implement the customization of the verification rule.
The verification engine comprises an executor 400 and a verification rule base 500; the verification module is specifically configured to:
the verification rule library 500 carries out configuration of verification rules for the request to be verified according to the request to be verified;
the executor 400 reads the configured verification rule, extracts the name of the verification term, and verifies the request to be verified.
The present disclosure provides a device for verifying a system access request, where the device intercepts and analyzes a request to be verified through an agent module 100, where the request to be verified is an access request initiated to a target system; then, the proxy module 100 sends the parsed request to be verified to the verification module 200, wherein the verification module comprises a verification engine 300, and the verification engine 300 supports the customization of the verification rule; the verification engine 300 verifies the standardability of the request to be verified according to a self-defined verification rule to obtain a verification result, and sends the verification result to the proxy module 100; the proxy module 100 performs a corresponding operation according to the verification result.
By the device for verifying the system access request, the customized and finer-granularity verification rule can be added on the basis of the existing input verification logic of the system, the process of intercepting the request to be verified through the proxy module and sending the request to the verification module for verification can realize strong constraint on the input of the system, and the request data which does not pass the verification cannot be submitted to the target system, so that the system is free from the interference of illegal request data. Meanwhile, the verification mechanism of the device does not need to invade a system, is completely decoupled from the system, and the verification logic is completely autonomous and controllable.
The modules described in the embodiments of the present disclosure may be implemented in software or hardware. The name of a module is not limited to the module itself in some cases, and the first acquisition unit may be described as a "unit that acquires at least two internet protocol addresses", for example.
The embodiment of the disclosure also provides corresponding equipment and a computer readable storage medium, which are used for realizing the scheme provided by the embodiment of the disclosure.
The device comprises a memory for storing instructions or code and a processor for executing the instructions or code to cause the device to perform a method for verifying a system access request according to any embodiment of the present disclosure.
In practical applications, the computer-readable storage medium may take the form of any combination of one or more computer-readable media. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. The computer readable storage medium can be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or a combination of any of the foregoing. More specific examples (a non-exhaustive list) of the computer-readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In this embodiment, a computer-readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.
The computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, either in baseband or as part of a carrier wave. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination of the foregoing. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.
Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.
Computer program code for carrying out operations of the present application may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, smalltalk, C ++ and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any kind of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or may be connected to an external computer (for example, through the Internet using an Internet service provider).
According to one embodiment of the present disclosure, there is provided a method of verifying a system access request, comprising:
the agent module intercepts a request to be checked, wherein the request to be checked is an access request initiated to a target system;
the proxy module analyzes the request to be verified;
the agent module sends the parsed request to be verified to a verification module, wherein the verification module comprises a verification engine, and the verification engine supports the customization of verification rules;
the verification engine verifies the standardability of the request to be verified according to a self-defined verification rule to obtain a verification result, and sends the verification result to the proxy module;
and the proxy module performs corresponding operation according to the verification result.
According to one embodiment of the present disclosure, there is provided a method of customizing a verification rule, comprising:
determining the purpose of a verification rule;
refining the verification rule according to the purpose;
writing the refined check rules into different check item classes and adding the check item classes into a check rule table to realize the self definition of the check rules, wherein the check rules are formed by arranging one or more check items.
According to one embodiment of the present disclosure, example 3 provides a method of verifying the standardability of the request to be verified, comprising:
the verification rule library carries out configuration of verification rules for the request to be verified according to the request to be verified;
and the executor reads the configured verification rule, extracts the name of the verification term and verifies the request to be verified.
According to one embodiment of the present disclosure, example 4 provides a method for collaborative flow of an executor, a verification rule, and a verification term, including:
writing a check item source file;
compiling the check item source code into a byte code file;
placing the byte code file into a specified system directory;
configuring a verification rule;
the executor reads the configured check rule and extracts the name of the check item;
the executor loads the corresponding byte code file according to the name of the check item to execute check;
and summarizing the result of the verification.
According to one embodiment of the present disclosure, there is provided an apparatus for verifying a system access request, including:
the device comprises: the system comprises an agent module and a verification module; the verification module comprises a verification engine, and the verification engine supports the customization of verification rules;
the agent module is used for intercepting a request to be verified, analyzing the request to be verified and sending the analyzed request to be verified to the verification module;
the verification module is used for verifying the standardability of the request to be verified according to a self-defined verification rule through the verification engine and sending a verification result to the proxy module;
the agent module is also used for carrying out corresponding operation according to the verification result obtained by the verification engine.
According to one embodiment of the present disclosure, there is provided a storage medium for verifying a system access request, comprising:
corresponding devices and computer readable storage media for implementing the solutions provided by the embodiments of the present disclosure.
The device comprises a memory for storing instructions or code and a processor for executing the instructions or code to cause the device to perform a method for verifying a system access request according to any embodiment of the present disclosure.
Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are example forms of implementing the claims.
While several specific implementation details are included in the above discussion, these should not be construed as limiting the scope of the disclosure. Certain features that are described in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination.
The foregoing description is only of the preferred embodiments of the present disclosure and description of the principles of the technology being employed. It will be appreciated by persons skilled in the art that the scope of the disclosure referred to in this disclosure is not limited to the specific combinations of features described above, but also covers other embodiments which may be formed by any combination of features described above or equivalents thereof without departing from the spirit of the disclosure. Such as those described above, are mutually substituted with the technical features having similar functions disclosed in the present disclosure (but not limited thereto).
Claims (11)
1. A method of verifying a system access request, the method comprising:
the agent module intercepts a request to be checked, wherein the request to be checked is an access request initiated to a target system;
the proxy module analyzes the request to be verified;
the agent module sends the parsed request to be verified to a verification module, wherein the verification module comprises a verification engine, and the verification engine supports the customization of verification rules;
the verification engine verifies the standardability of the request to be verified according to a self-defined verification rule to obtain a verification result, and sends the verification result to the proxy module;
and the proxy module performs corresponding operation according to the verification result.
2. The method of claim 1, wherein the customizing the verification rule specifically comprises:
determining the purpose of a verification rule;
refining the verification rule according to the purpose;
writing the refined check rules into different check item classes and adding the check item classes into a check rule table to realize the self definition of the check rules, wherein the check rules are formed by arranging one or more check items.
3. The method of claim 1, wherein the verification engine comprises an executor and a library of verification rules;
the verification engine performs verification on the standardability of the request to be verified according to a self-defined verification rule, and specifically comprises the following steps:
the verification rule library carries out configuration of verification rules for the request to be verified according to the request to be verified;
and the executor reads the configured verification rule, extracts the name of the verification term and verifies the request to be verified.
4. The method of claim 1, wherein the proxy module performs a corresponding operation according to the verification result, including:
if the verification result is that the request to be verified accords with the verification rule, the proxy module forwards the request to be verified to a target system;
if the verification result is that the request to be verified does not accord with the verification rule, the proxy module refuses the request to be verified, redirects the request to be verified to a verification failure prompt page, and displays a verification failure information list on the verification failure prompt page.
5. The method of claim 1, wherein the proxy module intercepting the request to be verified comprises:
the agent module intercepts the request to be checked by utilizing an interception rule, wherein the interception rule is generated after pre-analyzing a target system.
6. The method according to claim 5, wherein the generating the interception rule after pre-analyzing the target system specifically comprises:
capturing a network request corresponding to a submitting operation on an interface of the target system through a network analysis tool, and acquiring a URL type of the network request corresponding to a user when submitting different service data;
and generating interception rules according to the URL types.
7. The method of claim 1, wherein the proxy module resolving the request to be verified comprises:
analyzing the request to be verified to obtain the URL and the input content in the request to be verified.
8. An apparatus for verifying a system access request, the apparatus comprising: the system comprises an agent module and a verification module; the verification module comprises a verification engine, and the verification engine supports the customization of verification rules;
the agent module is used for intercepting a request to be verified, analyzing the request to be verified and sending the analyzed request to be verified to the verification module;
the verification module is used for verifying the standardability of the request to be verified according to a self-defined verification rule through the verification engine and sending a verification result to the proxy module;
the agent module is also used for carrying out corresponding operation according to the verification result obtained by the verification engine.
9. The apparatus of claim 8, wherein the verification engine comprises:
the purpose determining submodule is used for determining the purpose of the check rule;
a rule refinement sub-module for refining the verification rule according to the purpose;
and the rule adding sub-module is used for writing the thinned check rule into different check item classes and adding the check item classes into a check rule table to realize the self definition of the check rule.
10. The apparatus of claim 8, wherein the verification engine comprises an executor and a library of verification rules; the verification module is specifically configured to:
the verification rule library carries out configuration of verification rules for the request to be verified according to the request to be verified;
and the executor reads the configured verification rule, extracts the name of the verification term and verifies the request to be verified.
11. A computer readable storage medium, wherein a program for implementing a method for verifying a system access request is stored on the computer readable storage medium, and the program for implementing the method for verifying a system access request implements the steps of the method according to any one of claims 1-7 when being executed by a processor.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310032955.4A CN116781314A (en) | 2023-01-10 | 2023-01-10 | Method, device and storage medium for verifying system access request |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310032955.4A CN116781314A (en) | 2023-01-10 | 2023-01-10 | Method, device and storage medium for verifying system access request |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN116781314A true CN116781314A (en) | 2023-09-19 |
Family
ID=87984789
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202310032955.4A Pending CN116781314A (en) | 2023-01-10 | 2023-01-10 | Method, device and storage medium for verifying system access request |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN116781314A (en) |
-
2023
- 2023-01-10 CN CN202310032955.4A patent/CN116781314A/en active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Lu et al. | Chex: statically vetting android apps for component hijacking vulnerabilities | |
| US7849509B2 (en) | Detection of security vulnerabilities in computer programs | |
| Felt et al. | Android permissions demystified | |
| TWI575397B (en) | Point-wise protection of application using runtime agent and dynamic security analysis | |
| Lin et al. | Automated forensic analysis of mobile applications on Android devices | |
| US11062022B1 (en) | Container packaging device | |
| US8615750B1 (en) | Optimizing application compiling | |
| US20120017280A1 (en) | APPARATUS AND METHOD FOR DETECTING, PRIORITIZING AND FIXING SECURITY DEFECTS AND COMPLIANCE VIOLATIONS IN SAP® ABAPtm CODE | |
| CN109558320B (en) | System testing method, device, system, equipment and computer readable storage medium | |
| US9262311B1 (en) | Network page test system and methods | |
| CN112149109B (en) | Modularized authority control management method and system | |
| CN108614702B (en) | Byte code optimization method and device | |
| CN107451474A (en) | Software vulnerability restorative procedure and device for terminal | |
| CN113961919B (en) | Malicious software detection method and device | |
| US10705949B2 (en) | Evaluation of library test suites using mutation testing | |
| US7802089B2 (en) | Analyzing interpretable code for harm potential | |
| CN108228312B (en) | System and method for executing code through interpreter | |
| GB2511329A (en) | Web service black box testing | |
| Alzaidi et al. | DroidRista: a highly precise static data flow analysis framework for android applications | |
| CN113760339A (en) | Vulnerability repair method and device | |
| Kim et al. | {FuzzOrigin}: Detecting {UXSS} vulnerabilities in browsers through origin fuzzing | |
| US20140359258A1 (en) | Declarative Configuration Elements | |
| CN111563260A (en) | Android application program-oriented Web injection code execution vulnerability detection method and system | |
| CN110647749A (en) | Second-order SQL injection attack defense method | |
| CN110348226A (en) | A kind of scan method of project file, device, electronic equipment and storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |