JP2013125497A - Information processing device, information processing method and program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To excellently inhibit vulnerability etc. in a web application.SOLUTION: A processing unit performs information processing on the basis of prescribed processing data selected from a plurality of pieces of processing data. A control unit controls operation of the processing unit. In this case, the control unit performs control on the basis of security restriction associated with the prescribed processing data. For example, the processing unit is a web browser and the processing data is an object composing a document object model. For example, the security restriction is given to the object as a property, defined by a security object or defined by an HTTP header etc.

Description

  The present technology relates to an information processing apparatus, an information processing method, and a program, and more particularly, to an information processing apparatus, an information processing method, and a program that prevent vulnerabilities on web applications.

  2. Description of the Related Art In recent years, web (Web) systems that browse homepages and send and receive mail via a network have been widely used (see, for example, Patent Document 1). Web applications are used in various fields, including business applications, due to technological advances such as rich client technology using script code and the ease of execution if a web browser is installed on the client device. . The web application operates on a client / server type web system in which a client device and a server device are connected via a network.

  In a web application, if there is a bug such as forgetting to escape the program on the web application or the server, (1) any malicious script runs on the web browser, (2) sends a malicious request to the server, Leads to vulnerabilities such as This means that a slight bug in the web application will cause the user to take over an account and leak personal information.

  At present, in order to prevent damage due to the above-mentioned vulnerability, the web application running on the web browser and the program on the server are verified, and the bug is removed. For example, (1) confirmation that there is no escape leak, and (2) confirmation that a one-time token is always used for communication with the server. Alternatively, a mechanism for checking whether there is a request for an attack or information leakage on the client side or the server side can be considered.

JP 2010-128877 A

  However, no matter how much the program is verified, in reality, bugs are discovered and vulnerabilities are exposed. Also, bug detection is expected to become more difficult as web applications grow in size and complexity each year. With that in mind, web applications must always have bugs, and web browsers need to protect users from those bugs. However, none of the conventional techniques correspond to this.

  The objective of this technique is to make it possible to satisfactorily prevent vulnerabilities on web applications.

The concept of this technology is
A processing unit that performs information processing based on predetermined processing data selected from a plurality of processing data;
The information processing apparatus includes: a control unit that controls an operation of the processing unit based on a security constraint associated with the predetermined processing data.

  The processing unit performs information processing based on predetermined processing data selected from a plurality of processing data. The operation of the processing unit is controlled by the control unit. In this case, control is performed based on security constraints associated with predetermined processing data. Here, for example, the processing unit may be a web browser, and the processing data may be an object constituting a document object model. In this technology, it is possible to satisfactorily prevent vulnerabilities on web applications.

  For example, the security constraint may be the right to insert a script into the object. Further, for example, the security constraint may be a right to execute a script in the object. Further, for example, the security constraint may be a restriction regarding a request. Also, for example, the security constraint may be a designation of an accessible or inaccessible object of the script.

  Also, for example, the security constraint may be an access right to the application programming interface. Further, for example, the security constraint may be a policy change of an object reference or change request from a different generation source. For example, the security constraint may be an upper limit of heap usage including child objects. For example, the security constraint may be the upper limit of the number of objects including child objects. Further, for example, the security constraint may be an upper limit of a character string length that can be set for the object.

  For example, security constraints may be given to objects as attributes. In that case, the security constraint may be specified in a class. Further, for example, the security constraint may be defined by a security object. Further, for example, as a security constraint for an object for which no security constraint is specified, the security constraint from the parent may be taken over.

  For example, when a script in a predetermined object calls and executes a script in another object, the security constraint of the predetermined object may be taken over. Further, for example, the security constraint may be specified by an HTTP header. Further, for example, the security constraint may be dynamically changed according to a predetermined condition.

  According to the present technology, it is possible to satisfactorily prevent the vulnerability on the web application.

It is a block diagram which shows the structural example of the web system as embodiment. It is a block diagram which shows the structural example of a web browser. It is a flowchart which shows an example of the flow of a process of a script engine roughly. It is a figure for demonstrating the case where the security constraint given to the object of DOM is the insertion authority of the script in an object. It is a figure for demonstrating the case where the security constraint given to the object of DOM is the executable authority of the script in an object. It is a figure for demonstrating the case where the security constraint given to the object of DOM is the executable authority of the script in an object (when a "div element" is operated via a script). It is a figure for demonstrating the case where the security restrictions given to the object of DOM are the restrictions regarding a request. It is a figure for demonstrating the case where the security constraint given to the object of DOM is designation | designated of the object which can be accessed of a script, or an inaccessible object. It is a figure which shows the example (Example 1) of how to write a security constraint in the case of giving a security constraint as an attribute to each object. It is a figure which shows the example (Example 2) of how to write a security constraint in the case of giving a security constraint as an attribute to each object. When a security constraint is indirectly specified by class specification, it is a figure for demonstrating that the object which defines a security class is provided in DOM. It is a figure which shows the example (Example 3) of how to write a security constraint in the case of designating a security constraint with an HTTP header. It is a flowchart which shows roughly an example (dynamic change of a security constraint) of the flow of a script engine process.

