Patent ID: 12192230

DETAILED DESCRIPTION

The following description and associated figures teach the best mode of the invention. For the purpose of teaching inventive principles, some conventional aspects of the best mode may be simplified or omitted. The following claims specify the scope of the invention. Note that some aspects of the best mode may not fall within the scope of the invention as specified by the claims. Thus, those skilled in the art will appreciate variations from the best mode that fall within the scope of the invention. Those skilled in the art will appreciate that the features described below can be combined in various ways to form multiple variations of the invention. As a result, the invention is not limited to the specific examples described below, but only by the claims and their equivalents.

Digital skimming attacks, also known as Magecart attacks, JavaScript sniffing, and web skimming, are an increasing problem for website owners and the security of private user information. Digital skimming attacks are typically carried out by attackers installing their own malicious JavaScript code on web sites, either by directly embedding the code on a website itself or indirectly through third-party service providers that the site depends on. The undetected malicious code then functions to skim user account credentials, credit card information, and other sensitive data while users are interacting with the website.

As a website owner, it is very difficult to control the development and security of third-party tools and services. Further, because third-party JavaScript code and third-party browser extensions get loaded by client browsers at runtime, the website owner has little to no transparency into what is actually being added or downloaded at the individual browser level from third-party application servers. To help combat code injection attacks and cross-site scripting, modern web browsers support content security policy (CSP), which enables website administrators to specify the domains that the browser can trust as valid sources of executable scripts and other code. Subresource integrity (SRI) is a similar security mechanism that is often utilized in conjunction with CSP to protect website integrity. By specifying what resources a website depends on along with their approved origins and security hashes, SRI can be used to validate web assets provided by third parties, such as content delivery networks (CDNs) and other third-party services. To enable CSP, a website administrator needs to configure the web server to return the Content-Security-Policy hypertext transfer protocol (HTTP) header and provide values to specify resources the browser is allowed to load. However, because creating and maintaining these policies is a very laborious and manual process, it can be difficult and burdensome for website developers and administrators to implement CSP and SRI and keep up to date with changes on the site and changes made by third-party service providers.

The techniques disclosed herein provide for the protection of web applications from digital skimming attacks by automatically determining dependencies of the web service and then analyzing the reputation of the domains with which the dependencies communicate. By utilizing browser automation and a novel browser extension, the domain reputation analysis system described herein operates by passively scanning web applications using a scalable system of crawlers to obtain information about first-party internal web assets and third-party external web assets along with the domains to which these assets call or send data outbound from pages belonging to the web service. This domain information may then be processed with a threat intelligence database and utilize graph analysis to determine domain reputation data. Specifically, the dependency and domain data that is acquired by passively crawling the website may be analyzed against a database of information designed to alert if a particular domain being called is potentially suspicious or known to be malicious. In at least one implementation, this analysis may comprise scoring the reputation of the name server used by the domain, the specific IP address hosting the domain, the “neighborhood” of IP addresses belonging to the hosting provider, and whois registration information about the domain itself. In some implementations, elements of these scores may comprise the past presence and behavior of the IP addresses and other hosting infrastructure in the threat intelligence database, which may contain information related to other application security threats that were observed previously. In addition, the analysis may also include scoring on the reliability of the domains hosting the assets, derived from known patterns in whois information like the age of the domain, the registrar and registrant information, and their connection to either legitimate businesses or known malicious infrastructure. Finally, the analysis may take into account the relationship between web assets in the graph, where assets that are highly trusted and reputable tend to have different relationship patterns than assets that may be suspicious or designed to mimic another service to execute a digital skimming attack. In at least one implementation, the outcome of this automated analysis may comprise assigning individual domain reputation scores for all domains in the graph based on the various attributes described above. Further, in some implementations, content security policies could be dynamically created periodically from the domain reputation scores and graph data analysis, which may then be deployed via CDNs and application integration to protect the web service.

These techniques provide an advantage by enabling website administrators to detect digital skimming attacks without any active page modification or changes to CDNs or application servers. The system affords website owners with visibility into third-party dependencies and the domains that may receive outbound data to help bring awareness to the JavaScript code and other web assets that are being rendered on their site at the client browser level. Further, with the knowledge that these techniques provide about the reputation of the domains that assets on the website communicate with, the website operators can engage in reporting and enforcement of policies designed to protect their site from digital skimming attacks.

Referring now to the drawings,FIG.1illustrates a communication system that describes the design and flow of a domain reputation analysis system in an exemplary implementation.FIG.2illustrates another communication system that may be used to analyze domain reputations and help detect digital skimming attacks on a web service in an exemplary embodiment.FIG.3illustrates a flow diagram of an exemplary operation to facilitate domain reputation analysis and prevention of malicious digital skimming attacks on a web service.FIG.4illustrates another communication system that may be used to analyze domain reputations and help detect digital skimming attacks on a web service in an exemplary embodiment.FIG.5illustrates a sequence diagram of an exemplary operation to analyze domain reputations and prevent malicious digital skimming attacks on a website.FIG.6illustrates an exemplary computing system that may be used to perform any of the domain reputation analysis processes and operational scenarios described herein. One possible design and operational flow of a domain reputation analysis system will now be described in detail with respect toFIG.1.

Turning now toFIG.1, communication system100illustrates an exemplary design and operational flow of a domain reputation analysis system in an exemplary implementation. Communication system100provides an example of a system that may be used to implement a domain reputation analysis process to facilitate domain reputation analysis and prevention of malicious attacks on a web service as described herein. Communication system100provides an example of one possible implementation of a domain reputation analysis architecture that may be employed to implement a domain reputation analysis process as described herein, but note that other implementations could employ different architectures with additional and/or alternative components, services, and systems. The techniques described below with respect toFIG.1could be combined with operation300ofFIG.3in some implementations.

