JP2020091633A - Information processing device, information processing device control method and program - Google Patents

Abstract

To facilitate a user's determination and to improve a security by presenting, to the user, information for determining the safety of a Web application that requests an access to a device connected to an information processing device.SOLUTION: When an access is made to a website containing a Web application by a Web browser from a client computer 101, and when a connection to a device 102 that is connected to the client computer 101 is requested, the Web browser obtains, from the device, information indicating an obtainment destination on a white list (S505), and the Web application that has requested the connection is verified using the white list obtained from the obtainment destination (S506 and S507). Next, whether or not an alert is contained in the displayed detail of an allowance prompt for causing a user to check whether or not to allow the Web application to be connected to the device is changed in accordance with the verification result (S509).SELECTED DRAWING: Figure 5

Description

The present invention relates to control for verifying the security of a web application that has requested access to a device.

There are technologies called WebUSB and WebBluetooth that allow a Web application to access and operate a USB device or a Bluetooth device connected to a client computer. In this technique, when a web application requests access to a USB device or a Bluetooth device, the web browser displays a permission prompt and asks the user for permission to access. When the user permits the access at the permission prompt, the web application can access the USB device or the Bluetooth device. Note that Bluetooth and Bluetooth are registered trademarks.

Patent Document 1 discloses a technique of determining whether or not an application for using a service can access a server that provides content, according to a white list acquired from a server managed by a service provider. According to this, it is possible to manage the security of the Internet connection on the content providing side.

JP, 2014-102568, A

As described above, in WebUSB and WebBluetooth, the user requests the permission for the Web application to access the device. At this time, the web browser does not verify the safety of the web application. Therefore, when the user is asked for permission, there is no information for determining whether or not the Web application that requested the access is safe. Therefore, it is difficult for the user to determine whether or not to allow access to the device (whether it is safe or not) even if the user is requested to allow access. If the user permits a request from a malicious web application that the device vendor does not trust, malicious operation may be performed on the device, which is not secure. Absent. In addition, when the user rejects a request from a secure web application trusted by the device vendor, there is a problem that the service related to the web application cannot be used.

The present invention has been made to solve the above problems. An object of the present invention is to provide a mechanism capable of appropriately presenting to a user information for determining the safety of a Web application that has requested access to an external terminal (device) connected to an information processing device. It is what

The present invention is an information processing device in which a web browser is executed, and when the web browser accesses a website including a web application, a request for connection to an external terminal connected to the information processing device is made. If there is, the web browser uses the information about the reliability acquired from the external terminal to obtain the information indicating the acquisition destination of the information about the reliability, and the information about the reliability acquired through the network using the acquired information. , A verification means for verifying the website that has requested the connection, and, according to the result of the verification, warns the content displayed on the screen for confirming whether or not to permit the user to connect the website to an external terminal. And a control means for switching whether or not to include.

According to the present invention, it is possible to appropriately present to a user information for determining the safety of a web application that has requested access to an external terminal (device) connected to an information processing apparatus.

The figure which shows an example of the whole structure of the system which shows this embodiment. FIG. 3 is a hardware configuration diagram of an information processing apparatus that configures a client computer, a device, and a Web server. The functional block diagram of a client computer, a device, and a Web server. The sequence diagram which shows an example of an access permission process. The flowchart which shows the access permission process of 1st Embodiment. The flowchart which shows the detailed procedure of a verification process. The flowchart which shows the detailed procedure of the verification process by a whitelist. The flowchart which shows the detailed procedure of the verification process by a landing page. The UI figure which shows the example of a display of a permission prompt. The flowchart which shows the procedure of the access permission process of 2nd Embodiment. The flowchart which shows the detailed procedure of the reconfirmation process of access permission information.

Embodiments for carrying out the present invention will be described below with reference to the drawings.
[First Embodiment]
<System configuration>
FIG. 1 is a diagram showing an example of the overall configuration of a system showing an embodiment of the present invention.
In FIG. 1, a client computer 101 is a computer used by a user. The client computer 101 may be a personal computer, a laptop computer, a tablet computer, a smartphone, or the like.

