Horizontal overreach detection method and device

Abstract

The present specification provides a method and device for detecting horizontal unauthorized access, which includes: scanning data entry instructions to determine the data flow of the target resource identifier and the target user identifier; when there are multiple determined data flows, selecting the target data flow from the multiple determined data flows, and determining the intersection node between the target data flow and other data flows in the multiple data flows, the database operation instruction corresponding to the target data flow is used to obtain the target resource represented by the target resource identifier, and the intersection node contains the actual owner identifier of the target resource; selecting the node in the target data flow that meets all preset conditions as the target node, and determining the existence of a horizontal unauthorized access risk when it is confirmed that there is a data flow from the data source point of the target user identifier to the target node; wherein the preset conditions include: being located after the intersection node and containing the actual owner identifier.

Description

Technical Field

[0001] The embodiments of this specification relate to the field of data security technology, and more particularly to a method and device for detecting horizontal unauthorized access. Background Art

[0002] With the rapid development of network technology, information security is facing huge challenges, and user privacy is facing huge challenges. User privacy is often accessed by others without authorization, resulting in information leakage. Therefore, major website platforms will conduct unauthorized risk detection when users access data to prevent information leakage.

[0003] When detecting horizontal privilege escalation, black-box testing is typically used. This involves creating two accounts with the same permission level. The first account is used to perform a legitimate test, obtaining a legitimate test request URL. Based on the legitimate test request URL, a control test request is performed using the second account, obtaining a corresponding control test request result. This control test request result is then compared with the first account's operational permissions to determine whether a horizontal privilege escalation vulnerability exists. However, this horizontal privilege escalation detection method requires pre-creating accounts and then performing separate tests, making deployment cumbersome and inefficient. Therefore, an efficient horizontal privilege escalation detection method is urgently needed. Summary of the Invention

[0004] In view of this, this specification provides a horizontal override detection method and device to address the deficiencies in the related art.

[0005] Specifically, this specification is implemented through the following technical solutions:

[0006] According to a first aspect of an embodiment of this specification, a method for detecting horizontal override is provided, including:

[0007] Scan the data entry instruction to determine the data flow of the target resource identifier and the target user identifier;

[0008] In the case where there are multiple determined data flows, a target data flow is selected from the multiple determined data flows, and an intersection node between the target data flow and other data flows in the multiple data flows is determined, the database operation instruction corresponding to the target data flow is used to obtain the target resource represented by the target resource identifier, and the intersection node includes the actual owner identifier of the target resource;

[0009] A node in the target data flow that meets all preset conditions is selected as the target node, and when it is confirmed that there is a data flow from the data source point of the target user identifier to the target node, it is determined that there is a risk of horizontal unauthorized access; wherein the preset conditions include: being located after the intersecting node and containing the actual owner identifier.

[0010] According to a second aspect of the embodiments of this specification, a horizontal override detection device is provided, the device comprising:

[0011] An instruction scanning unit, used to scan data entry instructions and determine the data flow of the target resource identifier and the target user identifier;

[0012] a target data stream determining unit, configured to, when there are multiple determined data streams, select a target data stream from the multiple determined data streams, and determine an intersection node between the target data stream and other data streams in the multiple data streams, wherein the database operation instruction corresponding to the target data stream is used to obtain a target resource represented by the target resource identifier, and the intersection node includes an actual owner identifier of the target resource;

[0013] A risk judgment unit is used to select a node in the target data flow that meets all preset conditions as a target node, and determine whether there is a horizontal authority overflow risk when confirming the existence of a data flow from the data source point of the target user identifier to the target node; wherein the preset conditions include: being located after the intersecting node and containing the actual owner identifier.

[0014] According to a third aspect of the embodiments of this specification, a computer-readable storage medium is provided, on which a computer program is stored. When the program is executed by a processor, the steps of the method described in the first aspect are implemented.

[0015] According to a fourth aspect of the embodiments of this specification, an electronic device is provided, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, the steps of the method described in the first aspect are implemented.

[0016] In the technical solution provided in this specification, the data flow of the target resource identifier and the target user identifier are determined by scanning the data entry instruction, and the intersection node containing the actual owner identifier of the target resource is determined based on the target data flow selected from multiple data streams, and then the target node in the target data flow that meets all preset conditions is determined, so that when there is a data flow from the data source point of the target user identifier to the target node, it can be determined that there is a horizontal authority override risk. Among them, since the existence of the above-mentioned target node indicates that the target data flow must involve the actual owner identifier in the process of obtaining the target resource, and the existence of the data flow from the data source point of the target user identifier to the target node further indicates that the target data flow involves the use of the target user identifier and the actual owner identifier, it is possible to judge whether there is a horizontal authority override risk based on the data flow; in addition, the horizontal authority override detection method does not rely on other external conditions, making it more efficient to determine whether there is a horizontal authority override risk.

[0017] It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] In order to more clearly illustrate the embodiments of this specification or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments recorded in this specification. For ordinary technicians in this field, other drawings can also be obtained based on these drawings.

[0019] Figure 1 is a schematic diagram of the architecture of a horizontal authority violation detection system shown in an exemplary embodiment of this specification;

[0020] Figure 2 This is a flowchart of a horizontal override detection method shown in an exemplary embodiment of this specification;