Hereinafter, modes for carrying out the invention (hereinafter referred to as “embodiments”) will be described. The description will be given in the following order.
1. Embodiment 2. FIG. Modified example

<1. Embodiment>
[Web system]
FIG. 1 shows a configuration example of a web system 100 as an embodiment. The web system 100 is configured by connecting a client device 110 including a web browser and server devices 120 a and 120 B via a network 130. The client device 110 and the server devices 120A and 120B communicate with each other.

  The web system 100 is not different from existing systems at a general network level. The web browser reads the page from the server device 120A and displays it. In that case, it also includes acquiring a resource from the other server apparatus 120B. In addition, the web browser includes a system in which access to the server apparatuses 120A and 120B is generated by a script even after being displayed.

  FIG. 2 shows a configuration example of the web browser. The web browser includes a document object model (DOM) composed of objects such as a screen and a script, and a script engine. Web browsers load pages and images. Further, the web browser issues a request to the server device by an application programming interface (API) called from a script, and receives a response from the server device.

  In this embodiment, security restrictions are given to each object of the DOM. Then, when the script engine executes the script, it is verified whether or not the constraint is satisfied, and when the script engine does not satisfy the constraint, the operation is shifted to a special operation.

  The flowchart in FIG. 3 schematically shows an example of the processing flow of the script engine. In step ST1, the script engine starts processing. Then, in step ST2, the script engine determines whether or not execution of the script is instructed. When the execution of the script is instructed, the script engine determines whether or not the security constraint is satisfied in step ST3.

  When the security constraint is satisfied, the script engine executes the script in step ST4. After the process of step ST4, the script engine ends the process in step ST5. On the other hand, when the security constraint is not satisfied in step ST3, the script engine issues a special operation, for example, an error dialog indicating the error location and the cause thereof in step ST6, instead of executing the script. After the process of step ST6, the script engine ends the process in step ST5.

  Next, the security constraint, the method for specifying the security constraint, the operation of the web browser, etc. will be specifically described.

[Security constraints]
Examples of the security restrictions given to the DOM object include the following.

(1) Authority to Insert a Script into an Object A security constraint given to a DOM object can be an authority to insert a script into the object. In this case, for example, insertion into an object such as a post including an attack script can be prevented.

  FIG. 4 shows a case where the security constraint given to the DOM object is the right to insert a script into the object. First, an operation example when no security constraint is given will be described. (1) The attacker sends a post including the attack script to the server. (2) The client receives a post including this attack script from the server. (3) On the client, a post including this attack script is placed on the DOM. (4) Then, this attack script is executed.

  If the DOM object is given the right to insert a script into the object as a security constraint, if the inserted “div element” does not have the right to insert a script, the attack script in step (3) above. Can be prevented and attack script execution can be prevented.

(2) Executable authority of script in object A security constraint given to a DOM object can be an executable authority of a script in the object. In this case, for example, execution of the attack script can be prevented.

  FIG. 5 shows a case where the security constraint given to the DOM object is the executable authority of the script in the object. First, an operation example when no security constraint is given will be described. (1) The attacker sends a post including the attack script to the server. (2) The client receives a post including this attack script from the server and displays it. (3) The attack script is executed.

  If the DOM object is granted the executable permission for the script in the object as a security constraint, the attack in the above stage (3) if the inserted “div element” does not have the executable permission for the script Can prevent script execution.

  FIG. 6 also shows the case where the security constraint given to the DOM object is the executable authority of the script in the object. In this case, a case where a “div element” is operated via a script is shown. First, an operation example when no security constraint is given will be described. (1) The attacker sends a post including the attack script to the server. (2) The client receives a post including this attack script from the server. (3) In the client, a post including the attack script is placed on the DOM. (4) Then, the attack script is executed.

  If the DOM object is granted the executable permission of the script in the object as a security constraint, the attack in the above stage (4) if the inserted “div element” does not have the executable authority of the script Can prevent script execution.

