Determination device, determination method, and determination program

Abstract

A determination device (10) includes a scenario creation unit (131), an execution control unit (132), and a determination unit (134). The scenario creation unit (131) creates a scenario for a test that includes access to a web page that requests, via a browser, authorization to acquire data from equipment provided in a device that executes the browser. The execution control unit (132) causes the browser of an execution device (20) to execute the scenario. The determination unit (134) determines whether or not the web page or browser is vulnerable on the basis of the result of executing the scenario.

Description

[Technical Field]

[0001] The present invention relates to a determination device, a determination method, and a determination program. [Background technology]

[0002] To realize a wide range of content, there are websites that are linked to the camera, microphone, and GPS (Global Positioning System) functions of the execution device 20. Such websites provide services such as maps, video conferencing, and voice chat.

[0003] Furthermore, when a website wants to obtain privacy-sensitive data such as location information, camera footage, or microphone audio, it requests permission from the user through the permission mechanism of the web browser (hereafter simply referred to as the browser). The browser's behavior in requesting such permission is called a permission request or an authority request.

[0004] If there is a vulnerability in the implementation of permissions, privacy data may be accessed and violated in ways that the user does not intend.

[0005] Conventionally, there are known techniques for investigating security problems in browsers (see, for example, Non-Patent Document 1 and Non-Patent Document 2). [Prior art documents] [Non-patent literature]

[0006] [Non-Patent Document 1] Gertjan Franken et al. (2018 USENIX), Who Left Open the Cookie Jar? A ComprehensiveEvaluation of Third-Party Cookie Policies [Non-patent document 2] Tales of Favicons and Caches: Persistent Tracking in Modern Browsers Summary of the Invention [Problem to be solved by the invention]

[0007] However, conventional techniques have the problem that they may not be able to detect browser vulnerabilities related to permissions.

[0008] For example, the technology described in Non-Patent Document 1 investigates vulnerabilities related to cookies. Also, for example, the technology described in Non-Patent Document 2 investigates vulnerabilities in which users are tracked by Favicons. In this way, the technologies described in Non-Patent Document 1 and Non-Patent Document 2 investigate security issues in browsers, but do not investigate vulnerabilities related to permissions. [Means for solving the problem]

[0009] In order to solve the above-mentioned problems and achieve the objectives, the judgment device is characterized by having a scenario creation unit that creates a test scenario including access to a web page via a browser that requests permission to obtain data from equipment provided in a device that runs the browser, an execution control unit that causes the browser to execute the scenario, and a judgment unit that determines whether or not the web page or the browser has a vulnerability based on the execution result of the scenario. [Effects of the Invention]

[0010] According to the present invention, browser vulnerabilities related to permissions can be discovered. [Brief explanation of the drawings]

[0011] [Figure 1] FIG. 1 is a diagram illustrating an example of the configuration of a determination device. [Figure 2] FIG. 2 is a diagram illustrating an example of a scenario. [Figure 3] FIG. 3 is a diagram illustrating an example of a scenario. [Figure 4] FIG. 4 is a diagram illustrating an example of a scenario. [Figure 5] FIG. 5 is a diagram illustrating an example of a scenario. [Figure 6] FIG. 6 is a diagram illustrating an example of a scenario. [Figure 7] FIG. 7 is a diagram illustrating an example of a scenario. [Figure 8] FIG. 8 is a flowchart showing the flow of processing by the determination device. [Figure 9] FIG. 9 illustrates an example of a computer that executes a determination program. DETAILED DESCRIPTION OF THE INVENTION

[0012] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Preferred embodiments of a determination device, a determination method, and a determination program according to the present invention will be described in detail below with reference to the accompanying drawings. However, the present invention is not limited to the following embodiments.

[0013] [Configuration of the first embodiment] First, the configuration of the analysis system of the first embodiment will be described with reference to Fig. 1. Fig. 1 is a diagram showing an example of the configuration of a determination device.

[0014] The determination device 10 creates a test scenario for investigating browser permission vulnerabilities. The determination device 10 causes the browser of the execution device 20 to execute the scenario. The determination device 10 also determines the vulnerability of the browser of the execution device 20. Note that the browser may be, for example, Chrome (registered trademark), Firefox (registered trademark), Opera, Safari (registered trademark), or the like.

[0015] The execution device 20 functions as a host that provides a web page and as a client that requests the web page.