[0021] Figure 3 is a flowchart of another horizontal authority override detection method shown in an exemplary embodiment of this specification;

[0022] Figure 4a This is a data link diagram of a data flow of a target resource identifier shown in an exemplary embodiment of this specification;

[0023] Figure 4b This is a data link diagram of another data flow of a target resource identifier shown in an exemplary embodiment of this specification;

[0024] Figure 5 is a schematic structural diagram of an electronic device shown in an exemplary embodiment of this specification;

[0025] Figure 6 It is a structural diagram of a horizontal override detection device shown in an exemplary embodiment of this specification. DETAILED DESCRIPTION

[0026] Exemplary embodiments are described in detail herein, with examples illustrated in the accompanying drawings. In the following description, when referring to the drawings, identical numerals in different figures represent identical or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments are not intended to represent all possible embodiments consistent with this specification. Rather, they are merely examples of apparatuses and methods consistent with certain aspects of this specification.

[0027] It should be noted that in other embodiments, the steps of the corresponding method are not necessarily performed in the order shown and described in this specification. In some other embodiments, the method may include more or fewer steps than those described in this specification. In addition, a single step described in this specification may be broken down into multiple steps for description in other embodiments, and multiple steps described in this specification may be combined into a single step for description in other embodiments. It should be understood that although this specification may use terms such as first, second, and third to describe various information, such information should not be limited to these terms. These terms are merely used to distinguish between information of the same type. For example, first information may also be referred to as second information, and similarly, second information may be referred to as first information, without departing from the scope of this specification. Depending on the context, the term "if" as used herein can be interpreted as "when," "when," or "in response to a determination."

[0028] First, the terms involved in one or more embodiments of this specification are explained.

[0029] Horizontal privilege escalation: This occurs when an attacker attempts to access user resources with the same permissions as the attacker, for example, accessing data that does not belong to the attacker or operating on data that does not belong to the attacker.

[0030] Static scanning: Scan the code directly without compiling it.

[0031] Data source point (source point): data entry, usually used to execute initialization documents.

[0032] Vulnerability trigger point (sink point): also called taint sensitive point, is a system call point where tainted data may be misused.

[0033] Tainted parameters: Parameters passed in by the front-end are called tainted in security terms. Tainted parameters mean that users can modify them themselves. Similarly, non-tainted parameters are not parameters passed in by the front-end, which means that users cannot modify them at will.

[0034] With the rapid development of network technology, information security is facing huge challenges, and user privacy is facing huge challenges. User privacy is often accessed by others without authorization, resulting in information leakage. Therefore, major website platforms will conduct unauthorized risk detection when users access data to prevent information leakage.

[0035] When performing horizontal unauthorized access detection, there are usually two detection methods: one is black box detection, which is to create two accounts with the same authority level, use the first account to perform legal testing, and obtain a legal test request website; based on the legal test request website, use the second account to perform a control test request, obtain the corresponding control test request result, and compare the control test request result with the first account operation authority to determine whether there is a horizontal unauthorized access vulnerability. However, this horizontal unauthorized access detection method requires creating an account in advance and then testing it separately, which is relatively cumbersome to deploy and results in low efficiency. The other is the detection method of interactive application security testing (IAST), which detects horizontal unauthorized access by combining database resource parsing and detection models of SQL statements. However, this method is also very dependent on external conditions, such as detection models, and the deployment is relatively cumbersome, resulting in low efficiency. Therefore, this specification proposes the following technical solutions to solve the above problems.

[0036] Figure 1 This is a schematic diagram of the architecture of a horizontal overreach detection system shown in an exemplary embodiment of this specification. Figure 1 As shown, the system includes a client 11 and a server 12.

[0037] The client 11 is an electronic device capable of initiating a data access request to the server 12, such as a PC terminal device, a mobile terminal device, an Internet of Things device, and other forms of smart devices with certain computing capabilities, etc., and one or more embodiments of this specification do not limit this. During the operation of the system, when a user has a data access demand, he can initiate a user access request to the server 12 through the client 11. The server 11 scans the user access request and obtains the target resource identifier, that is, the resource identifier that the user wants to access. Since the user identifier and the resource identifier are two core indicators in horizontal unauthorized access detection, the data flow direction of the target resource identifier can be tracked, and the data source point of the target user identifier corresponding to the above user can be located. In the case that there are multiple determined data flows, the target data flow is selected from the determined multiple data flows, and the intersection node between the above target data flow and other data flows in the above multiple data flows is determined, and then the target node is determined, so as to judge whether the user's behavior of accessing the above target resource has a horizontal unauthorized access risk based on the data flow from the data source point of the above target user identifier to the above target node.

[0038] The server 12 is a network device that supports data transmission and processing functions. During the operation of the system, taking the actual data access scenario as an example, the server 12 generally has a large amount of source code. This source code is related to the locally set access control policy. It can be source code related to user login, source code for access control policies, source code for data storage, etc., collectively referred to as source code. The server 12 scans the source code and scans the target user identifier from the source code. Specifically, it can be scanned from source code related to user login (such as login state code). In addition, the server 12 can be built by a physical server of an independent host or a virtual server hosted by a host cluster, and this manual does not limit this.

