A method, device, system and medium for detecting unauthorized access

Abstract

The embodiment of the present invention discloses a method, device, system and medium for detecting unauthorized access. The method includes: if an access request is detected from a client, the request parameters of the access request are marked by a client plug-in; wherein the marked label content is determined based on the configuration file synchronized by the core plug-in; after the client sends the access request to the server, the access request is parsed by a node plug-in to obtain the request parameters and the marked label content; the marked label content is analyzed by the risk detection engine of the node plug-in to obtain risk notification information and provide risk prompts; wherein the risk detection engine performs analysis based on the detection rules synchronized by the core plug-in. This technical solution can provide developers with clear vulnerability handling guidance, improve the detection rate and accuracy of unauthorized access, and effectively reduce false alarms.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a method, device, system and medium for detecting unauthorized access. Background Art

[0002] While the internet has brought convenience to people's lives, the advancement of computer technology also presents numerous potential security risks. Cyber ​​warfare will undoubtedly be the primary battlefield of future wars. Unauthorized access is a common vulnerability, widespread and potentially devastating, and is ranked second among the top ten web application security risks by OWASP.

[0003] In the existing technology, different account identities are mainly constructed to initiate requests for the same operation, and then the response messages are compared to determine whether there is a horizontal privilege escalation vulnerability.

[0004] However, in the era of big data, each user sees different information. For example, different users may see different products on their app homepages. Comparing response messages can easily lead to false positives. Furthermore, this detection method is designed for security testers, and the results are highly specialized, so developers cannot directly use the test results. Summary of the Invention

[0005] The present invention provides a method, device, system and medium for detecting unauthorized access, which can provide developers with clear vulnerability handling guidance, improve the detection rate and accuracy of unauthorized access, and effectively reduce false alarms.

[0006] According to one aspect of the present invention, a method for detecting unauthorized access is provided. The method is performed by an unauthorized access detection system. The system includes a client plug-in, a core plug-in, and a node plug-in. The client plug-in is installed on a client, the node plug-in is installed on a server, and the core plug-in is connected to the client plug-in and the node plug-in and installed on the unauthorized access detection system server. The method includes:

[0007] If an access request is detected from the client, the request parameters of the access request are marked by the client plug-in; wherein the marked label content is determined based on the configuration file synchronized by the core plug-in;

[0008] After the client sends the access request to the server, the node plug-in parses the access request to obtain the request parameters and the labeled label content; wherein the request parameters are used for the server to perform business processing;

[0009] The risk detection engine of the node plug-in analyzes the labeled label content to obtain risk notification information and provide risk prompts; wherein, the risk detection engine performs analysis based on the detection rules synchronized with the core plug-in.

[0010] Optionally, the method further includes:

[0011] If there is an access request initiated by the local end or a relayed access request on the server, the request parameters of the access request initiated by the local end or the relayed access request are marked through the node plug-in; wherein the marked label content is determined based on the configuration file synchronized by the core plug-in.

[0012] Optionally, after analyzing the labeled content through the risk detection engine of the node plug-in to obtain risk notification information and issue a risk prompt, the method further includes:

[0013] Recording the request parameters of the access request, the time of receiving the access request, and the time of responding to the access request in a first log file; and

[0014] The risk notification information of the access request is recorded in a second log file.

[0015] Optionally, the method further includes:

[0016] The second log file is synchronized to the core plug-in so that the unauthorized detection system server can store the second log file.

[0017] Optionally, the content of the label includes whether the parameters are sent to the front end and the parameter attributes;

[0018] The parameter of whether to send data to the front end includes three parameter values: send data to the front end, send data to the front end with transfer required, and send data to the front end;

[0019] The parameter attributes include two parameter values, namely user attributes and public attributes.

[0020] Optionally, after marking the request parameters of the access request by the client plug-in, the method further includes:

[0021] Based on the request parameters of the access request and the marked tag content, the access request is transformed to obtain an access request string in Json format.

[0022] Optionally, the core plug-in includes a Privilege.xml file, and the Privilege.xml file is used to record permissions of all interfaces;

[0023] The core plug-in is used to determine risk notification information based on the permissions of all interfaces recorded in the Privilege.xml file.

[0024] According to another aspect of the present invention, there is provided a device for detecting unauthorized access, the device being configured in an unauthorized access detection system, the system comprising a client plug-in, a core plug-in, and a node plug-in, the client plug-in being installed on a client, the node plug-in being installed on a server, the core plug-in being connected to the client plug-in and the node plug-in, and being installed on a server side of the unauthorized access detection system; the device comprising:

[0025] An access request marking module, configured to mark the request parameters of the access request through the client plug-in if an access request is detected from the client; wherein the marking tag content is determined based on the configuration file synchronized by the core plug-in;

[0026] A parameter and content acquisition module is used to parse the access request through the node plug-in after the client sends the access request to the server to obtain the request parameters and the labeled label content; wherein the request parameters are used for the server to perform business processing;

[0027] The risk warning module is used to analyze the labeled content through the risk detection engine of the node plug-in, obtain risk notification information, and provide risk warnings; wherein, the risk detection engine performs analysis based on the detection rules synchronized with the core plug-in.

[0028] According to another aspect of the present invention, a system for detecting unauthorized access is provided, comprising a client plug-in, a core plug-in, and a node plug-in; the client plug-in is installed on a client, the node plug-in is installed on a server, and the core plug-in is connected to the client plug-in and the node plug-in and is installed on a server of the unauthorized access detection system; wherein:

[0029] The core plug-in is used to synchronize with the client plug-in to determine the labeled label content; and is used to synchronize detection rules with the risk detection engine of the node plug-in for analysis by the risk detection engine;

[0030] The client plug-in is configured to mark the request parameters of the access request if an access request is detected from the client;

[0031] The node plug-in is used to parse the access request after the client sends the access request to the server to obtain the request parameters and the marked label content; wherein the request parameters are used for the server to perform business processing;

[0032] The node plug-in is further used to analyze the labeled content through a risk detection engine, obtain risk notification information, and provide risk prompts.

[0033] According to another aspect of the present invention, a computer-readable storage medium is provided, wherein the computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a processor to implement the method for detecting unauthorized access according to any embodiment of the present invention when executed.

[0034] The technical solution of the embodiment of the present invention is as follows: if an access request is detected from the client, the request parameters of the access request are marked by the client plug-in; wherein, the marked label content is determined based on the configuration file synchronized by the core plug-in; after the client sends the access request to the server, the access request is parsed by the node plug-in to obtain the request parameters and the marked label content; the marked label content is analyzed by the risk detection engine of the node plug-in to obtain risk notification information and provide risk prompts; wherein, the risk detection engine performs analysis based on the detection rules synchronized by the core plug-in. This technical solution can provide developers with clear vulnerability handling guidance, improve the detection rate and accuracy of unauthorized access, and effectively reduce false alarms.

[0035] It should be understood that the content described in this section is not intended to identify the key or important features of the embodiments of the present invention, nor is it intended to limit the scope of the present invention. Other features of the present invention will become readily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0037] Figure 1 This is a flow chart of a method for detecting unauthorized access according to the first embodiment of the present invention;

[0038] Figure 2 This is a basic framework diagram of a method for detecting unauthorized access provided in accordance with the first embodiment of the present invention;

[0039] Figure 3 is a flow chart of a method for detecting unauthorized access according to a second embodiment of the present invention;

[0040] Figure 4 2 is a schematic structural diagram of an unauthorized access detection device according to a third embodiment of the present invention; DETAILED DESCRIPTION

[0041] In order to enable those skilled in the art to better understand the solutions of the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the embodiments described are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of the present invention.

[0042] It should be noted that the terms "first", "second", etc. in the description and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that the numbers used in this way can be interchanged where appropriate, so that the embodiments of the present invention described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0043] Example 1

[0044] Figure 1 A flowchart of a method for detecting unauthorized access is provided for the first embodiment of the present invention. This embodiment is applicable to the case of detecting unauthorized access. The method can be executed by an unauthorized access detection device. The unauthorized access detection device can be implemented in the form of hardware and / or software. The unauthorized access detection device can be configured in an unauthorized access detection system. Figure 1 As shown, the method includes:

[0045] S110: If an access request is detected from the client, the client plug-in tags the request parameters of the access request; wherein the tag content is determined based on the configuration file synchronized by the core plug-in.

[0046] The technical solution of this embodiment can be executed by an unauthorized access detection system. The system includes a client plug-in (ClientModule, CM for short), a core plug-in (KernalModule, KM for short) and a node plug-in (NodeModule, NM for short). The client plug-in CM is installed on the client, and the node plug-in NM is installed on the server. The core plug-in is connected to the client plug-in and the node plug-in, and is installed on the unauthorized access detection system server. The technical solution of this embodiment is based on the principle of horizontal unauthorized access vulnerabilities. All requests to the system are automatically marked by the plug-ins of the client and the server, and the user attributes of the requests are identified. Then, in combination with the risk detection rules, clear vulnerability handling guidance is provided to developers, thereby improving the detection rate and accuracy of horizontal unauthorized access and effectively reducing false alarms. In addition, the implementation of the technical solution of this embodiment depends on a clear understanding of how many interfaces the system has, the parameters of the interfaces, and other information.

