TECHNIQUES FOR PROTECTING WEB-BROWSERS AGAINST CROSS-SITE SCRIPTING EXPLOITATION ATTACKS

A method and system for detecting client-side cross-site scripting exploitation attacks according to an embodiment are disclosed. The method includes downloading an access list from a remote server; capturing a request to access an external resource, wherein the request is initiated by a script executed over the web browser, wherein the external web resource is external to the web browser executed on a client device; determining, based on the access list, if the requested external web resource can be accessed; and applying a mitigation action on the request to access the external web resource when it is determined that the external web resource cannot be accessed.

TECHNICAL FIELD

This disclosure generally relates to network security technology, and more particularly to client-side protection.

BACKGROUND

Hackers try different techniques to steal personal information from individuals. Personal information is defined as either personally identifiable information, or sensitive personal information, as used in information security and privacy laws, or is information that can be used on its own or with other information to identify, contact, or locate a single person, or to identify an individual in context. Examples for personal information include social security numbers, credit card information, and so on.

Some hacking techniques include attacking servers, databases, and the like that store or otherwise process such information. Other attacks target user (client) devices to steal personal information at the source. A recent client targeted attack is known as “Megacart”, which is a type of zero-day exploitation attack.

Client-side attacks (or browser's threats), such as Megacart, operate by gaining access to websites either directly or via third-party services and injecting malicious JavaScript that steals data which shoppers enter into online payment forms, typically on checkout pages. Such attacks operatives either breach sites directly or via supply chain attacks. Supply chain attacks target third-party servers that supply code to websites. Thus, when a third-party server is compromised, a hacker can effectively breach thousands of sites at once.

FIG.7is a schematic diagram illustrating the operatives of client-side cross-site scripting exploitation attacks. The entities depicted inFIG.7includes a browser701executed by a client device710, a third-party server720, a web server730hosting a web site accessed by the browser, and a hacker server740managed by a hacker.

To execute a cross-site scripting exploitation attack, such as the Megacart attack, the hacker101injects a script721to a webpage of a website. The script721includes a piece of malicious code that being executed by the browser701when rendering or processing a webpage. For example, the third-party server720may include JavaScript(R) that when processed by the browser701calls an external payment service, such JavaScript(R) code can be manipulated by the hacker to include a form-jacking script that would push information from the browser701to the hacker server740.

When a user of the device710accesses a web site hosted by the third-party server720, a web page is returned to the browser701. The web page includes the modified script retrieved from the third-party server720, thus such when interpreted or processed by the browser would capture personal or sensitive information and send information to the hacker server740. For example, in Megacart, the modified script extracts information (such login credentials and credit card information) from a shopping cart.

The domain name of the hacker server740is different than the web server730. Further, the third-party server720is not hosted by the web server730. The third-party code from the third-party server720is integrated with thousands of websites, so when one service is compromised, thousands of websites become vulnerable at once.

Current solutions, such as anti-virus or anti-malware, are designed to protect the client devices, but cannot protect from information leakage of such devices. Further, anti-virus or anti-malware solutions are not zero-day. That is, such solutions first learn signatures of the virus or malware, and then block malicious activity based on the learned signatures. Solutions for protecting the web servers are not practical in such types of attacks, as the malicious code is implemented from a third-party resource and attacks the user devices without any prior knowledge of the malicious code.

Therefore, it would be advantageous to provide an efficient solution for protecting web-browsers against cross-site scripting exploitation attacks.

SUMMARY

Certain embodiments disclosed herein include a method for detecting client-side cross-site scripting exploitation attacks according to an embodiment. The method includes downloading an access list from a remote server; capturing a request to access an external resource, wherein the request is initiated by a script executed over the web browser, wherein the external web resource is external to the web browser executed on a client device; determining, based on the access list, if the requested external web resource can be accessed; and applying a mitigation action on the request to access the external web resource when it is determined that the external web resource cannot be accessed.

Certain embodiments disclosed herein include a system for detecting client-side cross-site scripting exploitation attacks according to an embodiment. The system includes a processing circuitry; and a memory, the memory containing instructions that, when executed by the processing circuitry, configure the system to: download an access list from a remote server; capture a request to access an external resource, wherein the request is initiated by a script executed over the web browser, wherein the external web resource is external to the web browser executed on a client device; determine, based on the access list, if the requested external web resource can be accessed; and apply a mitigation action on the request to access the external web resource when it is determined that the external web resource cannot be accessed.

DETAILED DESCRIPTION

The embodiments disclosed herein are only examples of the many possible advantageous uses and implementations of the innovative teachings presented herein. In general, statements made in the specification of the present application do not necessarily limit any of the various claimed embodiments. Moreover, some statements may apply to some inventive features but not to others. In general, unless otherwise indicated, singular elements may be in plural and vice versa with no loss of generality. In the drawings, like numerals refer to like parts through several views.

According to the disclosed embodiments, techniques for protecting web browsers against cross-site scripting exploitation attacks are disclosed. In an embodiment, the solution is based on an agent installed on a webpage and utilized to defend against such attacks. The defense is achieved, in part, by communicating with a backend server configured to instructions to the agent. The disclosed embodiments allow to detect and block attacks, such as, but not limited to, Megacart attacks, and prevent from user information to be revealed. Thus, the disclosed techniques improve the security of users, users' information, and can also prevent identity theft.

FIG.1shows an example network diagram100utilized to describe the various disclosed embodiments for protecting against cross-site scripting exploitation attacks. Here, the web browser of the user device, and hence the user, are protected against stealing the user's data, identity, or other information considered personal or confidential.

The network diagram100illustrated inFIG.1includes a client device (or simply client)110, a defense server120, a web server130, and a third-party server140all connected to the network150. In the deployment shown inFIG.1, a reverse proxy160is connected in the network150and configured to proxy communication between the client110and the servers120and130. The third-party server140may include a code repository or library.

The client110may be a PC, a mobile phone, a smart phone, a tablet computer, a server, or any compute device, and the like. The client110is operated by a legitimate user or a legitimate program. In one configuration, the client110is configured to execute a web browser115. The web browser (or simply browser)115may include any software application to access the content stored or accessible through the web server130. For example, the web server130may host a website for the web browser115to render and display webpages of that website.

The web server130may include a web server, a steaming server, a database server, or any other type of servers that provide content or information to the client110. The web server130may utilize the third-party server140to serve the client110. The third-party server140may include a code repository that provides a piece of code that is processed when downloading pages of the website (hosted by the server130). The piece of code may include a script code, such as a JavaScript.

The reverse proxy160is a device that retrieves resources on behalf of the client110from the defense server120or web server130. Such resources are then returned to the client110, appearing as if they originated from the reverse proxy160. In an example embodiment, the reverse proxy160is configured to ensure that a defense agent (117) is the first piece of code being executed when a webpage is downloaded to the web browser115.

According to the disclosed embodiment, the defense agent117is configured to detect and mitigate cross-site scripting exploitation attacks. To this end, the defense agent117is configured to inspect actions performed by other scripts executed on the web page. This is further illustrated inFIG.2where an example webpage200is shown.

The webpage200may be a HTML page that includes one or more scripts220-1through220-n,in additional to the defense agent117. The webpage200may include HTML code230. The defense agent117, in an embodiment, is also a script. The defense agent117is called and executed first on the webpage200. To this end, the webpage may include a code line calling for the defense agent117. For example, the code line may include:<link href=“css/defense-agent.css” rel=“stylesheet” type=“text/css”>

To this end, the webpage200may be programmed by the website's developer to first call the defense agent117. In an embodiment, the reverse proxy160is configured to capture a response (web page) from the web server130and rewrite the webpage200to first call for the defense agent117.

The defense agent117, when executed, is configured to intercept any outgoing request from any of the scripts220or the HTML code230in the webpage200. The intercepted request is for any URL resource (e.g., image, another web page, a script code, etc.) The request can be issued by fetching, XmlHttpRequest, by an HTML resource URL, and the like. The interception of requests can be performed using JavaScript application programming interface (API) modification or a Service Worker. These techniques are discussed below.

In an embodiment, the defense agent117, when executed, is further configured determine if the requested URL is in a whitelist. If so, the request is approved; otherwise, the request is blocked. The whitelist may be configured with the defense agent117and may be determined by the defense server120. The defense agent117may communicate with the defense server120to retrieve the most recent whitelist for the webpage200. By whitelisting URLs, any access to malicious servers (e.g., a hacker server) are blocked, as the URLs of such servers would not be listed.

As an example, the script220-1executes a cross-site exploitation script to collect user information and send such information to the server at a domain not included in the whitelist, thus any attempt to access the server would be blocked. It should be noted that a typical web page includes tens of different URLs of different domains or sub-domains of the web server130hosting the web page.

In another embodiment, the defense agent117is configured to monitor actions performed by any of the scripts220and determine if such actions are attempts to exploit user's information. For example, accessing certain form fields in a webpage, accessing a domain that is not frequently called, and so on.

In an embodiment, the defense agent117is configured to harden all the scripts220-1to220-nto intercept requests by modifying APIs of scripts. Typically, the scripts220-1through220-nare JavaScript(R) and the modification is JavaScript API modification.

The JavaScript API modification includes hardening the JavaScript base API calls so that any API call from a script220(e.g., script220-2) would be directed through the defense agent117. For example, the defense agent117is configured to change the windows.fetch API to a guarded implementation, causing any fetch call to go through the defense agent117. Other API that are hardened in a similar fashion includes Fetch, XmlHttpRequest, Image, Form Submit, Frame, an element ‘src’, attribute, an element ‘href’ attribute, and so on.

In an embodiment, hardening of scripts220-1to220-nis performed by implementing and executing at least one service worker. A service worker is a method that enables applications to take advantage of persistent background processing, including hooks, to enable bootstrapping of web applications while offline. Further, service workers allow for cross browser features, allowing handling requests, modifying responses, and handling cache. Service workers are currently supported by modern web browsers, such as Internet Explorer(R) 11, Firefox(R), Chrome(R), and so on.

In one configuration, the defense agent117, when executed, is configured to load a service worker from the main root of the website, so to handle any site request. The loaded service worker can capture any request sent from the web browser's tab, rendering the webpage200. It should be noted that as the service worker is executed by the browser, all requests from any script220, regardless of the hacker JavaScript API usage, can be captured. The requests captured by a service worker are transferred to the defense agent117to determine if the request is directed to a URL designated in the whitelist. Only whitelist requests are allowed.

It should be noted the defense agent117is a piece of software code executed over the client (110,FIG.1). A script is a high-level, often just-in-time compiled, software code. The software shall be construed broadly to include any type of instructions. Instructions may include code (e.g., in source code format, binary code format, executable code format, or any other suitable format of code). The instructions, when executed, cause the processing circuitry (e.g., embedded in the client device) to perform the various functions or processes of the defense agent117.

FIG.3is an example flow diagram300illustrating the interactions between the elements inFIG.1when there are blocking browser cross-site exploitation attacks. The web browser115, defense server120, web server130, third-party server140, and reverse proxy160discussed in detail above.

At S310, the browser115sends a request to access a website hosted on the web server130. The request is passed through the reverse proxy160.

At S320, a response302returned to the browser115is captured by the reverse proxy160. The response302is an HTML page of the web site.

At S330, the reverse proxy160injects the defense agent117to the response (web page) as the first script to be executed by the browser115. The defense agent117is configured with an initial whitelist. The modified response (with the defense agent) is replayed to the browser115.

At S340, the defense agent117, when executed over the browser115is configured to request and receive updated whitelist from the defense server120. The proxy160passes and communication between the web browser115and defense server120.

At S350, any request, and specifically cross-site requests, are captured by the defense agent117. A cross-site request is a request that is directed to a website that is not hosted by defense server120. In the example shown inFIG.2, the server130is a third-party server accesses through a domain name designated in the whitelist. If the request is directed to a domain in the whitelist, the request, at S360, is sent to the destination, e.g., server130inFIG.3. Otherwise, the request is blocked (S365, not shown).

At S360, all captured requests (allowed or blocked) are gathered and sent to the defense server120. Alternatively or collectively, the metadata on each captured script may be generated and sent the server120. Such metadata may include a script name generated the request, the requested destination (e.g., URL), time and date of the request, status of the request (allowed or blocked), and so on.

The defense server120is configured to process the received requests and/or the respective metadata to determine if the whitelist can be updated. The defense server120can determine if a requested URL should be added to a blacklist based on information received from reputation services. In an embodiment, blacklisting a URL by cross correlating a request with requests from different web browsers accessing to different web servers.

FIG.4is an example flowchart400illustrating a method for detecting and mitigation client-side cross-site scripting exploitation attacks according to an embodiment.

The method may be performed by defense agent being executed by the browser as the web page embedding the request is uploaded. As the defense agent is the first in the webpage, this script would be the first script to be executed. It should be noted that the defense agent, and hence the browser, are being executed over a client device. As noted above, such a device may include any computing device including a processor and memory.

The defense agent is injected to the browser (e.g., browser115) in response to a request access a web source (e.g., website, webpage, a service) hosted on the web server. Such a request is passed through the reverse proxy. The response, is returned to the, returned to the browser is captured by the reverse proxy, which injects the defense agent to the response (web page) as the first script (or piece of code) to be executed by the browser.

At S410, script's APIs of each script (other than the defense agent) in the webpage are modified to harden their functionality. As noted above, this is performed to capture API calls by the defense agent. In an embodiment, the scripts are JavaScript(R) and at least following APIs are modified: Fetch, XmlHttpRequest, Image, Form Submit, Frame, element ‘src’ attributes, and element href attributes.

Collectivity or alternatively to S410, at S420, a service worker is injected for execution by the browser. The injected Service Worker is configured to capture all requests from the browser (or a browser tab) and transfer the captured requests to the defense agent.

At S430, a request is sent to the defense server to receive an updated access list. In an embodiment, the access list a whitelist. The whitelist is specific for the protected website hosted on protected web server, being accessed by the browser executing the defense agent. In an embodiment, the defense agent is configured with an initial whitelist based on the web site being accessed. The initial whitelist can be updated by the defense server. In another embodiment, the access list may include a blacklist, i.e., a list of vulnerable web resources.

At S440, a request to access a resource generated by any script in the web page is being captured. The request may include uploading content or resources to web page. For example, a request may be to a reposting to download images, advertisements (ads), video streams, and the like. As another embodiment, the request may be for analytics services. The resource accessed by the script may be external to the webpage. That is, the resource may be downloaded from a server may or may not hosting the web server. The requests generated by the resources may be in a form of API calls, generated by the script.

At S450, the URL or domain name in the captured request is compared to the whitelist. If the URL is in the whitelist, at S460, the request is sent to the requested destination. Otherwise, at S480, the mitigation action is performed on the request. The mitigation action may include blocking the request, reporting on a malicious activity, displaying an alert on the browser, and so on. The mitigation action may include any combination of the above.

Then, at S470, the captured request is sent for the defense server. In an embodiment, a number of captured requested or their respective metadata are collected and sent as a batch.

FIG.5is an example diagram500illustrating logical component of the defense server120according to an embodiment. The embodiment includes an in-memory data structure510, an agent generator520, a gatekeeper530, and a graphical user interface540.

The in-memory data structure510is a persistence memory for both configuration and detection. In an embodiment, the data structure510can be realized as a REDIS is a cluster REDIS deployment and is automatically scaled by a proprietary micro service in case of high load. The load is a factor of the CPU average on all of the REDIS pods. By default, the REDIS cluster starts with 6 pods.

The agent generator520is configured to provide the scripts (e.g., JavaScript) to be injected into the main site's HTML. That is, the agent generator520is responsible to generate the defense agent117. The generated defense agent117includes two elements a JavaScript(R) API modification and a service worker to modify or capture the calls or requests generated by other scripts running on the page.

The gatekeeper530is used for API calls, and as an auth request by the reverse proxy. The gatekeeper530is configured to provide several APIs including, for example: ‘/auth’ (a request URL be injected by a script and/or CSP header in the response); ‘/getpolicy’ (received latest version of the whitelist); ‘/getscrip’ (get a service worker to be called from the root of the main site); and ‘/report’ (gets the detection reports from the agents).

The GUI540is a management system that allows to configure the defense server120. In an embodiment, the defense server120supports a multi-tenant architecture, where each tenant servers a different web site. The multi-tenant architecture allows independent configuration per tenant. For example, the following can be set per tenant: a list of regular expressions of the protected URLs; a list of webpages, per site, to inject the defense agent; enable/disable page protection; a mitigation policy per website or webpage; enable/disable the defense agent operation, and so on. In an embodiment, the configuration of the defense server120is enabled via the GUI of the defense server120.

The mitigation action that can be defined for the defense agent117(via the server120) may include reporting a malicious URL or domain (a domain of a hacker server), blocking access to a URL or domain, and the like. Blocking a URL can be performed using a content-security-protection (CSP) method. The CSP method allows to block requests using a special header in the response. The blocking may also include not sending requests to malicious URLs. In an embodiment, a mitigation policy can be defined per URL (known or a previously discovered).

In an embodiment, the defense agent117can be configured to specifically handle iFrames within a webpage. An iFrame protection is required as a hacker can use the hacked 3rd-party to create a remote frame to his selected site and use postMessage to communicate between the main site page and the iFrame. To prevent that defense can either block iFrames (requested by a 3rdparty server) or a proxy such frames. Blocking iFrames include preventing the creation of an iFrame in the protected web site. Proxying of iFrames includes converting an iFrame into a local domain frame and injecting the defense agent into the local domain frame. The defense agent can block any request when injected into the local domain frame. Further, the local frame when executing the defense agent can now access the reverse proxy. The reverse proxy160would proxy requests generated by the scripts in the page and the converted frame requests. In an embodiment, the service worker, initiated by the defense agent, is configured to replace any request from the converted frame to have a specific prefix, hence allowing special handling to be executed in the reverse proxy. It should be noted that the elements of the defense server120can be implemented in hardware as demonstrated inFIG.6.

FIG.6is an example block diagram of a hardware architecture600of a defense server120. In embodiment, the client device110and the reverse proxy160are realized using the hardware architecture600.

The hardware architecture600includes a processing circuitry610coupled to a memory620, a storage630, and a network interface640. In an embodiment, the components of the client device (or simply “client”)110may be communicatively connected via a bus650.

The memory620may be volatile (e.g., RAM, etc.), non-volatile (e.g., ROM, flash memory, etc.), or any combination thereof. In one configuration, computer readable instructions needed to implement one or more embodiments disclosed herein may be stored in the storage630.

In another embodiment, the memory620is configured to store software. Software shall be construed broadly to mean any type of instructions, whether referred to as software, firmware, middleware, microcode, or hardware description language. Instructions may include code (e.g., in source code format, binary code format, executable code format, or any other suitable format of code). The instructions, when executed by the one or more processors, cause the processing circuitry610to perform the various processes described herein. Specifically, the instructions, when executed, cause the processing circuitry610to generate identity key(s) by executing the script code as discussed above. In a further embodiment, the memory620may further include a memory portion625including the instructions.

The storage630may be magnetic storage, optical storage, and the like, and may be realized, for example, as flash memory or other memory technology, CD-ROM, Digital Versatile Disks (DVDs), hard-drives, SSD, or any other medium which can be used to store the desired information, such as, log of transactions, public keys, and so on. The storage630may include the various access policies and games.

It should be understood that the embodiments described herein are not limited to the specific architecture illustrated inFIG.6, and that other architectures may be equally used without departing from the scope of the disclosed embodiments.

It should be further noted that the client device110and the reverse proxy160may be realized using a computing architecture similar to the architecture illustrated inFIG.6, but that other architectures may be equally used without departing from the scope of the disclosed embodiments. Further, the memory620may include instructions for executing the function of the respective device, e.g., a client device110or the reverse proxy160.