(3) Request restriction A security restriction given to a DOM object can be a restriction on a request (permission of sending information such as a cookie). In this case, for example, transmission of a request with a cookie from the attack link to the server can be prevented.

  FIG. 7 shows the case where the security constraint given to the DOM object is a request-related constraint. Here, mail (Mail) and social networking service (SNS: Social Network Service) that require authentication are assumed.

  First, an operation example when no security constraint is given will be described. (1) An attacker sends a post including an attack link to a server. (2) The client receives a post including the attack link from the server and displays the attack link. (3) When the user steps on the attack link in the client, (4) a request is sent from the client to the server. At this time, the client also sends a cookie to the server. Therefore, the server status can be changed with the user authority of the client (posting, deletion, and setting change are possible).

  If the DOM object is restricted as a security constraint as a security constraint, the attack link will not have any effect unless it has the authority to send a cookie to the “div element” in which the post is displayed. And can.

(4) Specification of accessible / inaccessible object of script The security constraint given to the DOM object can be specified as an accessible or inaccessible object of the script. In this case, for example, the attack script can be prevented from acquiring a cookie, and for example, the information acquired by the attack script can be prevented from being transmitted to the attacker's server by API.

  FIG. 8 shows a case where the security constraint given to the DOM object is a designation of an accessible or inaccessible object of the script. First, an operation example when no security constraint is given will be described.

  (1) A client reads content from a server. (2) A hacked server is hacked and replaced with a library containing an attack script, which is read by the client. (3) The attack script is executed at the client, and the attack script acquires session information and personal information. (4) Then, the attack script sends the acquired information to the attacker's server (attacker sever).

  If the DOM object is specified as a security-restricted object that can be accessed by the script or an object that cannot be accessed, if the access authority to the cookie is restricted, Can prevent the acquisition of cookies, etc. Further, in this case, if the usable API is restricted, the attack script can be prevented from transmitting the acquired information to the attacker's server.

(5) Other Security Constraints Security constraints given to DOM objects can be API access rights. However, when an API is also defined as an object, it is equivalent to the item “(4) Specification of accessible / impossible object of script” described above.

  Further, the security constraint given to the DOM object can be a change in a policy of a request such as SOP (Same Origin Policy) or CORS (Cross-Origin Resource Sharing). Here, the SOP is a mechanism that prohibits reference and change of objects from different generation sources, and the CORS is a mechanism that enables reference and change of objects from different generation sources.

  Further, the security constraint given to the DOM object can be set as the upper limit of the heap usage amount including the child object. In addition, the security constraint given to the DOM object can be the upper limit of the number of objects including child objects. Furthermore, the security constraint given to the DOM object can be the upper limit of the character string length that can be set in each attribute of the object.

  In addition to XHR (XML Http Request), it is also possible to constrain by the domain or port of the request destination to the outside by “img”, “iframe” or the like.

[How to specify security constraints]
Next, a security constraint designation method (how to write) will be described.

(1) Giving each object as an attribute Security constraints can be given to each object as attributes. FIG. 9 shows an example (Example 1) of how to write a security constraint in that case. FIG. 10 also shows a writing example (example 2) of the security constraint in that case. In the example of FIG. 9, the security constraint is directly specified for the element. In the example of FIG. 10, the security class is specified for the element, and the security constraint is indirectly specified. In the example of FIG. 10, as shown in FIG. 11, an object defining a security class is provided on the DOM.

(2) Definition by security object The security constraint of each object can be defined by the security object. In this case, an object that enumerates security constraints is defined in the HTML, and what kind of security constraint is given at the time of object generation is determined.

(3) Specification by HTTP header The security constraint of each object can be specified by the HTTP header. In this case, a security object definition can be written. Alternatively, it is possible to specify simply that the script can be executed only in the header. FIG. 12 shows an example (Example 3) of how to write a security constraint in that case. In this case, execution of a script with only a header tag is permitted. Since it is specified in one line, complicated specification is not possible. It is mainly specified to crush the location that is the target of attack, such as prohibition of script execution in the form.

(4) Inheritance of security constraint from parent It is also possible to inherit the security constraint of an object for which no security constraint is specified, from the security constraint of the parent. In this way, by inheriting the specification of the security constraint from the parent, it is possible to efficiently specify the security constraint. For example, suppose that the security of the parent object is designated as class A, the security of the first child object is not designated, and the security of the second child object is designated as class B. In this case, the class A that is the security of the parent object is taken over by the first child object.