The device 102 is a device that is used by connecting to the client computer 101. In the present embodiment, a USB (Universal Serial Bus) device will be described as an example of the device 102. However, the device 102 is not limited to the USB device, and may be, for example, a Bluetooth device as long as it is a device connected to the client computer 101. Note that there may be a configuration in which there are a plurality of devices 102 that are used by connecting to the client computer 101. The client computer 101 and the device 102 are communicatively connected via a wired or wireless connection 105. In the above example, the connection 105 is a USB connection.

The web server 103 provides a web application (web application) to the client computer 101 via the network. Here, the administrator of the Web server 103 (provider of the Web application) may be different from the vendor of the device 102 (the provider of the device 102).

The web server 104 provides the whitelist to the client computer 101 via the network. Here, the white list is a list of Web applications trusted by the device vendor. The administrator (whitelist provider) of the Web server 104 is the vendor of the device 102.

The client computer 101 and the Web servers 103 and 104 are connected via the network 106. The network 106 is, for example, the Internet. The network 106 is a communication network realized by any one of a LAN, a WAN, a telephone line, a dedicated digital line, an ATM or a frame relay line, a cable television line, a data broadcasting wireless line, or a combination thereof.

<Hardware configuration of information processing device>
FIG. 2 is a block diagram showing an example of the hardware configuration of an information processing apparatus that configures the client computer 101, the device 102, and the Web servers 103 and 104.
As shown in FIG. 2, the information processing apparatus includes a CPU 201 that executes software stored in a hard disk drive (HDD) 203 that is a storage device. The CPU 201 comprehensively controls each hardware connected to the system bus 205.

The memory 202 functions as a main memory and a work area of the CPU 201.
A hard disk drive (HDD) 203 records data as a mass storage device. Incidentally, instead of or in combination with the HDD, another storage device such as a solid state drive (SSD) may be provided.
A network interface card (NIC) 204 bidirectionally exchanges data with other nodes via a network.

The keyboard controller 206 controls input from an input device such as a keyboard 207 or a pointing device (for example, a mouse) not shown. Depending on the role of the information processing device, the keyboard controller 206, the keyboard 207, etc. may be omitted.
The display controller 208 controls display on a display device 209 such as a liquid crystal display. Depending on the role of the information processing device, the display controller 208 and the display device 209 may be omitted.

<Functional configuration>
FIG. 3 is a block diagram showing an example of the functional configuration of the client computer 101, the device 102, and the web servers 103 and 104.
The client computer 101 includes a web browser (web browser) 301. The web browser 301 provides a function of analyzing and displaying HTML data of a web application acquired from the web server 103, a function of analyzing and executing Javascript (registered trademark) of the web application, and the like. Furthermore, the web browser 301 executes an access permission process when receiving a request for access to the device 102 from the web application, and verifies the safety of the web application. Details of the access permission processing will be described later. The web browser 301 is realized by the CPU 201 of the client computer 101 loading a program stored in the HDD 203 into the memory 202 and executing the program.

The web server 103 includes a web application management unit 302. The web application management unit 302 provides a web application such as HTML or Java Script in response to a request from the web browser 301. The Web application of the present embodiment includes JavaScript that accesses and operates the device 102. The web application management unit 302 is realized by the CPU 201 of the web server 103 loading a program stored in the HDD 203 into the memory 202 and executing the program.

The device 102 includes a whitelist acquisition destination management unit 303, a landing page management unit 304, and a device control unit 305. The whitelist acquisition destination management unit 303, the landing page management unit 304, and the device control unit 305 are realized by the CPU 201 of the device 102 loading a program stored in the HDD 203 into the memory 202 and executing the program.

The whitelist acquisition destination management unit 303 provides a whitelist acquisition destination in response to a request from the web browser 301. Here, the white list is a list of Web applications provided by a device vendor that trust access to the device 102. The white list of this embodiment is a list of domains of the web server 103 of a trusted web application. The whitelist acquisition source of this embodiment is the address of the whitelist acquisition API (Application Programming Interface) of the Web server 103 managed by the device vendor.

The landing page management unit 304 provides the address of the landing page in response to the request from the web browser 301. Here, the landing page is a Web application that can be displayed when the device 102 is connected to the client computer 101. The address of the landing page is set in the device 102 by the device vendor.
The device control unit 305 provides a function of receiving an operation instruction from a web application permitted to access via the web browser 301 and executing an operation according to the operation instruction.

