Method and device for monitoring abnormal user codes

Abstract

The present invention discloses a method and apparatus for monitoring user abnormal coding, relating to the field of computer technology. A specific implementation of the method includes: obtaining a call request from a user to call a tool class method library; determining whether the address corresponding to the call request is in a preset whitelist, and determining the result of the determination; if the result is negative, reporting the data corresponding to the user according to the call request; if the result is positive, sending the call request. This implementation avoids the technical drawback of the prior art that it is impossible to monitor users who are writing malicious code, thereby achieving the beneficial effect of real-time monitoring of whether users have abnormal coding behavior.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a method and device for monitoring abnormal user codes. Background Art

[0002] When a page is displayed, JavaScript (JS, a just-in-time compiled programming language) is usually open to the user. However, if a user inserts malicious code into the page, it may cause immeasurable losses.

[0003] Existing technology can use self-built services by the testing team or security team to monitor whether all published pages have malicious embedded code; existing technology can also use Node-side technology to directly render the Node service, or use the browser to asynchronously render the page.

[0004] In the process of implementing the present invention, the inventors discovered that the prior art has at least the following problems:

[0005] When using a testing team or security team to build their own service, there are technical defects such as long development time and the problem of page access security cannot be completely solved after the page is published;

[0006] When using front-end Node technology, there is a situation where it is impossible to monitor or report in real time the situation where users are writing malicious code. Summary of the Invention

[0007] In view of this, an embodiment of the present invention provides a method and device for monitoring user abnormal coding, which can avoid the technical defect of the existing technology that it is impossible to monitor users who are writing malicious code, and thus achieve the beneficial effect of real-time monitoring whether users have abnormal coding behavior.

[0008] To achieve the above object, according to one aspect of an embodiment of the present invention, a method for monitoring abnormal user codes is provided, comprising:

[0009] Get the user's call request to call the tool class method library;

[0010] Determine whether the address corresponding to the call request is in a preset whitelist, and determine the result of the determination;

[0011] If the result is no, reporting the data corresponding to the user according to the call request;

[0012] If the result is yes, the call request is sent.

[0013] Optionally, determining whether the address corresponding to the call request is in a preset whitelist includes:

[0014] Using the tool method library, determine whether the address corresponding to the call request is in the preset whitelist;

[0015] And / or, using the copied browser object request, determine whether the address corresponding to the call request is in a preset whitelist.

[0016] Optionally, using the copied browser object request, determining whether the address corresponding to the call request is in a preset whitelist includes:

[0017] Filtering the call request to determine request parameters;

[0018] According to the request parameters, the address corresponding to the call request is obtained by using the corresponding open method of the copied browser object request;

[0019] The sending method corresponding to the copied browser object request is used to determine whether the address corresponding to the call request is in the preset whitelist.

[0020] Optionally, using the copied browser object request, determining whether the address corresponding to the call request is before the preset whitelist includes:

[0021] The browser object request is replicated.

[0022] Optionally, duplicating the browser object request includes:

[0023] In the open method corresponding to the browser object request, add a monitoring object for storing the address corresponding to the call request;

[0024] In the sending method corresponding to the browser object request, a judgment object is added for judging whether the address stored in the monitoring object is in a preset white list.

[0025] Optionally, before obtaining a user's call request to call a tool class method library, include:

[0026] Prohibit the execution of native methods that may cause security risks;

[0027] It is prohibited to store objects that pose a safety hazard;

[0028] Establish a tool class method library.

[0029] Optionally, after reporting the data corresponding to the user according to the call request, the following steps are included:

[0030] Output an exception log according to the result of the judgment;

[0031] Determine the urgency of the result according to the abnormality log;

[0032] If the urgency level is urgent, prohibit the user from calling the tool class method library, clear the user's page request, and notify the user of the result of the judgment;

[0033] If the urgency level is not urgent, the user is notified of the result of the determination.

[0034] According to another aspect of an embodiment of the present invention, there is provided an apparatus for monitoring abnormal user codes, comprising:

[0035] The request module is used to obtain the user's call request for calling the tool class method library;

[0036] A judgment module, configured to judge whether the address corresponding to the call request is in a preset whitelist, and determine a result of the judgment;

[0037] The processing module is used to report the data corresponding to the user according to the calling request if the result is no; and send the calling request if the result is yes.

[0038] Optionally, determining whether the address corresponding to the call request is in a preset whitelist includes:

[0039] Using the tool method library, determine whether the address corresponding to the call request is in the preset whitelist;

[0040] And / or, using the copied browser object request, determine whether the address corresponding to the call request is in a preset whitelist.

[0041] According to another aspect of an embodiment of the present invention, there is provided an electronic device for monitoring abnormal user codes, comprising:

[0042] one or more processors;

[0043] a storage device for storing one or more programs,

[0044] When the one or more programs are executed by the one or more processors, the one or more processors implement the method for monitoring user abnormal coding provided by the present invention.

[0045] According to another aspect of an embodiment of the present invention, a computer-readable medium is provided, on which a computer program is stored. When the program is executed by a processor, the method for monitoring abnormal user codes provided by the present invention is implemented.

[0046] One embodiment of the above invention has the following advantages or beneficial effects: By monitoring the call request, the present application can avoid the technical defect of the existing technology that it is impossible to monitor users who are writing malicious code, thereby achieving the beneficial effect of real-time monitoring of whether users have abnormal coding behavior.

[0047] The further effects of the above-mentioned non-conventional optional manner will be described below in conjunction with specific embodiments. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] The accompanying drawings are provided for a better understanding of the present invention and are not intended to limit the present invention.

[0049] Figure 1 1 is a schematic diagram of the main process of a method for monitoring abnormal user coding according to an embodiment of the present invention;

[0050] Figure 2 It is a structural diagram of the encapsulated tool class method library;

[0051] Figure 3 This is a flowchart of the main steps for determining whether the user's URL address is in the preset whitelist in case three;

[0052] Figure 4 A schematic diagram of the main process of using browser object request to replicate;

[0053] Figure 5 This is a schematic diagram of the main process of alarm processing;

[0054] Figure 6 is a schematic diagram of main modules of an apparatus for monitoring abnormal user coding according to an embodiment of the present invention;

[0055] Figure 7 is an exemplary system architecture diagram in which embodiments of the present invention may be applied;

[0056] Figure 8 It is a schematic diagram of the structure of a computer system of a terminal device or a server suitable for implementing an embodiment of the present invention. DETAILED DESCRIPTION

[0057] The following description of exemplary embodiments of the present invention is made in conjunction with the accompanying drawings, in which various details of the embodiments of the present invention are included to facilitate understanding. These details should be considered as merely exemplary. Therefore, it should be appreciated by those skilled in the art that various changes and modifications may be made to the embodiments described herein without departing from the scope and spirit of the present invention. Similarly, for the sake of clarity and conciseness, descriptions of well-known functions and structures are omitted in the following description.

[0058] Figure 1 FIG. 1 is a schematic diagram of the main process of a method for monitoring abnormal user coding according to an embodiment of the present invention. Figure 1 As shown, a method for monitoring user abnormal coding is provided, comprising:

[0059] Step S101: Obtain a user's call request for calling a tool class method library;

[0060] Step S102: determining whether the address corresponding to the call request is in a preset whitelist, and determining a result of the determination;

[0061] Step S103: If the result is no, then report the data corresponding to the user according to the call request; if the result is yes, then send the call request.

[0062] The most commonly used methods and objects of users are encapsulated in the tool class method library (also called the Utils method library). When users edit code, they need to call the tool class method library to obtain the methods and objects encapsulated in the tool class method library.

[0063] The embodiment of the present application obtains the user's calling request when calling the tool class method library, thereby obtaining the address corresponding to the calling request issued by the user, and then judges the legitimacy of the address to monitor the user's abnormal coding behavior.

[0064] By monitoring the call requests, this application avoids the technical drawback of the prior art, which is the inability to monitor users who are writing malicious code, thereby achieving the beneficial effect of real-time monitoring of whether users are engaging in abnormal coding behavior. Because the solution described in this application only requires monitoring call requests, the development time required to develop this embodiment is much shorter than that of the prior art, thereby significantly saving the time cost of monitoring users for abnormal coding.

[0065] If the result is no, the data corresponding to the user reported mainly includes: module unique identifier, template unique identifier, etc.

[0066] In a browser, when users write code, operations that are prone to causing security issues include obtaining cookies, manipulating DOM elements, collecting and storing user data, forcing redirects, obtaining browser response headers, popping up prompts, concatenating and executing malicious strings, and sending malicious requests. Specifically, the native JS (JavaScript) methods corresponding to these operations include document.cookie, document.getElementById(), document.getElementsByName(), document.getElementsByTagName(), window.open(), document.write(), document.writeln(), window.localStorage, location.href, navigator.userAgent, and alert. When users send abnormal requests, they often use native methods and XMLHttpRequest objects to call them, which requires disabling the native JS methods or objects that may cause security issues.