[0016] As shown in FIG. 1, the determination device 10 includes a communication unit 11, a storage unit 12, and a control unit 13.

[0017] The communication unit 11 is an interface for transmitting and receiving data to and from other devices, and is, for example, a network interface card (NIC).

[0018] The storage unit 12 is a storage device such as a hard disk drive (HDD), a solid state drive (SSD), an optical disk, etc. Note that the storage unit 12 may also be a data-rewritable semiconductor memory such as a random access memory (RAM), a flash memory, or a non-volatile static random access memory (NVSRAM).

[0019] The storage unit 12 stores data related to the OS (Operating System) and various programs executed by the determination device 10. For example, the storage unit 12 stores scenario information 121 and test result information 122.

[0020] The scenario information 121 is a test scenario. The scenario information 121 may also be information on unit tests, which are units that make up a test scenario. The unit tests are browser operations such as "accessing a specified web page," "selecting permission," "closing the browser," "launching (or restarting) the browser," "accessing a linked web page," "refreshing the page," "entering a specified character string into a text box," and "pressing a button."

[0021] The test result information 122 is the test results collected from the group of execution devices 20. The test result information 122 may be a log of the execution device 20, data output by the execution device 20 as test results, or a browser screen capture.

[0022] The control unit 13 controls the entire determination device 10. The control unit 13 is, for example, an electronic circuit such as a CPU (Central Processing Unit), an MPU (Micro Processing Unit), or a GPU (Graphics Processing Unit), or an integrated circuit such as an ASIC (Application Specific Integrated Circuit) or an FPGA (Field Programmable Gate Array).

[0023] The control unit 13 also has an internal memory for storing programs that define various processing procedures and control data, and executes each process using the internal memory. The control unit 13 also functions as various processing units by running various programs.

[0024] For example, the control unit 13 functions as a scenario creation unit 131, an execution control unit 132, an acquisition unit 133, and a determination unit .

[0025] The scenario creation unit 131 creates a test scenario that includes access, via a browser, to a web page that requests permission to acquire data from a device provided in the device that runs the browser.

[0026] For example, the scenario creation unit 131 writes scenarios such as those shown in Figures 2, 3, 4, 5, 6, and 7. Figures 2, 3, 4, 5, 6, and 7 are diagrams showing examples of scenarios. A scenario may be one that can be expressed as a flowchart such as that shown in Figure 2. Details of each scenario will be described later.

[0027] The execution control unit 132 causes the browser of the execution device 20 to execute the scenario. The execution control unit 132 causes the execution device 20 to run the code that the scenario creation unit 131 has generated from the scenario.

[0028] The acquisition unit 133 acquires test results from the execution device 20. The test results include logs from the execution device 20, data output by the execution device 20, and browser screen captures.

[0029] The determination unit 134 determines whether or not there is a vulnerability in the web page or browser based on the execution result of the scenario. The determination unit 134 makes a determination based on the test result acquired by the acquisition unit 133.

[0030] Below, examples of scenarios will be explained using Figures 2, 3, 4, 5, 6 and 7. Each step in the flowcharts shown in the figures corresponds to a unit test.

[0031] In addition, here, for each scenario, the execution device 20 outputs either “α” or “β.” The determination unit 134 determines vulnerability based on “α” or “β” acquired by the acquisition unit 133.

[0032] [Scenario 1: Persistence of permission requests] 2 is a flowchart of the first scenario. The determination device 10 can determine the permanence of the permission request from the result of the first scenario.

[0033] The execution device 20 first accesses an authority request page (step S101). For example, the authority request page requests authority to acquire information (camera images, location information, etc.) from the execution device 20 via a browser.

[0034] Next, the permission request is displayed on a permission request page on the browser of the execution device 20 (step S102). For example, the permission request is displayed as a pop-up screen including a message and buttons for selecting whether or not to grant permission.

[0035] Here, the execution device 20 selects permission for the authority (step S103). For example, the execution device 20 performs an operation to press the "OK" button on the pop-up screen.

[0036] Then, the execution unit 20 closes the browser (step S104), and then restarts the browser (step S105). After that, the execution unit 20 accesses the authority request page (step S106).

[0037] Here, if the authority request is not displayed again on the authority request page after step S106 (step S107, No), the execution device 20 determines that the authority request is to be made permanent and outputs "α" (step S108).

