CN117081850A - Method, device, equipment and computer readable medium for detecting unauthorized loopholes - Google Patents

Method, device, equipment and computer readable medium for detecting unauthorized loopholes Download PDF

Info

Publication number
CN117081850A
CN117081850A CN202311274798.4A CN202311274798A CN117081850A CN 117081850 A CN117081850 A CN 117081850A CN 202311274798 A CN202311274798 A CN 202311274798A CN 117081850 A CN117081850 A CN 117081850A
Authority
CN
China
Prior art keywords
user
request
request data
data
service system
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202311274798.4A
Other languages
Chinese (zh)
Inventor
纪涛
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
iFlytek Co Ltd
Original Assignee
iFlytek Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by iFlytek Co Ltd filed Critical iFlytek Co Ltd
Priority to CN202311274798.4A priority Critical patent/CN117081850A/en
Publication of CN117081850A publication Critical patent/CN117081850A/en
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1433—Vulnerability analysis
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
    • H04L63/1425—Traffic logging, e.g. anomaly detection
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols

Abstract

The invention provides a method, a device, equipment and a computer readable medium for detecting an override vulnerability, wherein the method monitors flow data during communication between a service system and a user side; if the first user is detected to be successfully logged in the service system in the process of monitoring the flow data, acquiring request data of the first user from the monitored flow data; the first user is used for referring to any user in the service system; if the fact that the request data of the second user matched with the request data of the first user exists in the session tracking record is detected, the fact that the first user is unauthorized to access resources of the second user is determined, unauthorized access attack aiming at unauthorized holes is detected, and therefore safety of a service system can be improved. The session tracking record comprises request data of the second user recorded after the second user successfully logs in the service system and response data corresponding to the request data of the second user.

Description

