U.S. patent application number 16/697082 was filed with the patent office on 2020-07-02 for firewall informed by web server security policy.
The applicant listed for this patent is SonicWALL US Holdings Inc.. Invention is credited to Hugo Vazquez Carames.
Application Number | 20200213278 16/697082 |
Document ID | / |
Family ID | 58663997 |
Filed Date | 2020-07-02 |
![](/patent/app/20200213278/US20200213278A1-20200702-D00000.png)
![](/patent/app/20200213278/US20200213278A1-20200702-D00001.png)
![](/patent/app/20200213278/US20200213278A1-20200702-D00002.png)
![](/patent/app/20200213278/US20200213278A1-20200702-D00003.png)
![](/patent/app/20200213278/US20200213278A1-20200702-D00004.png)
![](/patent/app/20200213278/US20200213278A1-20200702-D00005.png)
![](/patent/app/20200213278/US20200213278A1-20200702-D00006.png)
![](/patent/app/20200213278/US20200213278A1-20200702-D00007.png)
![](/patent/app/20200213278/US20200213278A1-20200702-D00008.png)
![](/patent/app/20200213278/US20200213278A1-20200702-P00999.TIF)
United States Patent
Application |
20200213278 |
Kind Code |
A1 |
Vazquez Carames; Hugo |
July 2, 2020 |
FIREWALL INFORMED BY WEB SERVER SECURITY POLICY
Abstract
A user of a client device that is protected by a firewall may
navigate to a website using a particular browser process (e.g., a
window/tab of a browser) of the client device, sending a content
request toward a web content server in the process. The firewall
may intercept the content request, and may also receive information
from the client device identifying which browser process initiated
the content request. Before passing the content request to the
appropriate web content server, the firewall may request and
download a security policy from a security policy server. The
security policy may notify the firewall which hosts are
authorized/unauthorized for use with a particular domain, and which
file types from each of these hosts are authorized/unauthorized for
use with the particular domain. The firewall may then filter
content related to the identified browser process based on the
security policy.
Inventors: |
Vazquez Carames; Hugo;
(Barcelona, ES) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
SonicWALL US Holdings Inc. |
Milpitas |
CA |
US |
|
|
Family ID: |
58663997 |
Appl. No.: |
16/697082 |
Filed: |
November 26, 2019 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
15636148 |
Jun 28, 2017 |
10491566 |
|
|
16697082 |
|
|
|
|
14937776 |
Nov 10, 2015 |
9723027 |
|
|
15636148 |
|
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
H04L 63/0245 20130101;
H04L 63/20 20130101; H04L 63/145 20130101; H04L 61/2007 20130101;
H04L 67/02 20130101; H04L 63/0263 20130101; H04L 63/101 20130101;
H04L 63/0227 20130101; H04L 63/1416 20130101; H04L 61/1511
20130101; G06F 16/951 20190101 |
International
Class: |
H04L 29/06 20060101
H04L029/06; H04L 29/08 20060101 H04L029/08; G06F 16/951 20060101
G06F016/951; H04L 29/12 20060101 H04L029/12 |
Claims
1. A method for controlling access to digital content, the method
comprising: receiving a first policy dictating that only data of a
type that matches an authorized type of data may be received from
an authorized data source; receiving a request to access data at
the authorized data source; identifying that the data request is
for the authorized type of data from the authorized data source;
and forwarding the data request to the authorized data source
according the first policy, the forwarding based on the
identification that the data request is for the authorized type of
data from the authorized data source.
2. The method of claim 1, further comprising preventing a second
type of data from being provided to a requesting computer based on
the first policy dictating that only the data of the type that
matches the authorized type of data may be received from the
authorized data source.
3. The method of claim 1, further comprising blocking data
associated with a second data request from being received from a
host device based on a field of the first policy that indicates
that requested data from host devices that require a reverse domain
name service (DNS) mapping should be blocked.
4. The method of claim 1, further comprising: receiving data
associated with a second request for accessing data at a second
authorized data source; identifying that the data associated with
the second request includes an unauthorized type of data; and
sending a reply without the second type of data to the requesting
computer.
5. The method of claim 1, further comprising receiving a second
policy that identifies a domain and a particular type of data, the
second policy dictating that requests for the particular data type
from the domain should be blocked.
6. The method of claim 5, further comprising blocking a request to
retrieve the particular type of data from the domain according to
the second policy.
7. The method of claim 2, further comprising: identifying that the
second type of data was requested from an unauthorized data source;
and sending information to the requesting computer that identifies
the unauthorized data source, wherein the information sent to the
requesting computer results in the requesting computer blocking
subsequent requests to access data from the unauthorized data
source.
8. A non-transitory computer-readable storage medium having
embodied thereon a program executable by a processor for
implementing a method for controlling access to digital content,
the method comprising: receiving a first policy dictating that only
data of a type that matches an authorized type of data may be
received from an authorized data source; receiving a request to
access data at the authorized data source; identifying that the
data request is for the authorized type of data from the authorized
data source; and forwarding the data request to the authorized data
source according the first policy, the forwarding based on the
identification that the data request is for the authorized type of
data from the authorized data source.
9. The non-transitory computer-readable storage medium of claim 8,
the program further executable to prevent a second type of data
from being provided to a requesting computer based on the first
policy dictating that only the data of the type that matches the
authorized type of data may be received from the authorized data
source.
10. The non-transitory computer-readable storage medium of claim 8,
the program further executable to block data associated with a
second data request from being received from a host device based on
a field of the first policy that indicates that requested data from
host devices that require a reverse domain name service (DNS)
mapping should be blocked.
11. The non-transitory computer-readable storage medium of claim 1,
the program further executable to: receive data associated with a
second request for accessing data at a second authorized data
source; identify that the data associated with the second request
includes an unauthorized type of data; and send a reply without the
second type of data to the requesting computer.
12. The non-transitory computer-readable storage medium of claim 8,
the program further executable to receive a second policy that
identifies a domain and a particular type of data, the second
policy dictating that requests for the particular data type from
the domain should be blocked.
13. The non-transitory computer-readable storage medium of claim
12, the program further executable to block a request to retrieve
the particular type of data from the domain according to the second
policy.
14. The non-transitory computer-readable storage medium of claim
10, the program further executable to: identify that the second
type of data was requested from an unauthorized data source; and
send information to the requesting computer that identifies the
unauthorized data source, wherein the information sent to the
requesting computer results in the requesting computer blocking
subsequent requests to access data from the unauthorized data
source
15. An apparatus for controlling access to digital content, the
apparatus comprising: a memory; a first policy stored in the memory
that dictates that only data of a type that matches an authorized
type of data may be received from an authorized data source; a
processor that executes instructions out of the memory to: compare
a request to access data at the authorized data source with the
first policy that dictates that only data of the type that matches
the authorized type of data may be received from the authorized
data source, identify that the data request is for the authorized
type of data from the authorized data source, and prepare to
forward the data request to the authorized data source according
the first policy, wherein the data request is forwarding based on
the identification that the data request is for the authorized type
of data from the authorized data source.
16. The apparatus of claim 15, wherein the processor also executes
instructions out of the memory to prevent a second type of data
from being provided to a requesting computer based on the first
policy dictating that only the data of the type that matches the
authorized type of data may be received from the authorized data
source.
17. The apparatus of claim 15, wherein the processor also executes
instructions out of the memory to block data associated with a
second data request from being received from a host device based on
a field of the first policy that indicates that requested data from
host devices that require a reverse domain name service (DNS)
mapping should be blocked.
18. The apparatus of claim 15, wherein the processor also executes
instructions out of the memory to: receive data associated with a
second request for accessing data at a second authorized data
source, identify that the data associated with the second request
includes an unauthorized type of data, and prepare to send a reply
that does not include the second type of data to the requesting
computer, wherein the reply is sent to the requesting computer
without the second type of data.
19. The apparatus of claim 15, wherein the processor also executes
instructions out of the memory to receive a second policy that
identifies a domain and a particular type of data, the second
policy dictating that requests for the particular data type from
the domain should be blocked.
20. The apparatus of claim 19, wherein the processor also executes
instructions out of the memory to block a request to retrieve the
particular type of data from the domain according to the second
policy.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application is a continuation and claims the priority
benefit of U.S. patent application Ser. No. 15/636,148 filed Jun.
28, 2017, now U.S. Pat. No. 10,491,566, which is a continuation and
claims the priority benefit of U.S. patent application Ser. No.
14/937,776 filed Nov. 10, 2015, now U.S. Pat. No. 9,723,027, the
disclosures of which are incorporated herein by reference.
BACKGROUND OF THE INVENTION
1. Field of the Invention
[0002] The present invention generally relates to network security.
More specifically, the present invention relates to a firewall that
receives, and is informed by, a security policy that identifies
authorized resource sources and content types required by a web
server to display a page and blocks anything that is not
authorized.
2. Description of the Related Art
[0003] Network-based data communications are useful for a variety
of tasks, such as sending and receiving emails, browsing Internet
webpages, browsing intranet private network portals, sending and
receiving instant messages, telephone calls over
voice-over-internet-protocol (VOIP) services, and video calls.
However, network-based data communications can be dangerous when
viruses, adware, spyware, or other kinds of malware are unwittingly
transmitted to a user device. Such malware may have been inserted
into a web content server by a third party attacker, or may have
been injected into a data transmission from the web content server
(e.g., via a man-in-the-middle attack) by the third party attacker,
or may be sent directly to a client device from the third party
attacker.
[0004] Typically, firewall systems accept incoming data, filter
through the incoming data to identify and block potentially
dangerous incoming data, and allow transmission of only data that
is safe to transmit. Some firewalls also automatically perform
antivirus scans or malware scans of data that the firewall has
deemed to be otherwise allowable, which may further be used to
block dangerous data in the event that a virus is found.
[0005] Virus scanners and malware scanners, while helpful,
typically cannot detect all possible viruses or malware. It takes
time for virus scanners and malware scanners to be updated to
detect new or uncommon viruses or malware, in which time such
viruses or malware may pass freely to client systems. Virus
scanners and malware scanners may also become compromised by a
third-party attacker that has disabled them or crippled them.
[0006] Wholesale blacklisting/blocking of certain types of data
from being transmitted to a client device (e.g., blocking all
executable files, blocking all Java files, blocking all Flash
files, blocking all media files) is practiced by some firewalls,
and can be effective for certain specialized systems that are only
used to perform certain types of tasks that only require receipt of
a specific subset of data types (e.g., a server whose only function
is to forward text messages). However, such wholesale blocking is
problematic in most circumstances, as it may break functionality of
certain software applications (e.g. "application store"
applications often download executable files) or web pages (e.g.,
the United States Patent and Trademark Office Private "PAIR" Patent
Application Information Retrieval webpage uses a Java applet).
[0007] Therefore, there is a need for improved firewall.
SUMMARY OF THE CLAIMED INVENTION
[0008] One exemplary method for data filtering includes receiving a
first content request from a client device, the first content
request having been generated by a first browser process of a
browser of the client device, the first content request directed at
a first web content server associated with a first domain. The
method also includes receiving a process identifier from the client
device that identifies the first browser process. The method also
includes transmitting a policy request to a security policy server.
The method also includes receiving a security policy from the
security policy server, the security policy identifying a host
filter and a resource type filter associated with the first domain.
The method also includes transmitting the first content request to
the first web content server. The method also includes receiving a
web content dataset from the first web content server. The method
also includes transmitting a filtered content dataset to the client
device for use by the first browser process, the filtered content
dataset including at least a subset of the web content dataset that
has been filtered based at least partly on the resource type filter
of the security policy. The method also includes preventing the
first browser process of the client device from requesting data
from one or more requested unauthorized hosts domains, the one or
more requested unauthorized host domains identified as being
unauthorized to provide data associated with the first domain based
at least partly on the host filter of the security policy.
[0009] One exemplary system for data filtering includes a
communication module for communicating with at least a browser of a
client device, a security policy server, and a first web content
server associated with a first domain. The system also includes a
processor coupled to a memory and also coupled to the communication
module. Execution of instructions stored in the memory by the
processor performs a variety of system operations. The system
operations include receiving a first content request from the
client device, the first content request having been generated by a
first browser process of the browser of the client device, the
first content request directed at the first web content server
associated with the first domain. The system operations also
include receiving a process identifier from the client device that
identifies the first browser process. The system operations also
include transmitting a policy request to the security policy
server. The system operations also include receiving a security
policy from the security policy server, the security policy
identifying a host filter and a resource type filter associated
with the first domain. The system operations also include
transmitting the first content request to the first web content
server. The system operations also include receiving a web content
dataset from the first web content server. The system operations
also include transmitting a filtered content dataset to the client
device for use by the first browser process, the filtered content
dataset including at least a subset of the web content dataset that
has been filtered based at least partly on the resource type filter
of the security policy. The system operations also include
preventing the first browser process of the client device from
requesting data from one or more requested unauthorized hosts
domains, the one or more requested unauthorized host domains
identified as being unauthorized to provide data associated with
the first domain based at least partly on the host filter of the
security policy.
[0010] One exemplary non-transitory computer-readable storage
medium may have embodied thereon a program executable by a
processor to perform a method for data filtering. The exemplary
program method includes receiving a first content request from a
client device, the first content request having been generated by a
first browser process of a browser of the client device, the first
content request directed at a first web content server associated
with a first domain. The program method also includes receiving a
process identifier from the client device that identifies the first
browser process. The program method also includes transmitting a
policy request to a security policy server. The program method also
includes receiving a security policy from the security policy
server, the security policy identifying a host filter and a
resource type filter associated with the first domain. The program
method also includes transmitting the first content request to the
first web content server. The program method also includes
receiving a web content dataset from the first web content server.
The program method also includes transmitting a filtered content
dataset to the client device for use by the first browser process,
the filtered content dataset including at least a subset of the web
content dataset that has been filtered based at least partly on the
resource type filter of the security policy. The program method
also includes preventing the first browser process of the client
device from requesting data from one or more requested unauthorized
hosts domains, the one or more requested unauthorized host domains
identified as being unauthorized to provide data associated with
the first domain based at least partly on the host filter of the
security policy.
BRIEF DESCRIPTION OF THE FIGURES
[0011] FIG. 1A illustrates an exemplary firewall ecosystem wherein
an exemplary firewall blocks a client device from requesting data
from an attacker.
[0012] FIG. 1B illustrates an exemplary firewall ecosystem wherein
an exemplary firewall detects and removes malware from infected web
content.
[0013] FIG. 1C illustrates an exemplary firewall ecosystem wherein
an exemplary firewall detects malware within infected web content
and returns an error.
[0014] FIG. 2A illustrates an exemplary whitelist-based security
policy provided by the security policy server to the firewall.
[0015] FIG. 2B illustrates an exemplary blacklist-based security
policy provided by the security policy server to the firewall.
[0016] FIG. 3A illustrates an exemplary firewall ecosystem wherein
an exemplary firewall detects and removes an unauthorized content
type.
[0017] FIG. 3B illustrates an exemplary firewall ecosystem wherein
an exemplary firewall detects an unauthorized content type and
returns an error.
[0018] FIG. 4 is a block diagram of an exemplary computing device
that may be used to implement an embodiment of the present
invention.
DETAILED DESCRIPTION
[0019] A user of a client device that is protected by a firewall
may navigate to a website using a particular browser process (e.g.,
a window/tab of a browser) of the client device, sending a content
request toward a web content server in the process. The firewall
may intercept the content request, and may also receive information
from the client device identifying which browser process initiated
the content request. Before passing the content request to the
appropriate web content server, the firewall may request and
download a security policy from a security policy server. The
security policy may notify the firewall which hosts are
authorized/unauthorized for use with a particular domain, and which
file types from each of these hosts are authorized/unauthorized for
use with the particular domain. The firewall may then filter
content related to the identified browser process based on the
security policy.
[0020] FIG. 1A illustrates an exemplary firewall ecosystem wherein
an exemplary firewall blocks a client device from requesting data
from an attacker.
[0021] The exemplary firewall ecosystem of FIG. 1A includes a
client device 100, a firewall 115, a domain name server (DNS) 120,
a security policy server 125, a web content server 130, and an
attacker server 195.
[0022] The client device 100 may be some variety of computer system
400 or may include at least a subset of the hardware components and
software elements identified in FIG. 4. The client device 100 may,
for example, include one or more memory and/or data storage
module(s) (e.g. which may include any kind of memory 420, mass
storage 430, portable storage 440, or some combination thereof),
one or more processor(s) (e.g. processor 410), one or more input
mechanism(s) (e.g. one or more input devices 460), and one or more
display screen(s) (e.g., such as display system 470).
[0023] The firewall 115 may include hardware, software, or some
combination thereof. For example, the firewall 115 may be located
at a network device, wired/wireless router of a private network,
such as a local area network (LAN), a wireless local area network
(WLAN), a municipal area network (MAN), or a wide area network
(WAN). Network devices may also include network servers or network
nodes that pass data along a data route. Network devices may also
include network controllers (e.g., OpenFlow controllers) or network
switches (e.g., OpenFlow switches) if the network is a
software-defined network. The firewall 115 may alternately be
software-based and executed directly at the client device 100, as
indicated by the dashed lines extending from client device 100 in
FIG. 1A. The firewall 115 may alternately be some combination of
hardware-based and software based, and may be executed by some
combination of a network device and the client device 100.
[0024] The various servers illustrated in FIG. 1A (including the
DNS 120, the Security Policy Server 125, the Web Content Server
130, and the Attacker Server 195) may also each be some variety of
computer system 400 or may include at least a subset of the
hardware components and software elements identified in FIG. 4. The
various servers illustrated in FIG. 1A may each, for example,
include one or more memory and/or data storage module(s) (e.g.
which may include any kind of memory 420, mass storage 430,
portable storage 440, or some combination thereof), one or more
processor(s) (e.g. processor 410), one or more input mechanism(s)
(e.g. one or more input devices 460), and one or more display
screen(s) (e.g., such as display system 470).
[0025] The illustrations of FIG. 1A suggest that client device 100
may be a desktop computer, a laptop computer, a mobile telephone
device, or a wearable device. The illustrations of FIG. 1A suggest
that the various servers illustrated in FIG. 1A (including the DNS
120, the Security Policy Server 125, the Web Content Server 130,
and the Attacker Server 195) may be desktop computers. It should be
understood that any of these systems may be any type of computing
device, including at least those types identified anywhere in this
paragraph or in the description of FIG. 4.
[0026] The client device 100 may execute various software
applications stored in its memory. For example, the client device
100 may execute a browser 105 as illustrated in FIG. 1, which a
user of the client device 100 may use to request, display, and
interact with network-based content. The browser 105 may be, for
example, Google Chrome, Mozilla Firefox, Microsoft Edge, Apple
Safari, Microsoft Internet Explorer, Opera, or another browser
based at least partially on Webkit, Trident, Gecko, Presto, some
combination thereof.
[0027] The client device 100 may also execute a client-side
communication tracking software 110, which may aid the firewall 115
by matching data requests made by the client device 100 to the
software applications (or individual processes) executed by the
client device 100 that triggered each of those requests. In the
example of FIG. 1A, the client-side communication tracking software
110 may, for example, separately track each window of a browser 105
that allows use of multiple windows, and each tab of a browser 105
that allows use of multiple tabs.
[0028] A number of communications are shown in FIG. 1A, illustrated
as arrows depicting the direction of the communication. Arrow 135
represents a Hypertext Transfer Protocol (HTTP) Request or HTTP
Secure (HTTPS) Request sent from the browser 105, for example, when
a user types a destination address (e.g., "example.com" in FIG. 1A)
or when a user clicks a hyperlink pointing to the destination
address (e.g., "example.com" in FIG. 1A). The request represented
by arrow 135 may be an HTTP request or an HTTPS request based on
the type of request and the type of content at the web content
server 130. For example, web content servers 130 often require use
of HTTPS when sensitive content, such as login credentials,
credit/debit card information, bank account information, e-payment
account information, user locations, emails, social media content,
or other personal information is to be transferred. HTTP is
typically used when security is less important, such as for regular
search engine queries, news articles, and the like.
[0029] The HTTP(S) Request of arrow 135 is intercepted by the
client-side communication tracking software 110, which identifies
the process (e.g., the browser, the browser window, and the browser
window tab) that the request originated from. Arrow 137 then
represents the client-side communication tracking software 110
allowing the HTTP(S) Request of arrow 135 to go on to the firewall
115 along with the identification of the process making the HTTP(S)
request.
[0030] Arrow 139 represents a domain name server (DNS) query sent
to the domain name server (DNS) 120 from the firewall 115, and
arrow 141 represents a DNS reply from the DNS 120 back to the
firewall 115. This allows the firewall to obtain an Internet
Protocol (IP) address of a web content server 130 corresponding to
a given domain name (e.g., an IP address of a web content server
130 corresponding to "example.com" in FIG. 1A). In some cases, the
DNS reply represented by arrow 141 may also identify an IP address
corresponding to a security policy server 125 related to the web
content server 130.
[0031] Arrow 143 represents an HTTPS request sent from the firewall
115 to the security policy server 125. Arrow 145 represents an
HTTPS reply sent from the security policy server 125 back to the
firewall 115. The HTTPS reply represented by arrow 145 includes a
security policy 147 that defines what types of resources are
authorized for use with the content of the web content server 130,
and what sources of content are authorized for use with the content
of the web content server 130. The security policy 200 of FIG. 2A
and the security policy 250 of FIG. 2B are examples of the security
policy 147. Once the firewall 115 receives the security policy 147,
it stores it in a security policy store 149, which may be some form
of memory or data storage system (e.g., memory 420, mass storage
430, portable storage 440) that is stored either physically at the
firewall 115 or at a location that is accessible by the firewall
115 (e.g., a data storage server within a private network guarded
by the firewall 115). The security policy store 149 may, in some
cases, store multiple security policies 147 corresponding to
multiple web content servers 130, and may organize such security
policies 147 through the use of a data structure, such as a
database, a table, a hash table, an array, an arraylist, a tree, a
list, a queue, or some combination thereof.
[0032] Arrow 151 represents an HTTP(S) request sent from the
firewall 115 to the web content server 130 that is sent requesting
the web content initially sought by the HTTP(S) request represented
by arrow 135. Arrow 153 represents an HTTP(S) reply sent from the
web content server 130 back to the firewall 115. The HTTP(S) reply
of arrow 153 may include web content stored at and supplied by the
web content server 130, such as markup text/code (e.g., HTML, CSS,
PHP, JavaScript), text, photos, videos, audio, flash applications,
java applets, ActiveX controls, downloadable files. The HTTP(S)
reply of arrow 153 may also identify and include a trigger
mechanism to obtain content from other sources of content, such as
an advertiser server storing advertisement content, a media server
storing images/audio/videos, or in some cases an attacker server
195 storing dangerous content intended to harm or compromise the
client device 100. Such a trigger mechanism to obtain content from
the attacker server 195 may be referred to as malware, and may take
many forms, and may trigger a download of data from the attack
server in many ways (e.g., by masquerading as an image or other
audiovisual file to be loaded as part of the page, by being
triggered by JavaScript or PHP, or some other method of
triggering). The HTTP(S) reply of arrow 153 may include such
malware if the attacker server 195 has inserted the malware either
into the web content server 130 (e.g., so that the malware become
embedded in the content that is served by the web content server
130) or into the HTTP(S) reply represented by arrow 153 by
compromising (e.g., altering or replacing) the communication before
it reaches the firewall 115 (e.g., via a man-in-the-middle attack,
packet injection, packet forging, or packet spoofing).
[0033] In the exemplary situation of FIG. 1A, the HTTP(S) reply
represented by arrow 153 passes through the firewall 115 without
detection of the malware (e.g., the trigger mechanism to obtain
content from the attacker server 195 may be disguised or otherwise
difficult to detect). Arrow 155 and arrow 157 represent the same
HTTP(S) reply, with the malware still inside, passing from the
firewall 155 to the client-side communication tracking software 110
and back to the browser 105, respectively.
[0034] Once the browser 105 receives the HTTP(S) reply represented
by arrows 153, 155, and 157, the malware triggers the browser to
request content from the attacker server 195 (e.g., "attacker.com"
in FIG. 1A). Thus, arrow 159 represents a malware-based HTTP(S)
request sent by the browser 159 to the client-side communication
tracking software 110, which identifies the browser process
requesting this content from the attacker server 195 and sends that
information along with the malware-based HTTP(S) request on to the
firewall 115 as represented by the arrow 161.
[0035] The firewall 115 then uses the process information (from the
communication represented by arrow 161) gathered by the client-side
communication tracking software 110 to identify the browser
process, and locates the corresponding security policy 197. The
security policy 197 can identify, among other information,
authorized sources of data for the web page served by the web
content server 130. This can be represented as a whitelist, as in
the listings 210 and 215 of the exemplary security policy 200 of
FIG. 2A, or can be represented as a blacklist, as in the listings
255 and 260 of the exemplary security policy 250 of FIG. 2B. Either
way, the firewall 115 then identifies that the attacker server 195
is not an authorized source of data for the web page served by web
content server 130 by not appearing on a whitelist of the security
policy 147, by appearing on a blacklist of the security policy 147,
or both.
[0036] Once the firewall 115 realizes that it should not be
obtaining content from the attacker server 195, it does not do so,
and instead either does nothing or transmits an error (e.g., a 403
"access denied/forbidden" error) back through the client-side
communication tracking software 110 and to the browser 105, as
represented by the arrow 163 and the arrow 165, respectively. In
this way, the firewall 115 prevents the client device 100 from
receiving data from the attacker server 195.
[0037] FIG. 1B illustrates an exemplary firewall ecosystem wherein
an exemplary firewall detects and removes malware from infected web
content. In particular, FIG. 1B illustrates the exemplary firewall
ecosystem of FIG. 1A, but where the firewall 115 is able to detect
and remove the malware from the HTTP(S) reply represented by arrow
160.
[0038] For example, once the firewall 115 receives the HTTP(S)
reply with inserted malware represented by arrow 160, the firewall
115 can parse the markup code (e.g., the HTML as well as any
JavaScript or PHP code) to identify a trigger mechanism of the
malware, such as by searching for Uniform Resource Locators (URLs),
IP addresses, or other identifying strings within the markup code
of the HTTP(S) reply of arrow 160. In FIG. 1B, the firewall 115
identifies this malware by detecting its triggering mechanism and
strips out at least enough of the malware to stop the client device
100 from trying to later retrieve data from the attacker server 195
upon receipt of the markup code from the firewall 115 (through the
client-side communication tracking software 110).
[0039] Once the malware has been stripped away from the markup code
of the HTTP(S) reply represented by arrow 160, the firewall 115
transmits the stripped version of the HTTP(S) reply with the
malware removed back through the client-side communication tracking
software 110 and to the browser 105, represented by arrows 171 and
173, respectively.
[0040] FIG. 1C illustrates an exemplary firewall ecosystem wherein
an exemplary firewall detects malware within infected web content
and returns an error. In particular, FIG. 1C illustrates the
exemplary firewall ecosystem of FIG. 1B, where the firewall 115 is
able to detect the malware from the HTTP(S) reply represented by
arrow 160.
[0041] Once the firewall 115 in FIG. 1C detects the malware in the
HTTP(S) reply of arrow 160, however, unlike FIG. 1B, it does not
try to strip the malware from the HTTP(S) reply of arrow 160.
Instead, it either returns nothing to the browser 105 of the client
device 100, or it returns an error message (e.g., a 403 "access
denied/forbidden" error) back through the client-side communication
tracking software 110 and to the browser 105, as represented by the
arrow 181 and the arrow 183, respectively.
[0042] In some cases, the firewall 115 of FIG. 1A, FIG. 1B, and
FIG. 1C may all be the same firewall. For example, FIG. 1B may
represent a situation where malware is detected within the HTTP(S)
reply of arrow 160, and is understood to be removable. FIG. 1C may
represent a situation where malware is detected within the HTTP(S)
reply of arrow 160, and is not well-understood or is understood to
be too complicated or dangerous to try to remove. FIG. 1A may
represent a situation where malware is hidden in a way that it has
not been detected by the firewall 115.
[0043] Alternately, the firewalls 115 of FIG. 1A, FIG. 1B, and FIG.
1C may all be the different firewalls that treat malware
differently in all cases. For example, the firewalls 115 of FIG. 1B
and 1C may detect malware within the HTTP(S) reply of arrow 160 and
have different approaches to it (e.g., remove it or simply return
nothing or an error). The firewall 115 of FIG. 1A may in some cases
lack malware-detection capabilities, or may detect the malware
within the HTTP(S) reply of arrow 160 and decide to ignore it,
knowing that it will be able to prevent the client device 100 from
later retrieving data from the attacker server 195.
[0044] FIG. 2A illustrates an exemplary whitelist-based security
policy provided by the security policy server to the firewall. The
whitelist-based security policy 200 of FIG. 2A is an example of the
security policy 147 illustrated in FIG. 1A, FIG. 1B, and FIG. 1C.
The security policy 200 of FIG. 2A includes several field
identifying several categories of information.
[0045] In particular, the security policy 200 includes a domain
field 205, which identifies a domain, or a URL base, of the web
content server 130, the domain being visited by a particular
browser process of the browser 105.
[0046] The security policy 200 also includes an "authorized hosts"
field 210, which identifies host domains that are authorized to
provide content for the process generating a web page related to
the domain identified in the domain field 205. For example, the
security policy 200 suggests that content may be provided by source
hosts associated with "example.com," "media.example.com," and
"advertiser.com."
[0047] Any other host (such as the "attacker.com" domain of the
attacker server 195) attempting to provide data to a web page
related to the domain identified in the domain field 205 (e.g.,
"example.com") may have its data rejected by firewall 115. The
firewall 115 may also prevent the client device 105 for asking for
such data from hosts not identified in the "authorized hosts" field
210. The client device may in some cases display or emit a
notification that such data has been blocked, and may in some cases
give the user the option to let it through anyway. By crafting the
security policy 200, then, an owner of the domain identified in
domain field 205 can help provide an additional layer of protection
to visitors of his/her web page who have a compatible firewall 115
and a client-side communication tracking software 110.
[0048] The security policy 200 also includes an "authorized
resource types" field 215, which identifies types of data that are
authorized to be used with the domain identified in the domain
field 205. For example, the security policy 200 suggests that
sources associated with "example.com" may provide markup data
(e.g., ".html" files, ".css" files, ".xml" files), PHP data (e.g.,
".php" files), and JavaScript data (e.g., ".js" files). The
security policy 200 also suggests that sources associated with
"media.example.com" may provide image data (e.g., ".jpg" files,
".png" files, ".gif" files). The security policy 200 also suggests
that sources associated with "media.example.com" may provide markup
data (e.g., ".html" files, ".css" files, ".xml" files) and Adobe
Macromedia Flash files (e.g., ".swf" files). If any other type of
file is attempted (e.g.
[0049] Any other file types not identified in the "authorized
resource types" field 215 may be rejected and blocked by the
firewall 115 from reaching the client device 105. Similarly, the
firewall 115 may block the client device 105 for requesting file
types not identified in the "authorized resource types" field 215.
The client device may in some cases display or emit a notification
that such data has been blocked, and may in some cases give the
user the option to let it through anyway. By crafting the security
policy 200, then, an owner of the domain identified in domain field
205 can help provide an additional layer of protection to visitors
of his/her web page who have a compatible firewall 115 and a
client-side communication tracking software 110.
[0050] The security policy 200 also includes a "reverse DNS
required" field 220, which identifies whether or not the domain
identified in the domain field 205 requires a reverse DNS mapping
that provides some identifying information about the client device
105 to the web content server 130. Reverse DNS is sometimes used by
analytics platforms or email clients, for example. In some cases,
the firewall 115 may be adjusted to also block pages that require a
reverse DNS mapping.
[0051] FIG. 2B illustrates an exemplary blacklist-based security
policy provided by the security policy server to the firewall. The
blacklist-based security policy 250 of FIG. 2B is similar to the
whitelist-based security policy 200 and includes the same "domain"
field 205 and "reverse DNS required" field 220.
[0052] Whereas the security policy 200 of FIG. 2A includes an
"authorized hosts" field 210 that identifies which host domains are
authorized for provide data, the security policy 250 of FIG. 2B
instead includes a "blacklisted hosts" field 255 that identifies
which host domains are not authorized to provide data. For example,
the security policy 250 of FIG. 2B identifies that hosts associated
with "attacker.com" (e.g., hosted by attacker server 195),
"virus.com," and "malware.com" are not authorized. The firewall 115
may thus block content from the blacklisted hosts identified in the
"blacklisted hosts" field 255 when loading a web page associated
with the domain identified in the domain field 205 (e.g.,
"example.com").
[0053] The "blacklisted hosts" field 255 of security policy 250 of
FIG. 2B is somewhat less secure than the "authorized hosts" field
210 of security policy 200 of FIG. 2A, but is also somewhat more
flexible. A disadvantage of the blacklist is that a dangerous host
might not be identified in the "blacklisted hosts" field 255 and
thus might slip past the firewall 115. An advantage of the
blacklist is that a web page can use content from numerous hosts,
which may be useful to keep certain types of web pages functioning
properly, such as a community-written "wild" page, a user comments
page, or a user-based forum page.
[0054] Whereas the security policy 200 of FIG. 2A includes an
"authorized resource types" field 215 that identifies which types
of data are authorized for use in associated with the domain 205,
the security policy 250 of FIG. 2B instead includes a "blacklisted
resource types" field 260 that identifies which data types are not
authorized to be used in associated with the domain 205. For
example, the security policy 250 of FIG. 2B identifies at the
"blacklisted resource types" field 260 that data from the host
domain "example.com" is not authorized to contain executable files
(e.g., ".exe" files, ".bat" files, ".bin" files, ".apk" files,
".ipa" files, ".app" files, ".osx" files, ".run" files, ".out"
files) which often have viruses, that data from the host domain
"media.example.com" is not authorized to contain video files
(".mov" files, ".avi" files, ".mp4" files, ".m4v" files, ".mkv"
files, ".wmv" files, ".rm" files) or source code files (".c" files,
".h" files, ".py" files, ".java" files), and that data from the
host domain "advertiser.com" is not authorized to contain audio
files (".mp3" files, ".mp4" files, ".m4a" files, ".wav" files,
".aac" files, ".flac" files, ".ogg" files) or java applet files
(".jar" files, ".class" files).
[0055] The "blacklisted resource types" field 260 of security
policy 250 of FIG. 2B is somewhat less secure than the "authorized
resource types" field 215 of security policy 200 of FIG. 2A, but is
also somewhat more flexible. A disadvantage of the blacklist is
that a dangerous file type might not be identified in the
"blacklisted resource types" field 260 and thus might slip past the
firewall 115. An advantage of the blacklist is that a web page can
use numerous file types, which may be useful to keep certain types
of web pages functioning properly, such as repositories for
downloadable software applications (e.g. "app stores", online
computer/video game stores) or cloud storage solutions that can
store and retrieve numerous types of files (e.g., Dropbox, Google
Drive, Box, OneDrive, iCloud).
[0056] Some security policies (not shown) may have a mix of
whitelists and blacklists. For example, a hypothetical security
policy may include an "authorized hosts" field 210 (as in the
security policy 200 of FIG. 2A) and a "blacklisted resource types"
field 260 (as in the security policy 250 of FIG. 2B). Alternately,
another hypothetical security policy may include a "blacklisted
hosts" field 255 (as in the security policy 250 of FIG. 2B) and an
"authorized resource types" field 215 (as in the security policy
200 of FIG. 2A).
[0057] FIG. 3A illustrates an exemplary firewall ecosystem wherein
an exemplary firewall detects and removes an unauthorized content
type.
[0058] The firewall ecosystem of FIG. 3A is similar structurally to
the firewall ecosystems illustrated in FIG. 1A, FIG. 1B, and FIG.
1C, and includes the same set of communications up until the HTTPS
Request represented by arrow 143. The HTTPS reply represented by
arrow 305, however, includes a particular security policy 350
(which is an example of a security policy 147) that allows only
HTML and image content types (e.g. via a whitelist-based
"authorized resource types" field 215). This security policy 350 is
stored in the security policy store 149 of the firewall 115.
[0059] The firewall 115 then transmits the HTTP(S) request of arrow
151 to the web content server 130 as it would in FIG. 1A, FIG. 1B,
or FIG. 1C. The web content server 130 sends back an HTTP(S) reply,
represented by arrow 315, which includes HTML content, image
content, and Java applet content.
[0060] The firewall 115 identifies that the Java applet content
received from the web content server 130 as part of the HTTP(S)
reply of arrow 315 is not an authorized content type according to
the security policy 350 stored in its security policy store 149.
Accordingly, in FIG. 3A, the firewall 115 strips out the Java
applet content from the HTTP(S) reply and sends the resulting
HTTP(S) reply with Java applet content removed back through the
client-side communication tracking software 110 and to the browser
105, as represented by the arrow 320 and the arrow 325,
respectively. Thus, if the Java applet content was inserted by an
attacker, for example, the owner of the web content server 130 can
still protect his/her visitors' client devices 100 using the
security policy 350.
[0061] FIG. 3B illustrates an exemplary firewall ecosystem wherein
an exemplary firewall detects an unauthorized content type and
returns an error. In particular, FIG. 3B illustrates the exemplary
firewall ecosystem of FIG. 3A, where the firewall 115 is able to
detect the Java applet content from the HTTP(S) reply represented
by arrow 315.
[0062] Once the firewall 115 in FIG. 3B detects the Java applet
content in the HTTP(S) reply of arrow 315, however, unlike FIG. 3A,
it does not try to strip the Java applet content from the HTTP(S)
reply of arrow 315. Instead, it either returns nothing to the
browser 105 of the client device 100, or it returns an error
message (e.g., a 403 "access denied/forbidden" error) back through
the client-side communication tracking software 110 and to the
browser 105, as represented by the arrow 330 and the arrow 335,
respectively.
[0063] In some cases, the firewall 115 of FIG. 3A and FIG. 3B may
be the same firewall. For example, FIG. 3A may represent a
situation where Java applet content is detected within the HTTP(S)
reply of arrow 315, and is understood to be removable. FIG. 3B may
represent a situation where Java applet content is detected within
the HTTP(S) reply of arrow 315, and is not well-understood or is
understood to be too complicated or dangerous to try to remove.
Alternately, the firewalls 115 of FIG. 3A and FIG. 3B may simply be
different firewalls with different approaches to protecting the
client device 100 using the security policy 350.
[0064] It should also be understood that some of the communications
represented by arrows in FIG. 1A, FIG. 1B, FIG. 1C, FIG. 3A, and
FIG. 3B may, in some cases, bypass the client-side communication
tracking software 110 and pass straight from the firewall 115 to
the browser 105 or straight from the browser 105 to the firewall
115.
[0065] It should be understood that any and all references to the
browser 105 of FIG. 1A, FIG. 1B, FIG. 1C, FIG. 3A, and FIG. 3B may
in some cases be replaced by another network-connected software
application, such as an e-mail client (e.g., Microsoft Outlook,
Mozilla Thunderbird, Apple Mail, iOS Mail), a
document-collaboration application (e.g., Microsoft Office, Google
Docs), a source-code version control application (e.g. Subversion,
Concurrent Versions System), a map application (e.g., Google Maps,
Apple Maps, Waze Maps, Microsoft Bing Maps), a file transfer
application (e.g. an "FTP" file transfer protocol application), a
cloud file storage application (e.g., Dropbox, Google Drive, Box,
OneDrive, iCloud), a terminal application, a video streaming
application (e.g., Netflix, Hulu, HBO Go, Amazon Prime Video,
VideoLan VLC), a music streaming application (e.g., Spotify, Apple
Music, Google Play Music, Amazon Prime Music, Pandora, VideoLan VLC
Player), a software application repository or store (e.g. Apple iOS
App Store, Apple OSX App Store, Valve Steam, Google Play Store,
Google Chrome Web Store, Amazon App Store, Microsoft Windows Store,
Electronic Arts Origin, GOG Galaxy), a video game application with
online multiplayer features, an instant messaging or chat
application (e.g., Google Hangouts, Pidgin, Digsby), a voice and/or
video call application (e.g., Skype, Google Hangouts, Apple
Facetime), an SMS text message application (e.g., Apple iMessage),
some combination thereof, or some other network-connected software
application.
[0066] FIG. 4 illustrates an exemplary computing system 400 that
may be used to implement an embodiment of the present invention.
The computing system 400 of FIG. 4 includes one or more processors
410 and memory 410. Main memory 410 stores, in part, instructions
and data for execution by processor 410. Main memory 410 can store
the executable code when in operation. The system 400 of FIG. 4
further includes a mass storage device 430, portable storage medium
drive(s) 440, output devices 450, user input devices 460, a
graphics display 470, and peripheral devices 480.
[0067] The components shown in FIG. 4 are depicted as being
connected via a single bus 490. However, the components may be
connected through one or more data transport means. For example,
processor unit 410 and main memory 410 may be connected via a local
microprocessor bus, and the mass storage device 430, peripheral
device(s) 480, portable storage device 440, and display system 470
may be connected via one or more input/output (I/O) buses.
[0068] Mass storage device 430, which may be implemented with a
magnetic disk drive or an optical disk drive, is a non-volatile
storage device for storing data and instructions for use by
processor unit 410. Mass storage device 430 can store the system
software for implementing embodiments of the present invention for
purposes of loading that software into main memory 410.
[0069] Portable storage device 440 operates in conjunction with a
portable non-volatile storage medium, such as a floppy disk,
compact disk or Digital video disc, to input and output data and
code to and from the computer system 400 of FIG. 4. The system
software for implementing embodiments of the present invention may
be stored on such a portable medium and input to the computer
system 400 via the portable storage device 440.
[0070] Input devices 460 provide a portion of a user interface.
Input devices 460 may include an alpha-numeric keypad, such as a
keyboard, for inputting alpha-numeric and other information, or a
pointing device, such as a mouse, a trackball, stylus, or cursor
direction keys. Additionally, the system 400 as shown in FIG. 4
includes output devices 450. Examples of suitable output devices
include speakers, printers, network interfaces, and monitors.
[0071] Display system 470 may include a liquid crystal display
(LCD), a plasma display, an organic light-emitting diode (OLED)
display, an electronic ink display, a projector-based display, a
holographic display, or another suitable display device. Display
system 470 receives textual and graphical information, and
processes the information for output to the display device. The
display system 470 may include multiple-touch touchscreen input
capabilities, such as capacitive touch detection, resistive touch
detection, surface acoustic wave touch detection, or infrared touch
detection. Such touchscreen input capabilities may or may not allow
for variable pressure or force detection.
[0072] Peripherals 480 may include any type of computer support
device to add additional functionality to the computer system. For
example, peripheral device(s) 480 may include a modem or a
router.
[0073] The components contained in the computer system 400 of FIG.
4 are those typically found in computer systems that may be
suitable for use with embodiments of the present invention and are
intended to represent a broad category of such computer components
that are well known in the art. Thus, the computer system 400 of
FIG. 4 can be a personal computer, a hand held computing device, a
telephone ("smart" or otherwise), a mobile computing device, a
workstation, a server (on a server rack or otherwise), a
minicomputer, a mainframe computer, a tablet computing device, a
wearable device (such as a watch, a ring, a pair of glasses, or
another type of jewelry/clothing/accessory), a video game console
(portable or otherwise), an e-book reader, a media player device
(portable or otherwise), a vehicle-based computer, some combination
thereof, or any other computing device. The computer can also
include different bus configurations, networked platforms,
multi-processor platforms, etc. The computer system 400 may in some
cases be a virtual computer system executed by another computer
system. Various operating systems can be used including Unix,
Linux, Windows, Macintosh OS, Palm OS, Android, iOS, and other
suitable operating systems.
[0074] The present invention may be implemented in an application
that may be operable using a variety of devices. Non-transitory
computer-readable storage media refer to any medium or media that
participate in providing instructions to a central processing unit
(CPU) for execution. Such media can take many forms, including, but
not limited to, non-volatile and volatile media such as optical or
magnetic disks and dynamic memory, respectively. Common forms of
non-transitory computer-readable media include, for example, a
floppy disk, a flexible disk, a hard disk, magnetic tape, any other
magnetic medium, a CD-ROM disk, digital video disk (DVD), any other
optical medium, RAM, PROM, EPROM, a FLASHEPROM, and any other
memory chip or cartridge.
[0075] While various flow diagrams provided and described above may
show a particular order of operations performed by certain
embodiments of the invention, it should be understood that such
order is exemplary (e.g., alternative embodiments can perform the
operations in a different order, combine certain operations,
overlap certain operations, etc.).
[0076] The foregoing detailed description of the technology has
been presented for purposes of illustration and description. It is
not intended to be exhaustive or to limit the technology to the
precise form disclosed. Many modifications and variations are
possible in light of the above teaching. The described embodiments
were chosen in order to best explain the principles of the
technology, its practical application, and to enable others skilled
in the art to utilize the technology in various embodiments and
with various modifications as are suited to the particular use
contemplated. It is intended that the scope of the technology be
defined by the claim.
* * * * *