In this example, the website and uniform resource locators (URLs) to crawl are added to a crawler queue. The URLs can either be manually submitted to the queue or could be automated to periodically re-crawl existing URLs, such as on a daily basis. In this example, the crawler queue is implemented using Amazon® Simple Queue Service (SQS), but any suitable message queuing service could also be used, such as Microsoft® Azure™ Service Bus, Kafka, Redis, ActiveMQ, RabbitMQ, and others. When setting up automated URL crawling, a time-based job scheduler such as cron jobs could be created to wake up periodically to re-crawl existing URLs. In this example, the cron jobs for the automated URL crawling could be created using Amazon® Elastic Kubernetes Service (EKS), but any suitable Kubernetes service could also be used, such as Microsoft® Azure™ Kubernetes Service, Google® Kubernetes Engine, Kubernetes Operations (kops), open-source Kubernetes (K8s), Rancher, and others.

Once the web site and specified URLs are loaded into the crawler queue, the website and URLs are crawled to obtain information about third-party external JavaScript assets, as well as first-party internal JavaScript assets, and the domains to which these scripts call or send data outbound from pages belonging to the web service being protected. In particular, each URL gets picked up by one of the auto-scalable crawlers using headless browser automation with a specialized security scanner browser extension that intercepts and injects a CSP header into the responses to collect CSP and SRI information. The automated browsers load each page and using their built-in CSP report-only mechanism (i.e., HTTP Content-Security-Policy-Report-Only response header), the browsers report all internal and external dependencies and associated domain information. In some implementations, the internal and external dependencies and associated domain information may be reported by the automated browsers to a CSP application programming interface (API) gateway. In such implementations, the CSP API gateway may invoke an event-driven serverless compute platform with all the submitted information in a CSP report, and the compute platform could responsively write the raw data to a cloud storage service, independently-operated database system, or any other storage system for long-term storage, including combinations thereof.

In this example, the dependency and domain information is received by a computing system for processing, which could comprise an independently-operated computing system or a cloud-based computing service in some examples. The computing system is in communication with a threat intelligence database that comprises historical attack information related to other application security threats that were previously observed. The threat intelligence database may be updated periodically with newly-detected attacks and other security threats to develop the database over time.

Upon receipt of the dependency and domain information, the computing system may then process this information with the threat intelligence database and employ graph analysis to determine domain reputation scores for the identified domains. In particular, the dependency and domain data may be analyzed by the computing system against the threat intelligence database to determine if a particular domain being called is potentially suspicious or known to be malicious. In at least one implementation, the computing system may perform this analysis and generate domain reputation scores by scoring the reputation of the name server used by the domain, the specific IP address hosting the domain, the “neighborhood” of IP addresses belonging to the hosting provider, such as all IP addresses in a classless inter-domain routing (CIDR) range, and whois registration information about the domain itself, among other information. In some implementations, the domain reputation scores may be based on both publically-available information and internal reputation monitoring and scoring algorithms. For example, the domain reputation scores could be based on any information about known attacks associated with any of the domains, scripts, or other web assets identified in the dependency information, along with domain registration information, domain name servers, IP addresses of the domains, length of time that a domain has been registered, the expiration date of the domain registration, the identity of the registrar and registrant, other domains that the registrant has registered before and whether any of those sites were associated with security risks or malicious or suspicious activity, and any other relevant data. This information could then be processed through an internal threat intelligence database that identifies particular name servers, IP addresses, and hosting providers that have been associated with suspicious activity or malicious attacks in the past in order to determine the domain reputation scores for the domains that are associated with the web service.

In some implementations, the threat intelligence database could comprise hosting provider reputation data, IP address reputation data, and name server reputation data. The hosting provider reputation data could include scoring on the reliability of the hosting provider, which may be derived from known patterns in publically-available whois domain registration information, such as the registrar and registrant information and the age of the domain, where older and more established domains are less of a security risk than newly-registered domains. In some implementations, the hosting provider reputation score could also account for the activity of the IP addresses in the “neighborhood” of a given IP address belonging to the hosting provider, such as analyzing all IP addresses in a CIDR range. Regarding the IP address reputation data, an IP address score may be determined by a combination of the past activity associated with an IP address based on the threat intelligence database along with an analysis of other domains hosted on that IP address. Finally, regarding the name server reputation, there are distinctive patterns that positively differentiate legitimate name servers that host websites of legitimate companies versus name servers that host potentially malicious domains, so an analysis of the domains hosted on a name server can provide an indication about the reliability of the name server. In some implementations, elements of these reputation scores may comprise the historical presence and behavior of the name servers, IP addresses, and other hosting infrastructure that is tracked in the threat intelligence database, along with the reliability of the domains hosting the assets, which may be derived from known patterns in whois information like the age of the domain, the registrar and registrant information, and their connection to either legitimate businesses or known malicious infrastructure.

In at least one implementation, the threat intelligence database could include a list of name servers, IP addresses, and hosting platforms that are commonly used to host malware or command-and-control servers controlled by attackers, and such servers are also often used to host other illegitimate activities such as media pirating, online gambling, and illegal file sharing. Further, in some implementations, the ratio of the number of unique domains to number of unique companies or entities could be calculated for a particular hosting platform, IP address, or name server to determine a security risk factor associated with that host or server. For example, a name server or IP address associated with a hosting infrastructure that tends to be exploited by malicious users will have a ratio of the number of unique domains to number of unique companies closer to 1:1, where every domain belongs to a different company or entity. However, because legitimate websites tend to register many different variations of their top-level domain (TLD) using the same hosting platform and name server, a more legitimate provider will have a ratio that is lower than 1:1, such as 2:1 or even 3:1, for example.

Each of the above factors and considerations could be scored individually and then compiled together to form an overall domain reputation score for each of the domains that are associated with the web service. In some implementations, the reputational scoring process discussed above could comprise graph analysis that takes into account the relationship between web assets in the graph, where assets that are highly trusted and reputable tend to have different relationship patterns than assets that may be suspicious or designed to mimic another service to execute a digital skimming attack. In at least one implementation, the outcome of this automated analysis may comprise assigning individual domain reputation scores for all domains in the graph based on the various attributes described above.

