Information processing device, vulnerability determination method, and vulnerability determination program

Abstract

This vulnerability determination device being an example of an information processing device has: a deployment unit that deploys an attack content into a content provision device providing content via a server device having a cache function; a registration unit that registers, into a cache of the server device, the attack content deployed in the content provision device; and a determination unit that determines vulnerability to a threat which causes a browser to download the attack content via the cache of the server device.

Description

Information processing device, vulnerability assessment method, and vulnerability assessment program

[0001] The present invention relates to an information processing device, a vulnerability determination method, and a vulnerability determination program.

[0002] IPFS (InterPlanetary File System) is an important element in building a distributed web in the Web3 era, and is positioned as a protocol that complements or replaces HTTP (Hyper Text Transfer Protocol).

[0003] Participating in such an IPFS network as a node can be a high hurdle for ordinary users, so the use case of accessing the IPFS network via an IPFS gateway to obtain and view content on the IPFS network on behalf of the user is widespread.

[0004] IPFS gateways have the ability to place any content provided by a user in a single origin. For this reason, IPFS gateways can be considered a type of web rehosting. With this type of web rehosting, content that originally had a different origin (for example, a domain, port, and scheme) is relocated to the same origin.

[0005] Therefore, if malicious content is included in the content to be rehosted, multiple attacks may be possible, violating the security boundary (Same Origin Policy). In particular, attacks using Service Workers (SW) are particularly serious because they provide attackers with opportunities to intercept and tamper with the content.

[0006] For this reason, an application that realizes the function of the IPFS gateway is provided with a measure to reject a request when a browser sends a request to the IPFS gateway to acquire a SW script.

[0007] Takuya Watanabe, Shioji Eitaro, Mitsuaki Akiyama, and Tatsuya Mori, “Melting Pot of Origins:Compromising the Intermediary Web Services that Rehost Websites” In NDSS. 2020.O.Gil, “WEB CACHE DECEPTION ATTACK” Black Hat USA, 2017.

[0008] However, if a reverse proxy that acts as a proxy for access to the IPFS gateway caches attack content, the cache takes priority, which means that the above countermeasures can be circumvented.

[0009] Note that the above problem was given as an example of a situation where content relocated by an IPFS gateway is cached in a reverse proxy, but similar problems can arise in situations where content is cached in a web server in general for services that provide content.

[0010] SUMMARY OF THE INVENTION It is therefore an object of the present invention to provide an information processing device, a vulnerability assessment method, and a vulnerability assessment program that can implement an inspection of vulnerability against attacks that exploit the cache function.

[0011] In order to solve the above-mentioned problems and achieve the objectives, the information processing device of the present invention has a deployment unit that deploys attack content to a content providing device that provides content via a server device having a cache function, a registration unit that registers the attack content deployed to the content providing device in the cache of the server device, and a judgment unit that judges vulnerability to a threat that downloads the attack content to a browser via the cache of the server device.

[0012] According to the present invention, it is possible to inspect for vulnerability to attacks that exploit the cache function.

[0013] FIG. 1 is a schematic diagram (1) showing an example of access to content. FIG. 2 is a schematic diagram (2) showing an example of access to content. FIG. 3 is a schematic diagram explaining an IPFS gateway. FIG. 4 is a diagram showing an example of an overall configuration including a vulnerability determination device. FIG. 5 is a schematic diagram explaining Web rehosting. FIG. 6 is a schematic diagram explaining an attack using a service worker. FIG. 7 is a diagram (1) showing the sequence of a SW attack. FIG. 8 is a diagram (2) showing the sequence of a SW attack. FIG. 9 is a block diagram showing an example of the functional configuration of a vulnerability determination device. FIG. 10 is a schematic diagram (1) showing the sequence of URL access. FIG. 11 is a schematic diagram (2) showing the sequence of URL access. FIG. 12 is a diagram showing an example of a vulnerability determination result. FIG. 13 is a flowchart showing the procedure of a vulnerability determination process. FIG. 14 is a diagram showing an example of a hardware configuration.

[0014] Hereinafter, an information processing device, a vulnerability assessment method, and a vulnerability assessment program according to the present application (hereinafter referred to as "embodiments") will be described with reference to the accompanying drawings. Note that the embodiments merely illustrate one example or one aspect, and the following description does not limit the specifics of the present invention, such as the structure, action, function, properties, characteristics, methods, and uses.

[0015] First, an IPFS network including an IPFS gateway and a reverse proxy will be taken as an example of one of the targets to be inspected by a vulnerability determination device corresponding to an example of an information processing device according to this embodiment.

[0016] <IPFS> IPFS is an important element in building a distributed web in the Web3 era, and is positioned as a protocol that complements or replaces HTTP.