[0047] The basic framework of the technical solution of this embodiment is as follows Figure 2 As shown, the front-end client plugin (CM) transforms the intercepted user request, adding the TYPE and PRIV attributes to the request parameters, and sends it to the server. After receiving the transformed request from the client plugin (CM), the server-side node plugin (NM) uses its risk detection engine to perform risk detection on the request and saves the detection results locally. The core plugin (KM) communicates with the client plugin (CM) and the node plugin (NM) to update detection rules and collect detection results. Users can access the core plugin (KM) to obtain global horizontal privilege escalation risks.

[0048] Among them, the access request can be an access request initiated by the user. The client plug-in CM is installed on the client, and its main function is to encapsulate HTTP requests and send requests. For example, the client plug-in CM in this embodiment is installed in the browser in the form of a browser plug-in. All requests sent through the browser can be set to pass through the client plug-in CM, and the client plug-in CM will perform actions such as request parameter tagging, deformation, and sending; all response messages passing through the client plug-in CM will perform message parsing actions. The encapsulated request can include the ability to tag request parameters and deform request messages. Among them, the labeled label content is determined based on the configuration file synchronized with the core plug-in. Request message deformation can be a change in the form of the request message. The change can make it easier for other plug-ins to read and parse the business content and label content in the message. The function of the client plug-in CM to send a request is to use the client plug-in CM as an agent to send the deformed request to the server.

[0049] The request parameters in this embodiment can be labeled by adding two tags, "whether the parameter is sent from the front end" (TYPE) and "parameter attribute" (PRIV), to the request parameters. The parameter TYPE of whether to send the parameter to the front end can have three attributes, including: client, client-node and self. Among them, client means that the parameter is sent from the front end. For all requests passing through the plug-in CM, the parameter will be marked with the tag "TYPE=client"; client-node means that the parameter is sent from the front end and is used as a parameter for initiating an interface-level request; self means that the parameter is obtained by the server, not sent from the front end.

[0050] The PRIV parameter attribute (full name: Privilege) can have two attributes: personal and public. Personal indicates that the parameter value is a user attribute; public indicates that the parameter value is a public attribute. The client plugin (CM) can mark the value based on the Privilege.xml configuration file synchronized from the local core plugin (KM). In the request body, the PRIV value of the parameter inherits the PRIV value of the corresponding interface.

[0051] In this embodiment, the core plug-in KM can be responsible for configuration file synchronization, detection rule synchronization, detection result collection, and log recording. It can be deployed on an independent server. It communicates with CM and NM through designated ports to achieve various synchronization tasks. Among them, the configuration file is stored in the Privilege.xml file and supports user customization. "Personal" means that the resources in {} are private and have user attribute characteristics. "Public" means that the resources in {} are public and do not have user attribute characteristics. When the local Privilege.xml and other configuration files are changed, the changes will be pushed to the client plug-in CM and node plug-in NM in a timely manner.

[0052] In this embodiment, if the unauthorized access detection system detects an access request sent by a user on the client, the client plug-in CM marks the request parameters of the access request, adds parameter TYPE and parameter attribute PRIV to the request parameters to indicate whether to send the parameter to the front end, and sends it to the server.

[0053] S120. After the client sends the access request to the server, the node plug-in parses the access request to obtain the request parameters and the marked label content; wherein the request parameters are used for the server to perform business processing.

[0054] The node plug-in NM can be installed on the server. In this embodiment, the main functions of the node plug-in NM may include: request encapsulation, risk detection engine, logging, and request parsing. Request parsing may be parsing the received request into the original request format, removing the TYPE and PRIV parameters. For example, the received request:

[0055] {

[0056] "name":

[0057] {"VALUE":"beijing","TYPE":"client","PRIV":"personal"}

[0058] }

[0059] Request after parsing and restoring:

[0060] name=beijing

[0061] In this embodiment, after the client sends the access request to the server, the node plug-in NM parses the access request to obtain the request parameters and the labeled label content. The request parameters can be used by the server for business processing.