In at least one implementation, content security policies may then be dynamically created periodically from the domain reputation scores and graph data analysis, which may then be deployed via CDNs and application integration to protect the web service. For example, in some implementations, the domain reputation scores may be used along with script reputation data to enrich the information about the internal and external web assets associated with the web service to generate enriched dependency graph data. In at least one implementation, data enrichment drivers may enrich the raw data from the CSP report with the domain reputation scores and script reputation data and persist the reputation-enriched data in graph format to a graph database. Security policies may then be automatically generated periodically from graph data analysis. In some examples, the policies generated could comprise CSP policy directives, SRI integrity hash values, approved origins, trusted domains, and any other information that may be used for CSP and SRI policy deployment. In at least one implementation, such policies could be created manually through a dashboard as well.

In some implementations, once the security policies are dynamically generated, the policies may be deployed to help protect the web application. For example, in at least one implementation, a CSP policy deployment mechanism may provide integration with the web server and different CDNs to push or pull the periodically-generated or updated policies to protect the web application without actively modifying web pages or application servers. Without employing the above techniques, CSP policies often require manual creation and updating, which results in policies remaining static and outdated for long periods of time, rendering them largely ineffective. Beneficially, the domain reputation analysis techniques disclosed herein along with dynamic policy creation and deployment help to prevent digital skimming attacks proactively, without requiring any changes to the web application, servers, or CDNs. By providing greater visibility into the reputation of domains associated with third-party web assets, along with integration with CDNs and security solutions without actively modifying web applications, digital skimming attacks that often originate through third-party JavaScript code and other web assets are more rapidly identified and prevented. Another communication system that may be used to analyze domain reputations and help prevent digital skimming attacks on a web service will now be described with respect toFIG.2.

FIG.2illustrates communication system200which may be used to analyze domain reputations and detect digital skimming attacks on a web service in an exemplary implementation. Communication system200provides an example of a system that may be used to implement a domain reputation analysis process to facilitate domain reputation analysis and prevention of malicious attacks on a web service as described herein. Communication system200provides an example of one possible implementation of a domain reputation analysis architecture that may be employed to implement a domain reputation analysis process as described herein, but note that other implementations could employ different architectures with additional and/or alternative components, services, and systems. In this example, communication system200includes client computing system201, communication network220, web server230, cloud services235, computing system236, threat intelligence database237, content delivery networks (CDNs)240, and third-party service providers250. An operation that may be employed to facilitate domain reputation analysis and prevention of malicious attacks on a web service will now be described with respect toFIG.3.

FIG.3is a flow diagram that illustrates an operation300in an exemplary implementation. The operation300shown inFIG.3may also be referred to as domain reputation analysis process300herein. The steps of the operation are indicated below parenthetically. The following discussion of operation300may proceed with reference to elements ofFIG.2in order to illustrate its operations, but note that the details provided inFIG.2are merely exemplary and not intended to limit the scope of process300to the specific implementation shown inFIG.2. Operation300may also be combined with the techniques described above with respect toFIG.1in some implementations.

Operation300may be employed to facilitate domain reputation analysis and prevention of malicious attacks on a web service. As shown in the operational flow of process300, computing system236crawls web resources associated with the web service to obtain information about internal and external web assets associated with the web service (301). In at least one implementation, the web resources associated with the web service could be crawled by passively scanning a website provided by the web service and any associated uniform resource identifiers (URIs) using a scalable system of crawlers. The crawlers may be implemented on an independent server computing system or supplied by a cloud service provider in some implementations. The information obtained about the internal and external web assets associated with the web service could comprise information about JavaScript assets, cascading style sheets (CSS), HTML, frames and other code, fonts, images, audio and video files, embeddable objects such as Java™ applets, and the domains to which these scripts and other web assets communicate with or send data outbound from pages belonging to the web service. In some examples, the internal web assets could comprise any internal first-party web assets that are included by the web service owner directly, and the external web assets could comprise any external third-party web assets that are indirectly included and managed by external third-party service providers.

Computing system236processes the information about the internal and external web assets to identify domains with which the internal and external web assets communicate (302). For example, in some implementations, computing system236could process the information obtained about the internal and external web assets to determine the domains to which these scripts and other assets communicate or send data outbound from web pages associated with the web service being protected. In at least one implementation, in order to process the information about the internal and external web assets to identify the domains with which the internal and external web assets communicate, computing system236could intercept responses from the internal and external web assets and dynamically inject content security policy headers into the responses to determine dependency data associated with the internal and external web assets to identify the domains with which the internal and external web assets communicate. In some implementations, to intercept the responses from the internal and external web assets and dynamically inject the content security policy headers into the responses, computing system236could utilize browser automation with a browser extension to intercept the responses from the internal and external web assets and dynamically inject the content security policy headers into the responses to determine all dependencies and the domains associated with the internal and external web assets. For example, in at least one implementation, computing system236could intercept the responses from the internal and external web assets using headless browser automation with a specialized security scanner browser extension that intercepts and injects a CSP header into the responses received from the internal and external web assets associated with the web service to collect dependency data and identify the domains associated with the internal and external web assets. The browser automation and CSP header injection may be implemented on an independent server computing system or supplied by a cloud service provider in some implementations. In at least one implementation, after the responses are injected with the CSP header, the browser automation may load each page and use a built-in CSP report-only mechanism (i.e., HTTP Content-Security-Policy-Report-Only response header) to determine and report all dependencies and the domains associated with the internal and external web assets. For example, computing system236could utilize the browser automation with the browser extension to intercept the responses from the internal and external web assets and dynamically inject content security policy report-only response headers into the responses to determine dependency data associated with the internal and external web assets to identify the domains.