The web server 104 includes a whitelist management unit 306. The whitelist management unit 306 supports services on the network managed by the device vendor and provides a whitelist in response to a request from the Web browser 301. In the present embodiment, the whitelist is returned when the whitelist acquisition API of the web server 104 is called. The whitelist management unit 306 is realized by the CPU 201 of the Web server 104 loading a program stored in the HDD 203 into the memory 202 and executing the program.

<Access permission processing>
The access permission process will be described below with reference to FIGS. 4 and 5.
The access permission process is a process for obtaining an access permission required for the Web application to access the device 102.
FIG. 4 is a sequence diagram showing an example of each process of the device 102, the web browser 301, the web application 302a, and the web servers 103 and 104 in the access permission process. The web application 302a corresponds to the web application managed by the web application management unit 302 of the web server 103.

FIG. 5 is a flowchart showing an example of the procedure of the access permission process executed by the web browser 301 in the first embodiment. Note that the processes shown in FIG. 5 and FIGS. 6 to 8 described later are realized by the CPU 201 of the client computer 101 loading a program stored in the HDD 203 into the memory 202 and executing the program.

First, the user performs an operation for accessing a web application via the web browser 301 of the client computer 101. When an operation for accessing the web application is performed, the web browser 301 transmits a web application acquisition request to the web server 103 (S401).
Upon receiving the Web application acquisition request, the Web application management unit 302 of the Web server 103 returns the Web application 302a to the Web browser 301 in response to the request.

Next, the web browser 301 processes the web application 302a acquired in S401 and executes Javascript included in the web application 302a (S402). The Javascript included in the Web application 302a of the present embodiment includes a process of accessing and operating the device 102 connected to the client computer 101.

When Javascript included in the web application 302a is executed by the web browser 301, the web application 302a transmits an access request to the web browser 301 (S403). This access request is a request for acquiring information on one or more devices connected to the client computer 101. Specifically, the access request is, for example, a request for acquiring from the OS of the client computer 101 the information of the connected device connected to the client computer 101 by USB or Bluetooth. By this request, the web browser 301 can acquire the information of the device 102. Note that a filter can be set for the access request, and the vendor ID, product ID, and serial number can be specified as a filter so that the provider of the Web application 302a can customize such that only the information of the desired device is acquired. Is. That is, it is possible to obtain information such as only the information of the device 102 or only the information of the connected device of the same vendor as the device 102 in the Web browser 301.
Upon receiving the access request, the web browser 301 starts the access permission process. Here, the access permission process will be described with reference to FIG.

Upon receiving the access request from the web application 302a (S501), the web browser 301 advances the process to S502.
In step S502, the web browser 301 acquires access permission information corresponding to a combination of the web application 302a that has requested access and one or more connected devices that are access request targets from a storage area managed by the web browser 301. Here, the access permission information is information on a combination of a device (access permitted device) and a Web application that the user has permitted to access at a permission prompt described later. The access permission information is information managed by the Web browser 301 in a table such as Table 1, and is stored in the HDD 203, for example. In the present embodiment, the access permission information, which is the information of the combination of the device and the Web application that the user has permitted to access at the permission prompt, is stored in the storage area managed by the Web browser 301, and the permission prompt is displayed at the next access. Omitted.

Table 1 shows an example of a table in which the web browser 301 manages access permission information.
In the present embodiment, the combination of the device vendor ID, the product ID, and the serial number is used as the device identification information, but the device model name or the like may be used as the device identification information. Further, the domain of the web server 103 that provides the web application is used as the web application identifier. Further, the access permission information also manages the verification result of the Web application executed in S507 described below (the verification result of whether the Web application is trusted by the device vendor).

Subsequently, in step S503, the web browser 301 determines whether access to the connected device from the web application 302a has already been permitted. That is, in S503, it is determined whether or not the access permission information corresponding to the combination of the Web application 302a that requested access in S502 and the connected device that is the target of the access request has been acquired. In this determination process, when there are a plurality of connected devices that are the target of the access request from the Web application 302a, it is determined whether or not all the access permission information corresponding to the combination has been acquired. Then, when all of them can be acquired, it is determined that the access from the Web application 302a to the connected device has been permitted. On the other hand, if there is a combination that cannot be acquired, it is determined that access from the Web application 302a to the connected device has not been permitted.