[0039] In one embodiment, when the server 12 receives a data access request from the client 11, it can return the result of whether there is a horizontal unauthorized access risk to the client 11. If there is a risk, the client is informed that there is a horizontal unauthorized access risk for this access. If not, it is displayed that this access is healthy and access can continue. In another possible implementation method, the server 12 can directly process the user access request initiated by the client based on the access result. If there is no risk, the server 12 directly releases the user access request, allowing the user access request to access normally. If there is a risk, the server 12 directly intercepts the user access request and denies access.

[0040] Figure 2 This is a flow chart of a horizontal overriding detection method shown in an exemplary embodiment of this specification. Figure 2 As shown, the above method may include the following steps:

[0041] S201, scanning data entry instructions to determine the data flow of the target resource identifier and the target user identifier.

[0042] The above-mentioned data entry instruction refers to the software entry of the data, that is, the software program that receives / generates data, which may include source code such as login state, and may also include code corresponding to user access request, etc. The above-mentioned target resource identifier refers to an identifier that represents the target resource, such as the name of the target resource, the location where the target resource is stored, etc. The above-mentioned target user identifier refers to an identifier that represents the identity of the target user, such as the login account of the target user, the user ID, etc. The above-mentioned data flow may refer to the data flow direction of such data in the entire execution process, wherein the complete execution code of a certain type of data in the above-mentioned entire execution process may be determined as the data flow information of the corresponding data flow, such as the information generated by the target user identifier from acquisition, deletion, etc.; the information generated by the target resource identifier from acquisition, deletion, judgment and matching, ..., to the output of the corresponding processing. It can be understood by those skilled in the art that since the above-mentioned data flow can be stored or represented in the form of the above-mentioned data flow information, when this specification describes the data flow of a certain type of data, it can be regarded as the data flow information generated by such data in the corresponding data flow direction, and vice versa.

[0043] When the client initiates a user access request for a target resource identifier to the server, the server can scan the corresponding data entry instruction and determine the data flow of the target resource identifier and the target user identifier corresponding to the user using the client. The process of scanning the data entry instruction can be to directly scan the code in a static scanning manner. Static scanning can be further divided into a variety of implementation methods, such as: scanning the keywords in the data entry instruction, extracting and summarizing the instructions containing the preset keywords to form data flow information; or scanning by comparison. Specifically, the parameters contained in the data entry instruction are split and extracted, and compared and screened with the parameters to be determined, such as uid (User Identification), resourceid (resource Identification), etc. The instructions corresponding to the compared parameters are extracted and combined to form data flow information. Through the above scanning method, the process of compiling the code is eliminated, the detection process is simplified, and the overall efficiency of horizontal unauthorized risk detection is improved.

[0044] Those skilled in the art will understand that the above-mentioned data flow information may refer to the information generated by the flow of data from the source point to the sink point. For example, the data flow information of the target resource identifier may be the information generated by the process of transferring the acquired target resource identifier (i.e., the above-mentioned resourceid) from the source point to the sink point through the processing of the intermediate data flow node; the data flow information of the target user identifier may be the information generated by the process of transferring the acquired target user identifier (i.e., the above-mentioned uid) from the source point to the sink point through the processing of the intermediate data flow node. Of course, in the scheme of this specification, this step may only determine the data flow of the above-mentioned target resource identifier and the data source point of the target user identifier below, thereby reducing the processing resources required to predetermine all the data flow information related to the target user identifier, and further improving the overall efficiency of horizontal unauthorized risk detection.

[0045] The data entry instruction may include source code and user access request, so as to achieve multi-channel acquisition of the target resource identifier and the target user identifier.

[0046] In one embodiment, a server can scan received user access requests to determine the data flow of a target resource identifier; and scan the corresponding source code to identify the code features representing the user identity in the source code as the target user identifier. The source code, also known as the source program, can refer to a series of codes generated by the server for access control when a user initiates an access request. It is also a series of readable computer language instructions. For example, when a user initiates an access request, the server generates code based on the access request. This code can correspond to the user access request or to a logged-in state. That is, the server can determine the target user's data flow information by scanning the logged-in state code or analyzing the code in context. A user access request refers to a request initiated by a user through a client to access a resource. For example, a user access request may include the identifier of the target resource, the storage location identifier of the target resource, the resource size identifier of the target resource, and so on. Code features refer to code features corresponding to parameters representing the user identity obtained by scanning the source code for access control. For example, to obtain the target user identifier, the uid can be searched. If the uid is found, the presence of the code feature is determined. In addition, since the data flow of the target resource identifier and the target user identifier are obtained through two different channels (i.e., source code and user access request), the method of determining the corresponding information is more extensive and covers a wider range, and the determined horizontal unauthorized risk results are more accurate.

[0047] Based on the different contents contained in the user access request, the parameters determined by scanning the user access request are also different. For example, if the parameter contained in the user access request is only the target resource identifier, then scanning the user access request can only obtain the data flow information of the target resource identifier; if the parameters contained in the user access request include the target resource identifier and the storage location identifier of the target resource, then scanning the user access request can obtain the data flow information of the target resource identifier and the storage location identifier of the target resource. Specifically, scanning the source code and the user access request can be performed by extracting keywords corresponding to the target user identifier and the target resource identifier, and respectively using the instruction information corresponding to the keywords as the data flow of the target resource identifier or the target user identifier; or it can be performed by splitting the source code and the user access request, comparing the parameters obtained by the split with the target user identifier and the target resource identifier, and using the parameters that are successfully matched or have a comparison rate exceeding a preset comparison threshold (e.g., 80%) as the successfully matched parameters, and using the instruction information corresponding to the successfully matched parameters as the data flow of the target resource identifier or the target user identifier.

