GB2540375A

GB2540375A - Preventing browser-originating attacks in a local area network

Info

Publication number: GB2540375A
Application number: GB1512306.0A
Authority: GB
Inventors: Hentunen Daavid
Original assignee: F Secure Oyj
Current assignee: WithSecure Oyj
Priority date: 2015-07-14
Filing date: 2015-07-14
Publication date: 2017-01-18
Also published as: GB201512306D0

Abstract

Preventing browser-originating attacks in a Local Area Network by rejecting or suspending the transmission of a connection request message Attacks, in particular browser port scanning attacks originating from a browser of a first LAN-connected device 100, are prevented by intercepting a connection request message to a second LAN-connected device 200, parsing the message to identify an address of a website that caused the browser to generate the request, and rejecting or suspending transmission of the message if the address is not trusted. Checking if the address, which may be an IP address or a URL, is trusted comprises determining if it is an address within the LAN, or in a database of trusted external network addresses. The request may be an HTTP request wherein the address is the content of an identified Referrer field, without which the message proceeds. The prevention may be implemented by a browser plugin on the first device, or at a network traffic analyser within the LAN, or partially by a network server. If the address is not trusted, the user of the first device may be prompted to approve the request before continuing with the establishment of the connection.

Description

Preventing Browser-originating Attacks in a Local Area Network

Technical Field

The invention relates to the field of preventing browser-originating attacks in a Local Area Network. It is applicable in particular, though not necessarily, to preventing attacks involving browser port scanning.

Background

The Internet of Things (loT) is the interconnection of uniquely identifiable embedded computing devices within the existing Internet infrastructure. For example, in some households there are already several Internet connected devices such as gaming consoles, Network Attached Storage (NAS) boxes, Smart TVs, tablets, smartphones, and laptops. All of these devices may connect to the Internet using the same home router, which acts as a Wi-Fi Access Point and allows the devices to connect to the Internet. In the future, more and more home and office devices will be connected to the Internet. Even household devices such as toasters and refrigerators may contain Wi-Fi chips and computing power.

From a security perspective, loT devices present a number of challenges. Many such devices rely upon relatively old versions of freeware operating systems, such as Linux. Such operating systems may lack automatic update capability and, due to limitations posed by the lack of a proper user interface, may not have robust systems for authentication and authorization. As a result, vulnerabilities found in an open source library software (serious and widespread examples from 2014 include “goto fail” CVE-2014-1266, “heartbleed” CVE-2014-0160, and “shellshock” CVE-2014-6271) is unlikely to be patched on loT devices and unauthenticated attack vectors are likely to exist. It is highly likely that attackers will start to target these devices. Compromised loT devices can be infected by malware and harnessed to money-making schemes such as DDoS, Bitcoin mining, Clickfraud, sending spam and so on.

Most home routers use Network Address Translation (NAT) between the loT device and the Internet. This means that loT devices at home are not readily accessible from the Internet. Furthermore, as most loT devices are not used for surfing the Internet or reading email, attacks such as drive-by-downloads are not able to compromise these devices. One of the driving forces behind the development of NAT was the limited number of IP addresses available. With the introduction of IPv6 there is no need to extend the IP address space. However, NAT and similar technologies that prevent “outside-in” connections are likely to remain in use, in order to protect the home network. This provides some level of protection for simple loT devices. A potential attack vector to compromise loT devices such as Smart TVs, NAS storage devices and so on, is via a home computer such as a PC, laptop, smartphone or other device that may be used for web browsing or reading emails and which is connected within the home Local Area Network. Examples of such attacks include drive-by-downloads or social engineering schemes. Once the home computer has been compromised, the attacker can then attack other loT devices served by the same home router. It is also possible that loT devices in the Local Area Network (LAN) can be compromised without actually installing any malware on the bridgehead device (typically a laptop, tablet, or smartphone). This can be accomplished by a technique sometimes referred to as “browser port scanning” in which a web browser on a device is used as a stepping stone to scan and attack vulnerable devices in the local network.