Here, when the web browser 301 determines that access from the web application 302a to the connected device has been permitted (Yes in S503), the process proceeds to step S512. In step S512, the web browser 301 returns a notification of access permission to the web application 302a, and ends the process of this flowchart.
On the other hand, when the web browser 301 determines that the access from the web application to the connected device is not permitted (No in S503), the process proceeds to S504.

In S<b>504 to S<b>508, the web browser 301 controls to execute the processes of S<b>505 to S<b>507 with respect to all the connection devices that have not been permitted to access among the one or more connection devices that are the target of the access request from the web application 302 a. To do. That is, the processes of S505 to S507 are executed for the device for which the access permission information corresponding to the combination of the Web application 302a requested to access in S502 and the connected device cannot be acquired. The details will be described below.

In step S504, the web browser 301 selects one unprocessed connected device, sets the selected device as a processing target, and advances the processing to step S505.
In step S505, the web browser 301 transmits an acquisition request for a whitelist acquisition destination to the device to be processed. Upon receiving the acquisition request for the whitelist acquisition destination, the whitelist acquisition destination management unit 303 of the device to be processed returns the whitelist acquisition destination to the Web browser 301 in response to the request. Upon receiving the whitelist acquisition destination, the web browser 301 advances the process to S506.

In step S506, the web browser 301 transmits a whitelist acquisition request to the web server 104 corresponding to the whitelist acquisition source acquired in step S505. Upon receiving the whitelist acquisition request, the whitelist management unit 306 of the Web server 104 returns the whitelist to the Web browser 301 in response to the request. Upon receiving the whitelist, the web browser 301 advances the process to S507.

In step S507, the web browser 301 verifies the safety of the web application 302a that has requested access to the processing target device 102 (verification process). In the verification process, it is possible to obtain a determination result as to whether or not the Web application 302a that has requested access to the device to be processed is trusted by the vendor of the device. Details of the verification process will be described later with reference to FIG.

Subsequently, in step S508, the web browser 301 determines whether there is a device (unprocessed device) that has not performed the processes of steps S505 to S507. If it is determined that there is an unprocessed device, the Web browser 301 returns the process to S504 and shifts to the process of the next unprocessed device.
On the other hand, if it is determined that there is no unprocessed device, the web browser 301 advances the process to S509.

In step S<b>509, the web browser 301 displays a permission prompt as shown in FIG. 9A or FIG. 9B based on the verification result of step S<b>507, and waits for the user to input whether to permit access. Here, the permission prompt will be described with reference to FIG.

<Permission prompt>
FIG. 9 is a diagram showing an example of a user interface (UI) screen corresponding to the permission prompt displayed in S509 shown in FIG. In this embodiment, the display of the permission prompt is changed depending on whether or not the Web application requesting access to the device is trusted by the device vendor based on the verification result of S507 in FIG. As a result, when the user gives access permission, information for judging whether the Web application is safe is presented.

FIG. 9A is a display example of a permission prompt in the case where the Web application making the access request is trusted by the device vendor.
The window 901 is the window of the web browser 301 displaying and executing the web application acquired from the web server 103. The address display 902 is a display of the address of the Web server 103 of the Web application displayed/executed by the Web browser 301.

The permission prompt 903 is a permission prompt displayed by the web browser 301 when the web application requests access to the device.
The list 904 is a list of devices that are the target of the access request from the Web application. The user selects a device to which access is permitted from the list 904. Here, the Web application (abc.com) requesting access to the device (“ABC Device” and “ABC Mobile”) is trusted by the vendor of the device (“ABC Device” and “ABC Mobile”). That is, it is determined in the verification process of S507 of FIG. 5 that the Web application is trusted by the device vendor. Therefore, the Web browser 301 displays an icon 907 indicating that it is trusted to the left of the device name. By the display of this icon 907, when the user determines the access permission, the information for determining whether or not the Web application is safe (in this example, the information indicating “trusted by the device vendor”) is appropriate. Can be presented to.

The connection button 905 is a button (access permission button) that is pressed to permit access from the Web application to the device. The cancel button 906 is a button (access denial button) that is pressed when access from the Web application to the device is not permitted.

FIG. 9B is a display example of a permission prompt in the case where the Web application making the access request is not trusted by the device vendor. The same components as those in FIG. 9A are designated by the same reference numerals. is there.