[0048] In addition, the specification requires that the above-mentioned target user identifier be determined through a non-user access request, thereby preventing users from illegally obtaining target resources by maliciously adding or tampering with user identifiers that do not match their own identities in user access requests. In addition, there are no restrictions on the specific methods of obtaining the above-mentioned target resource identifiers and the above-mentioned target user identifiers.

[0049] This specification can further judge and process the situation where the target user identification cannot be determined by scanning the data entry instruction.

[0050] In one embodiment, when it is impossible to determine the target user identifier by scanning the data entry instruction, the server can determine that there is a horizontal privilege escalation risk. Specifically, when no code features are identified in the source code, it can be determined that there is a horizontal privilege escalation risk. At the same time, when performing horizontal privilege escalation risk detection on a certain access, it is necessary to perform detection based on both the target user identifier and the target resource identifier. Therefore, when no code features are identified, the target user identifier cannot be determined, that is, it is determined that there is a horizontal privilege escalation risk. This logical process is rigorous and comprehensive, avoiding the occurrence of unidentified situations in the main process, and instead choosing to make direct judgments, thereby improving the efficiency of subsequent horizontal privilege escalation risk detection.

[0051] In another embodiment, when it is impossible to determine the target user identifier by scanning the data entry instruction, reference parameters can be extracted from the instruction parameters corresponding to the database operation instruction, and context analysis can be performed on the reference parameters in the data entry instruction to determine the target user identifier, wherein the reference parameters are parameters other than the target resource identifier; wherein, if the target user identifier cannot be determined by context analysis, it is determined that there is a risk of horizontal unauthorized access. In this embodiment, this specification does not limit the specific content, quantity, or form of the reference parameters. At the same time, this embodiment allows the server to determine the target user identifier by reverse query even if the target user identifier is not directly scanned, so that it can be determined from multiple aspects whether the access request has the risk of horizontal unauthorized access, thereby improving the accuracy of risk detection.

[0052] S202, when there are multiple determined data streams, select a target data stream from the multiple determined data streams, and determine the intersection node between the target data stream and other data streams in the multiple data streams, the database operation instruction corresponding to the target data stream is used to obtain the target resource represented by the target resource identifier, and the intersection node contains the actual owner identifier of the target resource.

[0053] If a user needs to access a target resource, the server must identify at least one target data stream among the data streams identified by the target resource identifier, and the database operation instruction corresponding to the target data stream can be used to access the target resource represented by the target resource identifier. Furthermore, the server can determine whether there is a risk of horizontal unauthorized access based on the number of data streams identified by the target resource identifier.

[0054] In one embodiment, if the number of the above-mentioned target data streams is greater than one, it means that in addition to the above-mentioned target data stream, the database operation instructions corresponding to the other data streams in the multiple data streams can be used for, for example, the actual owner identification of the above-mentioned target resource. In other words, when there are not multiple data streams for the above-mentioned target resource identification, the data stream must be the above-mentioned target data stream, that is, there is no database operation instruction corresponding to any data stream that can be used to obtain the above-mentioned actual owner identification, and thus the target node of the subsequent steps cannot be determined, so it can be determined in advance that there is a risk of horizontal overreach. It should be noted that in actual application scenarios, there are special cases where target resources are obtained using similar multi-table joint query methods, resulting in, for example, the above-mentioned destination data stream being realized by multiple sub-destination data streams. The solution of this specification can judge each sub-destination data stream as an independent destination data stream, thereby avoiding the interference of the above-mentioned special cases on the judgment result of the horizontal overreach risk and improving the accuracy of the results.

[0055] The following combination Figure 3 and Figure 4a , taking the application of the horizontal privilege violation detection method provided in this specification in resource access as an example, the horizontal privilege violation detection method is further explained. Figure 3 is a flow chart of another horizontal override detection method shown in an exemplary embodiment of this specification. Figure 4a This is a data link diagram of a target resource identification data flow shown in an exemplary embodiment of this specification. Figure 3 As shown, the method steps are as follows:

[0056] S301, scanning data entry instructions to determine the target user identifier.

[0057] In one embodiment, the target user identifier can be determined by identifying a corresponding code feature in the source code (eg, the instruction "String uid=Context().getuid()").

[0058] S302, scanning the data entry instruction to obtain the data stream identified by the target resource.

[0059] In one embodiment, the data flow of the target resource identification can be determined by scanning the user access request (eg, the instruction “Controller.start(resourceid)”).

[0060] S303: Determine whether there are multiple data flows.

[0061] In one embodiment, after successfully obtaining the data stream identified by the target resource, the execution operation can be further determined based on the number of data streams obtained. If more than one data stream is determined, S310 is executed, otherwise S304 is executed. Figure 4a For example, assuming that there is only one data stream obtained above, its data link is as follows Figure 4a As shown, by analyzing the source code corresponding to node 404 , it can be known that the data flow is the destination data flow, and S310 can be directly executed before executing node 406 .

[0062] S310, determining that there is a risk of horizontal overreach.