[0017] IPFS is implemented as a content-oriented protocol. Figures 1 and 2 are schematic diagrams showing examples of access to content. Here, Figure 1 shows access using HTTP, while Figure 2 shows access using IPFS.

[0018] For example, in the case of HTTP, a location-oriented protocol, the location where content exists is specified using an address such as a Uniform Resource Locator (URL). Through such location specification, a browser running on a user terminal accesses content hosted by a Web server on the Internet NW1, as shown in Figure 1. This has the effect of consolidating accesses from the browser to the Web server hosting the content.

[0019] On the other hand, in the case of IPFS, which is a content-oriented protocol, content hosting does not need to be centralized on a single server. For example, as shown in Figure 2, content is hosted by user terminals (hereinafter referred to as "IPFS nodes") participating in the IPFS network NW2. In such an IPFS network NW2, content is specified by its hash value or the like, allowing P2P (Peer to Peer) access to the IPFS node hosting the content. This allows the same content to be shared and hosted among multiple IPFS nodes, which has the aspect of functioning as distributed storage.

[0020] Such IPFS has the following advantages over HTTP. One aspect is that IPFS is tamper-resistant because if the original content is tampered with, the hash value changes and a different address is created. Another aspect is that IPFS is fault-tolerant because even if a failure occurs in the IPFS node that holds the original content, the same content can be obtained from another IPFS node. Another aspect is that IPFS is censorship-resistant because even if access to some IPFS nodes is blocked, other IPFS nodes can still be accessed.

[0021] For example, the following are examples of uses for IPFS. One aspect is that it is used as a file repository for NFT (Non-Fungible Token) art. Another aspect is that it is used as a repository for content snapshots and uncensored articles. Another example is that the Digital Agency has used it as a repository for "digital certificates."

[0022] Participating in such an IPFS network as an IPFS node presents a high barrier to entry for ordinary users. For one thing, it requires the installation of dedicated software. Another problem is the consumption of a large amount of resources, such as storage and communication. For example, communication is like a constant P2P connection, making it difficult for users of shared lines or smartphones to use.

[0023] <IPFS Gateway> For this reason, the use case of accessing content on the IPFS network via an IPFS gateway to obtain and view content on behalf of the user is widespread.

[0024] Fig. 3 is a schematic diagram illustrating an IPFS gateway. As shown in Fig. 3, an IPFS gateway 1A is constructed to relay between an HTTP-based Internet NW1 and an IPFS-based IPFS network NW2. This IPFS gateway 1A accepts an HTTP request specifying a CID (Content Identifier) ​​from a browser BR running on a user terminal, thereby allowing the browser BR to access content on the IPFS network NW2.

[0025] When an IPFS gateway is constructed in this way, there are issues in that it is difficult to encrypt communications because HTTPS access cannot be permitted, and furthermore, it is difficult to distribute the load when access increases.

[0026] For this reason, a common configuration is to build a reverse proxy that acts as an agent for access to the IPFS gateway, and have the reverse proxy relay access from the browser BR to the IPFS gateway.

[0027] <Overall Configuration> In consideration of the above, an example of an overall configuration including a vulnerability determination device 10 corresponding to an example of an information processing device according to this embodiment is shown in Fig. 4. Fig. 4 is a diagram showing an example of an overall configuration including the vulnerability determination device 10.

[0028] As shown in Fig. 4, the vulnerability determination device 10 is connected to an IPFS gateway 1A on an IPFS network NW2 via the Internet NW1. Furthermore, a reverse proxy 3A that acts as a proxy for access to the IPFS gateway 1A is constructed on the IPFS network NW2 side. Although not shown in Fig. 4, user terminals used by general users and attacker terminals used by attackers may be connected to the Internet NW1.

[0029] <Known Threats to the IPFS Gateway> With this configuration, known threats to the IPFS gateway 1A will be described. The IPFS gateway 1A has an aspect of placing any content prepared by the user in a single origin. For this reason, the IPFS gateway can be considered a type of web rehosting.

[0030] With this type of web rehosting, content that originally had a different origin (for example, a domain, port, and scheme) is relocated to the same origin. Therefore, if the content being rehosted contains malicious content, it may breach security boundaries and allow multiple attacks to take place.

[0031] Fig. 5 is a schematic diagram illustrating Web Rehosting. For example, Fig. 5 shows an example in which content A, content B, and content Atk, which belong to different domains, are relocated by an IPFS gateway 1A. Fig. 5 also shows an example in which, among content A, content B, and content Atk, content A and content B are legitimate content, while content Atk is attack content prepared by an attacker.