The list 914 is a list of devices that are the basis of the access request from the Web application, and particularly corresponds to a display example when the Web application requesting access to the device is not trusted by the device vendor.
The Web application (xxx.com) that requested access to the device (“ABC Device” and “ABC Mobile”) is not trusted by the vendor of the device (“ABC Device” and “ABC Mobile”). That is, it is determined in the verification process of S507 of FIG. 5 that the Web application is not trusted by the device vendor. Therefore, the Web browser 301 displays an icon 917 indicating that it is not trusted to the left of the device name. By the display of this icon 917, information for determining whether or not the Web application is safe when the user permits or denies access (here, information indicating "not trusted by the device vendor") is displayed. Can be properly presented.

That is, when the Web application that has requested access to the device is included in the white list, an icon 907 indicating that the device is trusted is displayed in the permission prompt to reassure the user. On the other hand, when the web application that has requested access to the device is not included in the white list, an icon 917 indicating that the device is not trusted is displayed in the permission prompt to warn the user.
Further, even if the whitelist acquisition destination or the whitelist acquisition shown in S505 and S506 fails, or even if the connected device does not support the whitelist, as shown in FIG. The prompt may display an icon 917 indicating that it is not trusted.

Hereinafter, the description returns to the flowchart of FIG.
Upon receiving an input as to whether or not to permit access from the permission prompt displayed in S509, the web browser 301 advances the process to S510.

In step S510, the web browser 301 determines whether or not the user has permitted access according to the permission prompt in step S509. Here, when the web browser 301 determines that the user has permitted access (Yes in S510), the process proceeds to S511.

In step S<b>511, the web browser 301 registers access permission information including information on the combination of the device (device to be processed) the user has permitted access to and the web application 302 a in a table such as Table 1. At that time, the web browser 301 also registers the verification result of the web application executed in S507 (whether or not the web application is trusted by the device vendor).
Subsequently, in step S512, the web browser 301 returns an access permission notification to the web application 302a, and ends the processing of this flowchart.

On the other hand, if the Web browser 301 determines in step S510 that the user has not permitted access (No in step S510), the process proceeds to step S513.
In step S513, the web browser 301 returns a notification of access disapproval to the web application 302a, and ends the processing of this flowchart.

<Verification process>
FIG. 6 is a flowchart showing an example of a detailed procedure of the verification process executed in S507 shown in FIG. The verification process of the present embodiment is a process of verifying the security of a web application by determining whether the web application requesting access to the device is a web application trusted by the device vendor.

When the verification process is started, in S601, the Web browser 301 determines whether or not the white list has been acquired by the processes of S505 and S506 of FIG. If the Web browser 301 determines that the white list has been acquired (Yes in S601), the process proceeds to S602.
In step S<b>602, the web browser 301 verifies the safety of the web application that has requested access to the device 102 using the whitelist (whitelist verification process). Then, the Web browser 301 ends this processing, and returns the processing to FIG. 5 with the verification processing result by the whitelist as the verification processing result. Details of the whitelist verification process will be described later with reference to FIG. 7.

On the other hand, in step S601, when the web browser 301 determines that the white list cannot be acquired (No in step S601), the processing proceeds to step S603.
In step S603, the web browser 301 verifies the safety of the web application requesting access to the device 102 using the landing page address (landing page verification process). Then, the web browser 301 ends this processing, and returns the processing to the processing in FIG. 5 with the verification result of the landing page as the verification processing result. The details of the verification process using the landing page will be described later with reference to FIG.

FIG. 7 is a flowchart showing an example of a detailed procedure example of the verification processing by the whitelist executed in S602 shown in FIG. The whitelist verification process is a process of determining whether or not the access-requested Web application is a Web application trusted by the device vendor of the device to be processed, using the whitelist.

When the verification processing based on the white list is started, in step S701, the web browser 301 determines whether the access-requested web application 302a is included in the white list acquired in step S506 of FIG. Here, when the web browser 301 determines that the web application 302a is included in the white list (Yes in S701), the process proceeds to S702.
In step S<b>702, the web browser 301 determines that the access-requested web application 302 a is “a web application trusted by the device vendor”. Then, the Web browser 301 ends this processing, and returns the processing to FIG. 6 with the judgment result as the verification processing result by the white list.

