CN109218296B

CN109218296B - XSS (XSS) defense system and method based on improved CSP (chip size service) strategy

Info

Publication number: CN109218296B
Application number: CN201810995401.3A
Authority: CN
Inventors: 黄书涵; 许光全; 郭峰; 邱铁; 黄雨
Original assignee: Tianjin University
Current assignee: Tianjin University
Priority date: 2018-08-29
Filing date: 2018-08-29
Publication date: 2021-03-23
Anticipated expiration: 2038-08-29
Also published as: CN109218296A

Abstract

The invention belongs to the field of Web security, and provides an XSS defense technical scheme which has richer characteristics and finer granularity control, is completely realized by Javascript, and can be compatible with browsers of different versions. The XSS defense system based on the improved CSP strategy comprises a strategy generation module, a strategy execution module, a rear-end module and a browser local storage module, wherein the strategy generation module generates a corresponding security strategy according to a pure web page, namely a page without malicious codes, issues a command to the rear-end module, stores the strategy in the browser local storage module, and is used for issuing a command to a background to acquire and execute the previously generated security strategy; the back-end module also intercepts requests issued by malicious scripts. The invention is mainly applied to Web safety occasions.

Description

XSS (XSS) defense system and method based on improved CSP (chip size service) strategy

Technical Field

The invention belongs to the field of Web security, relates to an XSS (cross site scripting attack) defense direction, and realizes the security requirement of Web application by designing an XSS defense technology based on improved CSP (content security policy) and named as JSSPS (Javascript-based CSP). In particular, it relates to an XSS defense method based on an improved CSP strategy.

Background

Currently, the mainstream XSS attack defense can be mainly divided into three types: based on wf (web application firewall), based on rule filtering, and based on security policy defense. The former two modes are easy to have false alarm and false alarm, and different defense means can not be adopted aiming at different web applications. Security policy based defense can effectively ameliorate these disadvantages. CSP, which is established by the W3C (world wide web consortium) organization, is currently the mainstream security policy-based defense. The CSP contains a variety of policy instructions, roughly in the format:

default-src'self'；script-src'self”userscripts.example.com'；img-src'statics.example.com'；

list 1: CSP instruction format

The list 1 has three groups of policy instructions default-src, script-src and img-src, which respectively limit the sources of different html elements. Wherein the source of the script tag can only be from the domain of the web page itself or from the user servers tags.

CSP instructions are typically given in HTTP headers and then parsed and executed by the browser kernel. However, this implementation has some disadvantages: a) different browsers have different support degrees on CSP, and the compatibility problem exists; b) CSP can only carry out integral limitation on the whole page and can not carry out finer-grained control; c) CSP policy directives can only be made manually and are not flexible enough.

Disclosure of Invention

In order to overcome the defects of the prior art, the invention aims to provide a novel XSS defense technology JSSPS based on a security policy. Compared with CSP, the method has richer characteristics and finer-grained control, is completely realized by Javascript, and can be compatible with browsers of different versions. By using the technology, XSS attack can be effectively defended under the condition of not modifying the back-end source code. The XSS defense system based on the improved CSP strategy comprises a strategy generation module, a strategy execution module, a rear-end module and a local browser storage module, wherein the strategy generation module generates a corresponding security strategy according to a pure web page, namely the page without malicious codes, issues a command to the rear-end module, stores the strategy in the local browser storage module, and the strategy execution module is used for issuing the command to a background to acquire and execute the previously generated security strategy; the back-end module also intercepts requests issued by malicious scripts.

The security policy specifically includes:

1) sandbox strategy: prohibiting the use of the Javascript function eval by adding a policy instruction "eval": false;

2) element strategy: the method comprises the steps of limiting the source of DOM elements in a page, and generating a white list strategy by marking script tags and the positions of elements containing event listeners, namely event-handler;

3) data strategy: the method is used for protecting important data in the DOM document from being read and written by an attacker, and the important data comprises a value of a password input box of a form, a cookie attribute of a document object and a localStorage attribute of a window object.

Policy generation specifically:

1) sandbox strategy: adding hooks to the get method of dangerous objects or functions which are not used in a normal page, thereby determining which functions or objects are not used, and then generating corresponding policy instructions according to the functions or objects;

2) DOM element policy: all elements in the DOM tree can be extracted, and the tag names of the elements can be stored in a white list;

3) data strategy: object.

Policy enforcement specifically:

firstly stopping rendering the DOM tree to prevent malicious script execution, then reloading the current page and copying the content into a safe DOM tree, setting all nodes in the DOM tree to be in an unmodifiable state so as to prevent an attacker from modifying some existing DOM attributes, then taking out the security policy in a local storage of a browser and sending the security policy to a policy executor to execute, modifying the DOM tree, marking and then deleting the malicious elements, directly deleting the policy-prohibited danger functions and objects to obtain a clean DOM tree, if some data or elements in the security policy need to be protected, adopting a DOM listener to monitor the access of the elements, setting important data to be in an unreadable state, and simultaneously adding some inline scripts into the DOM, adding function hooks Hook to newly-built or tagged functions, these function hooks may impose similar constraints on dynamically created elements; and finally, writing the modified DOM document content and the script required by applying the function hook into a DOM tree in the original page, and delivering the DOM document content and the script to a browser for continuous rendering.