[0032] As shown in Figure 5, if legitimate content A, legitimate content B, and attack content Atk are relocated to the same domain name, the attack content Atk can interfere with legitimate content A and B. This could lead to multiple attacks that exploit various browser functions. Attacks that exploit Service Workers (SW) are particularly serious because they provide attackers with opportunities to intercept and tamper with data.

[0033] <SW Attacks and Countermeasures> Fig. 6 is a schematic diagram illustrating an attack using a Service Worker. As shown in Fig. 6, when a user terminal U1 accesses attack content Atk through the IPFS gateway 1A (step S1), a malicious SW is registered in the browser of the user terminal U1 (step S2). After that, when the user terminal U1 accesses normal content A through the IPFS gateway 1A, the access to normal content A is intercepted and tampered with by the malicious SW (step S3).

[0034] In order to deal with such malicious SW scripts, the application that realizes the functions of the IPFS gateway 1A is provided with a measure to reject a request when a browser sends a request to acquire a SW script.

[0035] To address this issue, a browser specification is utilized in which an HTTP request header "Service-Worke:script" is automatically added when the browser attempts to obtain and register a SW script. In other words, the application that realizes the functions of the IPFS gateway 1A incorporates a filtering function that identifies and rejects requests that have an HTTP request header "Service-Worke:script" added.

[0036] <Avoiding the filtering function by misusing the cache function> However, if the reverse proxy 3A that handles access to the IPFS gateway 1A caches attack content, the cache takes priority, which means that the filtering function based on the HTTP header discrimination described above can be avoided.

[0037] The attack to circumvent the filtering function is carried out by the following steps S11 to S14.

[0038] First, the attacker deploys a malicious SW script on the IPFS network NW1 (step S11), and then accesses the malicious SW script deployed in step S11 via the IPFS gateway 1A (step S12).

[0039] At this time, if the HTTP request header "Service-Worke:script" is added (step S12A), the HTTP request is rejected. On the other hand, if the HTTP request header "Service-Worke:script" is not added (step S12B), the HTTP request is not rejected and the malicious SW script can be accessed.

[0040] Therefore, the attacker repeats step S12B above until the reverse proxy 3A caches the malicious SW script (step S13). After that, if the attacker makes the target browser click on a web page that causes the SW script to be registered, the malicious SW script, which would normally be rejected, is registered by the cache (step S14).

[0041] <Generalized Threat> The threat posed by attacks that exploit the cache function in this way is not limited to situations where content relocated by the IPFS gateway 1 A is cached in the reverse proxy 3 A. In other words, the above threat can occur in situations where content is cached in a Web server in all services in which content is provided.

[0042] In one aspect, the IPFS gateway 1A can be generalized as a content providing device that executes an application that provides content. Examples of such applications may include applications that provide the functions of the IPFS gateway 1A, as well as services such as web rehosting. In another aspect, the reverse proxy 3A can be generalized as a web server with a cache function. Examples of such web servers may include an HTTP server and a CDN (Contents Delivery Network).

[0043] 7 and 8 are diagrams showing the sequence of a SW attack. For example, Fig. 7 shows a case where the above filtering function is exercised, i.e., a failed SW attack, while Fig. 8 shows a case where the above filtering function is circumvented, i.e., a successful SW attack.

[0044] As shown in Figures 7 and 8, when an HTTP request with the header "Service-Work:script" is sent from the target browser BR to the content providing device 1, whether the SW attack will be successful or not depends on whether the malicious SW script is registered in the cache of the Web server 3.

[0045] For example, as shown in Fig. 7, if the malicious SW script is not registered in the cache of the Web server 3, the content providing device 1 can reject the HTTP request from the targeted browser BR based on the header attached to the HTTP request. On the other hand, as shown in Fig. 8, if the malicious SW script is registered in the cache of the Web server 3, the malicious SW script registered in the cache of the Web server 3 is registered in the targeted browser BR. In this case, the HTTP request from the targeted browser BR will be intercepted by the Web server 3, and therefore, even if the content providing device 1 is equipped with the above-mentioned filtering function, it will not function.

[0046] In this way, in all services in which content is provided, the threat of attacks that exploit the cache function can arise when content is cached on the Web server 3 .

[0047] Therefore, the vulnerability determination device 10 according to this embodiment provides a vulnerability determination function for determining vulnerability to attacks that exploit the cache function.

[0048] <Configuration of Vulnerability Determination Device 10> Next, an example of the functional configuration of the vulnerability determination device 10 that provides the vulnerability determination function will be described. Fig. 9 is a block diagram showing an example of the functional configuration of the vulnerability determination device 10.