[0067] Therefore, before obtaining the user's call request to call the tool class method library, include:

[0068] Prohibit the execution of native methods that may cause security risks;

[0069] It is prohibited to store objects that pose a safety hazard;

[0070] Establish a tool class method library.

[0071] Since the storage of native methods and objects that may cause security risks is prohibited, it is necessary to provide a packaged tool method library (also called a Utils method library) for users to use.

[0072] Figure 2 It is a structural diagram of the tool class method library that completes the encapsulation.

[0073] like Figure 2 As shown, the Utils method library encapsulates commonly used DOM operations, event operations, data operations, and ajax request methods. Among them, DOM operations can encapsulate native methods such as document.getElementById(), document.getElementsByName(), document.getElementsByTagName(), and can expand more methods for conveniently operating DOM elements;

[0074] Event operations can encapsulate native node events and extend more methods such as event delegation, event unbinding, and one event binding.

[0075] The data operation is to encapsulate the window.localStorage browser local cache;

[0076] The ajax request method encapsulates the native XMLHttpRequest object, making it easier for users to send URL requests.

[0077] Optionally, determining whether the address corresponding to the call request is in a preset whitelist may include the following three situations:

[0078] Case 1: Use the tool method library to determine whether the address corresponding to the call request is in the preset whitelist;

[0079] Case 2: Using the copied browser object request (XMLHttpRequest), determine whether the address corresponding to the call request is in the preset whitelist;

[0080] Case three: using the tool class method library to determine whether the address corresponding to the call request is in the preset whitelist; if the result of the determination is yes, using the copied browser object request to determine whether the address corresponding to the call request is in the preset whitelist.

[0081] Under normal circumstances, when editing code, users need to send a call request to the server to call the tool class method library, and the call request contains the user's URL address. This application compares the user's URL address with the address whitelist stored in the tool class method library to determine whether the user's call is legal. If the user's call request is illegal, the user's relevant parameters can be directly collected and reported, thereby facilitating subsequent operations such as alarms.

[0082] In actual applications, users may not call the tool class method library to edit code, that is, they send a request to the server through a browser object request. Therefore, in the second scenario described above, the copied browser object request is used to determine whether the user's URL address is in the preset whitelist. If the user's call request is not in the preset whitelist (that is, the call request is illegal), the user's relevant parameters can be directly collected and reported, thereby facilitating subsequent operations such as alarms.

[0083] Optionally, using the copied browser object request, determining whether the address corresponding to the call request is in a preset whitelist includes:

[0084] Filtering the call request to determine request parameters;

[0085] According to the request parameters, the address corresponding to the call request is obtained by using the corresponding open method of the copied browser object request;

[0086] The sending method corresponding to the copied browser object request is used to determine whether the address corresponding to the call request is in the preset whitelist.

[0087] The request parameters include: url address, data, dataType, contentType, type, timeout and other parameters.

[0088] The above situation 3 is to combine situation 1 with situation 2, and then determine whether the URL address of the user is in the preset whitelist. Specifically, the above situation 3 is described in detail below with a specific embodiment. Figure 3 This is a flowchart of the main steps for determining whether the URL address of the user is in the preset whitelist in case three. Figure 3 Shown, including:

[0089] Step S301: Using the tool class method library, determine whether the URL address corresponding to the user call request is in the preset whitelist;

[0090] If yes, go to step S302; if no, go to step S303;

[0091] Step S302: using the copied browser object request (XMLHttpRequest), determine whether the address corresponding to the call request is in a preset whitelist;

[0092] Wherein, step S302 includes:

[0093] Step S3021: Filter the user's call request and determine the request parameters;

[0094] Step S3022: according to the request parameters, using the corresponding open method (open method) of the copied browser object request, obtain the address corresponding to the call request;

[0095] Step S3023: Use the send method (send method) corresponding to the copied browser object request to determine whether the address corresponding to the call request is in the preset whitelist. If not, execute step S303; if so, execute step S304 to determine whether the user's URL address is in the preset whitelist;

[0096] Step S303: Determine whether the URL address of the user is in the preset whitelist.

[0097] Optionally, using the copied browser object request, determining whether the address corresponding to the call request is before the preset whitelist includes:

[0098] The browser object request is copied. The copied browser object request can be used to conveniently monitor the user URL address and determine whether the monitored user URL address is in a preset whitelist.

[0099] By using the technical means of duplicating the browser object request, it is solved that when the user does not use the tool class method library to request to edit the code, the user's editing behavior can also be effectively monitored.

[0100] Optionally, duplicating the browser object request includes:

[0101] In the open method (open method) corresponding to the browser object request, add a monitoring object (monitor object) for storing the address corresponding to the call request;

[0102] In the sending method corresponding to the browser object request, a judgment object is added for judging whether the address stored in the monitoring object is in a preset white list.

[0103] The main process of replicating the browser object request is described in detail below with a specific embodiment. Figure 4 The main process diagram for replication using browser object requests is shown in the figure, including:

[0104] Step S401: Add a monitor object to the open method (open method) corresponding to the browser object;

[0105] Step S402: define the URL attribute for the monitor object;

[0106] Step S403: In the sending method (send method) corresponding to the browser object request, a judgment object is added for judging whether the address stored in the monitoring object (monitor object) is in a preset whitelist.

[0107] When it is monitored that the user has edited the code abnormally, optionally, after reporting the corresponding data of the user according to the call request, an alarm is issued and / or the user is notified, specifically including:

[0108] Output an exception log according to the result of the judgment;

[0109] Determine the urgency of the result according to the abnormality log;

[0110] If the urgency level is urgent, prohibit the user from calling the tool class method library, clear the user's page request, and notify the user of the result of the judgment;

[0111] If the urgency level is not urgent, the user is notified of the result of the determination.

[0112] The following describes the alarm processing process in detail with a specific embodiment. Figure 5 The main flow chart of alarm processing is as follows: Figure 5 Shown, including:

[0113] Step S501: Output an abnormality log according to the judgment result;

[0114] Step S502: input the abnormality log into the monitoring service;

[0115] Step S503: Determine the result of the monitoring service's analysis of the abnormality log; wherein the analysis result includes both emergency and non-emergency situations;

[0116] When the analysis result is in an emergency state, step S504 is executed to disable the module used by the user and clear the user's page cache, and then step S505 is executed;

[0117] When the analysis result is in a non-emergency state, step S505 is executed to notify the user that the user's current editing behavior is abnormal.

[0118] In actual production, step S504 can be directly executed based on the judgment result, followed by step S505. Specifically, this can be implemented using the pre-packaged Node package jmfe-ump, by calling the businessAlarm() method and passing in the method name and content. jmfe-ump contains a standardized encapsulation of the monitoring service request, so simply sending the exception log to the monitoring service via the businessAlarm() method will trigger an SMS alert.

[0119] Figure 6 is a schematic diagram of the main modules of a device for monitoring abnormal user coding according to an embodiment of the present invention, such as Figure 6 As shown, a device 600 for monitoring abnormal user codes is provided, comprising:

[0120] Request module 601, used to obtain a user's call request for calling a tool class method library;

[0121] A determination module 602 is configured to determine whether the address corresponding to the call request is in a preset whitelist and determine a result of the determination;

[0122] The processing module 603 is configured to report the data corresponding to the user according to the call request if the result is no; and send the call request if the result is yes.

[0123] Optionally, determining whether the address corresponding to the call request is in a preset whitelist includes:

[0124] Using the tool method library, determine whether the address corresponding to the call request is in the preset whitelist;

[0125] And / or, using the copied browser object request, determine whether the address corresponding to the call request is in a preset whitelist.

[0126] Optionally, using the copied browser object request, determining whether the address corresponding to the call request is in a preset whitelist includes:

[0127] Filtering the call request to determine request parameters;

[0128] According to the request parameters, the address corresponding to the call request is obtained by using the corresponding open method of the copied browser object request;

[0129] The sending method corresponding to the copied browser object request is used to determine whether the address corresponding to the call request is in the preset whitelist.

[0130] Optionally, using the copied browser object request, determining whether the address corresponding to the call request is before the preset whitelist includes:

[0131] The browser object request is replicated.

[0132] Optionally, duplicating the browser object request includes:

[0133] In the open method corresponding to the browser object request, add a monitoring object for storing the address corresponding to the call request;

[0134] In the sending method corresponding to the browser object request, a judgment object is added for judging whether the address stored in the monitoring object is in a preset white list.

[0135] Optionally, a preparation module is further included, which is used to:

[0136] Prohibit the execution of native methods that may cause security risks;

[0137] It is prohibited to store objects that pose a safety hazard;

[0138] Establish a tool method library.

[0139] Optionally, the method further includes: a notification module configured to report the data corresponding to the user according to the call request:

[0140] Output an exception log according to the result of the judgment;

[0141] Determine the urgency of the result according to the abnormality log;

[0142] If the urgency level is urgent, prohibit the user from calling the tool class method library, clear the user's page request, and notify the user of the result of the judgment;

[0143] If the urgency level is not urgent, the user is notified of the result of the determination.

[0144] Figure 7 An exemplary system architecture 700 is shown to which the method for monitoring abnormal user coding or the apparatus for monitoring abnormal user coding according to the embodiment of the present invention can be applied.

[0145] like Figure 7 As shown, system architecture 700 may include terminal devices 701, 702, 703, a network 704, and a server 705. Network 704 is used to provide a medium for communication links between terminal devices 701, 702, 703 and server 705. Network 704 may include various connection types, such as wired or wireless communication links or fiber optic cables.

[0146] Users can use terminal devices 701, 702, and 703 to interact with server 705 via network 704 to receive or send messages, etc. Various communication client applications can be installed on terminal devices 701, 702, and 703, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social platform software, etc. (only as examples).

[0147] The terminal devices 701 , 702 , and 703 may be various electronic devices having a display screen and supporting web browsing, including but not limited to smart phones, tablet computers, laptop computers, and desktop computers.

[0148] Server 705 may be a server that provides various services, such as a backend management server (for example only) that supports shopping websites browsed by users using terminal devices 701, 702, and 703. The backend management server may analyze and process received data such as product information query requests, and feed back processing results (for example, target push information and product information—for example only) to the terminal device.

[0149] It should be noted that the method for monitoring user abnormality coding provided in the embodiment of the present invention is generally executed by the server 705 , and accordingly, the device for monitoring user abnormality coding is generally set in the server 705 .

[0150] It should be understood that Figure 7 The number of terminal devices, networks and servers in the embodiment is merely illustrative. Any number of terminal devices, networks and servers may be provided as required.

[0151] Reference below Figure 8 , which shows a schematic structural diagram of a computer system 800 of a terminal device suitable for implementing an embodiment of the present invention. Figure 8 The terminal device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present invention.

[0152] like Figure 8 As shown, the computer system 800 includes a central processing unit (CPU) 801, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 802 or a program loaded from a storage unit 808 into a random access memory (RAM) 803. Various programs and data required for the operation of the system 800 are also stored in the RAM 803. The CPU 801, the ROM 802, and the RAM 803 are connected to each other via a bus 804. An input / output (I / O) interface 805 is also connected to the bus 804.

[0153] The following components are connected to the I / O interface 805: an input section 806 including a keyboard, a mouse, and the like; an output section 807 including devices such as a cathode ray tube (CRT), a liquid crystal display (LCD), and a speaker; a storage section 808 including a hard disk; and a communication section 809 including a network interface card such as a LAN card or a modem. The communication section 809 performs communication processing via a network such as the Internet. A drive 810 is also connected to the I / O interface 805 as needed. A removable medium 811, such as a magnetic disk, an optical disk, a magneto-optical disk, or a semiconductor memory, is installed in the drive 810 as needed, so that computer programs read therefrom can be installed into the storage section 808 as needed.

[0154] In particular, according to the embodiments disclosed in the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, the embodiments disclosed in the present invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program comprising program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via the communication section 809, and / or installed from a removable medium 811. When the computer program is executed by the central processing unit (CPU) 801, the above-mentioned functions defined in the system of the present invention are performed.

[0155] It should be noted that the computer-readable medium described in the present invention can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media can include, but are not limited to, an electrical connection having one or more conductors, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In the present invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In the present invention, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. This propagated data signal can take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium that can transmit, propagate, or transport a program for use by or in conjunction with an instruction execution system, apparatus, or device. Program code embodied on a computer-readable medium may be transmitted using any suitable medium, including but not limited to wireless, wireline, optical fiber cable, RF, or any suitable combination thereof.

[0156] The flowcharts and block diagrams in the accompanying drawings illustrate the possible implementation architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present invention. In this regard, each box in the flowchart or block diagram can represent a module, program segment, or a part of code, and the above-mentioned module, program segment, or a part of code contains one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in an order different from that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flowchart, and the combination of boxes in the block diagram or flowchart, can be implemented with a dedicated hardware-based system that performs the specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0157] The modules involved in the embodiments of the present invention may be implemented in software or hardware. The modules described may also be provided in a processor. For example, they may be described as follows: a processor includes a sending module, an acquisition module, a determination module, and a first processing module. The names of these modules do not, in some cases, limit the modules themselves. For example, the sending module may also be described as a "module for sending a picture acquisition request to the connected server."