Method, device, equipment and computer readable medium for detecting unauthorized loopholes
Technical Field
The present invention relates to the field of vulnerability detection technologies, and in particular, to a method, an apparatus, a device, and a computer readable medium for detecting an unauthorized vulnerability.
Background
An override vulnerability is a security logical vulnerability that is common in network security. The override vulnerability can be specifically understood as: the user in the service system can only perform operations such as adding data, deleting data, modifying data, searching data (for short, adding, deleting, checking) and the like on the interfaces with the authority, but the authority control is not performed on the information interfaces due to negligence of programmers, so that the condition that the user has override access to the information interfaces is caused.
However, in the prior art, a detection scheme of unauthorized access attack aiming at an unauthorized vulnerability is not provided at the network traffic monitoring layer, so that a plurality of unauthorized accesses to user data exist in the service system, namely the service system is attacked by unauthorized access, and the network security of the service system is jeopardized.
Disclosure of Invention
In view of this, the embodiments of the present application provide a method, an apparatus, a device, and a computer readable medium for detecting an override vulnerability, so as to detect the override vulnerability and improve network security of a service system.
In order to achieve the above object, the embodiment of the present application provides the following technical solutions:
in a first aspect, the application discloses a method for detecting an override vulnerability, which is applied to a flow acquisition device, wherein the flow acquisition device is respectively in communication connection with a service system and a user side, and the method for detecting the override vulnerability comprises the following steps:
Monitoring flow data during communication between the service system and the user terminal;
if the first user is detected to successfully log in the service system in the process of monitoring the flow data, acquiring request data of the first user from the monitored flow data; wherein, the first user is used for referring to any user in the service system;
if the fact that the request data of the second user matched with the request data of the first user exists in the session tracking record is detected, determining that the first user is unauthorized to access the resources of the second user; the session tracking record comprises request data of the second user recorded after the second user successfully logs in the service system and response data corresponding to the request data of the second user; the request data and the response data of the second user both carry the credentials of the second user; the second user is used for referring to any user except the first user, and the time of the second user logging in the service system for the first time is earlier than the time of the first user logging in the service system for the first time.
Optionally, in the above method for detecting an override vulnerability, the determining that the first user has override access to the resource of the second user further includes:
Response data corresponding to the request data of the first user returned by the service system is obtained; the request data and the response data of the first user both carry the credentials of the first user;
if the similarity between the response data corresponding to the request data of the first user and the response data corresponding to the request data of the matched second user is detected to be larger than a similarity threshold value, determining that the first user is unauthorized to access the resource of the second user and the attack is successful;
and if the similarity between the response data corresponding to the request data of the first user and the response data corresponding to the request data of the matched second user is detected not to be larger than a similarity threshold value, determining that the attack failure of the first user for unauthorized access to the resource of the second user is detected.
Optionally, in the above method for detecting an override vulnerability, after determining that the attack of the first user for accessing the resource of the second user is successful, the method further includes:
and sending information for prompting success of attack of the first user for unauthorized access to the resources of the second user to the management user of the service system.
Optionally, in the above method for detecting an override vulnerability, the recording process of the session tracking record includes:
In the process of monitoring flow data, if a second user is detected to successfully log in the service system, request data carrying credentials of the second user are all determined to be the request data of the second user, and the request data of the second user are recorded into a session tracking record; and determining response data corresponding to the request data carrying the credentials of the second user as the response data corresponding to the request data of the second user, and recording the response data corresponding to the request data of the second user into a session tracking record.
Optionally, in the above method for detecting an override vulnerability, if it is detected that the second user successfully logs in the service system, the method includes:
if the request data carrying the account number and the password of the second user is detected in the monitored flow data, determining the request data carrying the account number and the password of the second user as login request data of the second user;
and if the monitored flow data detects that the response data returned by the service system to the second user carries information for explaining the successful login of the second user and credentials of the second user, determining that the second user successfully logs in the service system.
Optionally, in the above method for detecting an override vulnerability, the determining process of the request data of the second user matched with the request data of the first user includes:
if the request data of the first user does not comprise a request body, detecting whether the request data of a second user, the request mode and the request path of which are consistent with the request mode and the request path of the request data of the first user, exist in a session tracking record;
if the fact that the request data of the second user which is consistent with the request mode and the request path of the request data of the first user exists in the session tracking record is detected, determining the request data of the second user which is consistent with the request mode and the request path of the request data of the first user as the request data of the second user which is matched with the request data of the first user;
if the request data of the first user comprises a request body, detecting whether the request data of a second user, the request mode, the request path and the request parameters of which are consistent with those of the request data of the first user, exist in a session tracking record;
if the fact that the request data of the second user which is consistent with the request mode, the request path and the request parameters in the request body in the request data of the first user exists in the session tracking record is detected, the request data of the second user which is consistent with the request mode, the request path and the request parameters in the request body in the request data of the first user is determined to be the request data of the second user which is matched with the request data of the first user.
Optionally, in the above method for detecting an override vulnerability, the method further includes:
and if the fact that the request data of the second user matched with the request data of the first user does not exist in the session tracking record is detected, recording the request data of the first user and response data corresponding to the request data of the first user into the session tracking record.
The application discloses a detection device of an override vulnerability, which is applied to flow acquisition equipment, wherein the flow acquisition equipment is respectively in communication connection with a service system and a user side, and the detection device of the override vulnerability comprises:
the monitoring unit is used for monitoring flow data during communication between the service system and the user side;
the first acquisition unit is used for acquiring request data of a first user from the monitored flow data if the first user is detected to successfully log in the service system in the process of monitoring the flow data; wherein, the first user is used for referring to any user in the service system;
the first determining unit is used for determining that the first user is unauthorized to access the resources of the second user if the request data of the second user matched with the request data of the first user exists in the session tracking record; the session tracking record comprises request data of the second user recorded after the second user successfully logs in the service system and response data corresponding to the request data of the second user; the request data and the response data of the second user both carry the credentials of the second user; the second user is used to refer to any user other than the first user; the time of the second user logging in the service system for the first time is earlier than the time of the first user logging in the service system for the first time.
In a third aspect, the present application discloses a computer readable medium having stored thereon a computer program, wherein the program, when executed by a processor, implements a method according to any of the first aspects described above.
In a fourth aspect, the present application discloses a detection device for an override vulnerability, including:
one or more processors;
a storage device having one or more programs stored thereon;
the one or more programs, when executed by the one or more processors, cause the one or more processors to implement the method of any of the first aspects described above.
Based on the above method for detecting an override vulnerability provided by the embodiment of the application, the method is applied to a flow collection device, the flow collection device is respectively connected with a service system and a user terminal in a communication way, and if the first user is detected to successfully log in the service system in the process of monitoring the flow data by monitoring the flow data during communication between the service system and the user terminal, request data of the first user is obtained from the monitored flow data. The first user is used for referring to any user in the service system. And if the fact that the request data of the second user matched with the request data of the first user exists in the session tracking record is detected, determining that the first user is unauthorized to access the resources of the second user. The request data and the response data of the second user both carry the credentials of the second user, the second user is used for referring to any user except the first user, and the time of the second user logging in the service system for the first time is earlier than the time of the first user logging in the service system for the first time. Because the session tracking record in the embodiment of the application comprises the request data of the second user recorded after the second user successfully logs in the service system and the response data corresponding to the request data of the second user, the data recorded in the session tracking record can reflect the authority range of the second user accessible resource, and further, when the request data of the second user matched with the request data of the first user exists in the session tracking record, the first user can be determined to use the resource access authority of the second user to carry out unauthorized access, thereby realizing the detection of unauthorized access attack aiming at unauthorized loopholes and further improving the security of the service system.
Drawings
In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings that are required to be used in the embodiments or the description of the prior art will be briefly described below, and it is obvious that the drawings in the following description are only embodiments of the present application, and that other drawings can be obtained according to the provided drawings without inventive effort for a person skilled in the art.
FIG. 1 is a schematic structural diagram of an unauthorized vulnerability detection system disclosed in an embodiment of the present application;
FIG. 2 is a schematic flow chart of a method for detecting an override vulnerability according to an embodiment of the present application;
fig. 3 is a flow chart of a recording method of session tracking record according to an embodiment of the present application;
fig. 4 is a schematic diagram of a session tracking flow according to an embodiment of the present application;
fig. 5 is a flow chart illustrating a process for determining request data of a matched second user according to an embodiment of the present application;
FIG. 6 is a schematic diagram of a detection flow of an override vulnerability disclosed in an embodiment of the present application;
FIG. 7 is a schematic diagram of a detection flow for determining whether an unauthorized attack is successful according to an embodiment of the present application;
fig. 8 is a schematic structural diagram of an apparatus for detecting an unauthorized vulnerability according to an embodiment of the present application.
Detailed Description
The following description of the embodiments of the present application will be made clearly and completely with reference to the accompanying drawings, in which it is apparent that the embodiments described are only some embodiments of the present application, but not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the application without making any inventive effort, are intended to be within the scope of the application.
In the present disclosure, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.
Referring to fig. 1, the present application provides a detection system for an override vulnerability, which includes a traffic collection device 101, a service system 102, and a user terminal 103. The traffic collection device 101 is respectively in communication connection with the service system 102 and the user terminal 103. Traffic collection device 101 may be a device with traffic collection capabilities, such as a network intrusion detection system (network intrusion detection system, NIDS) device. The user terminal 103 in the system shown in fig. 1 may be understood as a generic term for a plurality of terminals of users accessing the service system. A business system is understood to be a system providing business services. For example, the system may be a system providing a web browsing service, a system providing a query service, or the like. Communication is achieved between the service system 102 and the user terminal 103 through a network. Traffic data may be transmitted between the service system 102 and the client 103 through a network firewall, a network gateway, and other network devices interposed therebetween. The traffic collection device 101 may be deployed in a network gateway, for example in a firewall, and also at an internet outlet. The embodiment of the present application does not limit the specific deployment location of the flow collection device 101, but only needs to be between the service system 102 and the user terminal 103.
The detection process of the override vulnerability in the system shown in fig. 1 is as follows: the service system 102 and the user terminal 103 communicate with each other via a network. The traffic collection device 101 monitors traffic data during communication between the service system 102 and the client 103. The traffic data includes request data sent by the client 103 to the service system 102, and also includes response data returned by the service system 102 to the client 103. When the traffic acquisition device 101 detects that the first user successfully logs in the service system in the process of monitoring the traffic data, request data of the first user is acquired from the monitored traffic data. The first user is used for referring to any user in the service system.
If the traffic acquisition device 101 detects that the request data of the second user matched with the request data of the first user exists in the session tracking record, it is determined that the first user is unauthorized to access the resource of the second user. The session tracking record includes the request data of the second user recorded after the second user successfully logs in the service system 102 and the response data corresponding to the request data of the second user. The request data and the response data of the second user each carry credentials of the second user, where the second user is used to refer to a user other than the first user in the service system 102. The flow collection device 101 records the request data of the second user after the second user successfully logs in the service system 102 and the response data corresponding to the request data of the second user into the session tracking record by tracking the credentials of the second user.
In the system for detecting an override vulnerability provided in the embodiment of the present application, the flow collection device 101 monitors flow data during communication between the service system 102 and the user terminal 103, and if it detects that the first user successfully logs in the service system 102 during monitoring of the flow data, obtains request data of the first user from the monitored flow data. Wherein a first user is used to refer to any user in business system 102. And if the fact that the request data of the second user matched with the request data of the first user exists in the session tracking record is detected, determining that the first user is unauthorized to access the resources of the second user. The request data and the response data of the second user carry the credentials of the second user, and the second user is used for referring to any user except the first user. Because the session tracking record in the embodiment of the application comprises the request data of the second user recorded after the second user successfully logs in the service system and the response data corresponding to the request data of the second user, the data recorded in the session tracking record can reflect the authority range of the second user accessible resource, and further the flow acquisition equipment 101 detects that the request data of the second user matched with the request data of the first user exists in the session tracking record, so that the first user can be determined to use the resource access authority of the second user to carry out unauthorized access, thereby realizing the detection of unauthorized access attack aiming at unauthorized loopholes, and further improving the security of the service system.
Referring to fig. 2, based on the above-mentioned detection system for an override vulnerability provided by the embodiment of the present application, the embodiment of the present application correspondingly discloses a detection method for an override vulnerability, which is applied to a traffic collection device, where the traffic collection device is respectively connected with a service system and a user side in a communication manner, and related description about the traffic collection device can be referred to the related description and will not be repeated here. The method for detecting the override vulnerability shown in fig. 2 comprises the following steps:
s201, monitoring traffic data during communication between the service system and the user.
Specifically, the user side can be understood as a generic term of all terminals corresponding to users who need to access the service system. The data (i.e. traffic data) interacted by the communication between the service system and the user terminal are monitored by the traffic collection device. Specifically, during communication between the service system and the user terminal, the traffic collection device monitors a traffic packet, specifically a response packet, sent by the service system to the user terminal. And the flow packets, in particular request packets, sent by the user side to the service system. The response packet includes response data. The request packet includes request data. Traffic data may be understood as a generic term for request data and response data.
The request data is used for requesting access, inquiry and other services from the service system. The response data is the result data obtained after the service system processes the request data, for example, if the request data is an access request, the corresponding response data returned by the service system is the accessed content.
It should be noted that, the process of monitoring the traffic data during communication between the service system and the client does not interfere with communication between the service system and the client, i.e. the traffic data is sent to the receiver after the traffic data is collected by the traffic collection device. Therefore, in the process of executing the method shown in fig. 2, the traffic collection device does not affect the service system to provide services for the user side.
S202, if the first user is detected to successfully log in the service system in the process of monitoring the flow data, acquiring request data of the first user from the monitored flow data, wherein the first user is used for referring to any user in the service system.
Specifically, the first user may be understood as any user in the service system that successfully logs into the service system. The flow collection device detects whether the first user successfully logs in the service system from the monitored flow data in the process of executing the step S201, and if the first user successfully logs in the service system, the flow collection device acquires each request data of the first user in the process of executing the step S201.
The request data of the first user at least comprises credentials of the first user and an account number of the first user. The credentials of the first user are fields specifically set by the service system for the first user after the first user successfully logs into the service system. The business system maintains a session with the first user through the credential.
Alternatively, in a specific embodiment of the present application, the request data mentioned in the embodiment of the present application may be HTTP request data. The request data may consist of a request body and a request header, or may include only the request header. The request mode corresponding to the request data can be a GET request mode or a POST request mode. The request mode corresponding to the request data can be confirmed from the request header. The request header includes a request path. The request body includes a request path. It should be noted that, in the embodiment of the present application, the type, format, etc. of the requested data do not affect the implementation of the embodiment of the present application.
The process of performing step S202 may be: and continuously acquiring request data sent to a service system by each user side in the process of monitoring the flow data, and then detecting whether the request data carrying the account number and the password of the user exist. If the request data carrying the account and the password of the user is detected, the request data is considered to be request data for logging in the service system, and then response data corresponding to the request data returned to the user by the service system is acquired. If the obtained response data carries information for explaining the successful login of the user and the credentials of the user, the user is considered to be successfully logged in the service system, and the user is taken as the first user in the embodiment of the application.
The user's credentials are fields set by the service system for maintaining a session with the user, and specific reference may be made to the description of the related credentials, which is not repeated herein. Illustratively, the credential may be a Cookie field. The Set-Cookie values in the Cookie fields of different users are not identical. It should be noted that the Cookie field is only an example of one of the credentials, and in other embodiments, the session may also be maintained by using the JWT manner of credentials, and the embodiments of the present application are not limited to the specific type and form of the credentials.
In some embodiments, the information that is carried in the response data corresponding to the request data and is used for explaining that the user logs in successfully may be fields such as success, true, etc. The embodiment of the application is not limited to the specific form of the information for explaining the success of the user login.
S203, detecting whether second user request data matched with first user request data exists in the session tracking record, wherein the session tracking record comprises second user request data recorded after the second user successfully logs in the service system and response data corresponding to the second user request data, the second user request data and the response data both carry credentials of the second user, the second user is used for referring to any user except the first user, and the time of the first login of the second user to the service system is earlier than that of the first user to the service system.
The second user may be understood as a generic term of any user except the first user, and may be specifically understood as a generic term of any user who successfully logs in the service system before the first user logs in the service system, that is, a time when the second user logs in the service system for the first time is earlier than a time when the first user logs in the service system for the first time. Because the second user has successfully logged in the service system, the flow collection device can obtain the credentials distributed to the second user by the service system after the second user logs in the service system, and further can record the request data of the second user after all the second users successfully log in the service system and the response data corresponding to the request data of the second user in the session tracking record by tracking the credentials of the second user.
In some embodiments, the account number of the second user may also be recorded in the session tracking record. The request data and the response data of the second user carry the account number and the certificate of the second user, and the certificate is equivalent to the certificate that the business system can provide service for the second user. Specifically, after acquiring a credential distributed to a second user by a service system, the traffic acquisition device marks the account number of the second user and the credential of the second user in a correlation manner, tracks request data and response data carrying the credential of the second user in traffic data, and records the tracked request data and response data carrying the credential of the second user in a session tracking record.
It should be noted that, the data recorded in the session tracking record is updated continuously, and when the user successfully logs into the service system, the traffic collection device starts to use the request data and the response data of the user's credential tracking record (i.e. the request data and the response data of the second user recorded in the session tracking record mentioned above). After the session between the service system and the user terminal is interrupted and the certificate expires, the user can record each request data and response data carrying the new certificate according to the new certificate of the user in the session tracking record after logging in the service system again successfully.
It should be noted that, if the first user does not log in the service system for the first time, the session tracking record also records the request data of the first user carrying the credentials of the first user and the response data corresponding to the request data of the first user, which are recorded after the first user successfully logs in the service system. However, in the process of executing step S203, the purpose is to see whether the first user wants to override access to the resource of the second user, so it is only necessary to compare whether the currently acquired request data of the first user matches the request data of the second user in the session tracking record, and not to compare whether the currently acquired request data of the first user matches the request data of the first user originally recorded in the session tracking record.
When it is detected in the session tracking record that there is request data of the second user that matches the request data of the first user, it is indicated that the resource requested to be accessed by the request data of the first user is the same as the resource that the second user has requested to be accessed, i.e. the first user is unauthorized to access the resource of the second user, so that step S204 is performed.
When the request data of the second user matched with the request data of the first user is not detected in the session tracking record, the first user is not authorized to access, so that no operation can be performed, or after the first user is determined not to be authorized to access: and recording the request data of the first user and the response data corresponding to the request data of the first user into a session tracking record. The request data of the first user and the response data corresponding to the request data of the first user are obtained by tracking the credentials of the first user. Because the first user does not have unauthorized access, the request data and the response data carrying the current credentials of the first user belong to the resource authority range of the first user, and can be recorded into the session tracking record. When the method shown in fig. 2 is re-executed later, the updated session tracking record may be used to detect whether the new first user has unauthorized access to the resources of other normal users (i.e., the second user in the session tracking record), and the specific process is not repeated.
In summary, the request data and the response data recorded in the session tracking record in the embodiment of the present application may be understood as the request data and the corresponding response data generated after the successful login of the service system by all normal users without unauthorized access. The request data and the response data reflect the authority ranges corresponding to the normal users respectively. Therefore, after the first user successfully logs in the service system, the request data of the first user can be tracked and acquired through the credentials distributed by the service system when the first user successfully logs in, and then whether the first user has unauthorized access to the resources of the second user is detected through the request data of the first user and the session tracking record.
The session tracking record may be stored in a table form or in a database, and the embodiment of the application does not limit the storage mode and storage position of the session tracking record.
Optionally, referring to fig. 3, in an embodiment of the present application, the recording process of the session tracking record includes:
s301, in the process of monitoring flow data, whether the second user successfully logs in the service system is detected.
Specifically, the execution process and principle of the execution step S301 may refer to the related description of the part of the step S202 related to the detection of the successful login of the second user to the service system, where the difference is only that the user is different, and the execution process and principle are the same, and are not repeated herein.
If step S301 detects that the second user successfully logs in to the service system, step S302 and step S303 are executed, and if it does not detect that the second user successfully logs in to the service system (for example, the second user fails to log in, or the user side of the second user does not detect that the user side sends the request data for logging in to the service system), the remaining operations are not executed, that is, the step of monitoring the traffic data is continuously executed.
Optionally, in an embodiment of the present application, if step S301 detects that the second user successfully logs into the service system, an implementation manner of the service system includes:
and if the request data carrying the account number and the password of the second user is detected in the monitored flow data, determining the request data carrying the account number and the password of the second user as login request data of the second user. If the response data returned by the service system to the second user is detected in the monitored flow data to carry information for indicating that the second user is successfully logged in and credentials of the second user, the second user is determined to be successfully logged in the service system.
Specifically, reference may be made to the description related to the step S202 for detecting the portion of the second user successfully logging into the service system, where the difference is only that the user is different, and the execution process and principle are the same, which is not repeated here.
S302, request data carrying credentials of the second user are all determined to be the request data of the second user, and the request data of the second user are recorded into a session tracking record.
After determining that the second user successfully logs in to the service system in step S301, the traffic collection device may obtain the credentials set by the service system for the second user after the second user successfully logs in to the service system. And then the second user's certificate is marked through session tracking, the request data carrying the second user's certificate can be detected in the process of monitoring the flow data, and then the request data is recorded into the session tracking record as the request data of the second user.
Optionally, in an embodiment of the present application, before performing step S302, the method may further include:
and if the second user is detected to be successfully logged in the service system in the process of monitoring the flow data, acquiring request data of the second user from the monitored flow data. If it is detected that there is no other user 'S request data matching the second user' S request data in the session tracking record, steps S302 to S303 are performed. Wherein the other users refer to users other than the second user.
The above execution process and principle are the same as the detection process of the first user's override vulnerability shown in fig. 2 in the embodiment of the present application, and will not be described here again. I.e. the request data and the response data of the second user are recorded only if it is determined that the second user has no unauthorized access. In other embodiments, the process shown in fig. 3 may be executed during a preset period of time after the service system is put into operation, so as to construct a session tracking record. After the preset period of time is over, the process shown in fig. 2 is performed for any user (i.e., the first user) who successfully logs into the service system.
S303, determining response data corresponding to the request data carrying the credentials of the second user as response data corresponding to the request data of the second user, and recording the response data corresponding to the request data of the second user into a session tracking record.
After detecting the request data carrying the credentials of the second user mentioned in the foregoing step S302, the service system may correspondingly return response data corresponding to the request data of the second user, so that the traffic collection device may continue to use the credentials of the second user, track the response data returned by the service system, and record the tracked response data as response data corresponding to the request data of the second user in the session tracking record.
Optionally, in an embodiment of the present application, the session tracking record records not only the request data and the response data of each second user, but also reflects the correspondence between the request data and the response data.
For example, as shown in fig. 4, taking the user a as an example, after the user a successfully logs in to the account a, the response data of successful login returned by the service system carries the credentials of the user a, so that the flow collection device can implement session tracking marks, and perform the functional operation of behavior tracking on the user a. Specifically, the flow collection device associates the account a of the user a with the credentials of the user a, and then tracks each request data and each response data of the account a (i.e., the request data and the response data carrying the credentials of the user a) through the credentials of the user a. As can be seen from the behavior trace (i.e. session trace record) shown in fig. 4, the manner of recording the request data of the account a may be: the request mode, the request path and the request body of the request data are recorded. The manner of recording the response data is to record a response body. The request manner, the request path, the request body and the content of the corresponding response body specifically recorded in the behavior trace shown in fig. 4 may be directly referred to in fig. 4, and will not be described in detail herein.
There are many specific recording modes of session tracking recording, for example, the mode of recording request data may be a recording request mode, a request path and a request body. The manner of recording the response data may be a recording response body. I.e. only the more important parts of the request data and the response data can be selectively recorded. For example, the complete request data and response data may be recorded, as embodiments of the application are not limited in this regard.
Optionally, referring to fig. 5, in an embodiment of the present application, if it is detected in step S203 that there is request data of a second user matching the request data of the first user in the session tracking record, the determining process of the request data of the second user matching the request data of the first user (i.e. the process of determining the request data of the second user matching the request data of the first user) may include the following steps:
s501, if the request data of the first user does not include a request body, detecting whether the request data of the second user, which is consistent with the request mode and the request path of the request data of the first user, exists in the session tracking record.
If step S501 detects that there is request data of the second user, which is consistent with the request mode and the request path of the request data of the first user, in the session tracking record, step S502 is executed. If it is detected in step S501 that the request data of the second user, which is consistent with the request mode and the request path of the request data of the first user, does not exist in the session tracking record, it is considered that the request data of the second user, which is matched with the request data of the first user, does not exist, and the matching flow is ended.
Specifically, the structure and form of different request data are different, so that the matching process is also different. For example, in the request data of the user a shown in fig. 4, the request data of the GET request method does not have a request body (i.e., the request body is null). Step S501 and step S502 can be understood as a matching process for the case where the request body is not included in the request data.
Because the request data of the first user does not include the request body, when detecting whether the request data of the second user matched with the request data of the first user exists, only the request data of the second user, the request mode and the request path of which are consistent with the request data of the first user, exists in the session tracking record can be detected, and whether the request data of the second user matched with the request data of the first user exists can be confirmed.
S502, determining the request data of the second user which is consistent with the request mode and the request path in the request data of the first user as the request data of the second user which is matched with the request data of the first user.
Since there is the request data of the second user which is identical to the request mode and the request path in the request data of the first user, and when the request mode and the request path of the two request data are identical to each other, the accessed resource is completely identical, the request data of the second user which is identical to the request mode and the request path in the request data of the first user can be determined as the request data of the second user which is matched with the request data of the first user, and the first user can be considered to be unauthorized to access the resource of the second user.
In order to make the description of the embodiment of the present application clearer, please refer to the example shown in fig. 6, it can be seen that after the session tracking is marked on the credentials of the user a, both the request data and the response data under the account a of the user a are recorded, and the detailed description is described with reference to the related description of fig. 4. For an attacker user B, after the user B logs in the account B, the flow acquisition equipment also performs session tracking marking, and the request data of the user B is tracked. As can be seen from fig. 6, the request data of the user B does not include a request body (i.e., the request body is null), so it is required to compare whether each request data associated with the account a of the user a has a request mode and request data consistent with those of the user B. As can be seen from fig. 6, the request manner and the request path in the first request data of the account a recorded by the behavior trace are completely consistent with those of the user B, so that the user B is unauthorized to access the resource of the user a (i.e., the user B is performing an unauthorized vulnerability attempt).
If the request data of the first user includes a request body, S503, it is detected whether the request data of the second user, which is consistent with the request mode, the request path and the request parameters in the request body, exists in the request data of the first user in the session tracking record.
If step S503 detects that the session tracking record has the request data of the second user that matches the request mode, the request path, and the request parameters in the request body in the request data of the first user, step S504 is executed. If step S503 detects that there is no request data of the second user, which is consistent with the request mode, the request path, and the request parameters in the request body in the request data of the first user, in the session tracking record, it is determined that there is no request data of the second user that matches the request data of the first user.
Specifically, the structure and form of different request data are different, so that the matching process is also different. For example, in the request data of the user a shown in fig. 4, the request data of the POST request method has a request body. Step S503 and step S504 can be understood as a matching process for the case where the request body is included in the request data.
Because the request data of the first user includes the request body, when detecting whether the request data of the second user matched with the request data of the first user exists, whether the request data of the second user matched with the request data of the first user exists or not can be confirmed only by detecting whether the request data of the second user consistent with the request mode, the request path and the request parameters in the request body exist in the session tracking record.
S504, determining the request data of the second user which is consistent with the request mode, the request path and the request parameters in the request body in the request data of the first user as the request data of the second user matched with the request data of the first user.
Since there is the request data of the second user which is identical to the request mode, the request path and the request parameters in the request body in the request data of the first user, and when the request mode, the request path and the request body of the two request data are identical to each other, the accessed resource is completely identical to each other, so that the request data of the second user which is identical to the request mode, the request path and the request body in the request data of the first user can be determined as the request data of the second user which is matched with the request data of the first user, and the first user can be considered to be unauthorized to access the resource of the second user.
S204, determining that the first user is unauthorized to access the resource of the second user.
When a first user attempts to access a resource of a second user in an unauthorized manner by acquiring a functional interface (i.e. acquiring a request path of the second user) and then traversing parameters or FUZZ (i.e. traversing request parameters), the traffic acquisition device of the embodiment of the application detects the resource of the first user in the authority range of accessing the second user through a session tracking record, and further detects the unauthorized access attack of the first user.
After detecting the override attack of the first user, the first user can be notified to the management user of the service system directly, or whether the override attack of the first user is successful (i.e. whether the response of the service system is successfully obtained) can be continuously detected, and whether the service system needs to be reminded is determined. In the embodiment of the application, the detection of unauthorized access is realized through the session tracking record, thereby improving the security of the service system.
Optionally, referring to fig. 7, in an embodiment of the present application, after performing step S204, the method further includes:
s701, response data corresponding to the request data of the first user returned by the service system is obtained, wherein the request data and the response data of the first user both carry credentials of the first user.
Specifically, through the foregoing description of detecting that the first user successfully logs in the service system, after the first user successfully logs in the service system, the flow acquisition device may acquire the credential set by the service system for the first user through monitoring the flow data. Because the request data and the response data generated by the session between the first user and the service system both carry the credentials of the first user, after determining that the first user is unauthorized to access the resources of the second user, the response data returned to the first user by the service system can be tracked by continuing to pass through the credentials of the first user.
S702, detecting whether the similarity between response data corresponding to the request data of the first user and response data corresponding to the request data of the matched second user is larger than a similarity threshold value.
In order to determine whether the first user is successful in accessing the resource of the second user with override, it may be detected whether the similarity between the response data corresponding to the request data of the first user and the response data corresponding to the matched request data of the second user is greater than a similarity threshold. When the similarity between the response data corresponding to the request data of the first user and the response data corresponding to the request data of the matched second user is greater than the similarity threshold, it is indicated that the response data returned by the service system to the first user carries the resource of the second user, that is, the service system does not successfully intercept the unauthorized access attack of the first user, so that the first user successfully accesses the resource of the second user, that is, step S703 is executed.
When the similarity between the response data corresponding to the request data of the first user and the response data corresponding to the request data of the matched second user is not greater than the similarity threshold, it is indicated that the service system is not the resource of the second user carried in the response data returned to the first user, that is, the service system successfully intercepts the unauthorized access attack of the first user, so that the first user cannot access the resource of the second user, that is, step S704 is executed.
Optionally, in an embodiment of the present application, a similarity between a response body corresponding to the request data of the first user and a response body corresponding to the request data of the matched second user may be used as a similarity between response data corresponding to the request data of the first user and response data corresponding to the request data of the matched second user. Specifically, the response data may be composed of a response header and a response body, where the response body specifically includes content of the resource requested to be accessed, so that when the similarity of the response bodies in the two response data is greater than a similarity threshold, the two response data are considered to be similar, that is, the first user successfully accesses the resource of the second user.
For example, as shown in fig. 6, it can be seen that the response body under the account B tracked by the behavior tracking is also consistent with the response body of the account a, so that the user B successfully overrides the access to the user a.
S703, determining that the first user is unauthorized to access the resource of the second user and the attack is successful.
If the first user override access is determined to be successful, the fact that the override vulnerability exists in the service system is indicated, and the override attack of the first user cannot be blocked.
Optionally, in some embodiments, after performing step S703, further includes:
And sending information for prompting successful attack of the first user for unauthorized access to the resources of the second user to the management user of the service system.
The specific form of the information for prompting the first user to override the access to the resource of the second user is not limited by the embodiment of the present application. After receiving the information, the management user can choose to block the processing modes of the first user, perfecting the access authority setting of the service system and the like, and eliminate the override vulnerability.
S704, determining that the first user is unauthorized to access the resource of the second user and the attack fails.
If the first user fails to override the attack of the resource of the second user, the service system can prevent the override attack of the first user, so that any processing can be not executed, or the first user attempting the override attack can be blocked.
The method for detecting the override vulnerability is applied to flow collection equipment, the flow collection equipment is respectively in communication connection with a service system and a user terminal, and if the first user is detected to successfully log in the service system in the process of monitoring the flow data by monitoring the flow data during communication between the service system and the user terminal, request data of the first user are obtained from the monitored flow data. The first user is used for referring to any user in the service system. And if the fact that the request data of the second user matched with the request data of the first user exists in the session tracking record is detected, determining that the first user is unauthorized to access the resources of the second user. The request data and the response data of the second user both carry the credentials of the second user, the second user is used for referring to any user except the first user, and the time of the second user logging in the service system for the first time is earlier than the time of the first user logging in the service system for the first time. Because the session tracking record in the embodiment of the application comprises the request data of the second user recorded after the second user successfully logs in the service system and the response data corresponding to the request data of the second user, the data recorded in the session tracking record can reflect the authority range of the second user accessible resource, and further, when the request data of the second user matched with the request data of the first user exists in the session tracking record, the first user can be determined to use the resource access authority of the second user to carry out unauthorized access, thereby realizing the detection of unauthorized access attack aiming at unauthorized loopholes and further improving the security of the service system.
Referring to fig. 8, based on the above method for detecting an override vulnerability according to the embodiment of the present application, the embodiment of the present application correspondingly discloses a device for detecting an override vulnerability, including: a monitoring unit 801, a first acquisition unit 802, and a first determination unit 803.
And the monitoring unit 801 is configured to monitor traffic data during communication between the service system and the user side.
The first obtaining unit 802 is configured to obtain, if it is detected that the first user successfully logs in to the service system during monitoring of the traffic data, request data of the first user from the monitored traffic data. The first user is used for referring to any user in the service system.
A first determining unit 803 is configured to determine that the first user is unauthorized to access the resource of the second user if it is detected that there is request data of the second user matching the request data of the first user in the session tracking record. The session tracking record comprises request data of the second user recorded after the second user successfully logs in the service system and response data corresponding to the request data of the second user. The request data and the response data of the second user both carry the credentials of the second user. The second user is used to refer to any user other than the first user, and the time when the second user first logs in the service system is earlier than the time when the first user first logs in the service system.
Optionally, in a specific embodiment of the present application, the method further includes: a second acquisition unit, a second determination unit, and a third determination unit.
The second acquisition unit is used for acquiring response data corresponding to the request data of the first user returned by the service system. The request data and the response data of the first user both carry the credentials of the first user.
And the second determining unit is used for determining that the first user is unauthorized to access the resource of the second user is successful if the similarity between the response data corresponding to the request data of the first user and the response data corresponding to the request data of the matched second user is detected to be greater than a similarity threshold value.
And the third determining unit is used for determining that the first user is unauthorized to access the resource of the second user fails if the similarity between the response data corresponding to the request data of the first user and the response data corresponding to the request data of the matched second user is not greater than the similarity threshold value.
Optionally, in a specific embodiment of the present application, the method further includes:
and the sending unit is used for sending information for prompting the first user to override the access to the resource of the second user to succeed in attack to the management user of the service system.
Optionally, in a specific embodiment of the present application, the method further includes:
and the first recording unit is used for determining request data carrying credentials of the second user as the request data of the second user and recording the request data of the second user into the session tracking record if the second user is detected to successfully log in the service system in the process of monitoring the flow data. And determining response data corresponding to the request data carrying the credentials of the second user as response data corresponding to the request data of the second user, and recording the response data corresponding to the request data of the second user into the session tracking record.
Optionally, in an embodiment of the present application, the recording unit is configured to, if it detects that the second user successfully logs into the service system: and if the request data carrying the account number and the password of the second user is detected in the monitored flow data, determining the request data carrying the account number and the password of the second user as login request data of the second user. If the response data returned by the service system to the second user is detected in the monitored flow data to carry information for indicating that the second user is successfully logged in and credentials of the second user, the second user is determined to be successfully logged in the service system.
Optionally, in a specific embodiment of the present application, the method further includes: a detection unit, a fourth determination unit, a fifth determination unit, and a sixth determination unit.
And the detection unit is used for detecting whether the request data of the second user, which is consistent with the request mode and the request path of the request data of the first user, exists in the session tracking record if the request data of the first user does not include the request body.
And the fourth determining unit is used for determining the request data of the second user which is consistent with the request mode and the request path in the request data of the first user as the request data of the second user which is matched with the request data of the first user if the request data of the second user which is consistent with the request mode and the request path in the request data of the first user exists in the session tracking record.
And a fifth determining unit, configured to detect whether the session tracking record contains request data of the second user, where the request data of the second user is consistent with the request mode, the request path, and the request parameters in the request body in the request data of the first user if the request data of the first user includes the request body.
And a sixth determining unit, configured to determine, if it is detected that the request data of the second user, which is consistent with the request mode, the request path, and the request parameter in the request body in the request data of the first user, exists in the session tracking record, the request data of the second user, which is consistent with the request mode, the request path, and the request parameter in the request body in the request data of the first user, as the request data of the second user that matches the request data of the first user.
Optionally, in a specific embodiment of the present application, the method further includes:
and the second recording unit is used for recording the request data of the first user and the response data corresponding to the request data of the first user into the session tracking record if the request data of the second user matched with the request data of the first user does not exist in the session tracking record.
It should be noted that, the execution process and principle of each unit and subunit in the device for detecting an override vulnerability provided in the embodiment of the present application are the same as those of the method for detecting an override vulnerability, which is not described herein.
The device for detecting the override vulnerability provided by the embodiment of the application is applied to a flow collection device, the flow collection device is respectively in communication connection with a service system and a user terminal, a monitoring unit 801 monitors flow data during communication between the service system and the user terminal, and if the first acquisition unit 802 detects that the first user successfully logs in the service system in the process of monitoring the flow data, request data of the first user are acquired from the monitored flow data. The first user is used for referring to any user in the service system. The first determining unit 803 determines that the first user is unauthorized to access the resource of the second user if it detects that there is request data of the second user matching the request data of the first user in the session tracking record. The request data and the response data of the second user both carry the credentials of the second user, the second user is used for referring to any user except the first user, and the time of the second user logging in the service system for the first time is earlier than the time of the first user logging in the service system for the first time. Because the session tracking record in the embodiment of the application includes the second user request data recorded after the second user successfully logs in the service system and the response data corresponding to the second user request data, the data recorded in the session tracking record can reflect the authority range of the second user accessible resource, and further the first determining unit 803 can determine that the first user uses the second user resource access authority to perform unauthorized access when detecting that the second user request data matched with the first user request data exists in the session tracking record, thereby realizing the detection of unauthorized access attack aiming at unauthorized vulnerability and further improving the security of the service system.
The embodiment of the application also discloses a computer readable medium, on which a computer program is stored, wherein the program is executed by a processor to realize the method for detecting the override vulnerability according to any one of the above embodiments of the application.
The embodiment of the application also discloses a detection device for the override vulnerability, which comprises the following steps: one or more processors; a storage device having one or more programs stored thereon; when the one or more programs are executed by the one or more processors, the one or more processors are caused to implement the method for detecting an override vulnerability according to any one of the embodiments of the present application.
In this specification, each embodiment is described in a progressive manner, and identical and similar parts of each embodiment are all referred to each other, and each embodiment mainly describes differences from other embodiments. In particular, for a system or system embodiment, since it is substantially similar to a method embodiment, the description is relatively simple, with reference to the description of the method embodiment being made in part. The systems and system embodiments described above are merely illustrative, wherein the elements illustrated as separate elements may or may not be physically separate, and the elements shown as elements may or may not be physical elements, may be located in one place, or may be distributed over a plurality of network elements. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment. Those of ordinary skill in the art will understand and implement the present application without undue burden.
Those of skill would further appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both, and that the various illustrative elements and steps are described above generally in terms of functionality in order to clearly illustrate the interchangeability of hardware and software. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.
The previous description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the invention. Thus, the present invention is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims (10)