On the other hand, in step S701, when the web browser 301 determines that the web application is not included in the white list (No in step S701), the process proceeds to step S703.
In step S703, the web browser 301 determines that the web application that requested the access is “a web application that is not trusted by the device vendor”. Then, the Web browser 301 ends this processing, and returns the processing to FIG. 6 with the judgment result as the verification processing result by the white list.

FIG. 8 is a flowchart showing an example of a detailed procedure of the verification processing by the landing page executed in S603 shown in FIG. The verification process using the landing page is a process of determining whether or not the access-requested Web application is a Web application trusted by the device vendor of the device to be processed, using the address of the landing page. This process is a process performed for a device that does not provide a whitelist.

When the verification process by the landing page is started, the web browser 301 transmits a request for acquiring the address of the landing page to the device to be processed in S801. When the landing page management unit 304 of the processing target device receives the acquisition request for the address of the landing page, the landing page management unit 304 returns the address of the landing page to the Web browser 301 in response to the request. Upon receiving the address of the returned landing page, the web browser 301 advances the process to S802.

In step S802, the web browser 301 determines whether the domain of the web server 103 of the web application 302a that has requested access to the device to be processed is the same as the domain of the landing page address acquired in step S801. If the web browser 301 determines that the domain of the web application 302a and the domain of the landing page are the same (Yes in S802), the process advances to S803.

In step S<b>803, the web browser 301 determines that the access-requested web application is “a web application trusted by the device vendor”. Then, the web browser 301 ends this processing, and returns the processing to FIG. 6 with the judgment result as the verification processing result by the landing page.

On the other hand, when the web browser 301 determines in step S802 that the domain of the web application and the domain of the landing page are not the same (No in step S802), the process proceeds to step S804.

In step S<b>804, the web browser 301 determines that the access-requested web application is “a web application that is not trusted by the device vendor”. Then, the web browser 301 ends this processing, and returns the processing to FIG. 6 with the judgment result as the verification processing result by the landing page.

As described above, the security of the Web application requesting access to the device is confirmed with the device vendor, and the icon 907 shown in FIG. 9A or the icon 917 shown in FIG. 9B is displayed. You can As described above, according to the first embodiment, it is possible to confirm the information for determining the safety of the Web application requesting access to the device with the device vendor and appropriately present the information to the user.

[Second Embodiment]
The second embodiment shows a configuration for reconfirming whether or not the Web application that the user has permitted to access in the past is still trusted by the device vendor.

In the above-described first embodiment, the display of the permission prompt is omitted in the next access for the combination of the device and the Web application that the user has permitted to access with the permission prompt in the past. However, when the device vendor updates the white list, the web application previously included in the white list may be deleted from the white list. For example, if a security hole is found in a web application included in the white list, the device vendor may delete the web application from the white list. In such a case, the web application deleted from the white list is not safe.

Therefore, in the second embodiment, it is checked again whether or not the web application that the user has permitted to access in the past is still trusted by the device vendor. Then, in the case of a web application that is no longer trusted, the user is notified by a permission prompt.
Hereinafter, the differences from the first embodiment will be described, and the description of the same parts as the first embodiment will be omitted.

<Access permission processing>
FIG. 10 is a flowchart showing an example of the procedure of the access permission process executed by the web browser 301 in the second embodiment. Note that the processing shown in FIG. 10 and FIG. 11 described later is realized by the CPU 201 of the client computer 101 loading the program stored in the HDD 203 into the memory 202 and executing the program. The same steps as those in FIG. 5 are designated by the same step numbers, and the description of these steps will be omitted.

In the second embodiment, when the web browser 301 determines that the access from the web application to the device has been permitted (Yes in S503), the process proceeds to S1001.

In step S1001, the Web browser 301 reconfirms the access permission information (access permission information reconfirmation process). In the reconfirmation process of the access permission information, it is not necessary to reconfirm the user using the permission prompt for the Web application 302a that has requested access to the processing target device (determined as permitted), and the user reconfirmation using the permission prompt is not necessary. Obtain a judgment result that confirmation is necessary (it is judged that it has become untrustworthy). Details of the reconfirmation processing of the access permission information will be described later with reference to FIG.

Subsequently, in step S1002, the web browser 301 determines whether or not the access from the web application to the device has been permitted as a result of the reconfirmation processing of the access permission information in step S1001. Here, as a result of the reconfirmation processing of the access permission information, the web browser 301 determines that the access to the device from the web application has been permitted (no need for reconfirmation of the user by the permission prompt) (Yes in S1002). , S512. Note that the processing from S512 onward is the same as that in the first embodiment, so description thereof will be omitted.