[0158] As another aspect, the present invention further provides a computer-readable medium, which may be included in the device described in the above embodiments, or may exist independently without being incorporated into the device. The computer-readable medium carries one or more programs, and when the one or more programs are executed by the device, the device includes:

[0159] Get the user's call request to call the tool class method library;

[0160] Determine whether the address corresponding to the call request is in a preset whitelist, and determine the result of the determination;

[0161] If the result is no, reporting the data corresponding to the user according to the call request;

[0162] If the result is yes, the call request is sent.

[0163] According to the technical solution of the embodiment of the present invention, the following beneficial effects can be achieved:

[0164] By monitoring the call request, the present application can avoid the technical defect of the existing technology that is unable to monitor users who are writing malicious code, thereby achieving the beneficial effect of real-time monitoring of whether users have abnormal coding behavior.

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

Claims

1. A method for monitoring abnormal user coding, characterized in that: include: Get the user's call request to call the tool class method library; Determine whether the address corresponding to the call request is in a preset whitelist, and determine the result of the determination; If the result is no, reporting the data corresponding to the user according to the call request; If the result is yes, sending the call request; After reporting the data corresponding to the user according to the call request, the method includes: outputting an exception log according to the result of the judgment; judging the urgency of the result according to the exception log; if the urgency is urgent, prohibiting the user from calling the tool method library, clearing the user's page request, and notifying the user of the result of the judgment; if the urgency is not urgent, notifying the user of the result of the judgment.

2. The method according to claim 1, characterized in that Determining whether the address corresponding to the call request is in a preset whitelist includes: Using a tool class method library, determine whether the address corresponding to the call request is in a preset whitelist; and / or using a copied browser object request, determine whether the address corresponding to the call request is in a preset whitelist.

3. The method according to claim 2, characterized in that Using the copied browser object request, determining whether the address corresponding to the call request is in a preset whitelist includes: Filtering the call request to determine request parameters; According to the request parameters, the address corresponding to the call request is obtained by using the corresponding open method of the copied browser object request; The sending method corresponding to the copied browser object request is used to determine whether the address corresponding to the call request is in the preset whitelist.

4. The method according to claim 3, characterized in that Using the copied browser object request, determining whether the address corresponding to the call request is before the preset whitelist includes: The browser object request is replicated.

5. The method according to claim 4, characterized in that Rewriting the browser object request includes: In the open method corresponding to the browser object request, add a monitoring object for storing the address corresponding to the call request; In the sending method corresponding to the browser object request, a judgment object is added for judging whether the address stored in the monitoring object is in a preset white list.

6. The method according to any one of claims 1 to 5, characterized in that: Before obtaining the user's call request for calling the tool class method library, the following steps are included: Prohibit the execution of native methods that may cause security risks; It is prohibited to store objects that pose a safety hazard; Establish a tool method library.

7. A device for monitoring abnormal user codes, characterized in that: include: The request module is used to obtain the user's call request for calling the tool class method library; A judgment module, configured to judge whether the address corresponding to the call request is in a preset whitelist, and determine a result of the judgment; a processing module, configured to report the data corresponding to the user according to the call request if the result is no; If the result is yes, sending the call request; The notification module reports the data corresponding to the user according to the call request and outputs an exception log according to the judgment result; Determine the urgency of the result according to the abnormality log; If the urgency level is urgent, prohibit the user from calling the tool method library, clear the user's page request, and notify the user of the result of the judgment; If the urgency level is not urgent, the user is notified of the result of the determination.

8. The device according to claim 7, characterized in that Determining whether the address corresponding to the call request is in a preset whitelist includes: Using a tool class method library, determine whether the address corresponding to the call request is in a preset whitelist; and / or using a copied browser object request, determine whether the address corresponding to the call request is in a preset whitelist.

9. An electronic device for monitoring abnormal user codes, characterized in that: include: one or more processors; a storage device for storing one or more programs, When the one or more programs are executed by the one or more processors, the one or more processors implement the method according to any one of claims 1 to 6.

10. A computer-readable medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the method according to any one of claims 1 to 6 is implemented.

Images