[0049] The vulnerability determination device 10 can provide the vulnerability determination function as a cloud service by executing a PaaS (Platform as a Service) type middleware or a SaaS (Software as a Service) type application.

[0050] 9, the vulnerability determination device 10 may be communicably connected to an inspector terminal 20 via the Internet NW 1. Note that, although an example in which one inspector terminal 20 is connected to one vulnerability determination device 10 is shown in FIG. 9, any number of inspector terminals 20 may be connected.

[0051] The inspector terminal 20 is a terminal device that receives the above-described vulnerability determination function. For example, the inspector terminal 20 can be used by an inspector who inspects vulnerabilities from an attacker's perspective, such as an external vulnerability testing company or a researcher. The inspector terminal 20 may be realized by any computer, such as a personal computer, a smartphone, a tablet terminal, or a wearable terminal.

[0052] Although the above example illustrates a case in which the vulnerability assessment function is provided as a cloud service, the present invention is not limited to this. For example, the above vulnerability assessment function may be provided on-premise. Furthermore, the above example illustrates a case in which the vulnerability assessment function is provided in a client-server system, but the present invention is not limited to this. For example, the above vulnerability assessment function may be provided standalone by executing a vulnerability assessment program corresponding to the above vulnerability assessment function on the inspector terminal 20.

[0053] As an example of a usage scenario of the vulnerability assessment function, an example where an IPFS gateway 1A and a reverse proxy 3A are constructed in the IPFS network NW2 will be given below, but as mentioned above, this is merely one example. In other words, it should be noted that the vulnerability assessment function can be applied not only to a situation where content relocated by the IPFS gateway 1A is cached in the reverse proxy 3A, but also to all situations where content is cached in a Web server in all services where content is provided.

[0054] Furthermore, as an example of the threat described above, a software attack that exploits software scripts, one of the functions of the target browser, is given, but this is just one example. In other words, the vulnerability assessment function described above can also be applied to attacks that exploit other functions of the target browser, such as Password Manager, Cookies, and localStorage, or attacks that exploit permissions, such as camera and microphone access rights.

[0055] For example, Fig. 9 shows a schematic diagram of selected blocks related to the vulnerability determination function of the vulnerability determination device 10. As shown in Fig. 9, the vulnerability determination device 10 has a communication control unit 11, a storage unit 13, and a control unit 15. Note that Fig. 9 only shows selected functional units related to the vulnerability determination function, and does not preclude the vulnerability determination device 10 from being provided with functional units other than those shown, such as an input unit and an output unit.

[0056] The communication control unit 11 is a functional unit that controls communication with other devices such as the IPFS gateway 1A, the reverse proxy 3A, and the inspector terminal 20. In one embodiment, the communication control unit 11 can be realized by a network interface card such as a LAN (Local Area Network) card.

[0057] As one aspect, the communication control unit 11 receives various requests and various uploads from the inspector terminal 20, and outputs processing results of the control unit 15 (described later) to the inspector terminal 20. As another aspect, the communication control unit 11 transmits an HTTP request for inspection to the IPFS gateway 1A via the reverse proxy 3A, and receives an HTTP response to the HTTP request for inspection from the reverse proxy 3A or the IPFS gateway 1A.

[0058] The storage unit 13 is a functional unit that stores various types of data. In one embodiment, the storage unit 13 may be realized by internal, external, or auxiliary storage of the vulnerability determination device 10. For example, the storage unit 13 stores cache condition information 13A. The cache condition information 13A will be described later together with a scene in which the cache condition information 13A is referenced or registered.

[0059] The control unit 15 is a functional unit that performs overall control of the vulnerability determination device 10. For example, the control unit 15 may be realized by a hardware processor. As shown in FIG. 9 , the control unit 15 has a reception unit 15A, a deployment unit 15B, a first determination unit 15C, a registration unit 15D, a registration status identification unit 15E, and a second determination unit 15F. The first determination unit 15C and the second determination unit 15F may be integrated into a single determination unit. Note that the control unit 15 may also be realized by hardwired logic or the like.

[0060] The reception unit 15A is a processing unit that receives various requests from the inspector terminal 20. As just one example, the reception unit 15A can receive an inspection request requesting the execution of a vulnerability inspection from the inspector terminal 20. As just one example, such an inspection request may include a specification of a service, such as a service domain, that is the target of the vulnerability inspection.

[0061] The deployment unit 15B is a processing unit that deploys attack content on the IPFS network NW2. The "attack content" referred to here may be a malicious script prepared by an attacker, such as a web page that causes a SW script or the like to be registered in a target browser.