(5) Inheritance of security constraint of call-back source When a script in a predetermined object calls and executes a script in another object, the security constraint of the predetermined object can be inherited. It can be used in libraries with functions such as wrappers for accessing objects that do not have their own security constraints.

  As described above, the definition of the security constraint may be written in HTML, but it can also be defined by an external file. In that case, referring to an external file is described in HTML.

[Web browser operation]
(1) When an access to an object on the DOM occurs during script execution, the following operation is performed. That is, it is confirmed whether there is an access right to the target object from the security constraint of the context being executed. If the user has the access right, the execution is continued. If not, the process is interrupted and an exception is generated. In this case, the script engine reads the exception handler and stops by giving an error dialog indicating the error location and cause.

  (2) When a request to the network is generated by a link click or a script, the following operation is performed. That is, it is confirmed whether there is an access right to the target domain or port from the security constraint of the context being executed. When a link is clicked, it is confirmed whether the request authority is given according to the security constraint to which the link belongs. If there is a request authority, the execution is continued. If there is no request authority, the process is interrupted and an exception is generated.

  (3) When calling a function object having a different security constraint, the current security constraint is stacked on the stack, and the security constraint of the destination function object is set in the context. When returning from a function object having a different security constraint, the security constraint is popped from the above stack and set in the context.

  (4) When rewriting the properties of an object, check that the number of characters and other constraints are not exceeded in accordance with the current security constraints.

  As described above, in the web system 100 shown in FIG. 1, even if a bug is found by setting an appropriate security constraint on an object on the DOM, XSS, CSRF, or an unknown vulnerability is detected. Can be prevented.

  Moreover, in the web system 100 shown in FIG. 1, the script on an external server can be safely used by setting an appropriate security constraint for the object on the DOM. Even if a malicious script is mixed in, this scripter cannot acquire important information and can minimize damage.

  In addition, in the web system 100 shown in FIG. 1, an unknown security vulnerability such as UXSS (Universal Cross Scripting) due to a bug of the web browser itself is set by setting an appropriate security constraint for an object on the DOM. Can be prevented.

  Further, in the web system 100 shown in FIG. 1, it is possible to safely use the web API beyond the same origin policy by changing the same origin policy while restricting some scripts. it can.

  Further, in the web system 100 shown in FIG. 1, by appropriately limiting the number of objects that can be changed, the number of objects that can be used, and the character string length of attributes, buffer overflow and heap spray (heap spray) ) Attacks that target vulnerabilities in the web browser itself, such as attacks, can be prevented.

<2. Modification>
In the above-described embodiment, it has been described that the security constraint set for each object is fixed. However, an example in which this security constraint changes dynamically according to other conditions is also conceivable.

  For example, an example in which external security restrictions are given according to a URL (Uniform Resource Locator) can be considered. That is, (1) In order for an external vendor to use each major site safely, it is conceivable to distribute security constraints for each site. (2) If the site does not have a security constraint, it is conceivable that the web browser applies a constraint associated with the URL.

  The flowchart in FIG. 13 schematically shows an example of the processing flow of the script engine in that case. In step ST11, the script engine starts processing. Then, in step ST12, the script engine determines whether script execution has been instructed. When the execution of the script is instructed, the script engine proceeds to the process of step ST13.

  In step ST3, the script engine determines whether or not the site from which the script instructed to be executed has a security constraint. If so, the script engine decides in step ST14 to use the security constraints of the acquisition site, and then proceeds to the processing of step ST15. On the other hand, when the acquisition destination site does not have security constraints in step ST13, the script engine determines in step ST16 that the security constraint associated with the URL of the acquisition destination site is used, and thereafter, step ST15. Move on to processing.

  In step ST15, the script engine determines whether security constraints are satisfied. When the security constraint is satisfied, the script engine executes the script in step ST17. After the process of step ST17, the script engine ends the process in step ST18. On the other hand, when the security constraint is not satisfied in step ST15, the script engine issues a special operation, for example, an error dialog indicating an error location and its cause, in step ST19, instead of executing the script. After the process of step ST19, the script engine ends the process in step ST18.