[0063] In one embodiment, the server prompts the user that there is a risk of horizontal unauthorized access in the current data access operation.

[0064] It should be noted that the specific writing specifications of the above code can vary depending on the persistence layer framework of the server's corresponding background (such as the object-relational mapping framework Hibernate or the Java-based persistence layer framework MyBatis), and the code for implementing the same function in each persistence layer framework usually has differences, so this manual does not limit the specific writing specifications of the code.

[0065] If the server determines that there are multiple data streams, it proves that in addition to the target data stream used to obtain the target resource represented by the target resource identifier, there are other data streams with other uses in the data stream of the target resource identifier. Among them, the purpose of the data stream can usually be determined by analyzing the corresponding database operation instructions and other traditional methods, which will not be described in detail in this manual. It can be understood that the essence of judging the risk of horizontal unauthorized access is to judge whether the current user has the legal right to access the above-mentioned target resources. Therefore, it is necessary to obtain the actual owner identification of the target resource to determine whether the current user is legal. It is impossible to further determine whether there is a risk of horizontal unauthorized access by relying solely on the number of determined data streams. Therefore, this manual can improve the accuracy of judging the risk of horizontal unauthorized access through the above-mentioned intersection nodes.

[0066] In one embodiment, when there are multiple determined data streams and the above-mentioned intersection node does not exist, the server can determine that there is a risk of horizontal unauthorized access. The intersection node is a node that overlaps between the above-mentioned target data stream and other data streams in the above-mentioned multiple data streams. For example, there are two determined data streams, which respectively serve to obtain the target resource represented by the above-mentioned target resource identifier and to obtain the actual owner identifier of the target resource. The former is the target data stream. In order to avoid the risk of horizontal unauthorized access, the actual owner identifier obtained in the latter can be used in the target data stream to authenticate the current user who applies to access the target resource. Therefore, the two data streams can have an intersection node, and the node contains the actual owner identifier of the above-mentioned target resource.

[0067] The following is still combined Figure 3 and Figure 4b , taking the application of the horizontal authority override detection method provided in this specification in resource access as an example, the horizontal authority override detection method is further explained. Figure 4b This is a data link diagram of another data flow of target resource identification shown in an exemplary embodiment of this specification, such as Figure 3 As shown, the method steps are as follows:

[0068] S301, scanning data entry instructions to determine the target user identifier.

[0069] S302, scanning the data entry instruction to obtain the data stream identified by the target resource.

[0070] S303: Determine whether there are multiple data flows.

[0071] The process of S301 to S303 is consistent with the above description, so it will not be described in detail in this specification.

[0072] S304: Select a target data stream.

[0073] In one embodiment, Figure 4b For example, assuming there are two data flows, the corresponding data links are: Data link 1: Controller.start(resourceId)->...(execute the operation corresponding to the intermediate data flow node)->resourceid_owner=get_resourceid_owner(resourceId)->Daoimpl.get_resourceid_owner(resourceId), that is Figure 4b The link formed by node 412->...->node 414->...->node 418 in the data flow; Data link 2: Controller.start(resourceId)->...(execute the operation corresponding to the intermediate data flow node)->resourceid_owner=get_resourceid_owner(resourceId)->if(uid.equals(resourceid_owner))->data=Daoimpl.query(resourceId,...)->return data (return the front-end data), that is, Figure 4b The data flow corresponding to link 1 is used to obtain the actual owner identifier of the target resource (i.e., resourceid_owner), and the data flow corresponding to link 2 is used to obtain the target resource represented by the target resource identifier. Therefore, it can be determined that the data flow corresponding to link 2 is the target data flow among the multiple data flows.

[0074] S305: Determine whether there is an intersecting node.

[0075] In one embodiment, if there is no intersection node between the target data stream and other data streams, it means that the target data stream does not involve the actual owner identifier, and the authentication operation of the current user who applies to access the target resource cannot be achieved, that is, there is a risk of horizontal unauthorized access, and S310 needs to be executed. If there is an intersection node, S307 can be executed to further determine whether there is a risk of horizontal unauthorized access. Figure 4bFor example, the data link 1 and the data link 2 have the same overlapping node, namely the node 414 containing the instruction "resourceid_owner=get_resourceid_owner(resourceId)". As an intersection node, this node can contain the value of the actual owner identifier of the target resource.

[0076] S306: Determine the actual owner identifier.

[0077] In one embodiment, as described above, the actual owner identifier can be used in the target data flow to authenticate the current user who applies to access the target resource. In this case, it may be necessary to continue executing other data flows to obtain the actual value of the actual owner identifier, thereby advancing the execution of subsequent steps. Figure 4b For example, the instructions in nodes 416 and 418 are equivalent to using SQL (Structured Query Language) statements to obtain the actual owner identifier in the database.

[0078] S203, selecting a node in the target data flow that meets all preset conditions as the target node, and determining whether there is a horizontal unauthorized access risk when confirming the existence of a data flow from the data source point of the target user identifier to the target node; wherein the preset conditions include: being located after the intersecting node and containing the actual owner identifier.

[0079] After determining the above-mentioned intersection node, it can be considered that the above-mentioned target data stream has obtained the actual owner identifier. In order to confirm whether the above-mentioned target data stream has actually used the above-mentioned actual owner identifier, the above-mentioned target node can be selected by formulating similar preset conditions to the above-mentioned preset conditions, wherein the above-mentioned preset conditions require that the selected target node must be after the above-mentioned target data stream and contain the above-mentioned actual owner identifier.