Since at least 2006, it has been a widely known problem that malicious websites on the Internet can scan and access intranet servers of companies if their employees visit those web sites (see, for example, Grossman, J. “JavaScript malware, port scanning, and beyond. Posting to the websecurity mailing list” (July 2006), and Grossman, J. “Browser port scanning without JavaScript” (08/01/07) (November 2006)). This can be accomplished with JavaScript and to an extent also with plain HTML. The same attack has applications in attacks against home users now that homes have multiple devices. A typical scenario involves a user using a computer within the Local Area Network to browse to a web page controlled by an attacker. The web page contains JavaScript code that is downloaded into the computer’s browser and executed to access hosts in private address ranges (172.16.x.x, 192.168.x.x and 10.x.x.x for IPv4 and fc00::/7 for IPv6). The attacker doesn’t have to scan the whole address space because home routers tend to default to just a few subnets such as 10.0.1.0/24 and 192.168.1.0/24, and hosts at home today are likely to be found at the lower ranges (2-10) within those subnets. If hosts are found, they are “fingerprinted” in order to identify the type of device. This may be achieved by pattern matching the http index page they provide. If any hosts are vulnerable to known http exploits (such as Shellshock Bash vulnerability, CVE-2014-6271), the JavaScript can launch an exploit and open a remote connection from the vulnerable host to the attacker thus defeating the outside-in blocking provided by the NAT or firewall.

Browser port scanning can be prevented by preventing devices in the LAN from communicating with each other. For example, if all loT devices in the LAN are prevented from connecting to port 80 on other devices, most of these attacks could be prevented. If this is limited only to connections with a browser user-agent, the problem of preventing valid remote control apps from working is avoided. However, it is often the case that the same computer that is likely to be used as the bridgehead is also the device that the legitimate user uses when accessing the administration (web) interfaces of the various home devices, e.g. a user will use his or her smart phone to check the contents of a fridge. If connecting from the user’s computer is prevented or made more difficult, then users are unlikely to use the loT device or are likely to disable the security features that prevent or limit connection.

Summary of the Invention

In accordance with a first aspect of the present invention, there is provided a method of preventing a browser-originating attack in a Local Area Network (LAN). The method comprises intercepting a connection request message generated by a browser instance at a first LAN-connected device and directed to a second LAN-connected device. The method further comprises parsing the connection request message to identify an address of a website that caused said browser instance to generate the request. The method further comprises performing a check of said address to determine whether or not the address is trusted and, if it is trusted, then allowing the connection request message to proceed, otherwise rejecting or suspending transmission of the connection request message.

The step of performing a check of said address to determine whether or not the address is trusted may comprise treating the address as trusted if it is an address within the LAN. If the address is not an address of the LAN, a database of trusted and/or untrusted external network addresses may be used to determine whether or not the address is trusted.

The step of intercepting a connection request message generated by a browser instance at a first LAN-connected device and directed to a second LAN-connected device may be carried out at said first LAN-connected device or at a network traffic analyser deployed within the LAN. The step of parsing the connection request message to identify an address of a website that caused said browser instance to generate the request may also be carried out at said first LAN-connected device or at a network traffic analyser deployed within the LAN.

The step of performing a check of said address to determine whether or not the address is trusted and, if it is trusted, then allowing the connection request message to proceed, otherwise rejecting or suspending transmission of the connection request message, may be carried out at a network server. The step of parsing the connection request message to identify an address of a website that caused said browser instance to generate the request may also be carried out at the network server.

The method may further comprise, following interception of the request, transmitting a query containing the request or a part of the request to said network server. The method may further comprise, following allowing the connection request message to proceed or otherwise rejecting or suspending transmission of the connection request message, sending a result from the network server to the first-LAN connected device or to said network entity.

In accordance with a second aspect of the present invention, there is provided apparatus for preventing a browser-originating attack in a Local Area Network (LAN). The apparatus comprises processor circuitry and a storage unit for storing instructions executable by the processor circuitry. The apparatus is operative to intercept a connection request message generated by a browser instance at a first LAN-connected device and directed to a second LAN-connected device. The apparatus is further operative to parse the connection request message to identify an address of a website that caused said browser instance to generate the request. The apparatus is further operative to perform a check of said address to determine whether or not the address is trusted and, if it is trusted, then allow the connection request message to proceed, otherwise reject or suspend transmission of the connection request message.

In performing a check of said address to determine whether or not the address is trusted, the apparatus may be operative to treat the address as trusted if it is an address within the LAN. The apparatus may also be operative to use a database of trusted and/or untrusted external network addresses to determine whether or not the address is trusted, if the address is not an address of the LAN.