[0038] On the other hand, if the authority request is displayed again on the authority request page after step S106 (step S107, Yes), the execution device 20 proceeds to step S110.

[0039] If steps S103 to S106 have been repeated N times (for example, N=5) (step S110, Yes), the execution device 20 determines that the authority request is not to be made permanent and outputs "β" (step S111).

[0040] If the execution device 20 has not repeated steps S103 to S106 N times (step S110, No), it returns to step S103 and repeats the process.

[0041] After step S108 or step S111, the execution unit 20 closes the browser (step S109).

[0042] The scenario creation unit 131 may create a scenario in which "select to grant authority" in step S103 of the first scenario is replaced with "select to deny authority."

[0043] [Second scenario: Automatically denying permission requests] 3 is a flowchart of the second scenario. Based on the results of the second scenario, the determination device 10 can determine whether permission (permission or denial) will be automatically performed by repeatedly leaving no selection in response to a privilege request.

[0044] The execution device 20 first accesses an authority request page (step S201). For example, the authority request page requests authority to obtain information (camera images, location information, etc.) from the execution device 20 via a browser.

[0045] Next, the permission request is displayed on a permission request page on the browser of the execution device 20 (step S202). For example, the permission request is displayed as a pop-up screen including a message and buttons for selecting whether or not to grant permission.

[0046] Here, the execution unit 20 refreshes the page without selecting whether to grant or deny the authority (step S203).

[0047] Here, if the permission request is not displayed again on the permission request page after step S203 (step S204, No), the execution device 20 determines that repeated non-selection will automatically result in permission being denied, and outputs "α" (step S205).

[0048] On the other hand, if the authority request is displayed again on the authority request page after step S203 (step S204, Yes), the execution device 20 proceeds to step S207.

[0049] Here, if step S203 has been repeated N times (for example, N=5) (step S207, Yes), the execution device 20 determines that repeated non-selection will not automatically result in approval or rejection, and outputs "β" (step S208).

[0050] If step S203 has not been repeated N times (step S207, No), the execution device 20 returns to step S203 and repeats the process.

[0051] After step S205 or step S208, the execution unit 20 closes the browser (step S206).

[0052] [Third Scenario: Automatic Permission Denial (Background)] 4 is a flowchart of the third scenario. Based on the result of the third scenario, the determination device 10 can determine whether permission (permission or denial) is automatically performed in the background by repeatedly leaving no selection in response to a permission request.

[0053] The execution device 20 first accesses an authority request page (step S301). For example, the authority request page requests authority to acquire information (camera images, location information, etc.) from the execution device 20 via a browser.

[0054] Next, the permission request is displayed on a permission request page on the browser of the execution device 20 (step S302). For example, the permission request is displayed as a pop-up screen including a message and buttons for selecting whether or not to grant permission.

[0055] Here, the execution unit 20 accesses the dummy page in a new tab of the browser without selecting whether to grant or deny the authority, and brings the new tab to the foreground (step S303).The execution unit 20 then refreshes the original page that has become the background (step S304).

[0056] The dummy page is, for example, a page that does not request authority and may be a blank page. Access to the dummy page may be performed in a different mode or by a different process than access to the authority-requesting page.

[0057] Here, if the permission request is not displayed again on the permission request page after step S304 (step S305, No), the execution device 20 determines that repeated non-selection will automatically result in permission being denied, and outputs "α" (step S306).

[0058] On the other hand, if the authority request is displayed again on the authority request page after step S304 (step S305, Yes), the execution device 20 proceeds to step S308.

[0059] Here, if step S304 has been repeated N times (for example, N=5) (step S308, Yes), the execution device 20 determines that repeated non-selection will not automatically result in approval or rejection, and outputs "β" (step S309).

[0060] If step S304 has not been repeated N times (step S308, No), the execution device 20 returns to step S304 and repeats the process.

[0061] After step S306 or step S309, the execution unit 20 closes the browser (step S307).

[0062] In this way, the scenario creation unit 131 creates a scenario (first scenario) in which, after selecting whether to permit or deny a request for authority from a web page accessed by a browser, the browser is restarted and the web page is accessed again.

[0063] Furthermore, the scenario creation unit 131 creates a scenario (second scenario) for updating a web page after an authorization request from the web page accessed by the browser is displayed.