[0080] It should be noted that, since "introducing and using the actual owner identifier in the target data stream to verify whether the current user has the legal right to access the above-mentioned target resources" is in line with the technical logic and design intuition of those skilled in the art, the above-mentioned preset conditions can be set to: the target node can be correctly identified by being located after the intersection node and including the actual owner identifier. However, considering the differences in code writing capabilities of different designers, there are individual target data streams that meet the above-mentioned preset conditions but do not correctly utilize the above-mentioned actual owner identifier. This specification can also add the following content to the preset conditions for improvement: including the comparison logic between the above-mentioned actual owner identifier and the above-mentioned target user identifier, wherein the above-mentioned comparison logic can be used to determine whether the above-mentioned target user identifier is consistent with the above-mentioned actual owner identifier, such as the instruction "if (uid.equals (resourceid_owner))".

[0081] As mentioned above, in addition to the actual owner identifier, the target data flow also requires the use of the target user identifier (i.e., UID). Therefore, the target node can be used as a sink point. By determining whether there is a data flow from the source point of the target user identifier to the sink point, the risk of horizontal privilege escalation can be determined. Furthermore, by combining multidimensional data (such as data flow, node parameters, database operation instructions, etc.), the risk of horizontal privilege escalation can be determined, thereby improving the credibility of the judgment.

[0082] The following is still combined Figure 3 and Figure 4b , taking the application of the horizontal privilege violation detection method provided in this specification in resource access as an example, the horizontal privilege violation detection method is further explained. Figure 3 As shown, the method steps are as follows:

[0083] The process of S301 to S306 is consistent with the above description, so it will not be described in detail in this specification.

[0084] S307: Determine whether there is a destination node.

[0085] In one embodiment, Figure 2Taking data link 2 corresponding to the target data flow as an example, the data link contains four nodes (i.e., nodes 414, 424, 426 and 428): "resourceid_owner = get_resourceid_owner(resourceId)->if(uid.equals(resourceid_owner))->data = Daoimpl.query(resourceId,...)->return data". When S305 determines that node 414 is an intersection node, it can be determined that the above-mentioned node 424 is the target node according to the above-mentioned preset conditions.

[0086] S308: Determine whether there is a data flow from the data source point identified by the target user to the target node.

[0087] In one embodiment, the instruction "String uid = Context().getuid()" determined in S301 can be used as a new source point, and the above target node can be used as a sink point to determine whether there is a data link from the source point to the sink point (corresponding to Figure 4b If there is a link from source point 2 to sink point 3 in the data link, execute S309, otherwise execute S310. Of course, if there are multiple source points or sink points that meet the preset conditions, S309 can also be executed if there is a data link from any source point to any sink point, otherwise execute S310.

[0088] S309: Determine that there is no risk of horizontal overreach.

[0089] In one embodiment, the server prompts the user that there is no risk of horizontal unauthorized access in the current data access operation.

[0090] In addition, this manual may also overstep the level of risk found in attempted repairs.

[0091] In one embodiment, when it is determined that there is a risk of horizontal unauthorized access, the server can modify the above-mentioned target data stream based on the above-mentioned target resource identifier and the above-mentioned target user identifier, so that the instruction parameters corresponding to the above-mentioned database operation instruction include both the above-mentioned target user identifier and the above-mentioned target resource identifier. For example: assuming that the original database operation instruction of the target data stream is "Daolmpl.query(resourceId)", after determining that there is a risk of horizontal unauthorized access, it can be modified to "Daolmpl.query(resourceId, uid)", and the source code corresponding to the instruction can be further modified so that the modified database operation instruction is used to obtain the target resource that matches the above-mentioned target user identifier and the above-mentioned target resource identifier.

[0092] It can be seen from the above embodiments that the present specification can determine the data flow of the target resource identifier and the target user identifier by scanning the data entry instruction, and determine the intersection node containing the actual owner identifier of the target resource based on the target data flow selected from multiple data streams, and then determine the target node in the target data flow that meets all preset conditions, so that when there is a data flow from the data source point of the target user identifier to the target node, it can be determined that there is a horizontal overriding risk. Among them, since the existence of the above-mentioned target node indicates that the target data flow must involve the actual owner identifier in the process of obtaining the target resource, and the existence of the data flow from the data source point of the target user identifier to the target node further indicates that the target data flow involves the use of the target user identifier and the actual owner identifier, it is possible to judge whether there is a horizontal overriding risk based on the data flow; wherein, the horizontal overriding detection method does not rely on other external conditions, so that the efficiency of determining whether there is a horizontal overriding risk is higher, and the detection process combines multi-dimensional data (such as data flow, node parameters, database operation instructions, etc.) to analyze and judge whether there is a horizontal overriding risk, thereby improving the credibility of the judgment.

[0093] Figure 5 This is a schematic structural diagram of an electronic device in an exemplary embodiment. Figure 5 At the hardware level, the electronic device includes a processor, an internal bus, a network interface, a memory, and a non-volatile memory, and may also include other necessary hardware. The processor reads the corresponding computer program from the non-volatile memory into the memory and then runs it, forming a horizontal unauthorized access detection device at the logical level. Of course, in addition to software implementation, this specification does not exclude other implementation methods, such as logic devices or a combination of software and hardware, etc., that is, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0094] Corresponding to the aforementioned embodiment of the horizontal authority override detection method, this specification also provides an embodiment of a horizontal authority override detection device.