In accordance with a third aspect of the present invention, there is provided an end user device comprising the apparatus of the second aspect of the present invention.

In accordance with a fourth aspect of the present invention, there is provided a network traffic analyser comprising the apparatus of the second aspect of the present invention.

Brief Description of the Drawings

Figure 1 is an architecture diagram for an exemplary network;

Figure 2 is a block schematic diagram of a device of the exemplary network of Figure 1;

Figure 3 is a block schematic diagram of a security server of the exemplary network of Figure 1;

Figure 4 is a flow diagram for an exemplary method for preventing browser-originating attacks;

Figure 5 is a signal-flow diagram for an exemplary method and system for preventing browser-originating attacks;

Figure 6 is an architecture diagram for another exemplary network;

Figure 7 is a block schematic diagram of a security device of the exemplary network of figure 6;

Figure 8 is a flow diagram for an exemplary method for preventing browser-originating attacks; and

Figure 9 is a signal-flow diagram for an exemplary method and system for preventing browser-originating attacks.

Detailed Description

Disclosed herein are methods, systems and apparatus for preventing browser-originating attacks in a Local Area Network. These rely upon an appreciation that, for a browser-originating attack on an loT device to be successful in the Local Area Network, a connection must be established between a device running a browser and the loT device and that, in turn, a connection request may identify a website from which the attack originated.

For the purposes of this discussion, the term “browser” can be considered to be any software application that causes a device to connect to resources on the World Wide Web or the Internet. The software application may be configured to retrieve and/or traverse information from the World Wide Web or the Internet. The software application may also be configured to submit information to web servers via the Internet. Although in some cases the browser will present information to a user visually, this is not necessarily the case. Examples of browsers include Microsoft Internet Explorer™ and Google Chrome™. Less conventional browsers may include, for example, software installed on a user appliance such as a smart fridge. In this case, the software may be configured to communicate and interact with grocery store servers via the store’s websites and order food automatically to replenish the contents of the fridge.

Figure 1 is an architecture diagram for an exemplary network. The network includes a first device 100 and a second device 200, both in a Local Area Network 300 such as a home LAN. The devices are connected via a home router (not shown). In this example, the first device 100 is connected to the Internet 400 via the home router whilst the second device 200 is not connected to the Internet 400. Through its Internet connection, the first device 100 is capable of establishing a connection to a security server 500. The first device 100 is also capable of establishing a connection (perhaps unwittingly) to a malicious server 600.

The first device 100 is a user device such as a home PC, smartphone or laptop that the user can use to browse web pages or read emails. The second device 200 is a device without the capability to browse web pages and read emails, such as a Smart TV or an external hard drive. As such, the second device 200 is a device that is vulnerable to an attack from a browser running on the first device 100 (where the attack is initiated by the malicious server 600).

The skilled person will appreciate that the exemplary network shown in Figure 1 serves for illustration and explanation purposes. In other exemplary networks, any number of devices may reside in the Local Area Network. Of course, these devices may connect to any number of nodes and/or other devices in the Local Area Network in numerous ways via the home router or otherwise. Further, the devices may connect with any number of nodes and/or other devices in other remote networks. A security server may reside inside or outside a Local Area Network.

It is noted that the term “electrical communication”, unless otherwise stated, encompasses any one of wired and wireless electrical communication, or both. Therefore, electrical communication may be, for example, a network communication over a wired connection or a network communication over a radio frequency connection, or both.

Figure 2 is a schematic block diagram displaying the first device 100 of the exemplary network of Figure 1. The first device 100 is connected to the Internet 400 via the home router (not shown). The first device 100 has the capability to connect to the second device 200 within the Local Area Network 300 via the home router.

The first device 100 comprises a transmitter 102 and a receiver 104. The transmitter 102 and receiver 104 may be in electrical communication with other communication units, user equipments, servers and/or functions in the Local Area Network 300, and are configured to transmit and receive data accordingly. The first device 100 comprises a user interface 105 via which the user can interact with an Internet browser.