[0062] S130. Analyze the labeled content through the risk detection engine of the node plug-in to obtain risk notification information and provide risk prompts; wherein the risk detection engine performs analysis based on the detection rules synchronized with the core plug-in.

[0063] The risk detection engine is implemented based on detection rules synchronized with the core plug-in. Risk notification information can include the risk level of the tag content. Risk warnings can also be provided by the node plug-in to indicate whether there is a risk of unauthorized use.

[0064] For example, in this embodiment, the risk detection system uses the node plug-in's risk detection engine to analyze the labeled content in the collected logs based on the detection rules, obtain risk notification information, and issue risk warnings, which are saved in the logs. The risk detection rules are stored under rules.conf and are updated synchronously and regularly by the core plug-in KM. For example, based on the current risk rules, when horizontal risk detection is performed and request A hits rule-2, the node plug-in NM gives a risk warning "Request A hits rule2; the risk is High; there is a horizontal risk of overriding authority." When multiple rules are hit, the node plug-in NM gives multiple risk warnings.

[0065] In this embodiment, the risk detection rules are stored in Rules.conf, which can support user customization. Each rule consists of a complete set of <rules>< / rules>Label composition. <name>Represents the redefined name of this rule; <rule>Represents the validation logic of this rule; <security>Indicates the risk of hitting the rule, including four levels: High, Medium, Low, and Info; <message>Indicates the user prompt information given when the rule is matched, which can be customized by the user.

[0066] For example, Rules.conf looks like this:

[0067] <rules>

[0068] <name> rule-1< / name>

[0069] <rule> PRIV="personal" and TYPE="client-node"< / rule>

[0070] <security> Medium< / security>

[0071] <message> There is a risk of horizontal overreach< / message>

[0072] < / rules>

[0073] <rules>

[0074] <name> Rule-2< / name>

[0075] <rule> PRIV="personal" and TYPE="client"< / rule>

[0076] <security> High< / security>

[0077] <message> There is a risk of horizontal overreach< / message>

[0078] < / rules>

[0079] The technical solution of the embodiment of the present invention is as follows: if an access request is detected from the client, the request parameters of the access request are marked by the client plug-in; wherein, the marked label content is determined based on the configuration file synchronized by the core plug-in; after the client sends the access request to the server, the access request is parsed by the node plug-in to obtain the request parameters and the marked label content; the marked label content is analyzed by the risk detection engine of the node plug-in to obtain risk notification information and provide risk prompts; wherein, the risk detection engine performs analysis based on the detection rules synchronized by the core plug-in. This technical solution can provide developers with clear vulnerability handling guidance, improve the detection rate and accuracy of unauthorized access, and effectively reduce false alarms.

[0080] In this embodiment, optionally, after analyzing the marked label content through the risk detection engine of the node plug-in to obtain risk notification information and issue a risk prompt, the method further includes: if there is an access request initiated by the local end or a transit access request on the server, marking the request parameters of the access request initiated by the local end or the transit access request through the node plug-in; wherein, the marked label content is determined based on the configuration file synchronized by the core plug-in.

[0081] A local access request can be understood as a pure backend-initiated access request; the request parameters in this access request can be obtained by the server. A transit access request can be understood as an access request that comes from the frontend, passes through the server, and is then sent back; all received requests and parameters in this access request can be used as parameters for other interfaces if necessary.

[0082] In this embodiment, the node plug-in NM can be used selectively according to needs and can be installed on the server. The encapsulation request function of the node plug-in NM is the same as that of the client plug-in CM, and the encapsulation request includes the capabilities of marking, deformation, and sending. Among them, the marked label content is determined based on the configuration file synchronized by the core plug-in. For example, in this embodiment, if there is an access request initiated by the local end or a relay access request on the server, the request parameters of the access request initiated by the local end or the relay access request are marked by the node plug-in NM; if all received requests and parameters need to continue to be parameters of other interfaces, the TYPE in the request parameters is modified to "client-node", and other attributes remain unchanged; if the request parameters are obtained by the server, the TYPE is set to "self", and other attributes remain unchanged.

[0083] Through such a setting, this solution automatically tags all requests to the system through client and server plug-ins, identifies the user attributes of the requests, and makes it easier to detect them in combination with risk detection rules.

[0084] Example 2

[0085] Figure 3 This is a flowchart of a method for detecting unauthorized access provided in Example 2 of the present invention. This example is optimized based on the above example. Specifically, after analyzing the labeled content through the node plug-in's risk detection engine to obtain risk notification information and issue a risk warning, the method further includes: recording the request parameters of the access request, the time the access request was received, and the time the access request was fed back through a first log file; and, recording the risk notification information of the access request through a second log file.

