Web sites and applications as well as client devices are vulnerable to attack by malicious third parties. In some attacks, a browser extension may be abused to impair a client device on which the browser extension is operating, e.g., by downloading malicious executable files, hijacking user accounts, sniffing a user's web transactions, etc. In other attacks, browser extensions may be exploited to harm web sites visited by such client devices, e.g., by exploiting a web site's vulnerabilities to bypass two-factor authentication, launching Denial-of-Service (DOS) attacks, illegitimately scraping web site content, etc. Existing approaches to dealing with such attacks, such as server-side web application firewalls or client-side malware detection, do not fully address the range of threats.
According to various implementations, methods, apparatus, systems, and computer program products are provided for detecting browser extensions. According to a particular class of implementations, a request from a client to a server is received. The request corresponds to an interaction with a first web page hosted by the server. A pattern associated with the request is identified. It is determined that the pattern corresponds to a whitelisted browser extension with respect to the first web page. The request is passed to the server.
In some implementations, the whitelisted browser extension is provided to the client. It is determined, responsive to determining that the pattern corresponds to the whitelisted browser extension with respect to the first web page, that the user of the client is a trusted user of the first web page. The request is passed to the server in response to determining that the user of the client is the trusted user of the first web page.
In some implementations, the request is passed to the server based on a configurable security policy. Input is received from an authorized administrator. The security policy is configured based on the input.
According to some implementations, the request is passed to the server in response to determining that match criteria are met. The match criteria comprise: the request being associated with the whitelisted browser extension, and one or more of: an IP (Internet Protocol) address of the client corresponding to a designated IP address, a header of the request corresponding to a designated header, or the request being associated with a resource having a designated URI (Uniform Resource Identifier).
According to another class of implementations, a request from a client to a server is received at a device in communication with the server and the client. The request corresponds to an interaction with a first web page hosted by the server. A pattern associated with the request is identified. It is determined that the pattern corresponds to a particular browser extension associated with a web browser operating on the client. One or more actions are performed. The actions can include one or more of: logging the request, dropping the request, passing the request, banning an IP address associated with the client from communicating with the server, or causing a warning to be rendered by the web browser operating on the client.
In some implementations, the actions are performed based on a configurable security policy. Input is received from an authorized administrator associated with the first web page. The security policy is configured based on the input.
Also or alternatively, data is received at the device from an automated threat intelligence feed. The data represents a set of configurable rules related to verified malicious or potentially malicious browser extensions. The security policy is updated based on the data.
In some implementations the actions are performed in response to determining that match criteria are met. The match criteria comprise: the request being associated with the particular browser extension, and one or more of: the IP address of the client corresponding to a designated IP address, a header of the request corresponding to a designated header, or the request being associated with a resource having a designated URI.
According to some implementations detection code is injected into a response from the server to the client. The detection code is configured to detect the particular browser extension on the client, and to communicate data to the device. The data indicates that the browser extension is operating on the client.
In some implementations, a second request is received at the device from a second client to a second server. The further request corresponds to a second interaction with a second web page. The second web page is different from the first web page. A second pattern associated with the second request is identified. It is determined that the second pattern corresponds to the particular browser extension. The request to the second server.
According to some implementations, determining that the pattern corresponds to the particular browser extension comprises determining that the pattern represents an attribute of a group of browser extensions that includes the particular browser extension.
According to another class of implementations, a request from a client to a server is received at a device in communication with the server and the client. The request corresponds to an interaction with a first web page hosted by the server. The request is analyzed. It is determined that the request corresponds to an unknown browser extension associated with a web browser operating on the client. The request is logged. The request is processed based on a security policy.
In some implementations, processing the request comprises dropping the request, or passing the request to the server.
According to another class of implementations, requests from a plurality of clients to a server are received at a device in communication with the clients and the server. Each request corresponds to an interaction with a first web page hosted by the server. A pattern associated with a first one of the requests is identified. It is determined that that the pattern corresponds to a particular browser extension associated with a web browser operating on a first client. The first request originates at the first client. One or more actions are performed. The one or more actions include one or more of: logging the first request, dropping the first request, passing the first request, banning an IP address associated with the first client from communicating with the server, or causing a warning to be rendered by the web browser operating on the first client.
In some implementations, the actions are performed based on a configurable security policy. Input is received from an authorized administrator associated with the first web page. The security policy is configured based on the input.
Also or alternatively, data is received at the device from an automated threat intelligence feed. The data represents a set of configurable rules related to verified malicious or potentially malicious browser extensions. The security policy is updated based on the data.
In some implementations, the actions are performed in response to determining that match criteria are met. The match criteria comprise: the first request being associated with the particular browser extension, and one or more of: the IP address of the first client corresponding to a designated IP address, a header of the first request corresponding to a designated header, or the first request being associated with a resource having a designated URI.
In some implementations, detection code is injected into a response from the server to the first client. The detection code is configured to detect the particular browser extension on the first client, and to communicate data to the network appliance. The data indicates that the particular browser extension is operating on the client.
In some implementations it is determined that the pattern corresponds to the particular browser extension by determining that the pattern represents an attribute of the particular browser extension that corresponds to a group of browser extensions.
According to another class of implementations, requests from clients associated with a protected entity to a plurality of servers are received at a device in communication with the clients and the servers. Each request corresponds to an interaction with a web page hosted by one of the servers. A pattern associated with a first one of the requests is identified. It is determined that that the pattern corresponds to a particular browser extension associated with a web browser operating on a first client. The first request originates at the first client. One or more actions are performed. The one or more actions include one or more of: logging the first request, dropping the first request, passing the first request, banning an IP address associated with the first client from communicating with the server, or causing a warning to be rendered by the web browser operating on the first client.
In some implementations, the actions are performed based on a configurable security policy. Input is received from an authorized administrator associated with the entity. The security policy is configured based on the input.
Also or alternatively, data is received at the device from an automated threat intelligence feed. The data represents a set of configurable rules related to verified malicious or potentially malicious browser extensions. The security policy is updated based on the data.
In some implementations, detection code is injected into a response from a first one of the servers to the first client. The detection code is configured to detect the particular browser extension on the first client, and to communicate data to the network appliance. The data indicates that the particular browser extension is operating on the client.
A further understanding of the nature and advantages of various implementations may be realized by reference to the remaining portions of the specification and the drawings.
Reference will now be made in detail to specific implementations. Examples of these implementations are illustrated in the accompanying drawings. It should be noted that these examples are described for illustrative purposes and are not intended to limit the scope of this disclosure. Rather, alternatives, modifications, and equivalents of the described implementations are included within the scope of this disclosure as defined by the appended claims. In addition, specific details may be provided in order to promote a thorough understanding of the described implementations. Some implementations within the scope of this disclosure may be practiced without some or all of these details. Further, well known features may not have been described in detail for the sake of clarity.
This disclosure describes techniques for applying security policies based on detected browser extensions. As used herein, the term browser extension generally refers to a component operating in conjunction with a web browser on a client device that augments the web browser's standard functionality. A browser extension is sometimes also referred to as an “add-on,” a “plug-in,” an “app,” etc. Such browser extensions can be developed by a variety of sources such as browser vendors, independent providers, private individuals, etc. While many browser extensions are used to improve user experiences, some browser extensions can be abused to harm web servers and clients alike. By way of example, a malicious third party may develop a browser extension to sniff web transactions and gather identifying information such as credit card numbers or user authentication credentials. The malicious third party may induce unknowing users to install such an extension through phishing or by disguising it as a legitimate browser extension.
Browser extensions can also pose a significant threat to web sites. By way of example, a malicious third party might want to mine a social networking web site for data in order to sell the data to advertisers. The third party might create a “content-grabbing” browser extension that uses the credentials of users of the social networking web site to extract data from their friends' profiles and send the data back to the malicious third party's servers. Such data extraction may not be within the terms of service of the social networking web site. Therefore, the operator of the social networking web site may wish to block the content grabbing browser extension from accessing the web site.
According to specific implementations described herein, both malicious and benign browser extensions can be detected and appropriate automated responses can be produced. Returning to the example of the preceding paragraph, a request to grab content from the social networking web site can be intercepted and the content grabbing browser extension can be detected, as described below. A configurable security policy can define known browser extensions and actions to be performed when a request associated with such browser extensions is detected. Therefore, any requests associated with the content grabbing browser extension can be dropped before the requests reach the web servers of the social networking web site.
While some browser extensions can be exploited by malicious third parties, many browser extensions are desirable and can be used to improve user experience and enhance the functionality of web sites. Further complicating matters, a browser extension that is considered malicious with respect to one web site may actually be desired to enhance the functionality of a different web site. Returning to the example of the preceding paragraph, the content grabbing browser extension that presents a problem to the social networking web site can be neutral to a web page maintained by an online retailer. As such, while it is desirable for the social networking web site to deny the content grabbing browser extension access to its web site, the online retailer may want to allow users with the content grabbing browser extension to access their web site.
In some implementations, a browser extension that is desirable, or known to be benign to the functionality to a particular web site, can be “whitelisted,” e.g., a record of the browser extension can be maintained so that requests associated with that browser extension can be passed from a client to a server hosting a web page of the web site. Such whitelisting can operate within the context of a single device (or devices) implementing the browser extension detection and response techniques disclosed herein, or be extended to other security layers or devices deployed in front of the web site. In the latter case, if a browser extension is a whitelisted browser extension for the web site, all requests associated with the whitelisted browser extension can be directly forwarded to the web server(s) of the web site, without being routed through any other security layers or devices (such as a web application firewall, intrusion prevention system, etc.) deployed in front of the web site. This can be especially useful when these other security layers or devices cannot effectively detect the whitelisted browser extension themselves. Returning to the example of the preceding paragraph, the online retailer can add the content grabbing browser extension to their whitelist of allowed browser extensions. As described below, requests associated with whitelisted browser extensions can be passed directly to the web servers of the online retailer bypassing other security layers or devices, such as a web application firewall deployed in front of the web servers, while requests from other browser extensions can be dropped. Specific implementations will now be described with reference to the accompanying figures.
A load balancer 116 acts as an intermediary between the servers 104 and the network 108, distributing requests and responses (e.g., interactions by users of client devices 112 web pages served by servers 104) to one or more network appliances 120. The one or more network appliances 120 process at least a portion of the requests received, potentially performing actions in relation to the requests as described below. Ultimately, the one or more network appliances 120 can pass the requests to servers 112 via the load balancer 116.
A simplified block diagram of such a network appliance 120 is shown in
Appliance 120 also includes one or more network interfaces 208. The network interfaces 208 may be used to connect via wired or wireless connections to any of a variety of network types including, for example, cellular networks, wireless networks, the internet, public networks, private networks, wide area networks, local area networks, etc. In some implementations, appliance 120 might also include, network processors or network specific ASIC (Application-Specific Integrated Circuit) hardware chips.
Appliance 120 also includes one or more buses or other internal communications hardware or software (not shown) that allow for the transfer of data and instructions between the various modules and components of the appliance.
While appliance 120 might have many functions, this disclosure focuses mainly on the use of appliance 120 to detect browser extensions, to apply configurable security policies, and to take corresponding actions in response to detection. For example, appliance(s) 120 might function as web security appliances protecting servers 104. For example, appliance 120 might be a ShapeShifter® manufactured by Shape Security®, an MWS1000® appliance manufactured by Juniper Networks®, or any of a wide variety of other web security products.
In one implementation, appliance 120 receives request(s) 212 corresponding to an interaction with a web page through one or more network interfaces 208. For example, request(s) 212 may correspond to interactions by users of client devices 112 with web pages served by servers 104.
Request(s) 212 are processed by Browser Extension Firewall 216, which includes a series of modules that are described in greater detail below in the context of
After request(s) 212 are processed by Browser Extension Firewall 216, responses can be transmitted from the appliance 120 via the one or more network interfaces 208. As described in more detail below, such responses can vary across implementations. For example, a response may include transmission of request(s) 212 to a load balancer (e.g., load balancer 116 of
It should be noted that, despite references to specific computing paradigms and software tools in this disclosure, the computer program instructions on which implementations are based may correspond to any of a wide variety of programming languages, software tools and data formats, may be stored in any type of non-transitory computer-readable storage media or memory device(s), and may be executed according to a variety of computing models including, for example, a client/server model, a peer-to-peer model, on a stand-alone computing device, or according to a distributed computing model in which various functionalities may be effected or employed at different locations. In addition, references to particular protocols in this disclosure are merely by way of example. Suitable alternatives known to those of skill in the art may be employed as appropriate for particular implementations.
Referring now to
A request from a client to a server is received (304). The request can vary across implementations and is discussed below in the context of
Requests can be transmitted across a variety of transmission media. For example, a request might take the form of signals transmitted from client devices 112 by way of a T1 or T3 line, an optical carrier line such as a line to a synchronous optical network or a fiber optic network, a telephone line, a coaxial cable, a twisted pair copper cable, etc. Requests might also be transmitted wirelessly via a WiFi local area network, a Bluetooth private network, etc.
Returning to
In some implementations, browser extensions are not detected directly, but rather the effect or signature of a browser extension is detected in a request from a client, e.g., some browser extensions can be identified by common attributes in an HTTP (Hyper Text Transfer Protocol) request header and body.
Returning to
Patterns associated with browser extensions can be identified in a variety of manners. For example, a pattern associated with a given browser extension can be identified and learned by comparing traffic from clients that are operating with and without the extension. A pattern that is present in a request when the extension is operating on a client device but is not present when the extension is not operating on a client device can be verified to be associated with the browser extension. By way of illustration, when a user logs into a social networking web site without a particular browser extension, the request might contain only the user's username and password. On the other hand, when a user logs into the social networking web page with that browser extension the request might contain additional information. Therefore, if a request is received that contains the additional information, it can be determined that the browser extension is operating on the client device at which the first request originated.
One having skill in the art can appreciate that a large and diverse set of browser extensions is currently available with many new and updated browser extensions becoming available every day. Therefore, an entity such as a cyber-security provider can use the techniques described herein to maintain an up to date list of browser extensions and corresponding patterns that are presented in requests from clients operating such browser extensions.
Returning to
The injected code can be configured to cause browser extension information to be sent from a client at a variety of times. For example, browser extension information can be sent from client 400 of
Various techniques can be used to ensure that such injected code is not detected by malicious third parties having access to the client device. By way of example, injected code can be obfuscated such that it is difficult for malicious third parties to detect. According to various implementations, the ways in which injected code is obfuscated may vary considerably. For example, obfuscation of injected code may be accomplished in accordance with techniques described in the following U.S. patent applications, each of which is incorporated herein by reference and forms part of this disclosure: U.S. patent application Ser. No. 14/055,646 for Protecting Against the Introduction of Alien Content filed on Oct. 16, 2013; U.S. patent application Ser. No. 14/055,704 for Safe Intelligent Content Modification filed on Oct. 16, 2013; U.S. patent application Ser. No. 14/286,733 for Polymorphic Treatment of Data Entered at Clients filed on May 23, 2014.
It will be understood that obfuscation techniques evolve over time and an obfuscation module can be configured to execute the above-described obfuscation techniques and other existing obfuscation techniques, as well as yet-to-be conceived obfuscation techniques. Suitable variations will be apparent to those of skill in the art.
Returning to
Alternatively, some requests may be determined to be associated with an unknown browser extension. By way of illustration, if a request presents a pattern that cannot be identified at 312, and injected code cannot expose a recognizable browser extension at 316, it can be determined that the request is associated with an unknown browser extension.
In some implementations, when an unknown browser extension is detected the unknown browser extension can be tracked such that it can be identified in the future. By way of illustration, any requests associated with unknown browser extensions can be logged and such logs can be provided to a network administrator for a web site. A log of a request can include an indication of any patterns associated with the request as well as an indication the request is associated with an unknown browser extension. The network administrator can study the log and investigate the matter to identify the unknown browser extension, determine whether the unknown browser extension should be allowed to access the web site, and potentially update the security policy accordingly as described below.
According to some implementations, a security policy is applied in response to the detection of a known or unknown browser extension (324). By way of example, Security Policy Module 412 of
Match criteria can vary across implementations. By way of example, in a rule relating to one browser extension, the match criterion (or criteria) of the rule can be met by a request when it is determined that the request is associated with that browser extension at 320 of
Actions that are performed in response to match criteria being met can vary across implementations. For example, a request can be passed, a request can be dropped, a request can be logged with detailed information indicating what caused the match, a client at which a request originates can be redirected to a web page with warnings about a detected malicious browser extension, a client IP address at which a request originates can be banned for a configurable period of time, etc.
One example of a configurable a security policy with 5 rules is shown in Table 1.
Table 1 shows match criteria and actions corresponding to each of the 5 rules. By way of example, rule #4 is named “content-scraping-deny.” The first match criterion of rule 5 is met when the “content-scraper” browser extension is identified in a request. According to the match criteria of rule #4, the request can originate from any client IP address and must be directed to the host “www.content-server-example.com.” The remaining match criterion of rule #4 is met when the request involves accessing a resource with a URI containing the text “profile.” When the match criteria of rule #4 are met by a request, the request will be dropped, as indicated in the “Action” column. Therefore, returning to the example or the social networking web site described above, rule #4 can be included in a configurable security policy by an administrator of the social networking web site to block requests associated with the known content scraper browser extension that grabs profile information from the social networking web site.
Along the same lines, rules #1 and #2 represent the whitelisting of particular known benign browser extensions. Rule #3 represents redirecting a client at which a request associated with the “AdBlock” browser extension originates to a web page with warnings about the AdBlock extension. Lastly, rule #5 represents the logging of a request associated with an unknown browser extension.
The security policy described herein can be highly configurable, providing administrators and web site operators the flexibility to account for the fact that the same browser extension may present a threat to one web site but be completely legitimate with respect to another web site. For example, an authorized administrator of a web site can send input via his computing device to appliance 120 of
In some implementations, a security policy can be used to whitelist known benign or desirable browser extensions. By way of illustration an operator of a web page can generate a whitelist of 10 browser extensions that beneficially extend functionality of the web page. The operator can specify the security policy such that only requests from the whitelisted browser extensions can be passed directly to web servers of the web page and requests from any other browser extension can be subjected to standard security inspections, e.g., by a web application firewall, an intrusion prevention system, etc.
In some implementations, a whitelist of browser extensions can be dynamic to account for evolving threats to web sites. By way of example, a particular browser extension may be developed for a number of positive uses and, therefore, be added to a whitelist of browser extensions for a website. As the web site evolves, the web site may become vulnerable to newly discovered malicious uses of the particular browser extension. Therefore, the particular browser extension can be removed from the whitelist of browser extensions for the web site.
Also or alternatively, a whitelist of browser extensions can be used for authentication. By way of illustration, operators of a web site may implement an additional set of security mechanisms such as a web application firewall. Unfortunately, some of the web site's trusted users may be erroneously categorized as “bad users” by the web application firewall. Trusted users, and only trusted users, can be provided with an “authentication” browser extension. The authentication browser extension can be whitelisted such that requests associated with the authentication browser extension will be passed. On the other hand, requests from other users who do not have the whitelisted browser extension will go through standard security inspections, e.g., by a web application firewall. Therefore, the whitelisted authentication browser extension allows all trusted users to access the web site regardless of their classification by the web application firewall and enables crucial functionality support for the trusted users that would otherwise be impacted by the web application firewall.
In some implementations, browser extensions can be grouped and a security policy can be applied to groups of browser extensions. For example, as the number of browser extensions regulated by a security policy increases, it may be desirable to place functionally similar browser extensions in groups, and enforce security policy based on these groups. By way of example, the browser extensions regulated by a given security policy might fall into three categories: toolbar, content-scraping, and content-blocking. Browser extension groups for each of the three categories can be defined as shown below:
With above definitions, an administrator can define rules in a security policy having match criteria that are met when a request associated with a browser extension in the “toolbar-group,” “content-scraping-group,” and “content-blocking-group” is identified. In some implementations, groups can be defined dynamically in a security policy, e.g., if a browser extension is added to a first group, the security policy can be automatically updated accordingly.
Groups of browser extensions can be defined to have more than one hierarchical level. By way of illustration, a first group of browser extensions might include browser extensions that extract data from web sites in a particular manner. The first group of browser extensions might be part of a larger group of “general data extraction” browser extensions that includes the entire class of browser extensions that extract data from web sites. The group of “general data extraction” browser extensions may be part of a group of “general web site attacking” browser extensions that includes the entire class of browser extensions that can be used to attack web sites.
In some implementations, an “automated threat intelligence feed” can be used to keep a security policy up to date. By way of illustration, a vendor, such as a cyber security provider, can research and identify malicious, good, and benign browser extensions. The vendor can perform out-of-band research on published browser extensions from various browser providers' stores, e.g., the Google Chrome® web store. Such research can be used to produce a list of malicious and potentially malicious browser extensions. The vendor can use the list to generate an automated threat intelligence feed that includes configurable rules related to the malicious and potentially malicious browser extensions that the vendor researched and identified. The automated threat intelligence feed can be hosted on a server and provided to or retrieved by security policy module 412 of
In some implementations, a security policy can include a global security model definable by an administrator that defines a response that occurs when a client request does not match any rules in the security policy, e.g., a request that is associated with an unknown browser extension. For example, in a positive security model all client requests that do not meet the match criteria of any rules specified by the security policy will be dropped. A positive security model may be applied in environments with strict security requirements because all unknown or unidentified browser extensions are considered potentially unsafe. Alternatively, in a negative security model all client requests that do not meet the match criteria of any rules specified by the security policy will be passed. A negative security model may sometimes be applied in environments where user experience is valued over security because only known malicious browser extensions are considered potentially unsafe.
Returning to
One having skill in the art would appreciate that the disclosed techniques can be applied in a diverse array of computing environments in a variety of contexts. For instance,
Browser Extension Firewall 504 can reside in a variety of places such as on network appliance 120 of
Alternatively,
It will be understood by those skilled in the art that changes in the form and details of the implementations described herein may be made without departing from the scope of this disclosure. In addition, although various advantages, aspects, and objects have been described with reference to various implementations, the scope of this disclosure should not be limited by reference to such advantages, aspects, and objects. Rather, the scope of this disclosure should be determined with reference to the appended claims.
This application claims the benefit under 35 U.S.C. § 120 as a Continuation of U.S. patent application Ser. No. 14/942,769, filed on 2015 Nov. 16, the entire contents of which are hereby incorporated by reference as if fully set forth herein.
Number | Name | Date | Kind |
---|---|---|---|
5509076 | Sprunk | Apr 1996 | A |
6654707 | Wynn | Nov 2003 | B2 |
7058699 | Chiou | Jun 2006 | B1 |
7107347 | Cohen | Sep 2006 | B1 |
7398553 | Li | Jul 2008 | B1 |
7424720 | Chagoly | Sep 2008 | B2 |
7464326 | Kawai | Dec 2008 | B2 |
7797421 | Scofield | Sep 2010 | B1 |
7849502 | Bloch | Dec 2010 | B1 |
7870610 | Mitchell | Jan 2011 | B1 |
7895653 | Calo | Feb 2011 | B2 |
8170020 | Oliver | May 2012 | B2 |
8195953 | Yue | Jun 2012 | B1 |
8453126 | Ganelin | May 2013 | B1 |
8555388 | Wang | Oct 2013 | B1 |
8561193 | Srivastava | Oct 2013 | B1 |
8578499 | Zhu | Nov 2013 | B1 |
8589405 | Estan | Nov 2013 | B1 |
8615804 | Mui | Dec 2013 | B2 |
8650648 | Howard | Feb 2014 | B2 |
8677481 | Lee | Mar 2014 | B1 |
8689330 | Sinn | Apr 2014 | B2 |
8713684 | Bettini | Apr 2014 | B2 |
8726394 | Maor | May 2014 | B2 |
8739284 | Gardner | May 2014 | B1 |
8752208 | Shulman | Jun 2014 | B2 |
8762962 | Ben-Artzi | Jun 2014 | B2 |
8843820 | Kay | Sep 2014 | B1 |
8849985 | Colton | Sep 2014 | B1 |
8997226 | Call | Mar 2015 | B1 |
9043924 | Maor | May 2015 | B2 |
9158893 | Call | Oct 2015 | B2 |
9225729 | Moen | Dec 2015 | B1 |
9225737 | Call | Dec 2015 | B2 |
9258328 | Ibatullin | Feb 2016 | B2 |
9456050 | Lepeska | Sep 2016 | B1 |
9537888 | McClintock | Jan 2017 | B1 |
9609006 | Call | Mar 2017 | B2 |
9628498 | Aziz | Apr 2017 | B1 |
9635041 | Warman | Apr 2017 | B1 |
9639699 | Kurupati | May 2017 | B1 |
9646140 | Horadan | May 2017 | B2 |
9680850 | Rapaport | Jun 2017 | B2 |
9686300 | Kurupati | Jun 2017 | B1 |
9705902 | Call | Jul 2017 | B1 |
9906544 | Kurupati | Feb 2018 | B1 |
10165004 | Mehta | Dec 2018 | B1 |
20020194219 | Bradley | Dec 2002 | A1 |
20020199116 | Hoene | Dec 2002 | A1 |
20030123431 | Geck | Jul 2003 | A1 |
20040088651 | McKnight | May 2004 | A1 |
20050060535 | Bartas | Mar 2005 | A1 |
20050108554 | Rubin | May 2005 | A1 |
20050172338 | Sandu | Aug 2005 | A1 |
20050198099 | Motsinger | Sep 2005 | A1 |
20050216770 | Rowett | Sep 2005 | A1 |
20050240999 | Rubin | Oct 2005 | A1 |
20050251536 | Harik | Nov 2005 | A1 |
20050278626 | Malik | Dec 2005 | A1 |
20060053295 | Madhusudan | Mar 2006 | A1 |
20060101047 | Rice | May 2006 | A1 |
20060174323 | Brown | Aug 2006 | A1 |
20060195588 | Pennington | Aug 2006 | A1 |
20060230288 | Fox | Oct 2006 | A1 |
20060288418 | Yang | Dec 2006 | A1 |
20070011295 | Hansen | Jan 2007 | A1 |
20070064617 | Reves | Mar 2007 | A1 |
20070088955 | Lee | Apr 2007 | A1 |
20070128899 | Mayer | Jun 2007 | A1 |
20070234070 | Horning | Oct 2007 | A1 |
20080208785 | Trefler | Aug 2008 | A1 |
20080320567 | Shulman | Dec 2008 | A1 |
20090070459 | Cho | Mar 2009 | A1 |
20090099988 | Stokes | Apr 2009 | A1 |
20090106296 | Sickmiller | Apr 2009 | A1 |
20090199297 | Jarrett | Aug 2009 | A1 |
20090241174 | Rajan | Sep 2009 | A1 |
20090292791 | Livshits | Nov 2009 | A1 |
20100088404 | Mani | Apr 2010 | A1 |
20100106611 | Paulsen | Apr 2010 | A1 |
20100142382 | Jungck et al. | Jun 2010 | A1 |
20100186089 | Fu | Jul 2010 | A1 |
20100218253 | Andrew | Aug 2010 | A1 |
20100235637 | Lu | Sep 2010 | A1 |
20100235910 | Ku | Sep 2010 | A1 |
20100287132 | Hauser | Nov 2010 | A1 |
20110035733 | Horning | Feb 2011 | A1 |
20110154308 | Lobo | Jun 2011 | A1 |
20110225234 | Amit | Sep 2011 | A1 |
20110231305 | Winters | Sep 2011 | A1 |
20110320816 | Yao | Dec 2011 | A1 |
20120036576 | Iyer | Feb 2012 | A1 |
20120090030 | Rapaport | Apr 2012 | A1 |
20120198528 | Baumhof | Aug 2012 | A1 |
20120254727 | Jain | Oct 2012 | A1 |
20120255006 | Aly et al. | Oct 2012 | A1 |
20120324236 | Srivastava | Dec 2012 | A1 |
20130047255 | Dalcher | Feb 2013 | A1 |
20130086679 | Beiter | Apr 2013 | A1 |
20130219492 | Call | Aug 2013 | A1 |
20130239195 | Turgeman | Sep 2013 | A1 |
20130247030 | Kay | Sep 2013 | A1 |
20130263264 | Klein | Oct 2013 | A1 |
20130273882 | Walsh | Oct 2013 | A1 |
20140040051 | Ovick | Feb 2014 | A1 |
20140096194 | Bhogavilli | Apr 2014 | A1 |
20140101236 | Dietrich | Apr 2014 | A1 |
20140208198 | Ayoub | Jul 2014 | A1 |
20140282014 | Lee | Sep 2014 | A1 |
20140298469 | Marion | Oct 2014 | A1 |
20140304816 | Klein | Oct 2014 | A1 |
20140310392 | Ho | Oct 2014 | A1 |
20140365794 | Decker | Dec 2014 | A1 |
20150058992 | El-Moussa | Feb 2015 | A1 |
20150067031 | Acharya | Mar 2015 | A1 |
20150067866 | Ibatullin | Mar 2015 | A1 |
20150112892 | Kaminsky | Apr 2015 | A1 |
20150262183 | Gervais | Sep 2015 | A1 |
20150278491 | Horning | Oct 2015 | A1 |
20150281263 | McLaughlin | Oct 2015 | A1 |
20150358338 | Zeitlin | Dec 2015 | A1 |
20150379266 | McLaughlin | Dec 2015 | A1 |
20160005029 | Ivey | Jan 2016 | A1 |
20160072829 | Call | Mar 2016 | A1 |
20160119344 | Dos Santos | Apr 2016 | A1 |
20160191554 | Kaminsky | Jun 2016 | A1 |
20160342793 | Hidayat | Nov 2016 | A1 |
20160344769 | Li | Nov 2016 | A1 |
20160378989 | Park | Dec 2016 | A1 |
20170012960 | Idika | Jan 2017 | A1 |
20170013012 | Hansen | Jan 2017 | A1 |
20170048260 | Peddemors | Feb 2017 | A1 |
20170201540 | Call | Jul 2017 | A1 |
20170235954 | Kurupati | Aug 2017 | A1 |
20170237766 | Mattson | Aug 2017 | A1 |
20170257383 | Ficarra | Sep 2017 | A1 |
20170257385 | Overson | Sep 2017 | A1 |
20170293748 | Kurupati | Oct 2017 | A1 |
20180205747 | Ficarra | Jul 2018 | A1 |
20180255154 | Li | Sep 2018 | A1 |
20190081977 | Yang | Mar 2019 | A1 |
20190141064 | Call | May 2019 | A1 |
20190182251 | Jampani | Jun 2019 | A1 |
20190215304 | Yang | Jul 2019 | A1 |
20190245858 | Idika | Aug 2019 | A1 |
20190268359 | Zhang | Aug 2019 | A1 |
20190327265 | Zhao | Oct 2019 | A1 |
20190364019 | Yang | Nov 2019 | A1 |
20190373012 | Mattson | Dec 2019 | A1 |
20190394228 | Yang | Dec 2019 | A1 |
Number | Date | Country |
---|---|---|
101471818 | May 2011 | CN |
WO2008095018 | Aug 2008 | WO |
WO2008095031 | Aug 2008 | WO |
WO2008130946 | Oct 2008 | WO |
WO 2017007705 | Jan 2017 | WO |
WO 2017007936 | Jan 2017 | WO |
WO 2017074622 | May 2017 | WO |
Entry |
---|
NOA, mailed on Feb. 7, 2019, re: Siying Yang, U.S. Appl. No. 16/190,015, filed Nov. 13, 2018. |
CTNF, mailed on Mar. 9, 2017, re: Siying Yang, U.S. Appl. No. 14/925,547, filed Oct. 28, 2015. |
NOA, mailed on Apr. 23, 2015, re: Justin Call, U.S. Appl. No. 13/527,025, filed Jun. 19, 2012. |
CTFR, mailed on Feb. 10, 2015, re: Justin Call, U.S. Appl. No. 13/527,025, filed Jun. 19, 2012. |
CTNF, mailed on Nov. 2, 2012, re: Justin Call, U.S. Appl. No. 13/527,025, filed Jun. 19, 2012. |
CTFR, mailed on Apr. 23, 2013, re: Justin Call, U.S. Appl. No. 13/527,025, filed Jun. 19, 2012. |
CTNF. mailed on Aug. 4, 2014, re: Justin Call, U.S. Appl. No. 13/527,025, filed Jun. 19, 2012. |
NOA, mailed on Jun. 1, 2015, re: Justin Call, U.S. Appl. No. 13/527,025, filed Jun. 19, 2012. |
CTNF, mailed on Feb. 26, 2015, re: Justin Call, U.S. Appl. No. 14/055,576, filed Oct. 16, 2013. |
NOA, mailed on Aug. 21, 2015, re: Justin Call, U.S. Appl. No. 14/055,576, filed Oct. 16, 2013. |
CTNF, mailed on May 20, 2015, re: Justin Call, U.S. Appl. No. 14/110,659, filed Oct. 8, 2013. |
NOA, mailed on Aug. 19, 2015, re: Daniel Moen, U.S. Appl. No. 14/160,107, filed Jan. 21, 2014. |
CTNF, mailed on Jun. 27, 2014, re: Justin Call, U.S. Appl. No. 14/255,248, filed Apr. 17, 2014. |
NOA, mailed on Nov. 19, 2014, re: Justin Call, U.S. Appl. No. 14/255,248, filed Apr. 17, 2014. |
NOA mailed on Dec. 24, 2014, re: Justin Call, U.S. Appl. No. 14/255,248, filed Apr. 17, 2014. |
CTNF, mailed on Sep. 1, 2015, re: Ariya Hidayt, U.S. Appl. No. 14/293,895, filed Jun. 2, 2014. |
NOA mailed on Mar. 30, 2016, re: Ariya Hidayat, U.S. Appl. No. 14/293,895, filed Jun. 2, 2014. |
NOA, mailed on Jul. 21, 2016, re: Siying Yang, U.S. Appl. No. 14/541,062, filed Nov. 13, 2014. |
CTNF, mailed on Feb. 23, 2016, re: Siying Yang, U.S. Appl. No. 14/541,062, filed Nov. 13, 2014. |
CTNF, mailed on May 8, 2015, re: Timothy Peacock, U.S. App. No. 14/570,632, filed Dec. 15, 2014. |
NOA, mailed on Dec. 18, 2015, re: Timothy Peacock, U.S. Appl. No. 14/570,632, filed Dec. 15, 2014. |
CTNF, mailed on on Mar. 17, 2016, re: Justin Call, U.S. Appl. No. 14/672,879, filed Mar. 30, 2015. |
CTNF, mailed on Nov. 10, 2016, re: Nwokedi Idika, U.S. Appl. No. 14/728,621, filed Jun. 2, 2015. |
CTNF, mailed on Mar. 14, 2016, re: Justin Call, U.S. Appl. No. 14/874,717, filed Oct. 5, 2015. |
NOA, mailed on Apr. 28, 2016, re: Justin Call, U.S. Appl. No. 14/874,717, filed Oct. 5, 2015. |
NOA, mailed on Nov. 16, 2016, re: Justin Call, U.S. Appl. No. 14/980,409, filed Dec. 28, 2015. |
CTNF, mailed on Aug. 2, 2016, re: Justin Call, U.S. Appl. No. 14/980,409, filed Dec. 28, 2015. |
CTFR, mailed on Nov. 18, 2016, re: Justin D. Call, U.S. Appl. No. 14/672,879, filed Mar. 30, 2015. |
CTNF, mailed on Jun. 1, 2017, re: Siying Yang, U.S. Appl. No. 14/942,769, filed Nov. 16, 2015. |
CTNF, mailed on Jun. 2, 2017, re: Ariyna Hidayat, U.S. Appl. No. 15/224,978, filed Aug. 1, 2016. |
CTNF, mailed on Apr. 7, 2017, re: Yao Zhao, U.S. Appl. No. 14/861,906, filed Sep. 22, 2015. |
CTNF, mailed on May 25, 2017, re: Daniel G. Moen, U.S. Appl. No. 14/980,231, filed Dec. 28, 2015. |
CTNF, mailed on Jul. 26, 2017, re: Bei Zhang, U.S. Appl. No. 14/859,084, filed Sep. 18, 2015. |
CTNF, mailed on Jun. 21, 2017, re: Zhiwei Li, U.S. Appl. No. 14/718,736, filed May 21, 2015. |
CTNF, mailed on Aug. 30, 2017, re: Justin D. Call, U.S. Appl. No. 15/470,715, filed Mar. 27, 2017. |
CTFR, mailed on Sep. 5, 2017, re: Siying Yang, U.S. Appl. No. 14/925,547, filed Oct. 28, 2015. |
CTNF, mailed on Oct. 19, 2017, re: Jarrod S. Overson, U.S. Appl. No. 15/059,080, filed Mar. 2, 2016. |
NOA, mailed on Oct. 25, 2017, re: Michael J. Ficarra, U.S. Appl. No. 15/060,322, filed Mar. 3, 2016. |
CTNF, mailed on Nov. 13, 2017, re: Nwokedi Idika, U.S. Appl. No. 14/728,596, filed Jun. 2, 2015. |
CTNF, mailed on Dec. 13, 2017, re: Justin D. Call, U.S. Appl. No. 15/645,787, filed Jul. 10, 2017. |
NOA, mailed on Dec. 18, 2017, re: Yao Zhao, U.S. Appl. No. 14/861,906, filed Sep. 22, 2015. |
NOA, mailed on Jan. 5, 2018, re: Yao Zhao, U.S. Appl. No. 14/861,906, filed Sep. 22, 2015. |
NOA, mailed on Jan. 9, 2018, re: Justin D. Call, U.S. Appl. No. 15/470,715, filed Mar. 27, 2017. |
CTFR, mailed on Jan. 25, 2018, re: Siying Yang, U.S. Appl. No. 15/942,769, filed Nov. 16, 2015. |
CTNF, mailed on Feb. 7, 2017, re: Daniel G. Moen, U.S. Appl. No. 14/980,231, filed Dec. 28, 2015. |
CTFR, mailed on Jan. 10, 2018, re: Bei Zhang, U.S. Appl. No. 14/859,084, filed Sep. 18, 2015. |
NOA, mailed on Jan. 25, 2018, re: Zhiwei Li, U.S. Appl. No. 14/718,736, filed May 21, 2015. |
CTNF, mailed on Mar. 30, 2018, re: Michael J. Ficarra, U.S. Appl. No. 15/060,380, filed Mar. 3, 2016. |
CTNF, mailed on Apr. 19, 2018, re: Michael J. Ficarra, U.S. Appl. No. 15/919,034, filed Mar. 12, 2018. |
CTNF, mailed on May 15, 2018, re: Marc R. Hansen, U.S. Appl. No. 15/202,755, filed Jul. 6, 2016. |
CTFR, mailed on May 10, 2018, re: Nwokedi Idika, U.S. Appl. No. 14/728,596, filed Jun. 2, 2015. |
CTNF, mailed on Feb. 16, 2018, re: Siying Yang, U.S. Appl. No. 15/068,468, filed Mar. 11, 1016. |
NOA, mailed on May 18, 2018, re: Siying Yang, U.S. Appl. No. 14/942,769, filed Nov. 16, 2015. |
CTNF, mailed on May 23, 2018, re: Bei Zhang, U.S. Appl. No. 14/859,084, filed Sep. 18, 2015. |
CTFR, mailed on May 17, 2018, re: Jarrod S. Overson, U.S. Appl. No. 15/059,080, filed Mar. 2, 2016. |
CTNF, mailed on Jun. 7, 2018, re: Siying Yang, U.S. Appl. No. 14/925,547, filed Oct. 28, 2015. |
CTNF, mailed on Jun. 29, 2018, re: Timothy Dylan Peacock, U.S. Appl. No. 15/137,824, filed Apr. 25, 2016. |
CTNF, mailed on Feb. 1, 2018, re: Nwokedi Idika, U.S. Appl. No. 15/204,710, filed Jul. 7, 2016. |
NOA, mailed on Aug. 13, 208, re: Daniel G. Moen, U.S. Appl. No. 14/980,231, filed Dec. 28, 2015. |
NOA, mailed on Sep. 5, 2018, re: Daniel G. Moen, U.S. Appl. No. 14/980,231, filed Dec. 28, 2015. |
NOA, mailed on Sep. 17, 2018, re: Siying Yang, U.S. Appl. No. 14/942,769, filed Nov. 16, 2015. |
NOA, mailed on Sep. 5, 2018, re: Michael J. Ficarra, U.S. Appl. No. 15/919,034, filed Mar. 12, 2018. |
NOA, mailed on Jul. 5, 2018, re: Siying Yang, U.S. Appl. No. 15/068,468, filed Mar. 11, 2016. |
NOA, mailed on Sep. 19, 2018, re: Nwokedi Idika, U.S. Appl. No. 15/204,710, filed Jul. 7, 2016. |
CTNF, mailed on Sep. 19, 2018, re: Eli Mattson, U.S. Appl. No. 15/430,224, filed Feb. 10, 2017. |
CTFR, mailed on Sep. 11, 2018, re: Michael J. Ficarra, U.S. Appl. No. 15/060,380. filed Mar. 3, 2016. |
CTFR, mailed on Nov. 1, 2018, re: Marc R. Hansen, U.S. Appl. No. 15/202,755, filed Jul, 6, 2016. |
CTFR, mailed on Nov. 30, 2018, re: Siying Yang, U.S. Appl. No. 14/925,547, filed Oct. 28, 2015. |
NOA, mailed on Nov. 27, 2018, re: Nwokedi Idika, U.S. Appl. No. 15/204,710, filed Jul. 7, 2016. |
CTNF, mailed on Oct. 5, 2018, re: Zhiwei Li, U.S. Appl. No. 15/968,573, filed May 1, 2018. |
NOA, mailed on Sep. 12, 2018, re: Justin D. Call, U.S. Appl. No. 15/645,787, filed Jul. 10, 2017. |
CTNF, mailed on Nov. 29, 2018, re: Jarrod S. Overson U.S. Appl. No. 15/059,080, filed Mar. 2, 2016. |
NOA, mailed on Jan. 3, 2019, re: Bei Zhang, U.S. Appl. No. 14/859,084, filed Sep. 18, 2015. |
CTNF, mailed on Jan. 24, 2019, re: Nwokedi Idika, U.S. Appl. No. 14/728,596, filed Jun. 2, 2015. |
NOA, mailed on Feb. 6, 2019, re: Eli Mattson, U.S. Appl. No. 15/430,224, filed Feb. 10, 2017. |
NOA, mailed on Mar. 25, 2019, re: Siying Yang, U.S. Appl. No. 14/925,547, filed Oct. 28, 2015. |
CTFR, mailed on Apr. 15, 2019, re: Jarrod S. Overson, U.S. Appl. No. 15/059,080, filed Mar. 2, 2016. |
NOA, mailed on Mar. 11, 2019, re: Zhiwei Li, U.S. Appl. No. 15/968,573, filed May 1, 2018. |
CTNF, mailed on May 15, 2019, re: Michael J. Ficarra, U.S. Appl. No. 15/060,380, filed Mar. 3, 2016. |
NOA, mailed on Jun. 3, 2019, re: Siying Yang, U.S. Appl. No. 16/190,015, filed Nov. 13, 2018. |
CTFR, mailed on Jul. 1, 2019, re: Nwokedi Idika, U.S. Appl. No. 14//728,596, filed Jun. 2, 2015. |
CTNF, mailed on Sep. 4, 2019, re: Timothy Dylan Peacock, U.S. Appl. No. 15/137,824, filed Apr. 25, 2016. |
CTNF, mailed on Aug. 14, 2019, re: Nwokedi Idika, U.S. Appl. No. 16/236,520, filed Dec. 30, 2018. |
CTNF, mailed on Sep. 4, 2019, re: Justin D. Call, U.S. Appl. No. 16/234,848, filed Dec. 28, 2018. |
CTNF, mailed on Sep. 4, 2019, re: Bei Zhang, U.S. Appl. No. 16/413,451, filed May 15, 2019. |
NOA, mailed on Oct. 3, 2019, re: Marc R. Hansen, U.S. Appl. No. 15/202,755, filed Jul. 6, 2016. |
CTNF, mailed on Sep. 24, 2019, re: Ganesh Jampani, U.S. Appl. No. 16/259,890, filed Jan. 28, 2019. |
NOA, mailed on Oct. 17, 2019, re: Michael J. Ficarra, U.S. Appl. No. 15/060,380, filed Mar. 3, 2016. |
NOA, mailed on Dec. 3, 2019, re: Nwokedi Idika, U.S. Appl. No. 16/236,520, filed Dec. 30, 2018. |
CTNF, mailed on Dec. 11, 2019, re: Siying Yang, U.S. Appl. No. 16/236,519, filed Dec. 30, 2018. |
NOA, mailed on Dec. 11, 2019, re: Jarrod S. Overson, U.S. Appl. No. 15/059,080, filed Mar. 2, 2016. |
U.S. Appl. No. 16/190,015, filed Mar. 14, 2019, inventor Yang. |
U.S. Appl. No. 16/457,589, filed Oct. 24, 2019, inventor Li. |
Detection and Analysis of Drive-by-Download Attacks and Malicious JavaScript Code, Apr. 26, 2010. |
Defending Browsers against Drive-by Downloads: Mitigating Heap-spraying Code Injection Attacks, Jul. 9, 2009. |
Intrusion Detection using Sequences of System calls, Aug. 18, 1998. |
Recent Java exploitation trends and malware, Jul. 26, 2012. |
DoDOM: Leveraging DOM Invariants for Web 2.0 Application Robustness Testing, Nov. 1, 2010. |
Cujo: Efficient Detection and Prevention of Drive-by-Download Attacks, Dec. 6, 2010. |
Design and Implementation of a Distributed Virtual Machine for Networked Computers, 1999. |
International Search Report, dated Sep. 22, 2016, PCT/US16/40645. |
International Search Report, dated Feb. 16, 2017, PCT/US16/53472. |
International Search Report, dated Oct. 11, 2016, PCT/US16/41337. |
International Search Report, dated Jul. 1, 2016, PCT/US16/25092. |
International Search Report, dated Aug. 1, 2014, PCT/US14/24232. |
International Search Report, dated Jun. 3, 2013, PCT/US13/26516. |
DuPaul, Neil, “Common Malware Types: Cybersecurity 101”, Veracode, Oct. 12, 2012, 9 pages, Oct. 12, 2012. |
Friendly Bit, “Rendering a web page—step by step”, published Jan. 11, 2010, pp. 1-2, Jan. 11, 2010. |
“Custom Elements: defining new elements in HTML”, Dec. 8, 2013, 15 pages, Dec. 8, 2013. |
Number | Date | Country | |
---|---|---|---|
20190215304 A1 | Jul 2019 | US |
Number | Date | Country | |
---|---|---|---|
Parent | 14942769 | Nov 2015 | US |
Child | 16236519 | US |