[0064] Furthermore, the scenario creation unit 131 creates a scenario (third scenario) in which, after an authority request from a web page accessed by a browser is displayed, the web page is updated while the web page is in the background.

[0065] If the output of the first and second scenarios, or the first and third scenarios, is "α," the attacker can force a permission denial state (allowed or denied) without user interaction and make that state permanent. Furthermore, by checking the permission denial state when the user revisits the web page, the attacker can track users who have already visited the page without using cookies, etc.

[0066] The determination device 10 can perform the above-described vulnerability determination using the first scenario, the second scenario, and the third scenario.

[0067] [Scenario 4: Permission request permission transfer between modes (private → normal)] 5 is a flowchart of the fourth scenario. Based on the result of the fourth scenario, the determination device 10 can determine whether or not authority (permission of an authority request) is transferred from private mode to normal mode. Note that private mode is a mode in which so-called private browsing is performed, and browsing history and the like that are saved in normal mode are not saved.

[0068] The execution device 20 first accesses an authority request page in normal mode (step S401). For example, the authority request page requests authority to obtain information (camera images, location information, etc.) from the execution device 20 via a browser.

[0069] Next, the permission request is displayed on a permission request page on the browser of the execution device 20 (step S402). For example, the permission request is displayed as a pop-up screen including a message and buttons for selecting whether or not to grant permission.

[0070] Furthermore, when permission for the authority is selected (step S403), the execution device 20 accesses the authority request page in private mode (step S404).

[0071] Here, if the authority request is not displayed again on the authority request page after step S404 (step S405, No), the execution device 20 determines that the authority is inherited when the mode is switched from normal mode to private mode, and outputs "α" (step S406).

[0072] On the other hand, if the permission request is displayed again on the permission request page after step S404 (step S405, Yes), the execution device 20 determines that the permission is not carried over when the mode is switched from normal mode to private mode, and outputs "β" (step S408).

[0073] After step S406 or step S408, the execution unit 20 closes the browser (step S407).

[0074] [Scenario 5: Permission request permission transfer between modes (Private → Normal)] 6 is a flowchart of the fifth scenario. Based on the result of the fifth scenario, the determination device 10 can determine whether or not authority (permission of an authority request) is transferred from the normal mode to the private mode.

[0075] The execution device 20 first accesses an authority request page in normal mode (step S501). For example, the authority request page requests authority to obtain information (camera images, location information, etc.) from the execution device 20 via a browser.

[0076] Next, the permission request is displayed on a permission request page on the browser of the execution device 20 (step S502). For example, the permission request is displayed as a pop-up screen including a message and buttons for selecting whether or not to grant permission.

[0077] The executing device 20 selects permission for the authority (step S503). For example, the executing device 20 performs an operation to press the "OK" button on the pop-up screen.

[0078] Furthermore, the execution device 20 accesses the authority request page in private mode (step S504).

[0079] Here, if the permission request is not displayed again on the permission request page after step S504 (step S505, No), the execution device 20 determines that the permission is inherited when the mode is switched from normal mode to private mode, and outputs "α" (step S506).

[0080] On the other hand, if the permission request is displayed again on the permission request page after step S504 (step S505, Yes), the execution device 20 determines that the permission is not carried over when the mode is switched from normal mode to private mode, and outputs "β" (step S508).

[0081] After step S506 or step S508, the execution unit 20 closes the browser (step S507).

[0082] The scenario creation unit 131 may create a scenario in which "select to grant authority" in step S503 of the fifth scenario is replaced with "select to deny authority."

[0083] In this way, the scenario creation unit 131 creates scenarios (fourth and fifth scenarios) in which the user selects whether to grant or deny a request for authority from a web page accessed using a browser in the first mode, and then changes the browser to the second mode and accesses the web page again.

[0084] If the output of the fourth or fifth scenario is "α", the permission status is shared between normal mode and private mode, and the browser cannot be used while keeping user-specific information secret.

[0085] The determination device 10 can perform the above-described vulnerability determination using the fourth and fifth scenarios.

[0086] [Scenario 6: Permission request overlay] 7 is a flowchart of the sixth scenario. From the result of the sixth scenario, the determination device 10 can determine whether or not the authority request is displayed as an overlay on a page different from the page actually requested.

[0087] The execution device 20 first accesses an authorization request page that executes a delayed authorization request (step S601). For example, the authorization request page requests authorization to acquire information (camera images, location information, etc.) from the execution device 20 via a browser. In addition, in the authorization request page that executes a delayed authorization request, the authorization request is displayed a certain time after the content of the web page is displayed.

[0088] Next, the execution unit 20 accesses the dummy page in a new tab of the browser and brings the new tab to the foreground (step S602). After that, the execution unit 20 waits until a delayed authority request is made to the original page that has been brought to the background (step S603).

[0089] The dummy page is, for example, a page that does not request authority and may be a blank page. Access to the dummy page may be performed in a different mode or by a different process than access to the authority-requesting page.

[0090] Here, after step S603, if the authority request is overlaid (step S604, Yes), the execution device 20 determines that the authority request is overlaid on a page different from the page actually requested, and outputs "α" (step S605).

[0091] If step S604 returns Yes, the permission request is overlaid on the new tab that is in the foreground.

[0092] On the other hand, if the authority request is not displayed in an overlay after step S603 (step S604, No), the execution unit 20 determines that the authority request is not displayed in an overlay, and outputs "β" (step S607).

[0093] Note that cases where step S604 returns No include a case where the authority request is not displayed even after a certain time has passed, and a case where the authority request is displayed in the background and not shown on the screen.

[0094] In this way, the scenario creation unit 131 creates a scenario (sixth scenario) in which a web page accessed by a browser is placed in the background before an authorization request from the web page is displayed.

[0095] When the output of the sixth scenario is "α", an authorization request from a web page different from the page displayed to the user is overlaid, and the authorized destination recognized by the user may differ from the actual authorized destination.

[0096] The determination device 10 can perform the above-described vulnerability determination using the sixth scenario.

[0097] [Processing flow of the first embodiment] The flow of processing by the determination device 10 will be described with reference to Fig. 8. Fig. 8 is a flowchart showing the flow of processing by the determination device.

[0098] 8, first, the determination device 10 creates a scenario (step S11), and then the determination device 10 causes the execution device to execute the scenario (step S12).

[0099] The determination device 10 acquires the execution result of the scenario as a log (step S13), and then determines the vulnerability of the execution device based on the log (step S14).

[0100] [Effects of the first embodiment] As described above, the determination device 10 includes a scenario creation unit 131, an execution control unit 132, and a determination unit 134. The scenario creation unit 131 creates a test scenario that includes access to a web page via a browser that requests permission to acquire data from a device provided in the device that executes the browser. The execution control unit 132 causes the browser of the execution device 20 to execute the scenario. The determination unit 134 determines whether or not there is a vulnerability in the web page or browser based on the execution result of the scenario. According to the first embodiment, it is possible to discover browser vulnerabilities related to permissions.

[0101] [System configuration, etc.] Furthermore, the components of each device shown in the figure are functional concepts and do not necessarily have to be physically configured as shown. In other words, the specific form of distribution and integration of each device is not limited to that shown, and all or part of the devices can be functionally or physically distributed or integrated in any unit depending on various loads, usage conditions, etc. Furthermore, all or any part of the processing functions performed by each device can be realized by a CPU (Central Processing Unit) and a program analyzed and executed by the CPU, or can be realized as hardware using wired logic. Note that the program may be executed not only by the CPU but also by other processors such as a GPU.

[0102] Furthermore, among the processes described in this embodiment, all or part of the processes described as being performed automatically can be performed manually, or all or part of the processes described as being performed manually can be performed automatically using a known method.In addition, the information including the processing procedures, control procedures, specific names, various data and parameters shown in the above documents and drawings can be changed as desired unless otherwise specified.

[0103] [program] In one embodiment, the determination device 10 can be implemented by installing a determination program that executes the above-described determination process as package software or online software on a desired computer. For example, by causing an information processing device to execute the above-described determination program, the information processing device can function as the determination device 10. The information processing device referred to here includes desktop and notebook personal computers. In addition, the information processing device also includes mobile communication terminals such as smartphones, mobile phones, and PHS (Personal Handyphone Systems), as well as slate terminals such as PDAs (Personal Digital Assistants).

[0104] The determination device 10 may also be implemented as a determination server device that provides a service related to the above-described determination process to a client, the execution device 20 used by a user. For example, the determination server device may be implemented as a server device that provides a determination service that takes an authority request page as input and outputs a determination result. In this case, the determination server device may be implemented as a web server or as a cloud that provides a service related to the above-described determination process through outsourcing.