[0086] like Figure 3 As shown, the method of this embodiment specifically includes the following steps:

[0087] S310: If an access request is detected from the client, the request parameters of the access request are marked by the client plug-in; wherein the marked label content is determined based on the configuration file synchronized by the core plug-in.

[0088] S320: After the client sends the access request to the server, the node plug-in parses the access request to obtain the request parameters and the marked label content; wherein the request parameters are used for the server to perform business processing.

[0089] S330. Analyze the labeled content through the risk detection engine of the node plug-in to obtain risk notification information and provide risk prompts; wherein the risk detection engine performs analysis based on the detection rules synchronized with the core plug-in.

[0090] S340. Record the request parameters of the access request, the time of receiving the access request, and the time of responding to the access request in a first log file; and record the risk notification information of the access request in a second log file.

[0091] Among them, the first log can be the Message.log log of the node plug-in NM, which can record the request parameters of the access request, the receipt time of the access request, and the feedback time of the access request; the second log can be the Security.log log of the node plug-in NM, which can record the risk notification information of the access request.

[0092] The logging function of the node plug-in NM in this embodiment includes two types: Message.log, which is used to record all request information and time received and sent by the node plug-in NM; Security.log, which is used to record risk prompts given by the node plug-in NM risk detection engine.

[0093] The technical solution of the embodiment of the present invention is as follows: if it is detected that there is an access request from the client, the request parameters of the access request are marked by the client plug-in; after the client sends the access request to the server, the access request is parsed by the node plug-in to obtain the request parameters and the marked label content; the risk detection engine of the node plug-in analyzes the marked label content to obtain risk notification information and issue a risk prompt; the request parameters of the access request, the reception time of the access request and the feedback time of the access request are recorded in the first log file; and the risk notification information of the access request is recorded in the second log file. This technical solution is based on the analysis of the formation principle of horizontal unauthorized access vulnerabilities, and with the help of HTTP communication principles, a horizontal unauthorized access detection framework that can be used by all users is formed. Through this framework, developers can easily locate interfaces that may have horizontal unauthorized access risks and deal with them in a targeted manner to avoid risks.

[0094] In this embodiment, optionally, the method further includes: synchronizing the second log file to a core plug-in, so that the unauthorized detection system server can store the second log file.

[0095] The second log can be the Security.log file of the node plug-in NM, which can record the risk notification information of the access request. In this embodiment, the Security.log file of the node plug-in NM is transferred to the core plug-in KM so that the unauthorized access detection system server can store the second log file.

[0096] In this embodiment, the core plugin KM's detection result collection function synchronizes risk warning information from the Security.log file in each node plugin NM to the core plugin KM and stores it in Security.log. Furthermore, the core plugin KM's logs include Synch.log. Synch.log is used to record communication between the core plugin KM, the client plugin CM, and the node plugin NM.

[0097] Through such a setting, this solution synchronizes the log information of the node plug-in to the core plug-in, which facilitates synchronous update and timely storage.

[0098] In this embodiment, optionally, the content of the marked label includes whether the parameter is sent to the front end and the parameter attributes; the parameter whether to send to the front end includes 3 parameter values, namely, sending to the front end, sending to the front end and requiring transfer, and not sending to the front end; the parameter attributes include 2 parameter values, namely, user attributes and public attributes.

[0099] Among them, the label content of the labeling in this embodiment may include two labels: "whether to send parameters from the front end" (TYPE) and "parameter attributes" (PRIV). Whether to send parameters from the front end TYPE can include three parameter values: client, client-node and self. Among them, client represents that this parameter is sent from the front end. For all requests passing through the plug-in CM, the parameters will be marked with the label "TYPE=client", which can be understood as representing that the parameters are sent from the client; client-node represents that this parameter is sent from the front end and needs to be transferred. It can be understood that some access requests will be sent to the intermediate server through the front end, and then re-assembled by the intermediate server and sent to the back end; self represents that this parameter is obtained by the server and not sent from the front end. It can be understood that it means that the back end first returns to the front end, and the front end sends it to the server. In this implementation, since the front end sending is untrustworthy, it must be marked and marked with the label "TYPE=client"; the back end sending is identified as trustworthy.