1. The method for detecting the override vulnerability is characterized by being applied to flow acquisition equipment, wherein the flow acquisition equipment is respectively in communication connection with a service system and a user side, and the method for detecting the override vulnerability comprises the following steps:
monitoring flow data during communication between the service system and the user terminal;
if the first user is detected to successfully log in the service system in the process of monitoring the flow data, acquiring request data of the first user from the monitored flow data; wherein, the first user is used for referring to any user in the service system;
if the fact that the request data of the second user matched with the request data of the first user exists in the session tracking record is detected, determining that the first user is unauthorized to access the resources of the second user; the session tracking record comprises request data of the second user recorded after the second user successfully logs in the service system and response data corresponding to the request data of the second user; the request data and the response data of the second user both carry the credentials of the second user; the second user is used for referring to any user except the first user, and the time of the second user logging in the service system for the first time is earlier than the time of the first user logging in the service system for the first time.
2. The method of claim 1, wherein the determining that the first user is unauthorized to access the second user's resource further comprises:
response data corresponding to the request data of the first user returned by the service system is obtained; the request data and the response data of the first user both carry the credentials of the first user;
if the similarity between the response data corresponding to the request data of the first user and the response data corresponding to the request data of the matched second user is detected to be larger than a similarity threshold value, determining that the first user is unauthorized to access the resource of the second user and the attack is successful;
and if the similarity between the response data corresponding to the request data of the first user and the response data corresponding to the request data of the matched second user is detected not to be larger than a similarity threshold value, determining that the attack failure of the first user for unauthorized access to the resource of the second user is detected.
3. The method of claim 2, wherein after the determining that the attack of the first user to override access to the resource of the second user is successful, further comprising:
And sending information for prompting success of attack of the first user for unauthorized access to the resources of the second user to the management user of the service system.
4. The method of claim 1, wherein the recording of the session tracking record comprises:
in the process of monitoring flow data, if a second user is detected to successfully log in the service system, request data carrying credentials of the second user are all determined to be the request data of the second user, and the request data of the second user are recorded into a session tracking record; and determining response data corresponding to the request data carrying the credentials of the second user as the response data corresponding to the request data of the second user, and recording the response data corresponding to the request data of the second user into a session tracking record.
5. The method of claim 4, wherein if the second user is detected to successfully log into the service system, comprising:
if the request data carrying the account number and the password of the second user is detected in the monitored flow data, determining the request data carrying the account number and the password of the second user as login request data of the second user;
And if the monitored flow data detects that the response data returned by the service system to the second user carries information for explaining the successful login of the second user and credentials of the second user, determining that the second user successfully logs in the service system.
6. The method of claim 1, wherein the determining of the request data of the second user that matches the request data of the first user comprises:
if the request data of the first user does not comprise a request body, detecting whether the request data of a second user, the request mode and the request path of which are consistent with the request mode and the request path of the request data of the first user, exist in a session tracking record;
if the fact that the request data of the second user which is consistent with the request mode and the request path of the request data of the first user exists in the session tracking record is detected, determining the request data of the second user which is consistent with the request mode and the request path of the request data of the first user as the request data of the second user which is matched with the request data of the first user;
if the request data of the first user comprises a request body, detecting whether the request data of a second user, the request mode, the request path and the request parameters of which are consistent with those of the request data of the first user, exist in a session tracking record;
If the fact that the request data of the second user which is consistent with the request mode, the request path and the request parameters in the request body in the request data of the first user exists in the session tracking record is detected, the request data of the second user which is consistent with the request mode, the request path and the request parameters in the request body in the request data of the first user is determined to be the request data of the second user which is matched with the request data of the first user.
7. The method as recited in claim 1, further comprising:
and if the fact that the request data of the second user matched with the request data of the first user does not exist in the session tracking record is detected, recording the request data of the first user and response data corresponding to the request data of the first user into the session tracking record.
8. The utility model provides a detection device of override leak, its characterized in that is applied to flow acquisition equipment, flow acquisition equipment respectively with business system and user side communication connection, detection device of override leak includes:
the monitoring unit is used for monitoring flow data during communication between the service system and the user side;
The first acquisition unit is used for acquiring request data of a first user from the monitored flow data if the first user is detected to successfully log in the service system in the process of monitoring the flow data; wherein, the first user is used for referring to any user in the service system;
the first determining unit is used for determining that the first user is unauthorized to access the resources of the second user if the request data of the second user matched with the request data of the first user exists in the session tracking record; the session tracking record comprises request data of the second user recorded after the second user successfully logs in the service system and response data corresponding to the request data of the second user; the request data and the response data of the second user both carry the credentials of the second user; the second user is used for referring to any user except the first user, and the time of the second user logging in the service system for the first time is earlier than the time of the first user logging in the service system for the first time.
9. A computer readable medium, characterized in that a computer program is stored thereon, wherein the program, when executed by a processor, implements the method according to any of claims 1 to 7.
10. An apparatus for detecting an override vulnerability, comprising:
one or more processors;
a storage device having one or more programs stored thereon;
the one or more programs, when executed by the one or more processors, cause the one or more processors to implement the method of any of claims 1-7.
CN202311274798.4A 2023-09-28 2023-09-28 Method, device, equipment and computer readable medium for detecting unauthorized loopholes Pending CN117081850A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202311274798.4A CN117081850A (en) 2023-09-28 2023-09-28 Method, device, equipment and computer readable medium for detecting unauthorized loopholes

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202311274798.4A CN117081850A (en) 2023-09-28 2023-09-28 Method, device, equipment and computer readable medium for detecting unauthorized loopholes