The first device 100 further comprises a memory 106 and at least one processor 108. The memory 106 may comprise a non-volatile memory and/or a volatile memory. The memory 106 may have a computer program 110 stored therein. The computer program 110 may be configured to undertake methods disclosed herein. The computer program 110 may be loaded in the memory 106 from a non-transitory computer readable medium 112, on which the computer program 110 is stored. The processor 108 is configured to undertake at least the functions of a request identification unit 114, a request interrogation unit 116, a port control unit 118 and a determination unit 120 as set out below.

Each of the transmitter 102 and receiver 104, user interface 105, memory 106, processor 108, request identification unit 114, request interrogation unit 116, port control unit 118 and determination unit 120 is in electrical communication with the other features 102, 104, 105, 106, 108, 110 and 114, 116, 118, and 120 of the first device 100.

The first device 100 can be implemented as a combination of computer hardware and software. In particular, the request identification unit 114, request interrogation unit 116, port control unit 118 and determination unit 120 may each be implemented as software configured to run on the processor 108. The memory 106 stores the various programs/executable files that are implemented by a processor 108, and also provides a storage unit for any required data. The programs/executable files stored in the memory 106, and implemented by the processor 108, can include the request identification unit 114, request interrogation unit 116, port control unit 118 and determination unit 120, but is not limited to such.

Figure 3 shows a block schematic diagram displaying the security server of the exemplary network of Figure 1. The security server 500 comprises a transmitter 502 and a receiver 504. The transmitter 502 and receiver 504 may be in electrical communication with other communication units, user equipments, servers and/or functions and are configured to transmit and receive data accordingly.

The security server 500 further comprises a memory 506 and at least one processor 508. The memory 506 may comprise a non-volatile memory and/or a volatile memory. The memory 506 has a database 510 stored therein and may also store one or more programs. The database 510 may store information on websites trusted by a user, the first device 100, the second device 200 and/or the Local Area Network 300. The database 510 may store information on websites not trusted by a user, the first device 100, the second device 200 and/or the Local Area Network 300. Computer programs stored in the memory 506 may be implemented by the processor 508. The processor 508 may be configured to run queries on the database 510 and return information and/or indications arising from the queries. Each of the transmitter 502 and receiver 504, memory 506 and processor 508 is in electrical communication with the other features 502, 504, 506, 508 and 510 of the security server 500.

The security server 500 may have some or all of the functionality of the first device 100.

In some exemplary systems, the security server 500 may be integrated with the first device 100 inside the Local Area Network.

In a typical attack scenario, a user of the first device 100 is lured into visiting a webpage hosted by the malicious server 600. In the process of visiting this site, the first device 100 establishes a connection with the malicious server 600. Since the connection is initiated from inside the Local Area Network 300, the NAT will not provide any suitable protection (unless some URL-based blocking service is being implemented). The connection enables malicious code (e.g. JavaScript) to run on the first device 100 through the device’s browser. The malicious code may cause another window or instance of the device’s browser to be opened. The malicious code may continue to execute in the new browser window or instance. The new window or instance of the browser may act as a way of disguising or hiding the execution of the malicious code from the user of the first device 100. The new browser window or instance may point to the first device 100 or another node in the Local Area Network 300 in order to bypass anti-malware or firewall software that is present. In other words, by opening a new browser window or instance, the malicious code may be able to “trick” any anti-malware or firewall software on the first device 100 into determining that the malicious code originated from a trusted source (i.e. within the Local Area Network 300).

In the case of a browser scanning attack, the malicious code is configured to cause a network scan, from the first device 100, of local addresses in the Local Area Network 300. The local address of the second device 200 may be identified. The malicious code may then cause a fingerprint of the second device 200 to be taken. Fingerprinting involves detecting the device type, version and available services. If a known vulnerability is found on the second device 200, the malicious code may cause the second device 200 to be exploited.

The malicious code being executed on the first device 100 may cause further malicious executable instructions to be transmitted to the second device 200. The malicious executable instructions transmitted to the second device 200 may enable a remote shell connection or similar to be established back to the malicious server 600. Having an inside-out connection from the second device 200 to the server 600, means that the NAT will not provide suitable protection for second device 200. Through this direct connection, the malicious server 600 may be able to exploit the second device 200. Further, if the second device 200 lacks robust systems for authentication and authorisation, the malicious server 600 may be able to use the second device 200 as a platform to launch attacks on other nodes within the Local Area Network 300.