[0100] In this implementation, the parameter attribute PRIV can include two parameter values, namely user attributes and public attributes, which can be represented by personal and public. It can be understood that personal represents that this parameter value is a user attribute; public represents that this parameter value is a public attribute. User attributes are relatively sensitive and prone to vulnerabilities; for example, they may be viewed or deleted by other users. In this embodiment, the client plug-in CM can be marked according to the Privilege.xml configuration file synchronized with the local core plug-in KM, which contains interface information. In the request body, the PRIV value of the parameter inherits the PRIV value of the corresponding interface.

[0101] Through such a setting, this solution can automatically label all requests to the system through client and server plug-ins, identify the user attributes of the requests, and further improve the detection rate and accuracy of horizontal unauthorized access.

[0102] In this embodiment, optionally, after the request parameters of the access request are marked by the client plug-in, the method further includes: deforming the access request based on the request parameters of the access request and the marked label content to obtain an access request string in Json format.

[0103] The transformation can be performed by formatting and standardizing the request parameters into a string in JSON format. In this embodiment, the request message transformation function in the client plug-in CM's encapsulated request can format and standardize the request parameters of the access request based on the request parameters and the labeled tag content, thereby obtaining an access request string in JSON format.

[0104] In this embodiment, after the request parameters of the access request are marked by the client plug-in, the request parameters will contain TYPE and PRIV in addition to the parameter value. Therefore, the request parameters are formatted and standardized through transformation and transformed into a string in json format. The example is as follows:

[0105] Original request parameter: name=beijing

[0106] After marking and deformation by the client plug-in CM:

[0107] {

[0108] "name":

[0109] {"VALUE":"beijing","TYPE":"client","PRIV":"personal"}

[0110] }

[0111] Through such a setting, this solution can make it easier for other plug-ins to read and parse the business content and tag content in the message by transforming the access request.

[0112] In this embodiment, optionally, the core plug-in includes a Privilege.xml file, and the Privilege.xml file is used to record permissions of all interfaces; the core plug-in is used to determine risk notification information based on the permissions of all interfaces recorded in the Privilege.xml file.

[0113] Among them, all interfaces can be all interface information of the current system, which may include interface parameter information. In this embodiment, the core plug-in KM configuration file is stored in the Privilege.xml file and can support user customization. The core plug-in KM determines the risk notification information based on the permissions of all interfaces recorded in the Privilege.xml file. The Privilege.xml file records the permissions of all application interfaces; for example, the file content is as follows:

[0114] #personal#

[0115] {

[0116] Interface 1, #Query order

[0117] Interface 2, #Payment

[0118] Interface 3

[0119] }

[0120] #public#

[0121] {

[0122] Interface a, #View announcement

[0123] Interface b

[0124] }

[0125] Through such a setting, the core plug-in KM of this solution can provide developers with clear vulnerability handling guidance by determining risk notification information based on all interface information permissions recorded in the configuration file. In addition, this technical solution is highly scalable. By customizing the configuration rules.xml file and Privilege.xml file, it can increase the detection capability of other business logic vulnerabilities.

[0126] Example 3

[0127] Figure 4 This is a schematic diagram of the structure of an unauthorized access detection device provided in Example 3 of the present invention. The device is configured in an unauthorized access detection system, which includes a client plug-in, a core plug-in, and a node plug-in. The client plug-in is installed on the client, the node plug-in is installed on the server, and the core plug-in is connected to the client plug-in and the node plug-in and is installed on the unauthorized access detection system server. Figure 4 As shown, the device includes:

[0128] An access request marking module 410 is configured to mark the request parameters of the access request through the client plug-in if an access request is detected from the client; wherein the marking tag content is determined based on the configuration file synchronized with the core plug-in;

[0129] The parameter and content acquisition module 420 is used to parse the access request through the node plug-in after the client sends the access request to the server to obtain the request parameters and the labeled label content; wherein the request parameters are used by the server for business processing;

[0130] The risk warning module 430 is used to analyze the labeled content through the risk detection engine of the node plug-in, obtain risk notification information, and issue risk warnings; wherein, the risk detection engine performs analysis based on the detection rules synchronized with the core plug-in.

[0131] Optionally, the device further includes: a local and a transfer request marking module, configured to:

[0132] If there is an access request initiated by the local end or a relayed access request on the server, the request parameters of the access request initiated by the local end or the relayed access request are marked through the node plug-in; wherein the marked label content is determined based on the configuration file synchronized by the core plug-in.

[0133] Optionally, the device further includes a log recording module, configured to:

[0134] After the risk detection engine of the node plug-in analyzes the labeled label content, obtains risk notification information, and issues a risk prompt, the request parameters of the access request, the receipt time of the access request, and the feedback time of the access request are recorded through the first log file; and the risk notification information of the access request is recorded through the second log file.