On the other hand, if the Web browser 301 determines that the Web application is no longer trusted by the device vendor as a result of the reconfirmation processing of the access permission information (requires reconfirmation of user by permission prompt) (No in S1002), The process proceeds to S509. Note that the processing after S509 is the same as that in the first embodiment, and thus the description thereof is omitted.

Although not shown in FIG. 10, when there are a plurality of connected devices for which an access request is issued from the Web application 302a, the access permission information of S1001 is set for all the access permission information corresponding to the combination. Perform the reconfirmation process of. Then, in S1002, if the reconfirmation results of all the access permission information are "permitted", it is determined as Yes. On the other hand, if at least one of the access permission information reconfirmation results is not "permitted", the determination is No, and the permission prompt is displayed in S509.

<Reconfirmation process of access permission information>
FIG. 11 is a flowchart showing an example of a detailed procedure of the reconfirmation processing of the access permission information executed in S1001 shown in FIG.
When the access permission information reconfirmation process is started, in step S1101, the web browser 301 determines whether the web application was trusted by the device vendor when the user permitted access in the past. That is, it is determined whether the verification result of the access permission information acquired in S502 of FIG. 10 is “trusted”. In other words, this determination corresponds to the determination as to whether or not the Web application that has been permitted to access in the past was included in the white list acquired at the timing corresponding to the permission or matched with the landing page.

Here, when the web browser 301 determines that the web application is not trusted by the device vendor when the access is permitted (No in S1101), the process proceeds to S1105. The processing after S1105 will be described later.

On the other hand, in step S1101, when the web browser 301 determines that the web application is trusted by the device vendor when the access is permitted (Yes in step S1101), the process proceeds to step S1102.

In step S1102, the web browser 301 transmits an acquisition request for the whitelist acquisition destination to the device corresponding to the access permission information acquired in step S502 of FIG. Upon receiving the whitelist acquisition destination acquisition request, the whitelist acquisition destination management unit 303 of the device returns the whitelist acquisition destination to the Web browser 301 in response to the request. Upon receiving the returned whitelist acquisition source, the Web browser 301 advances the process to S1103.

In step S1103, the web browser 301 transmits a whitelist acquisition request to the web server 104 that is the whitelist acquisition destination acquired in step S1102. Upon receiving the whitelist acquisition request, the whitelist management unit 306 of the web server 104 returns the whitelist to the web browser 301 in response to the request. Upon receiving the returned whitelist, the web browser 301 advances the process to S1104.

In step S1104, the web browser 301 determines whether the access-requested web application is included in the white list acquired in step S1103. If the web browser 301 determines here that the web application is included in the white list (Yes in step S1104), the process advances to step S1105.
In step S1105, the web browser 301 determines that access from the web application to the device has been permitted, ends this processing, and returns the determination result to the processing of FIG.

On the other hand, if the web browser 301 determines in step S1104 that the web application is not included in the white list (NO in step S1104), the process advances to step S1106.
In step S1106, the web browser 301 determines that the web application requesting access to the device 102 is a web application that is no longer trusted by the device vendor, terminates this processing, and returns the determination result to the processing of FIG. ..

Although not shown in FIG. 11, in the reconfirmation process of the access permission information, if the whitelist does not exist, the verification process by the landing page is performed as in the processes of FIGS. 6 and 8. Good.

As described above, according to the second embodiment, the device vendor is reconfirmed with the information for determining the safety of the web application that has requested the access to the device even if the web application has been permitted by the user in the past. Can be properly presented to the user.

In the verification process of each of the above embodiments, the whitelist is used to verify the reliability of the Web application. However, the verification process may be performed using a black list including information (domain etc.) that identifies unreliable (dangerous) Web applications. The verification process may be performed using a white list or a black list. For example, the white list may be used when the white list can be acquired from the acquisition source acquired from the device, and the black list may be used when the black list can be acquired from the acquisition source. In the case of using the blacklist, when the domain of the Web application requesting access to the device is included in the blacklist, a warning is displayed in the display content of the permission prompt (for example, an icon 917 indicating that the device is not trusted). Shall be included.