Computing system236analyzes the domains to determine name server reputation, IP address reputation, and hosting provider reputation associated with the domains (303). In at least one implementation, computing system236may analyze the domains against threat intelligence database237to determine if a particular domain is potentially suspicious or known to be malicious. For example, in some implementations, analyzing the domains to determine the name server reputation, the IP address reputation, and the hosting provider reputation associated with the domains could comprise analyzing domain registration information associated with the domains to determine the name server reputation, the IP address reputation, and the hosting provider reputation associated with the domains. In at least one implementation, this analysis could comprise scoring the reputation of the name server used by the domain, the reputation of the IP address that hosts the domain, and the reputation of the hosting provider associated with the domain. In some implementations, elements of these reputation scores may comprise the historical presence and behavior of the name servers, IP addresses, and other hosting infrastructure that is tracked in threat intelligence database237, along with the reliability of the domains hosting the assets, which may be derived from known patterns in whois domain registration information like the age of the domain, the registrar and registrant information, and their connection to either legitimate businesses or known malicious infrastructure.

In some implementations, in order to determine the name server reputation, IP address reputation, and hosting provider reputation associated with the domains, computing system236may first analyze the domains to identify all of the name servers, IP addresses, and hosting providers associated with the domains. Once these elements are known, computing system236may analyze the name servers, IP addresses, and hosting providers associated with the domains against threat intelligence database237to determine the name server reputation, IP address reputation, and hosting provider reputation associated with the domains. In this example, threat intelligence database237could comprise information that identifies particular name servers, IP addresses, and hosting providers that have been associated with suspicious activity or malicious attacks in the past, along with other security data. Accordingly, in at least one implementation, analyzing the domains to determine the name server reputation, the IP address reputation, and the hosting provider reputation associated with the domains could comprise analyzing whether any name servers, IP addresses, or hosting providers associated with the domains were previously associated with malicious attacks.

In some implementations, the name server reputation associated with the domains could be determined by processing the name servers associated with the domains through threat intelligence database237to conduct an analysis of the various other domains hosted on a particular name server, which can provide an indication about the reliability of the name server. For example, there are distinctive patterns that positively differentiate legitimate name servers that host websites of legitimate companies versus name servers that host potentially malicious domains. Moreover, if any domains associated with suspicious or malicious activity in the past used one of the name servers being analyzed, this factor would negatively impact the reputation score of that name server.

In at least one implementation, the IP address reputation associated with the domains could be determined by processing the IP addresses associated with the domains through threat intelligence database237to analyze the IP addresses and assign reputation scores by a combination of the past suspicious or malicious activity associated with an IP address according to threat intelligence database237along with an analysis of other domains hosted on that IP address. For example, if any domains associated with suspicious or malicious activity in the past used one of the IP addresses being analyzed, this factor would negatively impact the reputation score of that IP address.

In some implementations, the hosting provider reputation associated with the domains could be determined by processing the hosting providers associated with the domains through threat intelligence database237to analyze and score the reliability of the hosting providers. For example, computing system236could derive known patterns in the whois domain registration information such as the length of time that a domain has been registered, the expiration date of the domain registration, the identity of the registrar and registrant, other domains that the registrant has registered before and whether any of those sites were associated with security risks or malicious or suspicious activity, and any other information about the hosting provider that is publically available in the domain registration information. In at least one implementation, the hosting provider reputation associated with the domains could also account for the activity of the IP addresses in the “neighborhood” of a given IP address belonging to the hosting provider, such as analyzing all IP addresses in a CIDR range of an IP address associated with the hosting provider undergoing analysis. Further, if any domains associated with suspicious or malicious activity in the past used one of the hosting providers being analyzed, this factor would negatively impact the reputation score of that hosting provider.

In at least one implementation, threat intelligence database237could include a list of name servers, IP addresses, and hosting providers that are commonly used to host malware or command-and-control servers controlled by attackers, and such servers are also often used to host other illegitimate activities such as media pirating, online gambling, and illegal file sharing. Therefore, any association with hosting these other illegitimate activities would negatively impact the reputation score of a given name server, IP address, and/or hosting provider. Accordingly, in at least one implementation, analyzing the domains to determine the name server reputation, the IP address reputation, and the hosting provider reputation associated with the domains could comprise analyzing whether any name servers, IP addresses, or hosting providers associated with the domains were previously involved in hosting illegitimate activities. Further, in some implementations, the ratio of the number of unique domains to number of unique companies or entities could be calculated for a particular hosting provider, IP address, and/or name server to determine a security risk factor associated with that host or server. For example, a name server or IP address associated with a hosting infrastructure that tends to be exploited by malicious users will have a ratio of the number of unique domains to number of unique companies closer to 1:1, where every domain belongs to a different company or entity. However, because legitimate websites tend to register many different variations of their top-level domain (TLD) using the same hosting provider, IP address, and name server, a more legitimate provider will have a ratio that is lower than 1:1, such as 2:1 or even 3:1, for example. Any of the above factors could be utilized by computing system236to analyze the domains to determine name server reputation, IP address reputation, and hosting provider reputation associated with the domains. Further, additional factors and considerations may be used to analyze the domains to determine name server reputation, IP address reputation, and hosting provider reputation associated with the domains and are within the scope of this disclosure.

Computing system236generates individual domain reputation scores for each of the domains based on the name server reputation, IP address reputation, and hosting provider reputation associated with the domains (304). For example, to generate the individual domain reputation scores for each of the domains, all of the above factors and considerations could be scored individually and then compiled together to form an overall domain reputation score for each of the domains that are associated with the web service. In at least one implementation, computing system236could process the individual name server reputation, IP address reputation, and hosting provider reputation associated with the domains by aggregating the individual reputation scores of the name server, IP address, and hosting provider for each of the domains to generate the individual domain reputation scores for each of the domains. In some implementations, the reputational scoring process discussed above could comprise graph analysis that takes into account the relationship between web assets in the graph, where assets that are highly trusted and reputable tend to have different relationship patterns than assets that may be suspicious or designed to mimic another service to execute a digital skimming attack. The outcome of this automated analysis could comprise assigning individual domain reputation scores for all domains in the graph based on the various attributes described above. For example, in at least one implementation, generating the individual domain reputation scores for each of the domains based on the name server reputation, the IP address reputation, and the hosting provider reputation associated with the domains could comprise performing graph analysis on relationships between the internal and external web assets and generating the individual domain reputation scores for each of the domains based on the graph analysis.

In some implementations, content security policies for the web service may be dynamically generated based on the individual domain reputation scores for each of the domains. For example, in at least one implementation, content security policies could be dynamically generated based on the individual domain reputation scores for any domain having a domain reputation score that exceeds a threshold reputation level indicative of a potential security risk. Further, in some implementations, the content security policies for the web service may be dynamically generated based on the individual domain reputation scores for each of the domains and graph data analysis. For example, in at least one implementation, once the individual reputation scores for each of the domains are generated, these domain reputation scores may then be used to enrich the information about the internal and external web assets associated with the web service to generate enriched dependency graph data. In some implementations, computing system236may enrich the raw data comprising the information about the internal and external web assets with the individual reputation scores for each of the domains and persist the reputation-enriched data in graph format to a graph database. Content security policies may then be automatically generated periodically from graph data analysis. For example, in at least one implementation, computing system236could analyze the enriched dependency graph data to dynamically generate content security policies for the web service. Some examples of the security policies that may be dynamically generated include CSP policy directives, SRI integrity hash values, cross-origin resource sharing (CORS) settings attributes, approved origins, trusted domains, and any other information that may be used for CSP and SRI policy deployment. In some implementations, the content security policies for the web service may be dynamically generated periodically from graph data analysis on the reputation-enriched dependency data in graph format. This periodic graph data analysis works to dynamically generate the content security policies on a regular basis, which ensures that the policies remain effective and are always kept up to date.

In at least one implementation, computing system236may also be configured to deploy the dynamically-generated security policies to protect the web service. In some implementations, content security policies may be deployed to the web server230to help protect the web service, which may be deployed periodically to help ensure the policies are kept current and regularly updated. In at least one implementation, the content security policies may also be deployed to the CDNs240as well. For example, to deploy the policies to protect the web service, computing system236may include integration with different CDNs240to push or pull the dynamically-generated and periodically-updated policies to protect the web application without actively modifying the web pages or application servers associated with the web service. In some implementations, the content security policies may be deployed via CDNs240and application integration. For example, after the content security policies are generated, the policies may be fed back to the origination point, either the CDNs240or the web server230, which can then take action to enforce the security policies by including the policies in their web pages.

Advantageously, the techniques disclosed herein provide for domain reputation analysis and scoring, which may be utilized to strongly protect web applications from digital skimming attacks without requiring any changes to the web application, servers, or CDNs. By passively scanning web applications using a scalable system of crawlers and providing visibility into third-party dependencies and information about the reputation of the domains that assets on the website communicate with, website owners are better informed of the JavaScript code and other web assets that are being rendered on a website at the client browser level. Further, by enriching the dependency data with the domain reputation scores and performing graph analysis to dynamically generate content security policies, web applications and CDNs can continuously receive updated policy information and prevent digital skimming attacks proactively by enforcing the security policies.

Turning now toFIG.4, communication system400is illustrated which may be used to analyze domain reputations and detect digital skimming attacks on a web service in an exemplary embodiment. Communication system400provides an example of a system that may be used to implement a domain reputation analysis process to facilitate domain reputation analysis and prevention of malicious attacks on a web service as described herein. Communication system400provides an example of one possible implementation of a domain reputation analysis architecture that may be employed to implement a domain reputation analysis process as described herein, but note that other implementations could employ different architectures with additional and/or alternative components, services, and systems. In this example, communication system400includes web server430, computing system440, content delivery networks, a communication network, web assets410, threat intelligence database, and web client401. An exemplary operation of communication system400will now be discussed with respect toFIG.5.

FIG.5is a sequence diagram that illustrates an operation of communication system400to analyze domain reputations to detect and prevent digital skimming attacks in an exemplary embodiment. Although the following description ofFIG.4will proceed with reference to elements of communication system300ofFIG.3in this example, the techniques described below with respect toFIG.4could also be executed by the systems of communication system200such as computing system236, and could be combined with operation300ofFIG.3in some implementations.

Initially, computing system440operates to obtain URLs of web assets410associated with the website to be protected. In this example, web assets410include both first-party web assets provided by the website owner and external web assets provided by third parties. In at least one implementation, the URLs could be provided manually by submitting the URLs to computing system440, but computing system440may also analyze the web pages of the website received from web server430in order to automatically identify URLs associated with the website in some implementations. For example, computing system440could crawl the website to get information about web assets410and the domains to which these assets call or send data outbound from pages belonging to the website being protected. In some implementations, cron jobs could also be created to automate the process of periodically re-crawling existing URLs to obtain updated information about web assets410.

In this example, computing system440intercepts responses from web assets410and dynamically injects a CSP header into each response to collect CSP and SRI information and determine dependencies of web assets410. In at least one implementation, computing system440utilizes headless browser automation with a specialized security scanner browser extension to intercept the responses from web assets410and dynamically inject the CSP headers into the responses to determine all internal and external dependencies associated with the web assets410. For example, the browser automation may load each web page and utilize a built-in CSP report-only mechanism (i.e., HTTP Content-Security-Policy-Report-Only response header) to determine and report the internal and external dependency data of web assets410.