In order to transmit malware to the second device 200, the malicious code would need to have established a connection between the first device 100 and the second device 200 either directly or via the home router. In a typical scenario, the malicious code would cause the first device 100 to send a Hyper Text Transfer Protocol (HTTP) connection request message to the second device 200. Of course other application connection request protocol messages could be used for this purpose.

An HTTP request message comprises an HTTP request header. Request headers are used to specify aspects of a request in “header fields” and define the operating parameters of the HTTP established connection. One such header field is the “Referer” field which is specified as being “the address of the previous web page from which a link to the currently requested page was followed”. In other words, when a browser sends an HTTP request to a peer node, the browser will include details of the URL or IP address of the webpage to which the browser is currently directed. Certain commonly used browsers include security features that prevent manipulation of the content of the Referer field. [A typical use of the Referer field is to allow a web server to reject requests (e.g. for content download) that originate from a third party server (i.e. to prevent linking through from an unauthorised site to an authorised site).] This means that even if the malicious code causes a new browser window or instance to be opened, the new browser window or instance will still include details of the original URL or IP address when it causes HTTP request messages to be generated. In other words, details of the original URL or IP address will be preserved in the Referer field even if the malicious code causes the address bar of the new browser window or instance to be manipulated. [An address bar could be manipulated by changing its URL or IP address to make it appear that the associated browser window or instance is pointing to a network address within the local area network.]

Figure 4 is a flow diagram of an exemplary method for preventing browser-originating attacks. This is a client-based approach (a client server-based approach is discussed below). The numbering used below follows that of Figure 4. A1. Using the first device 100, the user loads into a local web browser a web page from the malicious server 600 that contains malicious code. The user has been tricked into doing this, or is unaware that the webpage is operated by an attacker. A2. The malicious code is executed by the local web browser and causes the first device 100 to scan for web addresses of web services within the Local Area Network 300. The malicious code causes the first device 100 to identify the IP address of the second device 200 within the Local Area Network. The malicious code causes a request message to the second device 200 to be generated. The request message may be a HTTP request message. 51. Prior to transmittal of the request message by the transmitter 102 of the first device 100, the request message is identified in the first device 100. The request identification unit 114 of the first device 100 may identify the request message. The transmittal of the request message may be suspended pending further action. The port control unit 118 of the first device 100 may cause transmittal of the request message to be suspended. 52. A check is made to determine if the request message originates from a known browser. If the request message does not originate from a known browser, this indicates that the request has been generated from within the local area network, e.g. using a legitimate administration interface, and that the request is therefore likely to be benign. In this case, the procedure moves to step S8a. 53. The header fields of the request message are parsed. If the request message is an HTTP request message, a check is made to see if it contains a “Referer” field. Any Referer field will contain the address (URL) of any webpage that initiated the current connection request. If a “Referrer” field or similar is identified, the content of the field is extracted for analysis. 54. It is determined if the content of a Referer field points to an address outside of the Local Area Network 300. If so, the procedure moves to step S5. If there is not a Referrer field pointing to a network address outside of the Local Area Network, then the procedure moves to S8a. 55. A determination is made as to whether the network address that has been identified is a recognised address that is deemed to be safe. This may involve a crosscheck of the identified address against a database of known network addresses and servers deemed to be safe and or malicious.

If the first device 100 makes a determination that the originating address is safe, then the procedure moves to S8a. If on the other hand the first device 100 makes a determination that the network address is not safe, then the procedure moves to S6. 56. The user is prompted to approve the transmittal of the request message from the first device 100 to the second device 200. This may be implemented in various different ways, for example by causing a pop-up window to appear on the display, with a request to click “OK” if the user is happy to proceed. Alternative, potentially more secure methods include the following: 1. The first device 100 has a button that needs to be pressed in order for the connection to proceed. 2. The user is prompted to solve a simple task that’s simple for humans but difficult for code (e.g. CAPTCHA). 3. The user is prompted to enter a predefined password known only to the user and the security device. 4. The user needs to open an application on a mobile device and approve the connection via that means. 5. If the first device 100 has a speaker and a microphone the user may be asked to confirm the connection audibly. A common feature of the above techniques is that the malware code finds it difficult or impossible to approve the connection and some form of user intervention is required. S7a. If the user approves the request message, then the procedure moves to step S8a. S7b. If the user denies the request message, then the procedure moves to step S8b. S8a. Transmittal of the request message is allowed from the first device 100 to the second device 200. The request message may be allowed by the port control unit 120 of the first device 100 to be transmitted from the transmitter 102 of the first device to a receiver of the second device 200. A connection is established between device 100 and device 200 within the Local Area Network 300, via the home router. S8b. The request message is terminated. The port control unit 120 of the first device 100 may terminate the request message.