[0135] Optionally, the device further includes a log synchronization module, configured to:

[0136] The second log file is synchronized to the core plug-in so that the unauthorized detection system server can store the second log file.

[0137] Optionally, the content of the marked label includes whether the parameter is sent to the front end and the parameter attributes; the parameter whether to send to the front end includes 3 parameter values, namely, sending to the front end, sending to the front end and requiring transfer, and not sending to the front end; the parameter attributes include 2 parameter values, namely, user attributes and public attributes.

[0138] Optionally, the device further includes: an access request deformation module, configured to:

[0139] After the request parameters of the access request are marked by the client plug-in, the access request is transformed based on the request parameters of the access request and the marked tag content to obtain an access request character string in Json format.

[0140] Optionally, the core plug-in includes a Privilege.xml file, and the Privilege.xml file is used to record permissions of all interfaces; the core plug-in is used to determine risk notification information based on the permissions of all interfaces recorded in the Privilege.xml file.

[0141] An unauthorized access detection device provided by an embodiment of the present invention can execute an unauthorized access detection method provided by any embodiment of the present invention, and has corresponding functional modules and beneficial effects of the execution method.

[0142] Example 4

[0143] A fourth embodiment of the present invention further provides an unauthorized access detection system, which is used to perform an unauthorized access detection method. The system includes a client plug-in, a core plug-in, and a node plug-in; the client plug-in is installed on a client, the node plug-in is installed on a server, and the core plug-in is connected to the client plug-in and the node plug-in and installed on the unauthorized access detection system server; wherein: the core plug-in is used to synchronize with the client plug-in to determine the labeled label content; and is used to synchronize detection rules to the risk detection engine of the node plug-in for analysis by the risk detection engine;

[0144] The client plug-in is configured to mark the request parameters of the access request if an access request is detected from the client;

[0145] The node plug-in is used to parse the access request after the client sends the access request to the server to obtain the request parameters and the marked label content; wherein the request parameters are used for the server to perform business processing;

[0146] The node plug-in is further used to analyze the labeled content through a risk detection engine, obtain risk notification information, and provide risk prompts.

[0147] An unauthorized access detection system provided by an embodiment of the present invention can execute an unauthorized access detection method provided by any embodiment of the present invention, and has corresponding functional modules and beneficial effects of the execution method.

[0148] Example 5

[0149] Embodiment 5 of the present invention further provides a computer-readable storage medium, wherein the computer-readable storage medium stores computer instructions, and wherein the computer instructions are used to cause a processor to implement the unauthorized access detection method provided in all the embodiments of the present invention when executed:

[0150] If an access request is detected from the client, the request parameters of the access request are marked by the client plug-in; wherein the marked label content is determined based on the configuration file synchronized by the core plug-in;

[0151] After the client sends the access request to the server, the node plug-in parses the access request to obtain the request parameters and the labeled label content; wherein the request parameters are used for the server to perform business processing;

[0152] The risk detection engine of the node plug-in analyzes the labeled label content to obtain risk notification information and provide risk prompts; wherein, the risk detection engine performs analysis based on the detection rules synchronized with the core plug-in.

[0153] Any combination of one or more computer-readable media can be used. A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or component, or any combination thereof. More specific examples (a non-exhaustive list) of computer-readable storage media include: an electrical connection with one or more wires, a portable computer disk, 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 disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, device or device.

[0154] A computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, which carries computer-readable program code. Such a propagated data signal may take a variety of forms, including, but not limited to, electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium that can transmit, propagate, or transport a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0155] 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.

[0156] Computer program code for performing the operations of the present invention can be written in one or more programming languages, or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computer (e.g., through the Internet using an Internet service provider).

[0157] It should be understood that the various forms of the processes shown above can be used to reorder, add, or delete steps. For example, the steps described in the present invention can be performed in parallel, sequentially, or in a different order, as long as the desired results of the technical solution of the present invention can be achieved. This is not limited herein.

[0158] The above specific embodiments do not limit the scope of protection of the present invention. Those skilled in the art will appreciate that various modifications, combinations, sub-combinations, and substitutions may be made based on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention are intended to be included within the scope of protection of the present invention.< / message> < / security> < / rule> < / name>

Claims