Moreover, this technique can also take the following structures.
(1) a processing unit that performs information processing based on predetermined processing data selected from a plurality of processing data;
An information processing apparatus comprising: a control unit that controls an operation of the processing unit based on a security constraint associated with the predetermined processing data.
(2) The processing unit is a web browser,
The information processing apparatus according to (1), wherein the processing data is an object constituting a document object model.
(3) The information processing apparatus according to (2), wherein the security constraint is an authority to insert a script into the object.
(4) The information processing apparatus according to (2) or (3), wherein the security constraint is a right to execute a script in the object.
(5) The information processing apparatus according to any one of (2) to (4), wherein the security constraint is a request-related restriction.
(6) The information processing apparatus according to any one of (2) to (5), wherein the security constraint is designation of an accessible object or an inaccessible object of a script.
(7) The information processing apparatus according to any one of (2) to (6), wherein the security constraint is an access right to an application programming interface.
(8) The information processing apparatus according to any one of (2) to (7), wherein the security constraint is a policy change of an object reference or a change request from a different generation source.
(9) The information processing apparatus according to any one of (2) to (8), wherein the security constraint is an upper limit of a heap usage amount including a child object.
(10) The information processing apparatus according to any one of (2) to (9), wherein the security constraint is an upper limit of the number of objects including a child object.
(11) The information processing apparatus according to any one of (2) to (10), wherein the security constraint is an upper limit of a character string length that can be set for the object.
(12) The information processing apparatus according to any one of (2) to (11), wherein the security constraint is given to the object as an attribute.
(13) The information processing apparatus according to (12), wherein the security constraint is specified by a class.
(14) The information processing apparatus according to any one of (2) to (13), wherein the security constraint is defined by a security object.
(15) The information processing apparatus according to any one of (2) to (14), wherein a security constraint from a parent is taken over as a security constraint of an object for which no security constraint is specified.
(16) The information processing apparatus according to any one of (2) to (15), wherein when a script in a predetermined object calls and executes a script in another object, the security constraint of the predetermined object is taken over.
(17) The information processing apparatus according to claim 2, wherein the security constraint is designated by an HTTP header.
(18) The information processing apparatus according to any one of (2) to (17), wherein the security constraint is dynamically changed according to a predetermined condition.
(19) Processing steps for performing information processing based on predetermined processing data selected from a plurality of processing data;
A control step for controlling an operation of obtaining the processing step based on a security constraint associated with the predetermined processing data.
(20)
Processing means for performing information processing based on predetermined processing data selected from a plurality of processing data;
A program that functions as a control unit that controls the operation of the processing unit based on a security constraint associated with the predetermined processing data.

DESCRIPTION OF SYMBOLS 100 ... Web system 110 ... Client apparatus 120A, 120B ... Server apparatus 130 ... Network

Claims (20)

A processing unit that performs information processing based on predetermined processing data selected from a plurality of processing data;
An information processing apparatus comprising: a control unit that controls an operation of the processing unit based on a security constraint associated with the predetermined processing data. The processing unit is a web browser,
The information processing apparatus according to claim 1, wherein the processing data is an object constituting a document object model. The information processing apparatus according to claim 2, wherein the security constraint is an authority to insert a script into the object. The information processing apparatus according to claim 2, wherein the security constraint is a right to execute a script in the object. The information processing apparatus according to claim 2, wherein the security constraint is a restriction related to a request. The information processing apparatus according to claim 2, wherein the security constraint is designation of an accessible object or an inaccessible object of the script. The information processing apparatus according to claim 2, wherein the security constraint is an access right to an application programming interface. The information processing apparatus according to claim 2, wherein the security constraint is a policy change of an object reference or change request from a different generation source. The information processing apparatus according to claim 2, wherein the security constraint is an upper limit of a heap usage amount including a child object. The information processing apparatus according to claim 2, wherein the security constraint is an upper limit of the number of objects including child objects. The information processing apparatus according to claim 2, wherein the security constraint is an upper limit of a character string length that can be set for the object. The information processing apparatus according to claim 2, wherein the security constraint is given to the object as an attribute. The information processing apparatus according to claim 12, wherein the security constraint is specified by a class. The information processing apparatus according to claim 2, wherein the security constraint is defined by a security object. The information processing apparatus according to claim 2, wherein the security constraint from the parent is inherited as the security constraint of the object for which the security constraint is not specified. The information processing apparatus according to claim 2, wherein when a script in a predetermined object calls and executes a script in another object, the security constraint of the predetermined object is inherited. The information processing apparatus according to claim 2, wherein the security constraint is specified by an HTTP header. The information processing apparatus according to claim 2, wherein the security constraint is dynamically changed according to a predetermined condition. Processing steps for performing information processing based on predetermined processing data selected from a plurality of processing data;
A control step for controlling an operation of obtaining the processing step based on a security constraint associated with the predetermined processing data. Computer
Processing means for performing information processing based on predetermined processing data selected from a plurality of processing data;
A program that functions as a control unit that controls the operation of the processing unit based on a security constraint associated with the predetermined processing data.

Images