[0062] In one aspect, the deployment unit 15B causes an IPFS node holding attack content to join the IPFS network NW2 corresponding to the service domain specified when the above-mentioned inspection request was received. The IPFS node to join the IPFS network NW2 in this way may be any computer, such as a physical machine or a virtual machine. For example, it may be a computer specified by the inspector terminal 20, or a computer provided for inspection by a provider that provides the above-mentioned vulnerability assessment service. This allows the attack content to be deployed on the IPFS network NW2.

[0063] The first determination unit 15C is a processing unit that determines vulnerability to a threat of downloading attack content from the IPFS gateway 1A to a target browser. From another perspective, the "vulnerability determination" by the first determination unit 15C can also be said to refer to determining whether or not a measure to incorporate a filtering function that uses the above-mentioned HTTP header discrimination into an application that realizes the functions of the IPFS gateway 1A has not yet been implemented, that is, determining whether or not the IPFS gateway 1A has a vulnerability.

[0064] Hereinafter, the measure of incorporating a filtering function that uses the above-mentioned HTTP header discrimination into an application that realizes the functions of the IPFS gateway 1A may be referred to as "measure (a)."

[0065] In one aspect, the first determination unit 15C generates a URL for accessing the attack content Atk via the service specified in the inspection request. While the URL generation method varies depending on the service targeted for inspection, the URL for each service is determined using a specific algorithm. For example, in the case of IPFS Gateway, a URL can be generated using https: / / <service domain name> / <file hash>. Therefore, a library containing URL generation methods corresponding to each service can be generated, and the URL generation method can be identified by searching the library for a URL generation method corresponding to the service specified in the inspection request.

[0066] After the URL for accessing the attack content Atk is generated in this way, the first determination unit 15C accesses the URL with a specific header. For example, the first determination unit 15C sends an HTTP request with the specific header "Service-Work:script" to the IPFS gateway 1A specified by the URL.

[0067] Then, the first judgment unit 15C judges whether the IPFS gateway 1A is vulnerable, i.e., whether the above-mentioned measure (a) has not been implemented, based on whether access to the above-mentioned URL with a specific header is rejected.

[0068] If the access to the above URL with the specific header is denied, the first determination unit 15C determines that the IPFS gateway 1A has no vulnerability, i.e., the above measure (a) has already been implemented. On the other hand, if the access to the above URL with the specific header is permitted, the first determination unit 15C determines that the IPFS gateway 1A has a vulnerability, i.e., the above measure (a) has not yet been implemented.

[0069] FIG. 10 is a schematic diagram (1) showing the sequence of URL access. FIG. 10 shows an example in which the above-mentioned measure (a) incorporating a filtering function using HTTP header discrimination has already been implemented. As shown in FIG. 10, an HTTP request with a specific header "Service-Work:script" is sent from the target browser BR to the IPFS gateway 1A. At this stage, attack content has just been deployed on the IPFS network NW2, and no malicious SW scripts have been registered in the cache of the reverse proxy 3A. Therefore, the HTTP request with the header from the target browser BR is relayed to the IPFS gateway 1A by the reverse proxy 3A. In this case, the IPFS gateway 1A rejects the HTTP request with the specific header from the target browser BR based on the header added to the HTTP request. Since access to a URL with a header is rejected in this way, it can be inferred that the above-mentioned measure (a) has already been implemented. Although not shown in the figure, if access to a URL with a specific header is permitted, it can be assumed that the above measure (a) has not been implemented.

[0070] The registration unit 15D is a processing unit that registers the attack content in the cache of the reverse proxy 3A. In one aspect, the registration unit 15D repeatedly accesses the above URL without a specific header, based on the cache condition information 13A stored in the storage unit 13.

[0071] The cache condition information 13A may set access conditions, such as the frequency of attempts to access the above URL without a specific header and the number of repeated access attempts, as conditions for registering attack content in the cache of the reverse proxy 3A. For example, if the reverse proxy 3A is implemented using nginx, the default interval is 10 minutes, so an access condition may be set to repeat one access per minute about five times.

[0072] The conditions for cache registration and retention period vary depending on the software, hardware, and configuration files used by the reverse proxy 3A. Therefore, multiple access conditions can be set in stages in the cache condition information 13A. For example, the access frequency and number of repetitions set as access conditions can be gradually increased. Then, the access conditions applied by the registration unit 15D are gradually changed until the attack content is successfully registered in the cache of the reverse proxy 3A. This makes it possible to register attack content in the cache of the reverse proxy 3A even if the software, hardware, and configuration files used by the reverse proxy 3A change.