1. A method for detecting unauthorized access, characterized in that: The method is performed by an unauthorized access detection system, which includes a client plug-in, a core plug-in, and a node plug-in. The client plug-in is installed on the client, the node plug-in is installed on the server, and the core plug-in is connected to the client plug-in and the node plug-in and installed on the unauthorized access detection system server. The method includes: If an access request is detected from the client, the request parameters of the access request are marked by the client plug-in; wherein the marked label content is determined based on the configuration file synchronized by the core plug-in; After the client sends the access request to the server, the node plug-in parses the access request to obtain the request parameters and the labeled label content; wherein the request parameters are used for the server to perform business processing; The risk detection engine of the node plug-in analyzes the labeled content to obtain risk notification information and provide risk prompts; wherein the risk detection engine performs analysis based on the detection rules synchronized with the core plug-in; The content of the label includes whether the parameters are sent to the front end and the parameter attributes; The parameter of whether to send data to the front end includes three parameter values: send data to the front end, send data to the front end with transfer required, and send data to the front end; The parameter attributes include two parameter values, namely user attributes and public attributes.

2. The method according to claim 1, characterized in that The method further comprises: If there is an access request initiated by the local end or a relayed access request on the server, the request parameters of the access request initiated by the local end or the relayed access request are marked through the node plug-in; wherein the marked label content is determined based on the configuration file synchronized by the core plug-in.

3. The method according to claim 1, characterized in that After analyzing the labeled content through the risk detection engine of the node plug-in to obtain risk notification information and issue a risk warning, the method further includes: Recording the request parameters of the access request, the time of receiving the access request, and the time of responding to the access request in a first log file; and The risk notification information of the access request is recorded in a second log file.

4. The method according to claim 3, characterized in that The method further comprises: The second log file is synchronized to the core plug-in so that the unauthorized detection system server can store the second log file.

5. The method according to claim 1, wherein After marking the request parameters of the access request by the client plug-in, the method further includes: Based on the request parameters of the access request and the marked tag content, the access request is transformed to obtain an access request string in Json format.

6. The method according to claim 1, characterized in that The core plug-in includes a Privilege.xml file, which is used to record permissions for all interfaces; The core plug-in is used to determine risk notification information based on the permissions of all interfaces recorded in the Privilege.xml file.

7. A device for detecting unauthorized access, characterized in that: The device is configured in an unauthorized access detection system, which includes a client plug-in, a core plug-in, and a node plug-in. The client plug-in is installed on the client, the node plug-in is installed on the server, and the core plug-in is connected to the client plug-in and the node plug-in and is installed on the unauthorized access detection system server. The device includes: An access request marking module, configured to mark the request parameters of the access request through the client plug-in if an access request is detected from the client; wherein the marking tag content is determined based on the configuration file synchronized by the core plug-in; A parameter and content acquisition module is used to parse the access request through the node plug-in after the client sends the access request to the server to obtain the request parameters and the labeled label content; wherein the request parameters are used for the server to perform business processing; A risk warning module is used to analyze the labeled content through the risk detection engine of the node plug-in, obtain risk notification information, and issue risk warnings; wherein the risk detection engine performs analysis based on the detection rules synchronized with the core plug-in; The content of the label includes whether the parameters are sent to the front end and the parameter attributes; The parameter of whether to send data to the front end includes three parameter values: send data to the front end, send data to the front end with transfer required, and send data to the front end; The parameter attributes include two parameter values, namely user attributes and public attributes.

8. An unauthorized access detection system, characterized in that: The system includes a client plug-in, a core plug-in, and a node plug-in; the client plug-in is installed on the client, the node plug-in is installed on the server, and the core plug-in is connected to the client plug-in and the node plug-in and installed on the unauthorized access detection system server; wherein: The core plug-in is used to synchronize with the client plug-in to determine the labeled label content; and is used to synchronize detection rules with the risk detection engine of the node plug-in for analysis by the risk detection engine; The client plug-in is configured to mark the request parameters of the access request if an access request is detected from the client; The node plug-in is used to parse the access request after the client sends the access request to the server to obtain the request parameters and the marked label content; wherein the request parameters are used for the server to perform business processing; The node plug-in is further used to analyze the labeled content through a risk detection engine to obtain risk notification information and provide risk warnings; The content of the label includes whether the parameters are sent to the front end and the parameter attributes; The parameter of whether to send data to the front end includes three parameter values: send data to the front end, send data to the front end with transfer required, and send data to the front end; The parameter attributes include two parameter values, namely user attributes and public attributes.

9. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a processor to implement the method for detecting unauthorized access according to any one of claims 1 to 6 when executed.

Images