Computing system440may then process the information about the internal and external web assets410, including the internal and external dependency data of web assets410, to identify domains with which the internal and external web assets communicate. The domains are then analyzed to generate domain reputation scores. For example, the domain information may be processed with the threat intelligence database to determine domain reputation data, which may further utilize graph analysis in some implementations. In particular, the dependency and domain data that is acquired by passively crawling the website may be analyzed against the threat intelligence database which is designed to alert if a particular domain being called is potentially suspicious or known to be malicious. In some implementations, the domain reputation data may be based on both publically-available reputation information and internal reputation monitoring and scoring algorithms. The domains associated with all web assets410, including any domains associated with all of their internal and external dependencies, are analyzed to determine the reputations of any name servers, IP addresses, and hosting providers associated with the domains. Computing system440then generates domain reputation scores for each of the domains based on the name server reputation, IP address reputation, and hosting provider reputation associated with the domains. In some implementations, elements of these scores may comprise the past presence and behavior in the threat intelligence database of the name servers, IP addresses, hosting providers, and other hosting infrastructure associated with the domains, which may contain information related to other application security threats that were observed previously. In addition, the domain analysis may also include scoring on the reliability of the domains hosting the assets, derived from known patterns in whois information like the age of the domain, the registrar and registrant information, and their connection to either legitimate businesses or known malicious infrastructure. In at least one implementation, computing system440may enrich the domain and dependency data associated with web assets410with the domain reputation scores and persist the enriched data in graph format to a graph database. In some implementations, the domain analysis may take into account the relationship between web assets in the graph, where assets that are highly trusted and reputable tend to have different relationship patterns than assets that may be suspicious or designed to mimic another service to execute a digital skimming attack. In at least one implementation, the outcome of this automated analysis may comprise assigning individual domain reputation scores for all domains in the graph based on the various attributes described above.

Continuing this example, computing system440periodically generates CSP policies based on the domain reputation scores. In at least one implementation, the CSP policies could include SRI hash values and other security policies to utilize in conjunction with the CSP policies. Some examples of the security policies that may be periodically generated include CSP directives, SRI hash values, CORS settings attributes, approved origins, trusted domains, and any other information that may be used for CSP and SRI policy deployment. In some implementations, computing system440could periodically generate the CSP policies based on the domain reputation scores by periodically generating the CSP policies based on graph data analysis of the enriched domains and dependency graph data that is enriched with the domain reputation scores. This periodic graph data analysis works to dynamically generate the CSP policies on a regular basis, which ensures that the policies remain effective and are always kept up to date.

Computing system440then deploys the CSP policies to protect the website. In this example, the CSP policies are deployed to web server430, and may be deployed periodically to help ensure the policies are kept current and regularly updated. In some implementations, the CSP policies may also be deployed to one or more content delivery networks as well. For example, to deploy the policies to protect the website, computing system440may include integration with different CDNs to push or pull the periodically-updated CSP policies to protect the website without actively modifying the web pages or application servers associated with the website.

After the CSP policy deployment, when the web client401accesses the website URLs, web client401will receive responses that include CSP directives, SRI hash values, and other information that may be used for CSP and SRI policy deployment. The web browser executing on the web client401can then verify that web assets410are valid and received from known trusted sources as determined from the CSP directives and SRI hash values. Advantageously, these domain reputation scoring techniques along with dynamic security policy creation and deployment help to prevent digital skimming attacks proactively, without actively modifying web pages or requiring any changes to the website, web server430, or CDNs. Further, by providing greater visibility into third-party dependencies of web assets410and reputation information associated with web assets410, digital skimming attacks that often originate through third-party JavaScript code and other web assets410can be more rapidly detected and prevented, thereby greatly increasing the security of the website.

Now referring back toFIG.2, communication system200includes client computing system201, communication network220, web server230, cloud services235, computing system236, threat intelligence database237, content delivery networks240, and third-party service providers250. Client computing system201and communication network220communicate over communication link211. Communication network220and content delivery networks240communicate over communication link242, while communication network220and third-party service providers250are in communication over communication link252. Communication network220and web server230are in communication over communication link221. Web server230and cloud services235communicate over communication link231, while web server230and content delivery networks240are in communication over communication link241. Web server230and third-party service providers250communicate over communication link251. Cloud services235and content delivery networks240communicate over communication link233, while cloud services235and third-party service providers250are in communication over communication link232. Threat intelligence database237and cloud services235are in communication over communication link234. In at least one implementation, computing system236may be utilized to implement a domain reputation analysis process to facilitate domain reputation analysis and prevention of malicious attacks on a web service as described herein. In this example, computing system236is shown as part of cloud services235, but computing system236could be an independently-operated server computing system implemented separately from cloud services235in some implementations. In such implementations, computing system236could be in communication directly with web server230, threat intelligence database237, content delivery networks240, and third-party service providers250over separate communication links and networks that do not include cloud services235, but such network topology is not shown inFIG.2for clarity.

Client computing system201comprises a processing system and communication transceiver. Client computing system201may also include other components such as a user interface, data storage system, and power supply. Client computing system201may reside in a single device or may be distributed across multiple devices. Examples of client computing system201include mobile computing devices, such as cell phones, tablet computers, laptop computers, notebook computers, and gaming devices, as well as any other type of mobile computing devices and any combination or variation thereof. Examples of client computing system201also include desktop computers, server computers, and virtual machines, as well as any other type of computing system, variation, or combination thereof.

Communication network220could comprise multiple network elements such as routers, gateways, telecommunication switches, servers, processing systems, or other communication equipment and systems for providing communication and data services. In some examples, communication network220could comprise wireless communication nodes, telephony switches, Internet routers, network gateways, computer systems, communication links, or some other type of communication equipment, including combinations thereof. Communication network220may also comprise optical networks, asynchronous transfer mode (ATM) networks, packet networks, local area networks (LAN), metropolitan area networks (MAN), wide area networks (WAN), or other network topologies, equipment, or systems, including combinations thereof. Communication network220may be configured to communicate over metallic, wireless, or optical links. Communication network220may be configured to use time-division multiplexing (TDM), Internet Protocol (IP), Ethernet, optical networking, wireless protocols, communication signaling, or some other communication format, including combinations thereof. In some examples, communication network220includes further access nodes and associated equipment for providing communication services to several computer systems across a large geographic region.

