Patent Application
20190098045
The present invention relates to the technical field of browsers, and more particularly, to a browser injection prevention method, a browser client and apparatus having a browser client.
A browser is a software that can display file contents of HyperText Mark-up Language (HTML) contained in web servers or file systems and allow users to interact with these files. Web browsers interact with the web serves primarily via HTTP protocols and obtain webpages, which are specified by a uniform resource locator (URL) and generally have a file format of HTML.
In the process of using the browser, other programs may inject layered service provider (LSP) nodes to the browser, that is, dynamic link libraries of the LSP are injected. These dynamic link libraries have a function of processing network requests sent by the browser in Winsock, for example, hijacking the browser: the network requests being redirected to unsafe webpages, unsafe webpages being automatically and repeatedly added to bookmarks, items that can't be changed or hidden appearing in IE tabs, acquiring login names and passwords on the webpages, etc. Therefore, dynamic link libraries injected by these programs are not safe for the users' browsers.
In view of the above problems, the present invention is proposed to provide a browser client and a corresponding browser injection prevention method, which may overcome or at least partially solve the above problems.
According to an aspect of the present invention, there is provided a browser injection prevention method, which comprises: copying a source layered service provider chain table of a current browser to obtain a first layered service provider chain table; converting a source node to which access is not permitted, in the first layered service provider chain table, into a virtual node to obtain a converted second layered service provider chain table; wherein the virtual node implements an interface with each layered service provider and returns a null value; and controlling a network request of the current browser to be transmitted by means of the second layered service provider chain table.
According to another aspect of the present invention, a browser client is further disclosed, including: a network component, configured to initiate a network request to be sent to a server; an injection prevention component, specifically comprising: a chain table copying module, configured to copy a source layered service provider chain table of a current browser to obtain a first layered service provider chain table; a chain table converting module, configured to convert a source node to which access is not permitted, in the first layered service provider chain table, into a virtual node to obtain a converted second layered service provider chain table; wherein the virtual node implements an interface with each layered service provider and returns a null value; and a request control module, configured to control the network request to be transmitted by means of the second layered service provider chain table.
According to still another aspect of the present invention, an apparatus having a browser client is further disclosed, which comprises: a processor, and a memory loading a plurality of executable instructions, the plurality of instructions comprising a method for executing following steps: initiating a network request to be sent to a server; copying a source layered service provider chain table of a current browser to obtain a first layered service provider chain table; converting, after acquiring the first layered service provider chain table, a source node to which access is not permitted, in the first layered service provider chain table, into a virtual node to obtain a converted second layered service provider chain table, wherein the virtual node implements an interface with each layered service provider and returns a null value; and controlling the network request to be transmitted by means of the second layered service provider chain table.
According to still another aspect of the present invention, there is provided a computer program, comprising a computer-readable code, wherein a terminal device is caused to execute the browser injection prevention method when the computer-readable code runs on the terminal device.
According to still another aspect of the present invention, there is provided a computer-readable medium, in which the computer program of the browser injection prevention method is stored.
According to the browser injection prevention method of the present invention, a source layered service provider (LSP) chain table used by a browser may be converted into a secure second LSP chain table; thus a procedure in which a network request sent down by the browser is subjected to processing by an insecure LSP node in an LSP chain table is avoided. Hence, the problem of other application programs injecting an insecure LSP node into the browser to hijack the browser is solved, and a beneficial effect of improving the browser security is obtained.
Described above is merely an overview of a technical solution of the present invention. In order to more apparently understand the technical means of the present invention to implement in accordance with the contents of specification, and to more readily understand above and other objectives, features and advantages of the present invention, particular embodiments of the present invention are provided hereinafter.
Through reading the detailed description of the following preferred embodiments, various other advantages and benefits will become apparent to those of ordinary skills in the art. Accompanying drawings are merely included for the purpose of illustrating the preferred embodiments and should not be considered as limiting of the present invention. Further, throughout the drawings, like reference signs are used to denote like elements. In the drawings:
The following will describe in more detail the exemplary embodiments of the present invention with reference to the accompanying drawings. Although the accompanying drawings display the exemplary embodiments of the present invention, it should be understood that the present invention may be implemented in various forms but not limited by the embodiments set forth herein. Instead, these embodiments are provided to more thoroughly understand the present invention, and completely convey the scope of the present invention to those skilled in the art.
Referring to
Step 110: copying a source layered service provider chain table of a current browser to obtain a first layered service provider chain table.
In practical application, other application programs may inject an LSP node into the browser according to traditional way. That is, a dynamic link library (DLL) of the LSP may be injected into the browser, the DLL of the LSP may be may be written into a registry (for example, written into a corresponding location of a registry HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WinSock2\Parameters), and relevant configuration information may be written into configuration information of the source LSP chain table, wherein the configuration information records information such as the location of the registry of the DLL. According to traditional way, after the browser is started and before a request is sent out, the source LSP chain table may be loaded according to the configuration information of the source LSP chain table of the browser. That is, the DLL of each node in the LSP chain table is loaded, and then a network request of the browser may be transmitted, starting from a first LSP node in the source LSP chain table, downward via LSP nodes one by one until the network request is transmitted to other protocol layers such as TCP/IP protocol layer.
However, in the present invention, the source LSP chain table may be first converted before the first network request of the browser is sent out. First, a source LSP chain table is copied, for example, an order DLL file in the source LSP chain table is copied, wherein the copied version serves as a first LSP chain table for subsequent processing.
Step 120: converting a source node to which access is not permitted, in the first layered service provider chain table, into a virtual node to obtain a converted second layered service provider chain table; wherein the virtual node implements an interface with each layered service provider and returns a null value; and
It could be determined, one by one, whether each node in the first LSP chain table obtained by copying is the source node to which access is not permitted. The source node may be determined according to a name of a node. For example, the name of an LSP name is mswsock.dll, then the source node may be determined according to a whitelist or blacklist. For example, the name of a source node to which access is permitted is written into the whitelist, when each node in the first LSP chain table is not in the whitelist, access to the source node is not permitted, or it may be understood that the DLL of the LSP node is not permitted to be added. In this embodiment of the present invention, only default LSP node names in system initial situation may be written into the whitelist. Of course, LSP node names injected by other secure application programs may be written into the whitelist, which may be updated via a server. In the same way, the blacklist of an LSP node may be constructed.
In this embodiment of the present invention, the source node to which access is not permitted may be converted into a virtual node (namely, fake.dll). The virtual LSP node may implement all interfaces of the LSP, the network request transmitted by a previous node of the virtual node may normally access the virtual node. The virtual node does not process the network request, namely, the virtual node returns a null value NULL, and then continues to transmit the network request downward. Therefore, a situation of failure in surfing the Internet resulted from an abnormality in sending the network request does not occur in the virtual node. A second LSP chain table is obtained after the source node to which access is not permitted is replaced with the virtual node.
Step 130: controlling a network request of the current browser to be transmitted by means of the second layered service provider chain table.
The network request of the browser may be controlled to be transmitted by means of the second LSP chain table.
In the process of transmitting the network request of the browser outward, the network request needs to be first processed by an LSP chain table so as to be transmitted downward to a communication protocol layer (such as TCP/IP layer), and then the network request is transmitted outside. In the traditional technologies, a customized LSP node may be injected into the LSP chain table to hijack and process the network request of the browser, which may cause a problem of security risk. No matter how other application programs inject LSP nodes, in this embodiment of the present invention, before the browser sends a first network request, the source LSP chain table, in the system, including the LSP node injected by the application program may be replaced with the second LSP chain table, and a source node to which access is not needed is replaced with a virtual node. It may be guaranteed that a network request issued by the browser can be transmitted via a secure LSP chain table no matter how many LSP nodes are injected by how many application programs. Therefore, security of the browser can be improved.
Referring to
Step 210: copying a source layered service provider chain table of a current browser to obtain a first layered service provider chain table.
For example, the source LSP chain table is: A.dll->B.dll->C.dll->D.dll, and the first LSP chain table obtained by copying is A.dll->B.dll->C.dll->D.dll. Of course, in this embodiment of the present invention, a path of each source node recorded in the registry may be searched according to the configuration information of the source LSP chain table of the browser, and then each source node of the source LSP chain table may be copied via the path.
Step 220: obtaining identity information of each source node of the first layered service provider chain table by means of configuration information of the source layered service provider chain table.
Each node in the first LSP chain table is identical to each node of the source LSP chain table. Therefore, identity information of each source node of the first layered service provider chain table may be obtained by reading configuration information of the source LSP chain table. The identity information of each source node generally is stored in the configuration information of the source LSP chain table, for example, information such as registry entry and record name and order recorded for each node. In this embodiment of the present invention, the identity information of each node may be determined according to the configuration information, such as the name thereof. For example, in the above example, the obtained identity information of each node in each of the first LSP chain tables may be A, B, C and D in order.
Step 230: matching the identity information of the each source node with a preset identity information list to determine a source node to which access is not permitted according to a matching result.
In this embodiment of the present invention, an identity information whitelist or an identity information blacklist may be constructed to match the identity information of the each source node. For example, when [A, D] is set up in the whitelist, A, B, C and D are respectively matched with the whitelist, and the source nodes whose names are B and C may be determined as source nodes to which access is not permitted.
Step 240: converting a path, of the source node to which access is not permitted, in a registry into a path of the virtual node to obtain the converted second layered service provider chain table.
In this embodiment of the present invention, the virtual node may be set up in advance, for example fake.dll, storage and specified path.
When the source node is used, the source node needs to be loaded by means of the path of the source node recorded in the registry entry corresponding to the registry, and the path, of the source node to which access is not permitted, in the registry entry corresponding to the registry may be replaced with the path of the virtual node.
In this embodiment of the present invention, a virtual node may be set up for all source node to which access is not permitted, and paths, of the source nodes to which access is not permitted, in the registry entry corresponding to the registry may be replaced with the path of the virtual node, for example, the path of fake.dll. Of course, a corresponding number of virtual nodes may be copied by taking a virtual node initially set as a blueprint according to the number of determined source nodes to which access is not permitted, and file names of the virtual nodes are modified to be different. For example, in the preceding example there are two nodes B and C, two virtual nodes fake1.dll and fake2.dll may be obtained by copying, each virtual node having a path, the registry path of B.dll is modified into the path of fake1.dll, and the registry path of C.dll is modified into the path of fake2.dll.
In this way, the second LSP chain table is obtained, source nodes that are permitted to be loaded in the chain table are reserved, and source nodes that are not permitted to be loaded in the chain table are converted into the virtual nodes.
Steps 220-240 are preferred embodiments of Step 120 according to Embodiment I.
Step 250: controlling a network request of the current browser to be transmitted by means of the second layered service provider chain table.
After the second LSP chain table is obtained and before the browser needs to transmit the network request for the first time, loading may be conducted according to the second LSP chain table, and the network request may be transmitted via the second LSP chain table.
Preferably, the controlling a network request of the current browser to be transmitted by means of the second layered service provider chain table comprises following substeps.
Substep 251: searching a dynamic link library of each node of the second layered service provider chain table from a registry according to configuration information of the source layered service provider chain table and loading the dynamic link library.
In this embodiment of the present invention, the configuration information of the source layered service provider chain table of the browser is not modified, but only node path corresponding to the configuration information and node content are modified. When the browser acquires a corresponding dll according to the configuration information of the LSP chain table, for the configuration information of the source node whose path is replaced, the virtual node may be loaded from the path recorded in the registry entry thereof. Finally, the second LSP chain table is loaded, but the dll of the real source node to which access is not permitted is not loaded.
No matter how other application programs inject LSP nodes, in this embodiment of the present invention, before the browser sends a first network request, the source LSP chain table, in the system, including the LSP node injected by the application program may be replaced with the second LSP chain table, and a source node to which access is not needed is replaced with a virtual node. It may be guaranteed that a network request issued by the browser can be transmitted via a secure LSP chain table no matter how many LSP nodes are injected by how many application programs. Therefore, security of the browser can be improved.
Referring to
Step 310: copying a source layered service provider chain table of a current browser to obtain a first layered service provider chain table.
Step 320: obtaining identity information of each source node of the first layered service provider chain table by means of configuration information of the source layered service provider chain table.
Step 330: matching the identity information of the each source node with a preset identity information list to determine a source node to which access is not permitted according to a matching result.
Step 340: sending a registry path setup request to a first operating system service in a current operating system by the browser so that the first operating system service converts the path, of the source node to which access is not permitted, in a registry into the path of the virtual node by invoking a virtual device-level driver to obtain the converted second layered service provider chain table.
In this embodiment of the present invention, a permission level of the browser is lower, and a registry path setup request may be directly sent to a first operating system service in a current operating system so that the first operating system service converts the path, of the source node to which access is not permitted, in a registry into the path of the virtual node set up in advance by invoking a virtual device-level driver. In this way, the second LSP chain table is obtained finally. The registry path setup request includes registry location information of a node to which access is not permitted and the path of a virtual node corresponding to the node to which access is not permitted.
Preferably, Step S300 may be further included: obtaining and installing an installation file of the first operating system service by the browser to obtain the first operating system service in the current operating system.
In this embodiment of the present invention, a source node to which access is not permitted, in the first layered service provider chain table is converted into a virtual node via the browser. As a user-level permission, the browser has a lower permission level, which may likely exceed permission setting of the system and thus cause failure of executing the conversion. Therefore, conversion permission needs to be improved in form of service.
In the present invention, the browser may acquire in advance and install the installation file of the first operating system service. After being restarted, the service may be randomly started. The service has a relatively high permission level in the operating system, and thus may be less restricted in executing the above operation.
Of course, in this embodiment of the present invention, also it may be determined, in an implementation process, whether the first operating system service has been installed. That is, preferably, obtaining and installing an installation file of the first operating system service by the browser to obtain the first operating system service in the current operating system include following substeps.
Substep S301: determining whether the first operating system service exists; and obtaining and installing an installation file of the first operating system service to obtain the first operating system service in the current operating system when the first operating system service does not exist.
As a process, the first operating system service also has information such as a process name after being started. The browser may search, from the operating system, whether the process name of the first operating system service is present in the currently started processes. When the process name is present, this indicates that the first operating system service has been installed. Otherwise, the first operating system service has not been installed yet.
Preferably, obtaining and installing an installation file of the first operating system service by the browser to obtain the first operating system service in the current operating system include following substeps.
Substep S302: obtaining the installation file of the first operating system service, and installing a dynamic link library of the first operating system service and the virtual device-level driver by means of the installation file of the first operating system service.
In practice, the installation file of the first operating system service further includes the virtual device-level driver, which may be installed along with the installation file. When the first operating system service is not in use, the virtual device-level driver may be not invoked via logic in the dll.
The virtual device-level driver belongs to a kernel-level program and has a highest permission of the operating system. Therefore, replacement of the source node may be executed may be more easily executed by the virtual device-level driver.
Substep S303: starting a process where the first operating system service is to load the dynamic link library of the first operating system service; and invoking the virtual device-level driver by the first operating system service by means of the dynamic link library.
When in installation, the first operating system service may generate a dll file in the system (sys) file, and write relevant parameters of the dll into the registry of the operating system service. Meanwhile, the sys file of the virtual device-level driver may be installed in the operating system, and the relevant parameters of the sys file may be written into the registry. After the operating system is started, an exe file of the first operating system service may be started to wait for notification of a browser process.
Preferably, converting a path, of the source node to which access is not permitted, in a registry into a path of the virtual node by the first operating system service by invoking a virtual device-level driver includes following substeps:
Substep S341: when receiving the registry path setup request, creating, by the first operating system service according to the registry path setup request, an I/O request packet, and sending the I/O request packet to the virtual device-level driver.
In this embodiment of the present invention, the first operating system service may be started as the system is started and may keep running to monitor whether a request sent by the browser is received. When receiving the registry path setup request sent by the browser, an I/O request packet (IRP) may be created according to the registry path setup request and sent down to the virtual device-level driver. An instruction transmitted by the Windows operation system from an application layer to a bottom driver is transmitted by means of the I/O request packet. The first operating system service invokes the virtual device-level driver in this embodiment of the present invention, an IRP needs to be constructed for the purpose of the device-level driver, and then the IRP is sent down to the device-level driver. The IRP includes an instruction controlling the device-level driver to convert a path, of the source node to which access is not permitted, in a registry into a path of the virtual node, for example, including information of the registry entry of the node to which access is not permitted, and information such as the path of the virtual node corresponding to the node to which access is not permitted.
Substep S342: after receiving the I/O request packet, converting, by the virtual device-level driver by invoking a registry modification function, the path, of the source node to which access is not permitted, in a registry into the path of the virtual node.
After the virtual device-level driver determines that the program receives the I/O request packet sent by the first operating system service, an instruction in the I/O request packet is resolved to obtain the information of the registry entry of the node to which access is not permitted and the path information of the virtual node corresponding to the node to which access is not permitted. The path, of the source node to which access is not permitted, in a registry may be converted into the path of the virtual node by invoking the registry modification function.
The path, of the source node to which access is not permitted, in a registry may be converted into the path of the virtual node by means of the registry modification function RegSetValueEx( ) The function prototype of RegSetValueEx( ) is:
The converted second layered service provider chain table may be obtained through the above mentioned way.
In this embodiment of the present invention, the first operating system service may be installed as a part of processes of the browser when the browser is installed, serving as a functional module of the browser.
Step 340 is a preferred embodiment of Step 240 according to Embodiment II.
Step 350: controlling a network request of the current browser to be transmitted by means of the second layered service provider chain table.
No matter how other application programs inject LSP nodes, in this embodiment of the present invention, before the browser sends a first network request, the source LSP chain table, in the system, including the LSP node injected by the application program may be replaced with the second LSP chain table, and a source node to which access is not needed is replaced with a virtual node. It may be guaranteed that a network request issued by the browser can be transmitted via a secure LSP chain table no matter how many LSP nodes are injected by how many application programs. Therefore, security of the browser can be improved. In this embodiment of the present invention, the path, of the source node to which access is not permitted, in a registry is converted into the path of the virtual node by the first operating system service by invoking a virtual device-level driver to obtain the second LSP chain table, and the conversion is carried out with kernel-level permission, thereby avoiding a failed conversion caused by limit of conversion permission by the operating system.
Referring to
Step 410: copying a source layered service provider chain table of a current browser to obtain a first layered service provider chain table.
Step 420: obtaining identity information of each source node of the first layered service provider chain table by means of configuration information of the source layered service provider chain table.
Step 430: matching the identity information of the each source node with a preset identity information list to determine a source node to which access is not permitted according to a matching result.
Step 440: sending a registry path setup request to a browser-independent second application program by the browser by means of a preset interface.
Step 450: sending the registry path setup request by the browser-independent second application program to the first operating system service in the current operating system so that the first operating system service converts the path, of the source node to which access is not permitted, in a registry into the path of the virtual node by invoking a virtual device-level driver to obtain the converted second layered service provider chain table.
In this embodiment of the present invention, the browser is not provided with the function of the first operating system service, but the browser-independent second application program is provided with the function of the first operating system service, for example, programs such as 360 Safeguard and 360 WebShield. The browser may send the registry path setup request to the independent second application program by means of a preset external interface. The registry path setup request includes registry location information of a node to which access is not permitted and the path of a virtual node corresponding to the node to which access is not permitted. The browser-independent second application program sends the registry path setup request to the first operating system service in the current operating system so that the first operating system service converts the path, of the source node to which access is not permitted, in a registry into the path of the virtual node by invoking a virtual device-level driver to obtain the converted second layered service provider chain table.
Steps 440-450 are preferred embodiments of Step 240 according to Embodiment II.
Step 460: controlling a network request of the current browser to be transmitted by means of the second layered service provider chain table.
No matter how other application programs inject LSP nodes, in this embodiment of the present invention, before the browser sends a first network request, the source LSP chain table, in the system, including the LSP node injected by the application program may be replaced with the second LSP chain table, and a source node to which access is not needed is replaced with a virtual node. It may be guaranteed that a network request issued by the browser can be transmitted via a secure LSP chain table no matter how many LSP nodes are injected by how many application programs. Therefore, security of the browser can be improved. In this embodiment of the present invention, using the permission of a third-party application program, the path, of the source node to which access is not permitted, in a registry is converted into the path of the virtual node by the first operating system service by invoking a virtual device-level driver to obtain the second LSP chain table, and the conversion is carried out with kernel-level permission, thereby avoiding a failed conversion caused by limit of conversion permission by the operating system.
Referring to
Step 510: copying a source layered service provider chain table of a current browser to obtain a first layered service provider chain table.
Step 520: obtaining identity information of each source node of the first layered service provider chain table by means of configuration information of the source layered service provider chain table.
Step 530: matching the identity information of the each source node with a preset identity information list to determine a source node to which access is not permitted according to a matching result.
Step 540: sending a registry path setup request to a first operating system service in a current operating system by the browser.
Step 550: determining by the first operating system service whether a sender of the registry path setup request is a specified browser; entering into Step 552 when the sender of the registry path setup request is not the specified browser; or entering into Step 554 when the sender of the registry path setup request is the specified browser.
Step 552: not entering into subsequent processing.
Step 554: creating an I/O request packet according to the registry path setup request and sending the I/O request packet to the virtual device-level driver.
In this embodiment of the present invention, to prevent a browser not selected by a user or a browser cooperating with a third party from using the injection prevention function mentioned in this embodiment of the present invention and from increasing system resource consumption, a whitelist may be set up in the first operating system service for the browser. Next, the identity information of the sender of the registry path setup request is acquired and matched with the browser whitelist recorded in the first operating system service. An injection prevention process is not entered into when the matching fails. Otherwise, an I/O request packet is created according to the registry path setup request and sent down to the virtual device-level driver.
Preferably, the registry path setup request includes identity authentication information of the browser. The identity authentication information includes, for example, a browser name, namely signature information of the browser, or of course may be other unique identity authentication information.
Further, determining by the first operating system service whether a sender of the registry path setup request is a specified browser includes:
Substep S5501: resolving the identity authentication information in the registry path setup request, matching the identity authentication information with prestored identity authentication information; and determining that the sender of the registry path setup request is the specified browser when the matching is successful.
The browser name is matched with a browser name recorded in the first operating system service, or the signature information of the browser is matched with signature information of the browser recorded in the first operating system service. The sender of the registry path setup request may be regarded as the specified browser when the matching succeeds, and the device-level driver may be utilized to execute the injection prevention function.
Step 560: after receiving the I/O request packet, converting, by the virtual device-level driver by invoking a registry modification function, the path, of the source node to which access is not permitted, in a registry into the path of the virtual node to obtain a converted second layered service provider chain table.
Step 570: controlling a network request of the current browser to be transmitted by means of the second layered service provider chain table.
Referring to
Step 610: copying a source layered service provider chain table of a current browser to obtain a first layered service provider chain table.
Step 620: obtaining identity information of each source node of the first layered service provider chain table by means of configuration information of the source layered service provider chain table.
Step 630: matching the identity information of the each source node with a preset identity information list to determine a source node to which access is not permitted according to a matching result.
Step 640: sending a registry path setup request to a first operating system service in a current operating system by the browser.
Step 650: when receiving the registry path setup request, creating, by the first operating system service according to the registry path setup request, an I/O request packet, and sending the I/O request packet to the virtual device-level driver.
Step 660: determining, by the virtual device-level driver according to the I/O request packet, whether a sender of the registry path setup request is a specified browser; entering into Step 662 when the sender of the registry path setup request is not the specified browser; or entering into Step 664 when the sender of the registry path setup request is the specified browser.
Step 662: not entering into subsequent processing.
Step 664: converting a path, of the source node to which access is not permitted, in a registry into a path of the virtual node by invoking the registry modification function to obtain the converted second layered service provider chain table.
In this embodiment of the present invention, to prevent a browser not selected by a user or a browser cooperating with a third party from using the injection prevention function mentioned in this embodiment of the present invention and from increasing system resource consumption, a whitelist may be set up in the virtual device-level driver for the browser. Next, the identity information of the sender of the registry path setup request is acquired according to the I/O request packet and matched with the browser whitelist recorded in the virtual device-level driver. An injection prevention process is not entered into when the matching fails. Otherwise, an I/O request packet is created according to the registry path setup request and sent down to the virtual device-level driver.
Preferably, the registry path setup request includes identity authentication information of the browser. The identity authentication information includes, for example, a browser name, namely signature information of the browser, or of course may be other unique identity authentication information.
Further, determining by the virtual device-level driver whether a sender of the registry path setup request is a specified browser according to the I/O request packet includes following substeps.
Substep S6601: receiving, by the virtual device-level driver, an I/O request packet sent by the first operating system service; the I/O request packet including the identity authentication information of the browser.
The browser may transmit the registry path setup request to the first operating system service. The first operating system service may repackage the registry path setup request into an IRP based on registry location information of a node to which access is not permitted included in the registry path setup request, the path of the virtual node corresponding to the node to which access is not permitted, and the identity authentication information of the browser, and then transmit the IRP to the device-level driver.
Substep S6602: resolving the identity authentication information in the I/O request packet, matching the identity authentication information with prestored identity authentication information; and determining that the sender of the registry path setup request is the specified browser when the matching is successful.
After receiving the I/O request packet sent by the first operating system service, the device-level driver may resolve the registry location information of the node to which access is not permitted included in the I/O request packet, the path of the virtual node corresponding to the node to which access is not permitted, and the identity authentication information of the browser, and then match the identity authentication information with prestored identity authentication information. The sender of the registry path setup request is determined as the specified browser when the matching is successful.
Step 670: controlling a network request of the current browser to be transmitted by means of the second layered service provider chain table.
Referring to
Referring to
Preferably, the request control module 823 includes:
Referring to
Preferably, the browser client further includes:
Preferably, the first converting module includes:
Preferably, the service installing module further includes:
Preferably, the first converting module further includes:
Preferably, the first converting module includes:
Referring to
Referring to
Preferably, the registry path setup request includes identity authentication information of the browser.
Further, the first identity determining module includes:
Referring to
Preferably, the registry path setup request includes identity authentication information of the browser.
Further, the second identity determining module comprises:
Referring to
Preferably, the converting a source node to which access is not permitted, in the first layered service provider chain table, into a virtual node includes:
Preferably, the converting a path, of the source node to which access is not permitted, in a registry into a path of the virtual node includes:
Of course, the plurality of instructions may further include steps for executing various methods in the preceding embodiments.
Algorithm and display provided herein are not inherently related to a particular computer, virtual system or other equipment. Various general systems may also be used with the teaching based on the present invention. According to the above description, the required structure for constructing such a system is obvious. In addition, the present invention is not directed to any particular programming language. It should be understood that a variety of programming languages can be used to implement the disclosed contents as described herein and above description to the particular programming language is to disclose the best inventive implementation mode.
Many details are discussed in the specification provided herein. However, it should be understood that the embodiments of the present invention can be implemented without these specific details. In some examples, the well-known methods, structures and technologies are not shown in detail so as to avoid an unclear understanding of the description.
Similarly, it should be understood that, in order to simplify the present invention and to facilitate the understanding of one or more of various aspects thereof, in the above description of the exemplary embodiments of the present invention, various features of the present invention may sometimes be grouped together into a single embodiment, accompanying figure or description thereof. However, the method of this present invention should not be constructed as follows: the present invention for which the protection is sought claims more features than those explicitly disclosed in each of claims. More specifically, as reflected in the following claims, the inventive aspect is in that the features therein are less than all features of a single embodiment as disclosed above. Therefore, claims following specific embodiments are definitely incorporated into the specific embodiments, wherein each of claims can be considered as a separate embodiment of the present invention.
It should be understood by those skilled in the art that modules of the device in the embodiment can be adaptively modified and arranged in one or more devices different from the embodiment. Modules, units or components in the embodiment can be combined into one module, unit or component, and also can be divided into more sub-modules, sub-units or sub-components. Except that at least some of features and/or processes or units are mutually exclusive, various combinations can be used to combine all the features disclosed in specification (including claims, abstract and accompanying figures) and all the processes or units of any methods or devices as disclosed herein. Unless otherwise definitely stated, each of features disclosed in specification (including claims, abstract and accompanying figures) may be taken place with an alternative feature having same, equivalent or similar purpose.
In addition, it should be understood by those skilled in the art, although some embodiments as discussed herein comprise some features included in other embodiment rather than other feature, combination of features in different embodiment means that the combination is within a scope of the present invention and forms the different embodiment. For example, in the claims, any one of the embodiments for which the protection is sought can be used in any combination manner.
Each of devices according to the embodiments of the present invention can be implemented by hardware, or implemented by software modules operating on one or more processors, or implemented by the combination thereof. A person skilled in the art should understand that, in practice, a microprocessor or a digital signal processor (DSP) may be used to realize some or all of the functions of some or all of the parts in the browser injection prevention device according to the embodiments of the present invention. The present invention may further be implemented as device or browser client program (for example, computer program and computer program product) for executing some or all of the methods as described herein. Such program for implementing the present invention may be stored in the computer readable medium, or have a form of one or more signals. Such a signal may be downloaded from the Internet websites, or be provided on a carrier signal, or provided in any other form.
For example,
It should be noted that the above-described embodiments are intended to illustrate but not to limit the present invention, and alternative embodiments can be devised by a person skilled in the art without departing from the scope of claims as appended. In the claims, no reference mark between round brackets shall impose restriction on the claims. The word “include/comprise” does not exclude a component or step not listed in the claims. The wording “a” or “an” in front of an element does not exclude the presence of a plurality of such elements. The present invention may be realized by means of hardware comprising a number of different components and by means of a suitably programmed computer. In the unit claim listing a plurality of browser clients, some of these browser clients may be embodied in the same hardware. The wordings “first”, “second”, and “third”, etc. do not denote any order. These wordings can be construed as naming. Also, it should be noticed that the language used in the present specification is chosen for the purpose of readability and teaching, rather than explaining or defining the subject matter of the present invention. Therefore, it is apparent to an ordinary skilled person in the art that modifications and variations could be made without departing from the scope and spirit of the claims as appended. For the scope of the present invention, the publication of the present invention is illustrative rather than restrictive, and the scope of the present invention is defined by the appended claims.
| Number | Date | Country | Kind |
|---|---|---|---|
| 201410742770.3 | Dec 2014 | CN | national |
This application is the national stage of International Application No. PCT/CN2015/094844 filed Nov. 17, 2015, which claims the benefit of Chinese Patent Applications No. CN201410742770.3, filed Dec. 5, 2014, the entirety of which are incorporated herein by reference.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/CN2015/094844 | 11/17/2015 | WO | 00 |