[0073] The registration status identification unit 15E is a processing unit that identifies the registration status of the cache in the reverse proxy 3A. In one aspect, the registration status identification unit 15E identifies the registration status of whether or not the attack content has been registered in the cache of the reverse proxy 3A after the registration unit 15D attempts cache registration in accordance with the access conditions set in the cache condition information 13A. For example, such a registration status can be identified based on an HTTP response obtained by sending an HTTP request to the above URL without a specific header. If it is identified at this stage that the attack content has been registered in the cache of the reverse proxy 3A, it can be confirmed that the attack content has been registered at least in the user's personal cache.

[0074] The registration status identification unit 15E then changes the IP address and browser environment, such as cookies, used when deploying the attack content. The registration status identification unit 15E then re-executes the above-described registration status identification using the changed IP address and browser environment. If it is determined at this stage that the attack content has been registered in the cache of the reverse proxy 3A, it can be confirmed that the attack content has been registered in the cache shared by all users.

[0075] Furthermore, by repeatedly accessing the above URL without a specific header based on the cache condition information 13A, it is possible to assume that the attack content has been registered in the cache of the reverse proxy 3A with a certain degree of reproducibility, even if it is not possible to confirm that the attack content has been registered in the cache of the reverse proxy 3A. For this reason, it is not necessary to check the registration status in the user's personal cache and the user's common cache, and the user can select whether or not to check the registration status by the registration status identification unit 15E as an optional function.

[0076] The second determination unit 15F is a processing unit that determines vulnerability to a threat that downloads attack content to a target browser via the cache of the reverse proxy 3 A. Here, the "vulnerability determination" by the second determination unit 15F can also be said to refer to determining whether or not a countermeasure against an attack that exploits the cache function of the reverse proxy 3 A, such as incorporating a filtering function that uses the HTTP header discrimination described above into a Web application that realizes the function of the reverse proxy 3 A, has not yet been implemented, in other words, determining whether or not the reverse proxy 3 A has a vulnerability.

[0077] Hereinafter, the measure of incorporating a filtering function that uses the HTTP header discrimination described above into a Web application that realizes the function of the reverse proxy 3A may be referred to as "measure (b)."

[0078] In one aspect, when attack content is registered in a cache shared by all users, the second determination unit 15F accesses the above URL with a specific header. For example, the first determination unit 15C sends an HTTP request with the specific header "Service-Work:script" to the IPFS gateway 1A specified by the above URL.

[0079] Then, the second judgment unit 15F judges whether or not the reverse proxy 3A is vulnerable, i.e., whether or not the above-mentioned measure (b) has not been implemented, based on whether or not access to the above-mentioned URL with a specific header is rejected.

[0080] If the access to the above URL with the specific header is denied, the second determination unit 15F determines that the reverse proxy 3A has no vulnerability, i.e., that the above measure (b) has already been implemented. On the other hand, if the access to the above URL with the specific header is permitted, the second determination unit 15F determines that the reverse proxy 3A has a vulnerability, i.e., that the above measure (b) has not yet been implemented.

[0081] FIG. 11 is a schematic diagram (2) showing the sequence of URL access. FIG. 11 shows an example in which measure (b), which incorporates a filtering function using the HTTP header discrimination described above, has already been implemented. As shown in FIG. 11, an HTTP request with a specific header "Service-Work:script" is sent from the target browser BR to the IPFS gateway 1A. At this stage, attack content is registered in the user-shared cache of the reverse proxy 3A, but the filtering function described above has been incorporated into the reverse proxy 3A. Therefore, the reverse proxy 3A rejects the HTTP request from the target browser BR based on the header attached to the HTTP request without relaying it to the IPFS gateway 1A. If access to a URL with a header is rejected in this way, it can be inferred that measure (b) has already been implemented. Although not shown here, if access to a URL with a specific header is permitted, it can be inferred that measure (b) has not yet been implemented.

[0082] As described above, when the vulnerability determination by the first determination unit 15C and the vulnerability determination by the second determination unit 15F are performed, the determination results shown in FIG. 12 can be output to the inspector terminal 20. FIG. 12 is a diagram showing an example of the vulnerability determination result. As shown in FIG. 12, three types of determination results may be output: measure (a) not implemented, measure (b) not implemented, and measures (a) and (b) implemented. Of these, if it is determined that measure (a) not implemented, there is no measure in the application that realizes the function of the IPFS gateway 1A, so the inspector can be notified that the IPFS gateway 1A is vulnerable. Also, if it is determined that measure (b) not implemented, although there is a measure in the application that realizes the function of the IPFS gateway 1A, it is possible to circumvent the vulnerability by exploiting the cache of the reverse proxy 3A, so the inspector can be notified that the reverse proxy 3A is vulnerable. If it is determined that measure (a) not implemented or measure (b) not implemented, as described above, it suggests vulnerability to critical attacks such as SW attacks, so it is necessary to implement defensive measures and perform detailed risk assessments. On the other hand, if it is determined that the measures (a) and (b) have been implemented, it is possible to notify that the system is safe from critical attacks such as SW attacks.