Publications (1)

Publication Number Publication Date
CN117081850A true CN117081850A (en) 2023-11-17

Family

ID=88708278

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202311274798.4A Pending CN117081850A (en) 2023-09-28 2023-09-28 Method, device, equipment and computer readable medium for detecting unauthorized loopholes

Country Status (1)

Country Link
CN (1) CN117081850A (en)

Similar Documents

Publication Publication Date Title
US11503043B2 (en) System and method for providing an in-line and sniffer mode network based identity centric firewall
US11902307B2 (en) Method and apparatus for network fraud detection and remediation through analytics
CN107211016B (en) Session security partitioning and application profiler
CN105939326B (en) Method and device for processing message
US8392963B2 (en) Techniques for tracking actual users in web application security systems
US6910135B1 (en) Method and apparatus for an intruder detection reporting and response system
US8819803B1 (en) Validating association of client devices with authenticated clients
US20190034631A1 (en) System and method for malware detection
WO2018213486A1 (en) Account monitoring
CN106789935B (en) Terminal abnormity detection method
US20110289564A1 (en) System and method for providing authentication continuity
CN107948204A (en) One key login method and system, relevant device and computer-readable recording medium
US20170318054A1 (en) Authentication incident detection and management
US11570203B2 (en) Edge network-based account protection service
US20090055531A1 (en) Identity based network mapping
US10728267B2 (en) Security system using transaction information collected from web application server or web server
KR101658450B1 (en) Security device using transaction information obtained from web application server and proper session id
US20240089260A1 (en) System and method for graduated deny list
KR101658456B1 (en) Security device using transaction information obtained from web application server
CN117081850A (en) Method, device, equipment and computer readable medium for detecting unauthorized loopholes
KR101650475B1 (en) Security device using transaction information obtained from web server
CN115664686A (en) Login method, login device, computer equipment and storage medium
US11722459B1 (en) Cumulative sum model for IP deny lists
KR100564438B1 (en) Device for detecting and preventing system hacking
KR101045332B1 (en) System for sharing information and method of irc and http botnet

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination