Web application API sensitive data risk monitoring method and system

Abstract

The present invention relates to the field of computer security technology, and in particular to a method and system for monitoring the risk of sensitive data in a web application API. The method and system parse the API business mirror traffic data of a router or switch and obtain key field information in the business traffic data packet, and cache the key field information in a message queue; read the key field information in the message queue, and detect and identify the key fields containing sensitive information based on preset blacklist and whitelist permissions and sensitive information matching rules. By performing multi-dimensional sensitive information detection on API business traffic data packets in web applications, the present invention can help users automatically discover numerous known and / or unknown APIs in a complex and ever-changing Internet environment. By establishing an API list, the method and system can effectively identify the exposure of sensitive information that may be contained in the API, reduce API leakage and compliance risks, and classify and define API access behaviors, which helps users further analyze and judge, and effectively purify the web application environment.

Description

Technical Field

[0001] The present invention relates to the field of computer security technology, and in particular to a method and system for monitoring risks of sensitive data in a web application API. Background Art

[0002] With the development of electronic information technology, mobile applications, smart devices, and IoT services have become widely used in daily life. As these services become more widespread, they often provide services through APIs. APIs connect service functions and can be used to transmit data. However, while providing convenient services, they also present numerous cybersecurity risks. Existing API detection technologies and methods vary widely, with some focusing solely on the URL in the HTTP request line and failing to analyze key information in the request header. Risk assessments for APIs are also simplistic, with most simply matching response data and lacking the ability to detect data contained in actions such as uploading and downloading files. Consequently, these methods fail to effectively prevent the risk of sensitive and private data leaks. Summary of the Invention

[0003] To this end, the present invention provides a web application API sensitive data risk monitoring method and system, which can detect and identify sensitive data in business traffic data packets from multiple dimensions, timely discover sensitive data exposure risks, and effectively prevent the leakage of sensitive privacy data.

[0004] According to the design scheme provided by the present invention, a method for monitoring the risk of sensitive data in a web application API is provided, comprising:

[0005] Parse the API service mirror traffic data of the router or switch and obtain the key field information in the service traffic data packet, and cache the key field information in the message queue;

[0006] Read key field information in the message queue and detect and identify key fields containing sensitive information based on preset blacklist and whitelist permissions and sensitive information matching rules.

[0007] As a web application API sensitive data risk monitoring method of the present invention, further parsing the API business mirror traffic data of the router or switch includes:

[0008] First, a legitimate traffic collection engine is set up on the data interaction link of the router or switch;

[0009] Then, the legitimate traffic collection engine is used to collect the request information of the business service API interface and the response message returned to the request message.

[0010] As a web application API sensitive data risk monitoring method of the present invention, further, the key field information in the acquired business traffic data packet includes at least: source IP address, destination IP address, source port, destination port, request header line, request header, request body, response header, response line, response body, time and traffic packet size.

[0011] As a web application API sensitive data risk monitoring method of the present invention, further caching key field information in a message queue includes:

[0012] First, standardize the key field information;

[0013] Then, the standardized key field data is cached in the Kafka message queue.

[0014] As a web application API sensitive data risk monitoring method of the present invention, further, based on the preset blacklist and whitelist permissions and sensitive information matching rules, key fields containing sensitive information are detected and identified, including:

[0015] First, filtering service traffic data packets based on key fields, wherein the filtering process at least includes: determining whether the source IP address and the destination IP address in the key fields are in the black and white lists, determining whether the data packet status code in the key fields is in the status code table, and determining whether the request header uniform resource locator in the key fields is in the preset filtering URL table, and filtering the data that meets the requirements of the black and white lists, the status code table, and the preset filtering URL table;

[0016] Then, traffic data packets with information exposure risks are identified based on preset sensitive information matching rules, and the identified traffic data packets are alerted by displaying alarms and / or sending information reminders, where the preset sensitive information matching rules include but are not limited to: identity information matching rules, address information matching rules, and contact information matching rules all consisting of special characters and common characters.

[0017] As a web application API sensitive data risk monitoring method of the present invention, further, based on the preset black and white list permissions and sensitive information matching rules to detect and identify key fields containing sensitive information, it also includes: identifying business traffic data containing sensitive information to classify storage behavior and count, and sending a violation and excessive storage alarm prompt by comparing the storage count with the preset threshold upper limit.

[0018] As a web application API sensitive data risk monitoring method of the present invention, further, based on preset black and white list permissions and sensitive information matching rules to detect and identify key fields containing sensitive information, it also includes: identifying cross-border data access risks and issuing alarms by judging whether the source IP address and destination IP address in the key fields of the business traffic data packet are legally permitted access locations, and setting event tags for user access behaviors, and generating alarm prompts based on risk identification results and in combination with user access event tags.