Web server230may be representative of any computing apparatus, system, or systems that may connect to another computing system over a communication network. Web server230comprises a processing system and communication transceiver. Web server230may also include other components such as a router, server, data storage system, and power supply. Web server230may reside in a single device or may be distributed across multiple devices. Web server230may be a discrete system or may be integrated within other systems, including other systems within communication system200. Some examples of web server230include database systems, desktop computers, server computers, cloud computing platforms, and virtual machines, as well as any other type of computing system, variation, or combination thereof. In some examples, web server230could comprise a network security appliance, firewall, reverse proxy, load balancer, intrusion prevention system, web application firewall, web server, network switch, router, switching system, packet gateway, network gateway system, Internet access node, application server, database system, service node, or some other communication system, including combinations thereof.

Cloud services235comprise any cloud computing platform that provides computing services over a communication network. Cloud services235may be representative of any computing apparatus, system, or systems that may connect to another computing system over a communication network. In this example, cloud services250comprise computing system236. Computing system236may be representative of any computing apparatus, system, or systems on which the techniques disclosed herein or variations thereof may be suitably implemented. Computing system236comprises a processing system and communication transceiver. Computing system236may also include other components such as a router, server, data storage system, and power supply. Computing system236may reside in a single device or may be distributed across multiple devices. Computing system236may be a discrete system or may be integrated within other systems, including other systems within communication system200. Some examples of computing system236include database systems, desktop computers, server computers, cloud computing platforms, and virtual machines, as well as any other type of computing system, variation, or combination thereof. In some examples, computing system236could comprise a network security appliance, firewall, reverse proxy, load balancer, intrusion prevention system, web application firewall, web server, network switch, router, switching system, packet gateway, network gateway system, Internet access node, application server, database system, service node, or some other communication system, including combinations thereof.

Threat intelligence database237may be representative of any computing apparatus, system, or systems that may connect to another computing system over a communication network. Threat intelligence database237comprises a data storage system and communication transceiver. Threat intelligence database237may also include other components such as a processing system, router, server, and power supply. Threat intelligence database237may reside in a single device or may be distributed across multiple devices. Threat intelligence database237may be a discrete system or may be integrated within other systems, including other systems within communication system200. Some examples of threat intelligence database237include database systems, desktop computers, server computers, cloud computing platforms, and virtual machines, as well as any other type of computing system, variation, or combination thereof. In some examples, threat intelligence database237could comprise a stand-alone database system, a cloud-based storage service, or any other data storage system, including combinations thereof.

Content delivery networks240may be representative of any computing apparatus, system, or systems that may connect to another computing system over a communication network. Content delivery networks240comprise a processing system and communication transceiver. Content delivery networks240may also include other components such as a router, server, data storage system, and power supply. Content delivery networks240may reside in a single device or may be distributed across multiple devices. Content delivery networks240may be a discrete system or may be integrated within other systems, including other systems within communication system200. Some examples of content delivery networks240include database systems, desktop computers, server computers, cloud computing platforms, and virtual machines, as well as any other type of computing system, variation, or combination thereof. In some examples, content delivery networks240could comprise a network security appliance, firewall, reverse proxy, load balancer, intrusion prevention system, web application firewall, web server, network switch, router, switching system, packet gateway, network gateway system, Internet access node, application server, database system, service node, or some other communication system, including combinations thereof.

Third-party service providers250may be representative of any computing apparatus, system, or systems that may connect to another computing system over a communication network. Third-party service providers250comprise a processing system and communication transceiver. Third-party service providers250may also include other components such as a router, server, data storage system, and power supply. Third-party service providers250may reside in a single device or may be distributed across multiple devices. Third-party service providers250may be a discrete system or may be integrated within other systems, including other systems within communication system200. Some examples of third-party service providers250include database systems, desktop computers, server computers, cloud computing platforms, and virtual machines, as well as any other type of computing system, variation, or combination thereof. In some examples, third-party service providers250could comprise a network security appliance, firewall, reverse proxy, load balancer, intrusion prevention system, web application firewall, web server, network switch, router, switching system, packet gateway, network gateway system, Internet access node, application server, database system, service node, or some other communication system, including combinations thereof.

Communication links211,221,231,232,233,234,241,242,251, and252use metal, air, space, optical fiber such as glass or plastic, or some other material as the transport medium, including combinations thereof. Communication links211,221,231,232,233,234,241,242,251, and252could use various communication protocols, such as TDM, IP, Ethernet, telephony, optical networking, hybrid fiber coax (HFC), communication signaling, wireless protocols, or some other communication format, including combinations thereof. Communication links211,221,231,232,233,234,241,242,251, and252could be direct links or may include intermediate networks, systems, or devices.

Referring now toFIG.6, a block diagram that illustrates computing system600in an exemplary implementation is shown. Computing system600provides an example of computing system236, computing system440, or any computing system that may be used to execute domain reputation analysis process300or variations thereof, although such systems could use alternative configurations. Computing system600includes processing system601, storage system603, software605, communication interface607, and user interface609. Software605includes application606which itself includes domain reputation analysis process300. Domain reputation analysis process300may optionally be implemented separately from application606, as indicated by the dashed line inFIG.6.

Computing system600may be representative of any computing apparatus, system, or systems on which application606and domain reputation analysis process300or variations thereof may be suitably implemented. Examples of computing system600include mobile computing devices, such as cell phones, tablet computers, laptop computers, notebook computers, and gaming devices, as well as any other type of mobile computing devices and any combination or variation thereof. Note that the features and functionality of computing system600may apply as well to desktop computers, server computers, and virtual machines, as well as any other type of computing system, variation, or combination thereof.