[0095] Please refer to Figure 6 , Figure 6 This is a schematic diagram of a horizontal overriding detection method and device, as shown in an exemplary embodiment. Figure 6 As shown, in a software implementation, the device may include:

[0096] The instruction scanning unit 601 is used to scan the data entry instruction and determine the data flow of the target resource identifier and the target user identifier;

[0097] a target data stream determining unit 602 configured to, when there are multiple determined data streams, select a target data stream from the multiple determined data streams, and determine an intersection node between the target data stream and other data streams in the multiple data streams, wherein the database operation instruction corresponding to the target data stream is used to obtain the target resource represented by the target resource identifier, and the intersection node includes an actual owner identifier of the target resource;

[0098] The risk judgment unit 603 is used to select a node in the target data flow that meets all preset conditions as a target node, and determine whether there is a horizontal authority risk when confirming the existence of a data flow from the data source point of the target user identifier to the target node; wherein the preset conditions include: being located after the intersecting node and containing the actual owner identifier.

[0099] Optionally, the data entry instruction includes source code and a user access request; the instruction scanning unit 601 is specifically configured to:

[0100] Scan the user access request to determine the data flow of the target resource identification;

[0101] The source code is scanned, and a code feature representing a user identity in the source code is determined as a target user identifier.

[0102] Optionally, the device further includes:

[0103] The target user identification determination unit 604 is configured to determine that there is a risk of horizontal unauthorized access if the target user identification cannot be determined by scanning the data entry instruction; or

[0104] In the case where the target user identifier cannot be determined by scanning the data entry instruction, a reference parameter is extracted from the instruction parameter corresponding to the database operation instruction, and a context analysis is performed on the reference parameter in the data entry instruction to determine the target user identifier, where the reference parameter is a parameter other than the target resource identifier; wherein, if the target user identifier cannot be determined through context analysis, it is determined that there is a risk of horizontal unauthorized access.

[0105] Optionally, the device further includes:

[0106] The data flow quantity determining unit 605 is configured to determine that there is a risk of horizontal authority exceeding when there are not multiple determined data flows.

[0107] Optionally, the device further includes:

[0108] The node determination unit 606 is configured to determine that there is a risk of horizontal overreach when there are multiple determined data flows and the intersecting node does not exist; or

[0109] In the case that there are multiple determined data flows, the intersection node exists, and the target node does not exist, it is determined that there is a horizontal authority overflow risk.

[0110] Optionally, the preset condition further includes: a comparison logic including the actual owner identifier and the target user identifier, wherein the comparison logic is used to determine whether the target user identifier is consistent with the actual owner identifier.

[0111] Optionally, the device further includes:

[0112] The data flow modification unit 607 is used to modify the target data flow according to the target resource identifier and the target user identifier when it is determined that there is a risk of horizontal unauthorized access, so that the instruction parameters corresponding to the database operation instruction include both the target user identifier and the target resource identifier.

[0113] The implementation process of the functions and effects of each unit in the above-mentioned device is specifically described in the implementation process of the corresponding steps in the above-mentioned method, and will not be repeated here.

[0114] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to the partial description of the method embodiments. The device embodiments described above are merely illustrative, wherein the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this specification. A person of ordinary skill in the art can understand and implement it without paying any creative work.

[0115] Embodiments of the subject matter and functional operations described in this specification may be implemented in the following: digital electronic circuits, tangibly embodied computer software or firmware, computer hardware including the structures disclosed in this specification and their structural equivalents, or a combination of one or more of them. Embodiments of the subject matter described in this specification may be implemented as one or more computer programs, i.e., one or more modules of computer program instructions encoded on a tangible, non-transitory program carrier to be executed by a data processing device or to control the operation of the data processing device. Alternatively or additionally, the program instructions may be encoded on an artificially generated propagation signal, such as a machine-generated electrical, optical, or electromagnetic signal, which is generated to encode information and transmit it to a suitable receiver device for execution by the data processing device. The computer storage medium may be a machine-readable storage device, a machine-readable storage substrate, a random or serial access memory device, or a combination of one or more of them.

[0116] The processes and logic flows described in this specification can be performed by one or more programmable computers executing one or more computer programs to perform the corresponding functions by operating on input data and generating output. The processes and logic flows can also be performed by, and apparatus can be implemented as, special purpose logic circuitry, such as an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit).

[0117] Computers suitable for executing computer programs include, for example, general-purpose and / or special-purpose microprocessors, or any other type of central processing unit. Typically, the central processing unit will receive instructions and data from a read-only memory and / or random access memory. The basic components of a computer include a central processing unit for implementing or executing instructions and one or more memory devices for storing instructions and data. Typically, a computer will also include one or more mass storage devices for storing data, such as magnetic disks, magneto-optical disks, or optical disks, or the computer will be operably coupled to such mass storage devices to receive data from them or to transmit data to them, or both. However, a computer does not necessarily have such devices. In addition, a computer can be embedded in another device, such as a mobile phone, a personal digital assistant (PDA), a mobile audio or video player, a game console, a global positioning system (GPS) receiver, or a portable storage device such as a universal serial bus (USB) flash drive, to name a few.