As described above, according to each embodiment, it is possible to appropriately present the information for determining the safety of the web application requesting access to the device (external terminal connected to the information processing apparatus) to the user. This makes it easier for users to identify requests from malicious or less secure web applications that the device vendor does not trust, and allows users to easily grant requests from such web applications. It becomes possible to suppress that. As a result, it is possible to reduce the risk and improve security when accessing a website including a web application with a web browser.

The configurations and contents of the various data described above are not limited to this, and may be configured with various configurations and contents depending on the use and purpose.
Although one embodiment has been described above, the present invention can be implemented as, for example, a system, an apparatus, a method, a program, a storage medium, or the like. Specifically, it may be applied to a system composed of a plurality of devices, or may be applied to an apparatus composed of one device.
Further, the present invention also includes all configurations in which the above-described embodiments are combined.

(Other embodiments)
The present invention supplies a program that implements one or more functions of the above-described embodiments to a system or apparatus via a network or a storage medium, and one or more processors in a computer of the system or apparatus read and execute the program. It can also be realized by the processing. It can also be realized by a circuit (for example, ASIC) that realizes one or more functions.
Further, the present invention may be applied to a system including a plurality of devices or an apparatus including one device.
The present invention is not limited to the above-described embodiments, and various modifications (including organic combinations of the embodiments) are possible based on the gist of the present invention, which are excluded from the scope of the present invention. is not. That is, the present invention includes all configurations that combine the above-described embodiments and the modifications thereof.

Claims (11)

An information processing device that executes a web browser,
When accessing a website including a web application with the web browser, if there is a request for connection to an external terminal connected to the information processing device, the web browser sends information regarding reliability from the external terminal. Acquisition means for acquiring information indicating the acquisition destination,
Verification means for verifying the website that has requested the connection, using the information about the reliability acquired via the network using the acquired information,
Control means for switching whether or not to include a warning in the display content of the screen for confirming whether the website allows the user to connect to the external terminal according to the result of the verification;
An information processing device comprising: The reliability information is a list containing information on trusted websites,
The information processing apparatus according to claim 1, wherein the control unit includes a warning in the display content of the screen when the information of the website requesting the connection is not included in the list. .. The information processing apparatus according to claim 1, wherein the information regarding the reliability is a list including information about websites that are not reliable.
The information processing apparatus according to claim 1, wherein the control unit includes a warning in the display content of the screen when the information of the website requesting the connection is included in the list. .. The information processing apparatus according to claim 2 or 3, wherein the information on the reliability includes information on a landing page indicating a website that can be displayed when the external terminal is connected to the information processing apparatus. The verification means, when the list cannot be obtained, uses the information of the landing page to verify the website requesting the connection,
When the information of the landing page is used, the control means includes a warning in the display content of the screen when the information of the website requesting the connection does not correspond to the information of the landing page. The information processing device according to claim 4. The information processing apparatus according to any one of claims 1 to 5, wherein the information processing apparatus is connected to an external terminal by USB or Bluetooth. If the user has previously permitted a web application included in the website to connect to the external terminal, the control means executes the verification and the screen display without the website The information processing apparatus according to claim 1, wherein connection to an external terminal is permitted. The control means obtains the information on the reliability when a web application included in the website has been permitted by the user to connect to the external terminal in the past and at a timing corresponding to the permission. If it is, the information regarding the reliability is acquired again by using the information indicating the acquisition destination acquired from the external terminal, and the verification is performed. The information processing device according to item. The information on the reliability is obtained from a service on a network managed by a business operator that provides the external terminal,
9. The information processing apparatus according to claim 1, wherein the information indicating the acquisition destination of the information regarding the reliability acquired from the external terminal is set in the external terminal by the business operator. .. A method for controlling an information processing device in which a web browser is executed,
When accessing a website including a web application with the web browser, if there is a request for connection to an external terminal connected to the information processing device, the web browser sends information regarding reliability from the external terminal. An acquisition step of acquiring information indicating the acquisition source,
A verification step of verifying the website that has requested the connection, using the information about the reliability acquired via the network using the acquired information,
A control step of switching whether or not to include a warning in the display content of the screen for confirming whether the website allows the user to connect to the external terminal according to the result of the verification,
A method for controlling an information processing apparatus, comprising: A program for causing a computer to function as the means according to any one of claims 1 to 9.