[0083] 13 is a flowchart showing the steps of the vulnerability determination process. This process can be started when an inspection request is received by the reception unit 15A, as an example. This is just an example, and the process does not necessarily have to be executed on demand.

[0084] 13, the deployment unit 15B deploys the attack content on the IPFS network NW2 (step S101). Then, the first determination unit 15C generates a URL for accessing the attack content Atk via the service specified in the inspection request (step S102).

[0085] Thereafter, the first determination unit 15C transmits an HTTP request with the specific header "Service-Work:script" attached to the IPFS gateway 1A designated by the URL generated in step S102 (step S103).

[0086] Then, the first determination unit 15C determines whether or not access to the above URL with a specific header is denied (step S104).

[0087] Here, if access to the above URL with a specific header is permitted (step S104 No), the first judgment unit 15C judges that the IPFS gateway 1A is vulnerable, i.e., the above countermeasure (a) has not been implemented (step S105), and terminates the processing.

[0088] On the other hand, if the access to the above URL with the specific header is rejected (Yes in step S104), the first determination unit 15C determines that the IPFS gateway 1A has no vulnerability, i.e., the above measure (a) has been implemented. In this case, the registration unit 15D executes loop process 1, which repeats the process of step S106 described below, until the access conditions set in the cache condition information 13A, such as the frequency of access attempts and the number of repetitions, are satisfied.

[0089] That is, the registration unit 15D accesses the URL generated in step S102 without adding a specific header (step S106). By repeating this loop process 1, the possibility that attack content will be registered in the cache of the reverse proxy 3A increases.

[0090] Thereafter, the registration status identifying unit 15E identifies the registration status as to whether or not the attack content has been registered in the user's personal cache of the reverse proxy 3A (step S107).

[0091] At this time, if the attack content is not registered in the user's personal cache of the reverse proxy 3A (step S107 No), the process returns to the above-described loop process 1. In this case, it is possible to select an access condition from the multiple access conditions set in the cache condition information 13A that has a higher trial frequency and number of repetitions than the most recently used access condition.

[0092] On the other hand, if the attack content has already been registered in the user's personal cache of the reverse proxy 3A (Yes in step S107), the IP address and browser environment used to deploy the attack content in step S101 are changed (step S108).

[0093] Then, the registration status identification unit 15E re-identifies the registration status to determine whether or not attack content has been registered in the user-common cache of the reverse proxy 3A using the changed IP address and changed browser environment (step S109).

[0094] At this time, if the attack content is not registered in the user-shared cache of the reverse proxy 3A (step S109 No), the process returns to the above-described loop process 1. In this case, too, it is possible to select an access condition from the multiple access conditions set in the cache condition information 13A that has a higher trial frequency and number of repetitions than the most recently used access condition.

[0095] On the other hand, if the attack content has already been registered in the user-common cache of the reverse proxy 3A (step S109 Yes), the second judgment unit 15F sends an HTTP request with the specific header “Service-Worke:script” to the IPFS gateway 1A specified by the URL generated in step S102 (step S110).

[0096] Then, the second determination unit 15F determines whether or not access to the above URL with a specific header is denied (step S111).

[0097] Here, if access to the above URL with a specific header is permitted (step S111 No), the second judgment unit 15F judges that the reverse proxy 3A has a vulnerability, i.e., the above countermeasure (b) has not been implemented (step S112), and terminates the processing.

[0098] On the other hand, if access to the above URL with a specific header is rejected (step S111: Yes), the second judgment unit 15F judges that there is no vulnerability in the IPFS gateway 1A and the reverse proxy 3A, that is, that the above measures (a) and (b) have been implemented (step S113), and terminates the processing.

[0099] <Summary> As described above, the vulnerability determination device 10 according to this embodiment determines vulnerability to a threat that deploys attack content on the IPFS network NW2, registers the attack content deployed on the IPFS network NW2 in the cache of the reverse proxy 3A, and downloads the attack content to the target browser BR via the cache of the reverse proxy 3A.

[0100] Therefore, the vulnerability assessment device 10 according to this embodiment can test for vulnerabilities against attacks that exploit the cache function. Furthermore, because the test can be performed via the Internet, i.e., from outside the IPFS network, external vulnerability testing businesses and researchers can utilize the vulnerability assessment function without needing any source code or configuration diagram of the service or any special access rights.