The XSS defense method based on the improved CSP strategy comprises the following steps:

step one, installing and loading JSCP extension on a browser;

secondly, selecting a web page needing XSS defense, and firstly ensuring that an XSS attack code is not injected into the web page;

and step three, after the page loading in the step two is finished, generating security policies, wherein the security policies comprise three types: sandbox policy, DOM element policy, and data policy;

and fourthly, the JSCP execution module filters the attack vector according to the generated security policy so as to obtain a pure page.

The security policy specifically includes:

Policy generation specifically:

3) data strategy: object.

Policy enforcement specifically:

The invention has the characteristics and beneficial effects that:

1. this technique is effective against various XSS bypass techniques, such as coding and obfuscation, because it first parses the page into a complete DOM (document object model) tree and then filters it, at which time the various coding and obfuscation are restored.

2. All logics of the technology are realized by Javascript codes, and the technology can be conveniently deployed in all browsers supporting ES5 (namely ECMAScript 5 which is a mainstream Javascript language version and is supported by modern browsers), and has good compatibility. In addition, for a common user, the security policy can be automatically generated, and the learning cost of the user is reduced.

Description of the drawings:

FIG. 1 is a general block diagram.

FIG. 2 is a policy generation module.

FIG. 3 is a policy enforcement module.

Detailed Description

1. Integrated framework

The overall structure of the XSS defense technology related by the invention is shown in figure 1 and mainly comprises four parts, namely a strategy generation module, a strategy execution module, a back-end module and a localStorage (local storage of a browser). The policy generation module can generate a corresponding security policy according to a pure web page (i.e., a page without malicious codes), issue a command to the background module, and store the policy in a localStorage in a json (lightweight data exchange format). The policy executing module may issue a command to the background to obtain the previously generated security policy and execute the security policy. In addition, the background module can intercept the request sent by the malicious script.

2. Policy format

There are three security strategies in JSCSP, an example of which is given in list 2:

list 2: JSCP policy format

4) Sandbox strategy (2-5 rows). Some Javascript functions and objects are dangerous and easy to be used by attackers, wherein the objects include Proxy, XMLHTTPRequest, and the functions include eval only. As shown in line 3, we can disable the use of the eval function by adding a policy instruction "eval": false.

5) Element policy (6-32 rows). This type of policy is used to restrict the source of DOM elements in a page, and in addition to generate a white list policy by marking the script tag, and the location of the element containing the event-handle.

6) Data policy (lines 33-38). The strategy is used for protecting important data in the DOM document and enabling the important data not to be read and written by an attacker. These data include the value of the password input box of the form, the cookie attribute of the document object, and the localStorage attribute of the window object.

3. Policy generation

Figure 2 shows the architecture of JSCSP in the policy generation section. First we need to wait for the page to be completely loaded, otherwise some resources may be erroneously added to the blacklist. Then, Javascript scripts, HTML tags and sensitive data in the page can be analyzed by the DOM parser, and then the following three security policies are automatically generated.

1) A sandbox policy. This security policy is used to prohibit certain threat objects or functions that are not used on normal pages. We will hook the get method of these functions, or objects, to determine which functions or objects have not been used, and then generate the corresponding policy instructions accordingly. For example, if eval is not used, a policy instruction "eval": false is added.

2) DOM element policies. All elements in the DOM tree are extracted and their tag names (e.g., img) are saved in a white list. In addition, the href or src attribute of some elements (iframe, script) is saved in the source white list, and in addition, some common site sources are added. For those inline scripts, we mark their location in the DOM tree and generate the corresponding security policies. Malicious scripts that appear elsewhere are then deleted.

3) And (4) data policy. We also add policy instructions for protecting important data. We use object.

4. Policy enforcement

Figure 3 shows the architecture of JSCSP in the policy enforcement section. At this stage, assume that the user has accessed a contaminated page (into which a malicious script was inserted). First, our script will stop rendering the DOM tree to prevent malicious script execution (step 1). We then reload the current page and copy the content into a secure DOM tree, all nodes in the DOM tree are set to an un-modifiable state, preventing an attacker from modifying some existing DOM attributes (step 2). After which the security policy in the browser's local storage is retrieved and given to the policy executor for execution. The DOM tree will be modified, the malicious elements marked and then deleted, and the policy-prohibited danger functions and objects deleted directly, resulting in a clean DOM tree (steps 3, 4). If some data or elements need to be protected in the security policy, a DOM listener is used to listen to the access of the elements and to set important data in an unreadable and writable state. However, the dynamically created elements are not restricted, so we add some inline scripts to the DOM that add hooks to the functions used to create or add tags (including document. These function hooks may impose similar constraints on dynamically created elements. Finally, the modified DOM document content and the script required to apply the function hook are written into the DOM tree in the original page (step 6), and are delivered to the browser for continuous rendering.