[0019] Furthermore, the present invention also provides a web application API sensitive data risk monitoring system, comprising: a data parsing module and a risk identification module, wherein:

[0020] The data parsing module is used to parse the API service mirror traffic data of the router or switch and obtain the key field information in the service traffic data packet, and cache the key field information in the message queue;

[0021] The risk identification module is used to read key field information in the message queue and detect and identify key fields containing sensitive information based on preset blacklist and whitelist permissions and sensitive information matching rules.

[0022] Beneficial effects of the present invention:

[0023] By performing multi-dimensional sensitive information detection on API business traffic data packets in web applications, the present invention can help users automatically discover numerous known and / or unknown APIs in a complex and ever-changing Internet environment. It can also effectively identify sensitive information exposure issues that may be contained in APIs by establishing an API list, reduce API leakage and compliance risks, and classify and define API access behaviors, which helps users further analyze and judge, and effectively purify the web application environment. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] Figure 1 This is a schematic diagram of the web application API sensitive data risk monitoring process in an embodiment;

[0025] Figure 2 This is a schematic diagram of the API sensitive data risk monitoring algorithm principle in the embodiment. DETAILED DESCRIPTION

[0026] In order to make the objectives, technical solutions and advantages of the present invention clearer and more understandable, the present invention is further described in detail below with reference to the accompanying drawings and technical solutions.

[0027] Web application APIs are the primary means of collecting, using, and sharing personal information. Improper management can easily lead to legal compliance risks. APIs are crucial channels for transmitting data and connecting to services. They expose large amounts of sensitive data directly to open networks. API vulnerabilities can lead to serious data leaks. With the acceleration of information technology development, numerous shadow APIs may exist within web business systems, creating weak points in security management and susceptible to exploitation by those involved in the black and gray industries.

[0028] The embodiment of the present invention, see Figure 1 As shown, a web application API sensitive data risk monitoring method is provided, including:

[0029] S101, parsing the API service mirror traffic data of the router or switch and obtaining key field information in the service traffic data packet, and caching the key field information in the message queue;

[0030] S102: Read key field information in the message queue, and detect and identify key fields containing sensitive information based on preset blacklist and whitelist permissions and sensitive information matching rules.

[0031] By using the API service mirror traffic data of the router or switch to obtain and identify key field information in the service traffic data packet, and detecting and identifying key fields containing sensitive information based on preset blacklist and whitelist permissions and sensitive information matching rules, it can help users discover the actual exposed API interfaces in the WEB application and whether there are compliance risks or sensitive data leakage risks during the actual use of the API.

[0032] As a preferred embodiment, further parsing the API service mirror traffic data of the router or switch includes:

[0033] First, a legitimate traffic collection engine is set up on the data interaction link of the router or switch;

[0034] Then, the legitimate traffic collection engine is used to collect the request information of the business service API interface and the response message returned to the request message.

[0035] In web applications, individuals, organizations, or enterprises can log in to the service platform by registering an account, and initiate API call requests to obtain business services during the use of related services on the service platform. Business traffic data packets in request and response data can be obtained in gateway devices such as routers or switches.

[0036] Furthermore, in an embodiment of this case, the key field information in the obtained business traffic data packet includes at least: source IP address, destination IP address, source port, destination port, request line, request header, request body, response header, response line, response body, time and traffic packet size.

[0037] As a distributed, partitioned, and multi-replica data buffer, Kafka's greatest feature is its ability to process large amounts of data in real time to meet a variety of demand scenarios. In this embodiment, the key field information is cached in a message queue. First, the key field information is standardized; then, the standardized key field data is cached in the Kafka message queue. The Kafka message queue can meet the caching needs of real-time data pipelines and data streams.

[0038] As an embodiment of the present invention, further, detecting and identifying key fields containing sensitive information based on preset blacklist and whitelist permissions and sensitive information matching rules includes:

[0039] First, filtering service traffic data packets based on key fields, wherein the filtering process at least includes: determining whether the source IP address and the destination IP address in the key fields are in the black and white lists, determining whether the data packet status code in the key fields is in the status code table, and determining whether the request header uniform resource locator in the key fields is in the preset filtering URL table, and filtering the data that meets the requirements of the black and white lists, the status code table, and the preset filtering URL table;

[0040] Then, traffic data packets with information exposure risks are identified based on preset sensitive information matching rules, and the identified traffic data packets are alerted by displaying alarms and / or sending information reminders, where the preset sensitive information matching rules include but are not limited to: identity information matching rules, address information matching rules, and contact information matching rules all consisting of special characters and common characters.

[0041] See also Figure 2 As shown, for each piece of data, it is determined whether the source and destination IP addresses are in the blacklist and whitelist configured by the system. If so, the data is discarded without further processing; for each piece of data, it is determined whether the status code is in the system's built-in status code table, such as status codes [404, 500, 400]. If so, the data is discarded without further processing; for each piece of data, it is determined whether the URL in the request header is in the URL list that needs to be filtered configured by the system. If so, the data is discarded without further processing.