[0101] <Exercise of creativity> The matters described in this embodiment, such as specific examples of IPFS gateways and reverse proxies, and the types of attacks that IPFS networks are subject to, are merely examples and can be changed. Also, the order of the processes in the flowcharts described in this embodiment can be changed or some processes can be skipped within a consistent range.

[0102] <System> 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. For example, any one or more of the functional units of the vulnerability determination device 10, namely, the reception unit 15A, the deployment unit 15B, the first determination unit 15C, the registration unit 15D, the registration status identification unit 15E, and the second determination unit 15F, may be configured as separate devices.

[0103] 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. In other words, all or part of them can be functionally or physically distributed and integrated in any unit depending on various loads, usage conditions, etc. Note that each configuration may also be a physical configuration.

[0104] Furthermore, all or any part of the processing performed by the illustrated device may be realized by a program executed by a hardware processor such as an MPU (Micro-Processing Unit) or a CPU (Central Processing Unit), or may be realized as hardware using wired logic.

[0105] <Hardware> Next, an example of the hardware configuration of the vulnerability determination device 10 described in this embodiment will be described. For example, the vulnerability determination device 10 can be implemented by installing a program that realizes the functions of the vulnerability determination device 10 on a desired information processing device (computer). For example, the vulnerability determination device 10 can be implemented by causing a computer to execute the program, which is provided as package software or online software. The computer referred to here includes desktop or notebook personal computers, rack-mounted server computers, and the like. Other examples of computers also include smartphones, mobile phones, PHS (Personal Handyphone System) and other mobile communication terminals, as well as PDAs (Personal Digital Assistants). The functions of the vulnerability determination device 10 may also be implemented on a cloud server.

[0106] An example of a computer that executes the above-described program (vulnerability determination program) will be described using Fig. 14. As shown in Fig. 14, the computer 1000 includes, for example, a memory 1010, a CPU 1020, 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.

[0107] The memory 1010 includes a read-only memory (ROM) 1011 and a random access memory (RAM) 1012. The ROM 1011 stores a boot program such as a basic input / output system (BIOS). The hard disk drive interface 1030 is connected to a hard disk drive 1090. The disk drive interface 1040 is connected to a disk drive 1100. A removable storage medium such as a magnetic disk or optical disk is inserted into the disk drive 1100. 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.

[0108] 14, the hard disk drive 1090 stores, for example, an OS 1091, an application program 1092, a program module 1093, and program data 1094. The storage unit 13 described in the above embodiment is provided in, for example, the hard disk drive 1090 or the memory 1010.

[0109] Then, the CPU 1020 reads out the program module 1093 and the program data 1094 stored in the hard disk drive 1090 into the RAM 1012 as necessary, and executes the above-mentioned procedures.

[0110] The program module 1093 and program data 1094 related to the vulnerability determination program described above are not limited to being stored in the hard disk drive 1090, but may be stored in a removable storage medium, for example, and read by the CPU 1020 via the disk drive 1100 or the like. Alternatively, the program module 1093 and program data 1094 related to the program described above may be stored in another computer connected via a network such as a LAN or a WAN (Wide Area Network), and read by the CPU 1020 via the network interface 1070.

[0111] REFERENCE SIGNS LIST 1A IPFS gateway 3A reverse proxy 10 vulnerability determination device 11 communication control unit 13 storage unit 13A cache condition information 15 control unit 15A reception unit 15B deployment unit 15C first determination unit 15D registration unit 15E registration status identification unit 15F second determination unit 20 inspector terminal

Claims

1. An information processing device comprising: a deployment unit that deploys attack content to a content providing device that provides content via a server device having a cache function; a registration unit that registers the attack content deployed to the content providing device in the cache of the server device; and a judgment unit that judges vulnerability to a threat that downloads the attack content to a browser via the cache of the server device.

2. The information processing device described in claim 1, characterized in that the judgment unit judges vulnerability to a threat that causes the attack content to be downloaded to the browser from the content providing device after the attack content is deployed to the content providing device, and if it is determined that there is no vulnerability to the threat, judges vulnerability to a threat that causes the attack content to be downloaded to the browser via the cache of the server device.

3. A vulnerability assessment method executed on an information processing device, comprising: a deployment step of deploying attack content to a content providing device that provides content via a server device having a cache function; a registration step of registering the attack content deployed to the content providing device in the cache of the server device; and a assessment step of assessing vulnerability to a threat that downloads the attack content to a browser via the cache of the server device.

4. A vulnerability assessment program for causing a computer to execute the following steps: a deployment step of deploying attack content to a content providing device that provides content via a server device having a cache function; a registration step of registering the attack content deployed to the content providing device in the cache of the server device; and a assessment step of assessing vulnerability to a threat that downloads the attack content to a browser via the cache of the server device.

Images