Certain of the tasks described as being carried out at the first device 100 may instead be carried out at the security server 500 (Figure 1). In one embodiment, all of steps S2 to S5 may be carried out at the security server, with the security server merely reporting the result to the first device to allow the device to perform the user prompt at step S6.

Figure 5 shows a signal-flow diagram displaying a system and the exemplary method for preventing browser-originating attacks generally in line with the flow diagram of Figure 4, but with the step of checking the Referer address being delegated to the security server 500. The signal-flow diagram shows where each step of the procedure is carried out in the exemplary network displayed in Figure 1. The horizontal arrows shown in Figure 5 represent a communication between the connected network nodes.

The skilled person will appreciate that other exemplary methods may be carried out in different network architectures. Further, the skilled person will appreciate that steps of this exemplary method and other exemplary methods may be carried out at different nodes to those specified in Figures 4 and 5 without departing from the teaching of this disclosure. A method for preventing browser-originating attacks in a Local Area Network may be implemented at a security device within a Local Area Network. Figure 6 is an architecture diagram for an exemplary network. The network includes all of the elements of the exemplary network of Figure 1, but further comprises a security device 700 located in the Local Area Network 300. The security device 700 is connected to the first device 100 and the second device 200 via a home router (not shown). The security device 700 is also connected to the Internet 400 via the home router. Through its Internet 400 connection, the security device 700 is capable of establishing connections to the security server 500 and the malicious server 600.

In view of the presence of the security device 700 in the network, some of the functionality of the first device 100 and/or the security server 500 may be reduced and/or redundant in this exemplary network.

The security device 700 may be a separate physical device or may be new functionality provided to a home router of the Local Area Network 300. The security device 700 is able to intercept and filter traffic between the first device 100 and the second device 200. This can be accomplished in one of several ways. Exemplary ways of intercepting and filtering include the following: 1) The first device 100 and the second device 200 are located in their own subnets and the security device acts as the default gateway (GW) for both devices (Layer 3 solution) 2) VLAN (Layer 2 solution) 3) Separate Wi-Fi for the first device 100 and the second device 200 (Layer 1 solution) 4) Solutions such as the security device 700 responding to Address Resolution Protocol (ARP) signalling faster than the second device 200. This may be achieved, for example, by optimizing the logic in the security device 700 or ensuring that it the security device 700 is located closer to the first device 100.

Figure 7 shows a block schematic diagram displaying the first device 100 of the exemplary network of Figure 6. The security device 700 comprises a transmitter 702 and a receiver 704. The transmitter 702 and receiver 704 may be in electrical communication with other communication units, user equipments, servers and/or functions in the Local Area Network 300, and are configured to transmit and receive data accordingly.

The security device 700 further comprises a memory 706 and at least one processor 708. The memory 706 may comprise a non-volatile memory and/or a volatile memory. The memory 706 may have a computer program 710 stored therein. The computer program 710 may be configured to undertake methods disclosed herein. The computer program 710 may be loaded in the memory 706 from a non-transitory computer readable medium 712 on which the computer program 710 is stored. The processor 708 is configured to undertake at least the functions of a request identification unit 714, a request interrogation unit 716, a port control unit 718 and a determination unit 720.

Each of the transmitter 702 and receiver 704, memory 706, processor 708, request identification unit 714, request interrogation unit 716, port control unit 718 and determination unit 720 is in electrical communication with the other features 702, 704, 705, 706, 708, 710 and 714, 716, 718, and 720 of the security device 700.

The security device 700 can be implemented as a combination of computer hardware and software. In particular, the request identification unit 714, request interrogation unit 716, port control unit 1718 and determination unit 720 may each be implemented as software configured to run on the processor 708. The memory 706 stores the various programs/executable files that are implemented by a processor 708, and also provides a storage unit for any required data. The programs/executable files stored in the memory 706, and implemented by the processor 708, can include the request identification unit 714, request interrogation unit 716, port control unit 118 and determination unit 720, but is not limited to such.