[0105] 9 is a diagram showing an example of a computer that executes a determination program. The computer 1000 includes, for example, a memory 1010 and a CPU 1020. The computer 1000 also includes a hard disk drive interface 1030, a disk drive interface 1040, a serial port interface 1050, a video adapter 1060, and a network interface 1070. These components are connected by a bus 1080.

[0106] The memory 1010 includes a ROM (Read Only Memory) 1011 and a RAM (Random Access Memory) 1012. The ROM 1011 stores a boot program such as a BIOS (Basic Input Output System). The hard disk drive interface 1030 is connected to a hard disk drive 1031. The disk drive interface 1040 is connected to a disk drive 1041. A removable storage medium such as a magnetic disk or optical disk is inserted into the disk drive 1041. The serial port interface 1050 is connected to a mouse 1110 and a keyboard 1120, for example. The video adapter 1060 is connected to a display 1130, for example.

[0107] The hard disk drive 1031 stores, for example, an OS 1091, an application program 1092, a program module 1093, and program data 1094. That is, a program that defines each process of the determination device 10 is implemented as a program module 1093 in which computer-executable code is written. The program module 1093 is stored, for example, in the hard disk drive 1031. For example, a program module 1093 for executing the same process as the functional configuration of the determination device 10 is stored in the hard disk drive 1031. Note that the hard disk drive 1031 may be replaced with an SSD.

[0108] Furthermore, setting data used in the processing of the above-described embodiment is stored as program data 1094, for example, in the memory 1010 or the hard disk drive 1031. Then, the CPU 1020 reads the program module 1093 or the program data 1094 stored in the memory 1010 or the hard disk drive 1031 into the RAM 1012 as necessary, and executes the processing of the above-described embodiment.

[0109] The program module 1093 and program data 1094 are not limited to being stored in the hard disk drive 1031, but may also be stored in, for example, a removable storage medium and read by the CPU 1020 via the disk drive 1041 or the like. Alternatively, the program module 1093 and program data 1094 may be stored in another computer connected via a network (such as a LAN (Local Area Network) or WAN (Wide Area Network)). The program module 1093 and program data 1094 may then be read by the CPU 1020 from the other computer via the network interface 1070. [Explanation of symbols]

[0110] 10 Judgment device 11 Communications Department 12 Storage section 13 Control Unit 20 Execution Device 121 Scenario Information 122 Test result information 131 Scenario Creation Department 132 Execution control section 133 Acquisition Department 134 Judgment section

Claims

1. a scenario creation unit that creates a test scenario including access to a web page via a browser that requests permission to acquire data from a device included in a device that runs the browser; an execution control unit that causes a browser to execute the scenario; a determination unit that determines whether or not the web page or the browser has a vulnerability based on the execution result of the scenario; A determination device comprising:

2. The determination device described in claim 1, characterized in that the scenario creation unit creates a scenario in which, after selecting whether to allow or deny a request for authority from a web page accessed by a browser, the browser is restarted and the web page is accessed again.

3. 2. The determination device according to claim 1, wherein the scenario creation unit creates a scenario for updating a web page accessed by a browser after the web page displays an authorization request.

4. The determination device described in claim 1, characterized in that the scenario creation unit creates a scenario in which, after an authority request from a web page accessed by a browser is displayed, the web page is updated while the web page is in the background.

5. The determination device described in claim 1, characterized in that the scenario creation unit creates a scenario in which, after selecting whether to allow or deny a request for authority from a web page accessed by a browser in a first mode, the browser is changed to a second mode and the web page is accessed again.

6. 2. The determination device according to claim 1, wherein the scenario creation unit creates a scenario for backgrounding a web page accessed by a browser before the web page displays an authorization request from the web page.

7. A determination method executed by a determination device, a scenario creation step of creating a test scenario including accessing, via a browser, a web page requesting permission to acquire data from a device provided on a device running the browser; an execution control step of causing a browser to execute the scenario; a determining step of determining whether or not the web page or the browser has a vulnerability based on the execution result of the scenario; A determination method comprising:

8. a scenario creation step of creating a test scenario including accessing, via a browser, a web page requesting permission to acquire data from a device provided on a device running the browser; an execution control step of causing a browser to execute the scenario; a determining step of determining whether or not the web page or the browser has a vulnerability based on the execution result of the scenario; A determination program that causes a computer to execute the above.

Images