[0042] Sensitive information includes but is not limited to ID card number, bank card number, mobile phone number, address, email address, etc. The content of the matching rules using special characters and common characters can be as follows:

[0043] 1. Bank card matching regular expression: [ / ^([1-9]{1})(\d{14}|\d{18})$ / ];

[0044] 2. Mobile phone number matching regular expression: [(?:\"??[^\d])(1[3456789]\d{9})(?:[^\d]\"??)];

[0045] 3. ID card matching regular expression:

[0046] 【(?:\"??[^\d])((?:[1-6][1-9]|50)\d{4}(?:18|19|20)\d{2}(?:(?:0[1-9]) |10|11|12)(?:(?:[0-2][1-9])|10|20|30|31)\d{3}[\dXx])(?:[^\d]\"??)];

[0047] 4. Address matching regular expression: [((?:[\u4e00-\u9fa5]{2,5}?(?:province|autonomous region|city))(?:[\u4e00-\u9fa5]{2,7}?(?:city|district|county|state)){0,1}(?:[\u4e00-\u9fa5]{2,7}?(?:city|district|county)){0,1})]

[0048] 5. Email matching regular expression: [\"??([\w-]+@[\w\-.]+\.[A-Za-z]{2,4})\"? ? ]

[0049] For each piece of data, the cookie field in the request line, the information in the request body, and the response body are matched against the sensitive information defined above. If a match is successful, an alert is generated indicating a risk of sensitive information leakage.

[0050] Furthermore, based on the preset black and white list permissions and sensitive information matching rules, key fields containing sensitive information are detected and identified, which also includes: identifying business traffic data containing sensitive information, classifying storage behaviors and counting them, and sending an alarm prompt for illegal excessive storage of sensitive information by comparing the storage count with the preset threshold upper limit.

[0051] The identified sensitive information is classified and stored, and each type of information is deduplicated and counted. Once the number of sensitive information of any type exceeds the preset threshold upper limit, for example: the preset threshold upper limit is set to 1 million, when the number of identified ID numbers or mobile phone numbers exceeds 1 million, a risk alert is sent that there is a violation of the excessive storage of personal sensitive data. In actual applications, different preset threshold upper limits can also be set according to the specific environment to realize the detection of sensitive information of different APIs in web applications.

[0052] As a preferred embodiment, further, based on the preset black and white list permissions and sensitive information matching rules to detect and identify key fields containing sensitive information, it also includes: identifying cross-border data access risks and issuing alarms by judging whether the source IP address and destination IP address in the key fields of the business traffic data packet are legally permitted access locations, and setting event tags for user access behaviors, and generating alarm prompts based on the risk identification results and in combination with the user access event tags.

[0053] For each data entry, the source and destination IP addresses are deduplicated and the IP location is determined to be consistent with the permitted access location specified in the system configuration, such as the province or city level. If the location does not match the permitted location, an alert for cross-border data access risk is generated. Access behavior definitions include, but are not limited to, login, logout, upload, and download. Identifying access behavior helps users determine the certainty of risky behavior when tracing back against risk alerts.

[0054] Login behavior is determined by checking whether the URL in the request line of each data entry contains "login," "signin," "register," or "enroll," and whether the cookie in the request header contains one or more of the following: "userid," "account," "loginid," "user," "email," "phone," "phpsessid," or "token." If so, the data entry is labeled a login event and the eventtype field is set to 1.

[0055] The main basis for judging the logout behavior is to determine whether the URL in the request line of each data contains logout, exit, signout, quit, or retire. If it does, the data is labeled as a logout event and the eventtype field is set to 2.

[0056] The main basis for judging upload behavior is to determine whether the URL in the request line of each data contains upload, or whether the Content-Type in the request header contains multipart / form-data, application / pdf, application / msword, etc. If it does, the data is labeled as an upload event and the eventtype field is set to 3.

[0057] Download behavior is determined by checking whether the URL in the request line of each data entry contains "download" or whether the Content-Type header in the request contains "application / octet-stream". If so, the data entry is labeled as a download event and the eventtype field is set to 4.

[0058] If the access behavior is determined to be an upload or download behavior, the upload or download traffic will be reassembled and restored based on DPDK, the uploaded or downloaded file will be restored and saved, and then the file content will be checked to see if it contains the above-mentioned sensitive information. If so, an alarm will be generated that the uploaded or downloaded file contains sensitive information.

[0059] The system displays risk alerts based on the generated risk alerts and event tags based on access behavior. Alert delivery methods can be configured, such as email, SMS, WeChat, and DingTalk, to facilitate timely detection and interception of sensitive information leaks, effectively preventing the risk of sensitive and private data leaks.

[0060] Furthermore, based on the above method, an embodiment of the present invention also provides a web application API sensitive data risk monitoring system, comprising: a data parsing module and a risk identification module, wherein:

[0061] The data parsing module is used to parse the API service mirror traffic data of the router or switch and obtain the key field information in the service traffic data packet, and cache the key field information in the message queue;

[0062] The risk identification module is used to read key field information in the message queue and detect and identify key fields containing sensitive information based on preset blacklist and whitelist permissions and sensitive information matching rules.

[0063] Unless otherwise specifically stated, the relative steps, numerical expressions and values ​​of the components and steps set forth in these embodiments do not limit the scope of the present invention.

[0064] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. Reference can be made to the common and similar parts between the various embodiments. For the systems disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the description is relatively simple, and the relevant parts can be referred to the method description.

[0065] The units and method steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the components and steps of each example have been generally described in terms of function in the above description. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. A person of ordinary skill in the art may use different methods to implement the described functions for each specific application, but such implementation is not considered to be beyond the scope of the present invention.

[0066] Those skilled in the art will appreciate that all or part of the steps in the above method can be performed by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a magnetic disk, or an optical disk. Alternatively, all or part of the steps in the above embodiment can be implemented using one or more integrated circuits. Accordingly, each module / unit in the above embodiment can be implemented in the form of hardware or software functional modules. The present invention is not limited to any specific combination of hardware and software.

[0067] Finally, it should be noted that the above-described embodiments are only specific implementation methods of the present invention, which are used to illustrate the technical solutions of the present invention, rather than to limit them. The scope of protection of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the above-described embodiments, those skilled in the art should understand that any person skilled in the art can modify or easily conceive of changes to the technical solutions described in the above-described embodiments within the technical scope disclosed by the present invention, or replace some of the technical features therein with equivalents. Such modifications, changes, or replacements do not deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should be included in the scope of protection of the present invention. Therefore, the scope of protection of the present invention shall be subject to the scope of protection of the claims.

Claims

1. A web application API sensitive data risk monitoring method, characterized by: Include: By setting up a legitimate traffic collection engine on the data interaction link of the router or switch, the legitimate traffic collection engine is used to collect the request information of the business service API interface and the response message returned for the request message, so as to parse the API business mirror traffic data of the router or switch, and obtain the key field information in the business traffic data packet, standardize the key field information, and cache the standardized key field data in the Kafka message queue. The key field information in the obtained business traffic data packet at least includes: source IP address, destination IP address, source port, destination port, request line, request header, request body, response header, response line, response body, time and traffic packet size; Read the key field information in the message queue and filter the business traffic data packets based on the key fields, wherein the filtering process at least includes: filtering the data that meets the requirements of the black and white lists, the status code table and the preset filtering URL table by judging whether the source IP address and the destination IP address in the key fields exist in the black and white lists, judging whether the data packet status code in the key fields exists in the status code table and judging whether the request header uniform resource locator in the key fields exists in the preset filtering URL table; identifying the traffic data packets with information exposure risks based on the preset sensitive information matching rules, and issuing alarm prompts for the identified traffic data packets by displaying alarms and / or sending information reminders, wherein the preset sensitive information matching rules include but are not limited to: identity information matching rules, address information matching rules and contact information matching rules all consisting of special characters and common characters; and identifying cross-border data access risks and issuing alarms by judging whether the source IP address and the destination IP address in the key fields of the business traffic data packets are legally permitted access locations, and setting event tags for user access behaviors, and generating alarm prompts based on the risk identification results and in combination with the user access event tags.

2. The web application API sensitive data risk monitoring method according to claim 1 is characterized in that: Detect and identify key fields containing sensitive information based on preset blacklist and whitelist permissions and sensitive information matching rules. It also includes: identifying business traffic data containing sensitive information, classifying storage behaviors and counting them, and sending illegal excessive storage of sensitive information alarm prompts by comparing the storage count with the preset threshold upper limit.

3. A web application API sensitive data risk monitoring system, characterized by: The method according to claim 1 is implemented, comprising: a data analysis module and a risk identification module, wherein: The data parsing module is used to parse the API service mirror traffic data of the router or switch and obtain the key field information in the service traffic data packet, and cache the key field information in the message queue; The risk identification module is used to read key field information in the message queue and detect and identify key fields containing sensitive information based on preset blacklist and whitelist permissions and sensitive information matching rules.

4. An electronic device, characterized in that: It includes a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory communicate with each other via the communication bus; Memory for storing computer programs; A processor, configured to execute a program stored in a memory and implement the method steps described in any one of claims 1 to 2 when the program is executed.

5. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the method steps according to any one of claims 1 to 2 are implemented.

Images