In some exemplary security devices, a security server may be integrated into a security device. The security device would have the same functionality as the security server.

Figure 8 shows a flow diagram displaying another exemplary method for preventing browser-originating attacks. The exemplary method will be described below with reference to Figure 4 and Figure 8, and the numbering used below follows that of Figures 4 and 8.

The following adaptations are made with respect to Figure 4. B1. Step S1 is replaced with step B1. The security device intercepts a request. A request from the first device 100 to the second device 200 to establish a connection between the first device 100 and the second device 200 is intercepted by the security device 700. At this stage, a data file comprising a copy of the request message may be transmitted to the security server 500 for further analysis. Steps S2 to S7a/S7b may be carried out, at least in part, by the security server 500. S2 - S7a/b. These steps are similar to the corresponding steps of exemplary method shown in Figure 4. The steps can be implemented by the security device 700 and/or the security server 500. B8a. The security device 700 transmits the request to the second device 200. The port control unit 718 of the security device 700 may cause the request to be transmitted from the transmitter 702 of the security device 700 to the receiver 204 of the second device 200. B8b. The security device terminates the request and does not allow it to proceed to the second device 200. The port control unit 718 of the security device 700 may cause the request to be blocked. An indication that that the security device 700 has blocked the request may be transmitted to the first device 100.

Figure 9 is a signal flow diagram displaying a system and the exemplary method for preventing browser-originating attacks as shown in Figure 8. The signal flow diagram shows where each step of the procedure is carried out in the exemplary network displayed in figure 1. The horizontal arrows shown if Figure 9 represent a communication between the relevant network nodes. A computer program may be configured to provide any of the above described methods. The computer program may be provided on a computer readable medium. The computer program may be a computer program product. The product may comprise a non-transitory computer usable storage medium. The computer program product may have computer-readable program code embodied in the medium configured to perform the method. The computer program product may be configured to cause at least one processor to perform some or all of the method.

Various methods and apparatus are described herein with reference to block diagrams or flowchart illustrations of computer-implemented methods, apparatus (systems and/or devices) and/or computer program products. It is understood that a block of the block diagrams and/or flowchart illustrations, and combinations of blocks in the block diagrams and/or flowchart illustrations, can be implemented by computer program instructions that are performed by one or more computer circuits. These computer program instructions may be provided to a processor circuit of a general purpose computer circuit, special purpose computer circuit, and/or other programmable data processing circuit to produce a machine, such that the instructions, which execute via the processor of the computer and/or other programmable data processing apparatus, transform and control transistors, values stored in memory locations, and other hardware components within such circuitry to implement the functions/acts specified in the block diagrams and/or flowchart block or blocks, and thereby create means (functionality) and/or structure for implementing the functions/acts specified in the block diagrams and/or flowchart block(s).

Computer program instructions may also be stored in a computer-readable medium that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable medium produce an article of manufacture including instructions which implement the functions/acts specified in the block diagrams and/or flowchart block or blocks. A tangible, non-transitory computer-readable medium may include an electronic, magnetic, optical, electromagnetic, or semiconductor data storage system, apparatus, or device. More specific examples of the computer-readable medium would include the following: a portable computer diskette, a random access memory (RAM) circuit, a read-only memory (ROM) circuit, an erasable programmable read-only memory (EPROM or Flash memory) circuit, a portable compact disc read-only memory (CD-ROM), and a portable digital video disc read-only memory (DVD/Blu-ray).

The computer program instructions may also be loaded onto a computer and/or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer and/or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions/acts specified in the block diagrams and/or flowchart block or blocks.

Accordingly, the invention may be embodied in hardware and/or in software (including firmware, resident software, micro-code, etc.) that runs on a processor, which may collectively be referred to as "circuitry," "a module" or variants thereof.

It should also be noted that in some alternate implementations, the functions/acts noted in the blocks may occur out of the order noted in the flowcharts. For example, two blocks shown in succession may in fact be executed substantially concurrently or the blocks may sometimes be executed in the reverse order, depending upon the functionality/acts involved. Moreover, the functionality of a given block of the flowcharts and/or block diagrams may be separated into multiple blocks and/or the functionality of two or more blocks of the flowcharts and/or block diagrams may be at least partially integrated. Finally, other blocks may be added/inserted between the blocks that are illustrated.