The final implementation form of the invention is a browser extension. The process of protecting a web application using this extension is as follows:

in the first step, a JSCSP extension is installed and loaded on a browser.

And secondly, selecting a web page needing XSS defense, wherein XSS attack codes are not injected into the web page, and for example, a newly online web page can meet the requirement.

And thirdly, after the page loading in the second step is finished, clicking a button to generate security policies, wherein the security policies comprise three types: sandbox policies, DOM element policies, and data policies. The details of the strategy are found in section 2 of the detailed description.

Fourth, assume that the attacker successfully inserts the XSS attack vector into the protected page.

And fifthly, the user accesses the page again, and the JSSSP execution module filters the attack vector in the fourth step according to the generated security policy, so that a pure page is obtained.

Claims

1. An XSS defense system based on an improved CSP strategy is characterized by comprising four parts, a strategy generation module, a strategy execution module, a rear-end module and a local browser storage module, wherein the strategy generation module generates a corresponding security strategy according to a pure web page, namely a page without malicious codes, issues a command to the rear-end module, stores the strategy in the local browser storage module, and the strategy execution module is used for issuing a command to a background, acquiring and executing the previously generated security strategy; the back-end module can also intercept the request sent by the malicious script; the security policy specifically includes:

2) DOM element policy: the method comprises the steps of limiting the source of DOM elements in a page, and generating a white list strategy by marking a script tag and the position of an element containing an event listener event-handler;

3) data strategy: the method is used for protecting important data in the DOM document from being read and written by an attacker, wherein the important data comprises a value of a password input box of a form, a cookie attribute of a document object and a localStorage attribute of a window object;

policy generation specifically:

1) sandbox strategy: adding hooks to the get method of the dangerous object or function which is not used in the normal page, thereby determining the function or object which is not used, and then generating a corresponding policy instruction according to the function or object;

2) DOM element policy: extracting elements in all DOM trees, and storing tag names of the elements in a white list;

3) data strategy: adding a policy instruction for protecting important data, and limiting the read-write permission of a Javascript on the important data by using an object.

Policy enforcement specifically: firstly, stopping rendering the DOM tree to prevent malicious script execution, then reloading a current page and copying contents into a safe DOM tree, wherein all nodes in the DOM tree are set to be in an unmodifiable state, so that an attacker is prevented from modifying the existing DOM attribute, a security policy in a local storage of a browser is taken out and is handed to a policy executor to be executed, the DOM tree is modified, a malicious element is marked and deleted, and a risk function and an object forbidden by the policy are directly deleted, so that a clean DOM tree is obtained; if data or elements in the security policy need to be protected, a DOM listener is adopted to monitor access to the data or the elements, important data is set to be in an unreadable state, an inline script is added into the DOM at the same time, the inline script adds a function Hook to a function which is newly built or is added with a label, and the function Hook applies corresponding limitation to the dynamically built elements; and finally, writing the modified DOM document content and the script required by applying the function hook into a DOM tree in the original page, and delivering the DOM document content and the script to a browser for continuous rendering.

2. An XSS defense method based on an improved CSP strategy is characterized by comprising the following steps:

the method comprises the following steps that firstly, a Javascript-based content security policy (JSSPC) extension is installed and loaded on a browser;

and step three, after the page loading in the step two is finished, generating a security policy, wherein the security policy comprises three types: sandbox policy, DOM element policy, and data policy;

fourthly, the JSCP execution module filters the attack vector according to the generated security strategy, and therefore a pure page is obtained; the security policy specifically includes:

policy generation specifically:

Policy enforcement specifically:

firstly, stopping rendering the DOM tree to prevent malicious script execution, then reloading a current page and copying contents into a safe DOM tree, wherein all nodes in the DOM tree are set to be in an unmodifiable state, so that an attacker is prevented from modifying the existing DOM attribute, then a security policy stored in a local browser is taken out and is handed to a policy executor to be executed, the DOM tree is modified, malicious elements are marked and deleted, and a risk function and an object forbidden by the policy are directly deleted, so that a clean DOM tree is obtained; if data or elements in the security policy need to be protected, a DOM listener is adopted to monitor access to the data or the elements, important data is set to be in an unreadable state, an inline script is added into the DOM at the same time, the inline script adds a function Hook to a function which is newly built or is added with a label, and the function Hook applies corresponding limitation to the dynamically built elements; and finally, writing the modified DOM document content and the script required by applying the function hook into a DOM tree in the original page, and delivering the DOM document content and the script to a browser for continuous rendering.