Computing system600includes processing system601, storage system603, software605, communication interface607, and user interface609. Processing system601is operatively coupled with storage system603, communication interface607, and user interface609. Processing system601loads and executes software605from storage system603. When executed by computing system600in general, and processing system601in particular, software605directs computing system600to operate as described herein for domain reputation analysis process300or variations thereof. Computing system600may optionally include additional devices, features, or functionality not discussed herein for purposes of brevity.

Referring still toFIG.6, processing system601may comprise a microprocessor and other circuitry that retrieves and executes software605from storage system603. Processing system601may be implemented within a single processing device but may also be distributed across multiple processing devices or sub-systems that cooperate in executing program instructions. Examples of processing system601include general purpose central processing units, application specific processors, and logic devices, as well as any other type of processing device, combinations, or variations thereof.

Storage system603may comprise any computer-readable storage media capable of storing software605and readable by processing system601. Storage system603may include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data. Storage system603may be implemented as a single storage device but may also be implemented across multiple storage devices or sub-systems co-located or distributed relative to each other. Storage system603may comprise additional elements, such as a controller, capable of communicating with processing system601. Examples of storage media include random-access memory, read-only memory, magnetic disks, optical disks, flash memory, virtual memory and non-virtual memory, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and that may be accessed by an instruction execution system, as well as any combination or variation thereof, or any other type of storage media. In no case is the computer-readable storage media a propagated signal.

In operation, in conjunction with user interface609, processing system601loads and executes portions of software605, such as domain reputation analysis process300, to facilitate domain reputation analysis and prevention of malicious attacks on a web service. Software605may be implemented in program instructions and among other functions may, when executed by computing system600in general or processing system601in particular, direct computing system600or processing system601to crawl web resources associated with the web service to obtain information about internal and external web assets associated with the web service. Software605may further direct computing system600or processing system601to process the information about the internal and external web assets to identify domains with which the internal and external web assets communicate. Software605may also direct computing system600or processing system601to analyze the domains to determine name server reputation, IP address reputation, and hosting provider reputation associated with the domains. Finally, software605may direct computing system600or processing system601to generate individual domain reputation scores for each of the domains based on the name server reputation, IP address reputation, and hosting provider reputation associated with the domains.

Software605may include additional processes, programs, or components, such as operating system software or other application software. Examples of operating systems include Windows®, iOS®, and Android®, as well as any other suitable operating system. Software605may also comprise firmware or some other form of machine-readable processing instructions executable by processing system601.

In general, software605may, when loaded into processing system601and executed, transform computing system600overall from a general-purpose computing system into a special-purpose computing system customized to facilitate domain reputation analysis and prevention of malicious attacks on a web service as described herein for each implementation. For example, encoding software605on storage system603may transform the physical structure of storage system603. The specific transformation of the physical structure may depend on various factors in different implementations of this description. Examples of such factors may include, but are not limited to the technology used to implement the storage media of storage system603and whether the computer-readable storage media are characterized as primary or secondary storage.

In some examples, if the computer-readable storage media are implemented as semiconductor-based memory, software605may transform the physical state of the semiconductor memory when the program is encoded therein. For example, software605may transform the state of transistors, capacitors, or other discrete circuit elements constituting the semiconductor memory. A similar transformation may occur with respect to magnetic or optical media. Other transformations of physical media are possible without departing from the scope of the present description, with the foregoing examples provided only to facilitate this discussion.

It should be understood that computing system600is generally intended to represent a computing system with which software605is deployed and executed in order to implement application606and/or domain reputation analysis process300(and variations thereof). However, computing system600may also represent any computing system on which software605may be staged and from where software605may be distributed, transported, downloaded, or otherwise provided to yet another computing system for deployment and execution, or yet additional distribution. For example, computing system600could be configured to deploy software605over the internet to one or more client computing systems for execution thereon, such as in a cloud-based deployment scenario.

Communication interface607may include communication connections and devices that allow for communication between computing system600and other computing systems (not shown) or services, over a communication network611or collection of networks. In some implementations, communication interface607receives dynamic data621over communication network611. Examples of connections and devices that together allow for inter-system communication may include network interface cards, antennas, power amplifiers, RF circuitry, transceivers, and other communication circuitry. The aforementioned network, connections, and devices are well known and need not be discussed at length here.

User interface609may include a voice input device, a touch input device for receiving a gesture from a user, a motion input device for detecting non-touch gestures and other motions by a user, and other comparable input devices and associated processing elements capable of receiving user input from a user. Output devices such as a display, speakers, haptic devices, and other types of output devices may also be included in user interface609. In some examples, user interface609could include a touch screen capable of displaying a graphical user interface that also accepts user inputs via touches on its surface. The aforementioned user input devices are well known in the art and need not be discussed at length here. User interface609may also include associated user interface software executable by processing system601in support of the various user input and output devices discussed above. Separately or in conjunction with each other and other hardware and software elements, the user interface software and devices may provide a graphical user interface, a natural user interface, or any other kind of user interface. User interface609may be omitted in some implementations.

The functional block diagrams, operational sequences, and flow diagrams provided in the Figures are representative of exemplary architectures, environments, and methodologies for performing novel aspects of the disclosure. While, for purposes of simplicity of explanation, methods included herein may be in the form of a functional diagram, operational sequence, or flow diagram, and may be described as a series of acts, it is to be understood and appreciated that the methods are not limited by the order of acts, as some acts may, in accordance therewith, occur in a different order and/or concurrently with other acts from that shown and described herein. For example, those skilled in the art will understand and appreciate that a method could alternatively be represented as a series of interrelated states or events, such as in a state diagram. Moreover, not all acts illustrated in a methodology may be required for a novel implementation.

The above description and associated figures teach the best mode of the invention. The following claims specify the scope of the invention. Note that some aspects of the best mode may not fall within the scope of the invention as specified by the claims. Those skilled in the art will appreciate that the features described above can be combined in various ways to form multiple variations of the invention. As a result, the invention is not limited to the specific embodiments described above, but only by the following claims and their equivalents.