[0118] Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and storage devices, including, for example, semiconductor memory devices (e.g., EPROM, EEPROM, and flash memory devices), magnetic disks (e.g., internal hard disks or removable disks), magneto-optical disks, and CD ROM and DVD-ROM disks. The processor and memory can be supplemented by, or incorporated in, special purpose logic circuitry.

[0119] Although this specification includes many specific implementation details, these should not be interpreted as limiting the scope of any invention or the scope of protection claimed, but are mainly used to describe the features of specific embodiments of specific inventions. Certain features described in multiple embodiments within this specification may also be implemented in combination in a single embodiment. On the other hand, the various features described in a single embodiment may also be implemented separately in multiple embodiments or in any suitable sub-combination. In addition, although features may work in certain combinations as described above and even initially claimed as such, one or more features from the claimed combination may be removed from the combination in some cases, and the claimed combination may point to a sub-combination or a variation of the sub-combination.

[0120] Similarly, although operations are depicted in a particular order in the accompanying drawings, this should not be understood as requiring that these operations be performed in the particular order shown or performed sequentially, or that all illustrated operations be performed to achieve the desired results. In some cases, multitasking and parallel processing may be advantageous. In addition, the separation of various system modules and components in the above-described embodiments should not be understood as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product, or packaged into multiple software products.

[0121] Thus, specific embodiments of the subject matter have been described. Furthermore, the processes depicted in the accompanying drawings do not necessarily require the particular order shown or sequential order to achieve the desired results. In some implementations, multitasking and parallel processing may be advantageous.

[0122] The above description is only a preferred embodiment of this specification and is not intended to limit this specification. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of this specification should be included in the scope of protection of this specification.

Claims

1. A horizontal overreach detection method, comprising: Scan the data entry instruction to determine the data flow of the target resource identifier and the target user identifier; In the case where there are multiple determined data flows, a target data flow is selected from the multiple determined data flows, and an intersection node between the target data flow and other data flows in the multiple data flows is determined, the database operation instruction corresponding to the target data flow is used to obtain the target resource represented by the target resource identifier, and the intersection node includes the actual owner identifier of the target resource; A node in the target data flow that meets all preset conditions is selected as the target node, and when it is confirmed that there is a data flow from the data source point of the target user identifier to the target node, it is determined that there is a risk of horizontal unauthorized access; wherein the preset conditions include: being located after the intersecting node and containing the actual owner identifier.

2. The method according to claim 1, wherein the data entry instruction includes source code and a user access request; and wherein scanning the data entry instruction to determine the data flow of the target resource identifier and the target user identifier comprises: Scan the user access request to determine the data flow of the target resource identification; The source code is scanned, and a code feature representing a user identity in the source code is determined as a target user identifier.

3. The method according to claim 1, further comprising: In the case where the target user identifier cannot be determined by scanning the data entry instruction, determining that there is a risk of horizontal authority override; or, In the case where the target user identifier cannot be determined by scanning the data entry instruction, a reference parameter is extracted from the instruction parameter corresponding to the database operation instruction, and a context analysis is performed on the reference parameter in the data entry instruction to determine the target user identifier, where the reference parameter is a parameter other than the target resource identifier; wherein, if the target user identifier cannot be determined through context analysis, it is determined that there is a risk of horizontal unauthorized access.

4. The method according to claim 1, further comprising: When there are not multiple confirmed data flows, it is determined that there is a risk of horizontal unauthorized access.

5. The method according to claim 1, further comprising: In the case that there are multiple determined data flows and the intersection node does not exist, it is determined that there is a risk of horizontal authority exceeding; or, In the case that there are multiple determined data flows, the intersection node exists, and the target node does not exist, it is determined that there is a risk of horizontal authority overstepping.

6. The method according to claim 1, wherein the preset condition further comprises: a comparison logic including the actual owner identifier and the target user identifier, wherein the comparison logic is used to determine whether the target user identifier is consistent with the actual owner identifier.

7. The method according to claim 1, further comprising: When it is determined that there is a risk of horizontal unauthorized access, the target data stream is modified according to the target resource identifier and the target user identifier so that the instruction parameter corresponding to the database operation instruction includes both the target user identifier and the target resource identifier.

8. A horizontal override detection device, comprising: An instruction scanning unit, used to scan data entry instructions and determine the data flow of the target resource identifier and the target user identifier; a target data stream determining unit, configured to, when there are multiple determined data streams, select a target data stream from the multiple determined data streams, and determine an intersection node between the target data stream and other data streams in the multiple data streams, wherein the database operation instruction corresponding to the target data stream is used to obtain the target resource represented by the target resource identifier, and the intersection node includes an actual owner identifier of the target resource; A risk judgment unit is used to select a node in the target data flow that meets all preset conditions as a target node, and determine whether there is a horizontal authority overflow risk when confirming the existence of a data flow from the data source point of the target user identifier to the target node; wherein the preset conditions include: being located after the intersecting node and containing the actual owner identifier.

9. A computer-readable storage medium having a computer program stored thereon, wherein when the program is executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the method according to any one of claims 1 to 7 when executing the program.

Images