The skilled person will be able to envisage other embodiments without departing from the scope of the appended claims.

Claims

CLAIMS:

1. A method of preventing a browser-originating attack in a Local Area Network, LAN, the method comprising: a) intercepting a connection request message generated by a browser instance at a first LAN-connected device and directed to a second LAN-connected device; b) parsing the connection request message to identify an address of a website that caused said browser instance to generate the request; c) performing a check of said address to determine whether or not the address is trusted and, if it is trusted, then allowing the connection request message to proceed, otherwise rejecting or suspending transmission of the connection request message.

2. A method according to claim 1, wherein said step of performing a check of said address to determine whether or not the address is trusted comprises treating the address as trusted if it is an address within the LAN.

3. A method according to claim 2, wherein said step of performing a check of said address to determine whether or not the address is trusted comprises, if the address is not an address of the LAN, using a database of trusted and/or untrusted external network addresses to determine whether or not the address is trusted.

4. A method according to any one of the preceding claims, wherein said address is one of an IP address and a URL.

5. A method according to any one of the preceding claims, wherein the request is an HTTP request.

6. A method according to claim 5, wherein said step of parsing the connection request message comprises parsing the message to identify a Referer field, said address being the content of the Referer field.

7. A method according to claim 6, the method comprising allowing the connection request message to proceed in the event that the message does not include a Referer field.

8. A method according to any one of the preceding claims, wherein steps a) to c) are carried out at said first LAN-connected device.

9. A method according to claim 8, wherein steps a) to c) are implemented by a browser plugin.

10. A method according to any one of claims 1 to 7, wherein steps a) to c) are carried out at a network traffic analyser deployed within the LAN.

11. A method according to any one of claims 1 to 7, wherein step a) and optionally step b) is carried out at said first LAN-connected device or at a network traffic analyser deployed within the LAN, and step c), and optionally step b), is carried out at a network server, the method comprising, following interception of a request at step a), transmitting a query containing the request or a part of the request to said network server and, following completion of step c), sending a result from the network server to the first-LAN connected device or to said network entity.

12. A method according to any one of the preceding claims and comprising, if it is determined that said address is not trusted, prompting a user of the first LAN-connected device to approve the request before continuing with the establishment of the connection.

13. A non-transitory computer storage medium having stored thereon computer program code for implementing the method of any one of the preceding claims.

14. A computer program comprising instructions which, when executed on at least one processor, causes the at least one processor to implement the method of any one of claims 1 to 12.

15. Apparatus for preventing a browser-originating attack in a Local Area Network, LAN, the apparatus comprising processor circuitry and a storage unit for storing instructions executable by the processor circuitry, whereby the apparatus is operative to: a) intercept a connection request message generated by a browser instance at a first LAN-connected device and directed to a second LAN-connected device; b) parse the connection request message to identify an address of a website that caused said browser instance to generate the request; c) perform a check of said address to determine whether or not the address is trusted and, if it is trusted, then allow the connection request message to proceed, otherwise reject or suspend transmission of the connection request message.

16. The apparatus of claim 15, wherein, in performing a check of said address to determine whether or not the address is trusted, the apparatus is operative to treat the address as trusted if it is an address within the LAN.

17. The apparatus of claim 16, wherein, in performing a check of said address to determine whether or not the address is trusted, the apparatus is operative to use a database of trusted and/or untrusted external network addresses to determine whether or not the address is trusted, if the address is not an address of the LAN.

18. The apparatus of any one of claims 15 to 17, wherein said address is one of an IP address and a URL.

19. The apparatus of any one of claims 15 to 18, wherein the request is an HTTP request.

20. The apparatus of claim 19, wherein, in parsing the connection request message, the apparatus is operative to parse the message to identify a Referer field, said address being the content of the Referer field.

21. The apparatus of claim 20, wherein the apparatus is operative to allow the connection request message to proceed in the event that the message does not include a Referer field.

22. An end user device comprising the apparatus of any one of claims 15 to 21.

23. The end user device of claim 22, further comprising a browser plugin configured to implement steps of a) to c).

24. A network traffic analyser comprising the apparatus of any one of claims 15 to 21.