WO2019026172A1 - セキュリティ診断装置およびセキュリティ診断方法 - Google Patents

セキュリティ診断装置およびセキュリティ診断方法 Download PDF

Info

Publication number
WO2019026172A1
WO2019026172A1 PCT/JP2017/027822 JP2017027822W WO2019026172A1 WO 2019026172 A1 WO2019026172 A1 WO 2019026172A1 JP 2017027822 W JP2017027822 W JP 2017027822W WO 2019026172 A1 WO2019026172 A1 WO 2019026172A1
Authority
WO
WIPO (PCT)
Prior art keywords
account
parameter
http request
destination url
transition destination
Prior art date
Application number
PCT/JP2017/027822
Other languages
English (en)
French (fr)
Inventor
孝平 反町
Original Assignee
三菱電機株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 三菱電機株式会社 filed Critical 三菱電機株式会社
Priority to PCT/JP2017/027822 priority Critical patent/WO2019026172A1/ja
Priority to JP2019533770A priority patent/JP6636222B2/ja
Priority to CN201780093329.9A priority patent/CN110998577A/zh
Priority to US16/621,338 priority patent/US20200167478A1/en
Priority to EP17919720.7A priority patent/EP3651045A1/en
Publication of WO2019026172A1 publication Critical patent/WO2019026172A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/577—Assessing vulnerabilities and evaluating computer system security
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/604—Tools and structures for managing or administering access control systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1433—Vulnerability analysis
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/168—Implementing security features at a particular protocol layer above the transport layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/146—Markers for unambiguous identification of a particular session, e.g. session cookie or URL-encoding

Definitions

  • the present invention relates to a security diagnostic device that diagnoses inadequacy of authority management.
  • Web application diagnostic tools and security diagnostic services are available as methods to check the presence of web application vulnerabilities. These diagnose a presence or absence of a known vulnerability by performing a mock attack on a web application.
  • Inappropriate authority management is a case where, when there are two accounts having different authorities, a page or valid function that can be transited by only one account can be transitive or executable by the other account.
  • a diagnostic practitioner visually identifies gaps in privileges management by visually identifying differences between accounts for transmissible pages or enabled functions, and setting them in a tool or manually executing a mock attack. The thing is done.
  • Patent Document 1 creates a supposed access API by tracing a call of an authority request API and a call of an actual access API when an object is accessed, and a call of the actual access API It is confirmed whether it is associated with. In the case where the actual access API is not associated with the assumed access API, Patent Document 1 determines that the least privilege violation.
  • Patent Document 1 there is a problem that it is not possible to determine whether there is a deficiency in the management of authority if assignment of the authority to the object is unknown.
  • the present invention has been made to solve the above-mentioned problems, and provides a security diagnostic device capable of diagnosing whether there is a defect in authority management without grasping the transition destination URL of the Web application in advance.
  • the purpose is to get.
  • the fixed parameter having the same value as the parameter included in the HTTP request sent to the transition destination URL by the second account of the privilege
  • the extraction unit that extracts the URL and the parameter of the HTTP request to the transition destination URL by the general rights account include fixed parameters extracted by the extraction unit, and the value is different from the value of the account of the privilege
  • the fixed Based on a request generation unit that outputs an HTTP request in which the value of a privileged account is set in the parameter, a request transmission / reception unit that transmits an HTTP request to a transition destination URL with a general rights account, and receives an HTTP response, and an HTTP response Determine vulnerability of transition destination URL A determination unit, with a.
  • a security diagnostic device capable of diagnosing whether there is a deficiency in authority management without grasping the transition destination URL of the Web application in advance.
  • FIG. 2 is a block diagram showing an example of the hardware configuration of the security diagnosis device according to the first embodiment.
  • FIG. 2 is a block diagram showing an example of a functional configuration of the diagnostic device according to the first embodiment.
  • FIG. 6 is a view showing an example of an account information table according to the first embodiment.
  • FIG. 5 is a diagram showing an example of a login parameter table according to the first embodiment.
  • FIG. 6 is a diagram showing an example of a target URL table according to the first embodiment.
  • FIG. 5 is a diagram showing an example of an HTTP request / response table according to the first embodiment.
  • FIG. 5 is a diagram showing an example of a parameter table according to the first embodiment.
  • FIG. 6 shows an example of a fixed parameter table according to the first embodiment.
  • FIG. 6 is a diagram showing an example of a diagnosis result table according to the first embodiment.
  • FIG. 8 is a view showing an example of a result detail table according to the first embodiment.
  • the flowchart which shows the flow of processing of the input part, crawling implementation part, and extraction part concerning Embodiment 1.
  • FIG. FIG. 6 shows an example of an HTTP request / response table 441 according to the first embodiment.
  • FIG. 6 shows an example of a parameter table 451 according to the first embodiment.
  • 6 is a flowchart showing a flow of processing of a comparison unit, a request generation unit, a request transmission / reception unit, a determination unit, and an output unit according to the first embodiment.
  • FIG. 15 is a flowchart showing details of processing of the comparing unit in step S201 of FIG.
  • FIG. 14 The figure which shows an example of the HTTP request response table which concerns on Embodiment 2.
  • FIG. 7 is a view showing an example of a parameter table according to the second embodiment.
  • FIG. 7 is a view showing an example of a fixed parameter table according to the second embodiment.
  • FIG. 7 is a view showing an example of a fixed parameter table according to the second embodiment.
  • FIG. FIG. 15 is a flowchart showing details of processing of the comparing unit in step S201 of FIG. 14 according to the second embodiment;
  • FIG. FIG. 8 is a view showing an example of a diagnosis result table according to the second embodiment.
  • FIG. 16 is a view showing an example of a result detail table according to the second embodiment.
  • FIG. 13 is an entire block diagram including an example of a functional configuration of a diagnostic device according to a third embodiment.
  • the flowchart which shows the flow of a process of the input part which concerns on Embodiment 3, a crawl implementation part, and an extraction part.
  • FIG. 18 is a view showing an example of a parameter table of transition data DB according to the third embodiment.
  • 16 is a flowchart showing a flow of processing of a comparison unit, a request generation unit, a request transmission / reception unit, a determination unit, and an output unit according to the third embodiment.
  • FIG. 16 is a block diagram of the whole including an example of a functional configuration of a diagnosis object extraction device according to a fourth embodiment.
  • FIG. 16 is an entire block diagram including an example of a functional configuration of a diagnosis execution device according to a fourth embodiment.
  • 15 is a flowchart showing a flow of processing of an input unit, a crawling implementation unit, and an extraction unit of a diagnosis object extraction device according to a fourth embodiment.
  • the flowchart which shows the flow of processing of the input part of the diagnostic execution apparatus which concerns on Embodiment 4, a request production
  • FIG. 1 is a block diagram showing an example of a hardware configuration of a security diagnostic apparatus (hereinafter referred to as a diagnostic apparatus) 200 according to the first embodiment.
  • the diagnostic device 200 includes a communication interface 101 that communicates with a Web application to be diagnosed and HTTP, a processor 102 that performs arithmetic processing on HTTP requests and HTTP responses, a memory 103 that holds arithmetic results, and the like, and an input that receives input from a user.
  • the processor 102 is realized by a CPU that executes a program stored in a memory, and a processing circuit such as a system LSI (Large Scale Integration).
  • the processor 102 may be configured by cooperation of a plurality of processing circuits.
  • the memory 103 is configured by, for example, a read only memory (ROM), a random access memory (RAM), and a solid state drive (SSD).
  • the auxiliary storage device 105 is configured of, for example, an HDD (Hard Disk Drive).
  • FIG. 2 is a block diagram of the whole including an example of a functional configuration of the diagnostic device 200 according to the first embodiment.
  • the web application 203 transmits an HTTP request to the web server 201 via the Internet 202 based on an instruction from the diagnostic device 200.
  • the web application 203 receives an HTTP response from the web server 201, and outputs the content of the HTTP response to the diagnostic device 200.
  • the diagnostic device 200 may receive an HTTP response from the web server 201 in some cases.
  • the diagnostic device 200 includes an input unit 301, a crawling execution unit 302, an extraction unit 303, a comparison unit 304, a request generation unit 305, a request transmission / reception unit 306, a determination unit 307, an output unit 308, an account information database (hereinafter referred to as an account information database).
  • an account information database hereinafter referred to as an account information database.
  • a transition data database hereinafter referred to as transition data DB
  • transition data DB a fixed parameter database
  • result data database hereinafter referred to as result data DB
  • Programs and data for realizing the functions of the input unit 301, the crawling implementation unit 302, the extraction unit 303, the comparison unit 304, the request generation unit 305, the request transmission / reception unit 306, the determination unit 307, and the output unit 308 are stored in the memory 103. It is memorized. Further, the account information DB 309, the transition data DB 310, the fixed parameter DB 311, and the result data DB 312 are respectively arranged on the auxiliary storage device 105, and are appropriately expanded in the memory 103.
  • the input unit 301 is read by the memory 103 and executed by the processor 102.
  • the input unit 301 stores the value input via the input interface 106 in the auxiliary storage device 105.
  • the input unit 301 outputs the input value to the account information DB 309 and the transition data DB 310 on the auxiliary storage device 105.
  • a target URL to be diagnosed and account information (login information, authority information) are input to the input unit 301.
  • the account information DB 309 holds two types of tables, an account information table 410 and a login parameter table 420.
  • FIG. 3 is a diagram showing an example of an account information table according to the first embodiment.
  • the account information table 410 is a table having fields for storing the ID of an account that can log in to the Web application 203, a password, and the authority (account authority) assigned to the account.
  • a privilege is an administrator right that allows all operations.
  • the general right is an authority in which the operation range is limited only to the range in which the general user can operate.
  • the number of accounts stored in the account information table 410 is two or more for each right. It is to see differences in parameters due to differences in accounts with the same authority.
  • FIG. 4 is a diagram showing an example of a login parameter table according to the first embodiment.
  • the login parameter table 420 is a table having fields for storing parameter names necessary for login.
  • the transition data DB 310 holds three types of tables, a target URL table 430, an HTTP request / response table 440, and a parameter table 450.
  • FIG. 5 is a diagram showing an example of a target URL table according to the first embodiment.
  • the target URL table 430 is a table having a field for storing the target URL input by the input unit 301.
  • FIG. 6 is a diagram showing an example of the HTTP request / response table according to the first embodiment.
  • the HTTP request / response table 440 includes the transition destination URL to which the HTTP request is sent, the response code to the HTTP request to the transition destination URL, the content of the response to the HTTP request to the transition destination URL, and the HTTP request to the transition destination URL. It is a table having a field for storing the source of the transition source that is the source, and the authority of the account that has sent the HTTP request to the destination of the URL.
  • FIG. 7 is a diagram showing an example of the parameter table 450 according to the first embodiment.
  • the parameter table 450 is a table having fields for storing, for each transition destination URL, the parameter name of the HTTP request, the value of the parameter, and the value at which the parameter is described (URL query part, header part or body part). is there.
  • the value indicating the position where the parameter is described is the name part of the query string in the URL of the HTTP request, the header name of the HTTP header part, and the variable name of the HTTP body part.
  • the value of the parameter is a part of the value assigned to the parameter.
  • the crawling execution unit 302 is read into the memory 103 and executed by the processor 102.
  • the crawling implementation unit 302 reads the account information DB 309 and the transition data DB 310 from the auxiliary storage device 105.
  • the crawling implementation unit 302 logs in to each of the target URLs stored in the transition data DB 310 with each account stored in the account information DB 309, and crawls a web page that can be transitioned using the logged-in account.
  • the Web application 203 According to the instruction of the crawling implementation unit 302, the Web application 203 generates an HTTP request, and transmits the HTTP request to the Web server 201 via the Internet 202.
  • the crawling implementation unit 302 stores the HTTP request generated at the time of crawling and the HTTP response thereto in the transition data DB 310 on the auxiliary storage device 105.
  • Crawling is a technology in which a program called a crawler follows all hyperlinks in a given URL, collects page information of transition destinations, and performs indexing. In addition, it is possible to acquire all the information of the HTTP request and HTTP response generated from the local proxy by performing crawling via the local proxy.
  • the extraction unit 303 is read by the memory 103 and executed by the processor 102.
  • the extraction unit 303 reads the transition data DB 310 from the auxiliary storage device 105.
  • the difference of the parameter of the HTTP request is output to the fixed parameter DB 311 on the auxiliary storage device 105.
  • the fixed parameter DB 311 holds a fixed parameter table 460.
  • FIG. 8 is a diagram showing an example of the fixed parameter table 460 according to the first embodiment.
  • the fixed parameter table 460 is a table having a field for storing the parameter name of the HTTP request for each transition destination URL, and a field for indicating whether the parameter is fixed or variable.
  • the comparison unit 304 is read by the memory 103 and executed by the processor 102.
  • the comparison unit 304 reads the transition data DB 310 from the auxiliary storage device 105.
  • the comparison unit 304 compares the parameters for the same record in which the transition destination URL stored in the transition data DB 310 is the same, and outputs the transition destination URL having a different portion as the diagnosis target URL to the result data DB 312.
  • the request generation unit 305 is read by the memory 103 and executed by the processor 102.
  • the request generation unit 305 reads the result data DB 312 and the transition data DB 310 from the auxiliary storage device 105.
  • the request transmission / reception unit 306 is read by the memory 103 and executed by the processor 102.
  • the request generation unit 305 instructs the request transmission / reception unit 306 to generate an HTTP request for the URL to be diagnosed.
  • the request transmission / reception unit 306 instructs the Web application 203 to generate an HTTP request for the URL to be diagnosed.
  • the request transmission / reception unit 306 outputs the HTTP request generated by the Web application 203 to the request generation unit 305.
  • the request generation unit 305 rewrites the HTTP request generated by the Web application 203 for trial in order to test whether the same operation as general rights and privileges can be performed on the diagnosis target URL, and the rewritten HTTP request is transmitted to the request transmission / reception unit 306 Output to
  • the request transmission / reception unit 306 transmits the HTTP request input from the request transmission / reception unit 306 to the Web server 201 via the Internet 202.
  • the request transmission / reception unit 306 receives an HTTP response to an HTTP request from the web server 201 via the Internet 202, and outputs the received HTTP response to the determination unit 307.
  • the determination unit 307 is read by the memory 103 and executed by the processor 102.
  • the determination unit 307 reads the HTTP response received by the request transmission / reception unit 306 and the transition data DB 310 from the auxiliary storage device 105.
  • the determination unit 307 determines the presence or absence of vulnerability from the HTTP response and the HTTP response to the HTTP request with the privilege stored in the transition data DB 310, and outputs the determined result to the result data DB 312.
  • the output unit 308 is read by the memory 103 and executed by the processor 102.
  • the output unit 308 reads out from the auxiliary storage device 105 the result data DB 312 stored in the auxiliary storage device 105.
  • the output unit 308 outputs the determination result read out from the result data DB 312 to the output interface 106.
  • the result data DB 312 holds two types of tables, a diagnosis result table 470 and a result detail table 480.
  • FIG. 9 is a diagram showing an example of the diagnosis result table 470 according to the first embodiment.
  • FIG. 10 is a diagram showing an example of the result detail table 480 according to the first embodiment.
  • the diagnosis result table 470 is a table having fields for storing the diagnosis target URL and the result of the determination unit 307.
  • the result detail table 480 is a table having fields for storing diagnostic target URLs determined to be vulnerable and parameter names used.
  • FIG. 11 is a flowchart showing the flow of processing of the input unit 301, the crawling implementation unit 302, and the extraction unit 303 according to the first embodiment.
  • a solid line indicates a flow path, and a broken line indicates data writing and calling for each DB.
  • FIG. 12 is a diagram showing an example of the HTTP request / response table 441 according to the first embodiment.
  • FIG. 13 is a diagram showing an example of the parameter table 451 according to the first embodiment.
  • the input unit 301 When account information and a target URL are input through the input interface 106, the input unit 301 starts processing. In step S101 of FIG. 11, the input unit 301 stores the input account information in the account information table 410 and the login parameter 420 of the account information DB 309.
  • the account information includes login information such as an account ID and password required when logging in to the web application 203, account privileges of the account, and parameter names of parameters necessary for login.
  • the input unit 301 stores the account ID, the password, and the account authority in the items of the account ID, the password, and the authority of the account information table 410.
  • the account ID “mng1”, the password “1234abc”, and the right “privilege” are stored as the item number U01.
  • the input unit 301 stores the parameter name in the login parameter table 420.
  • the parameter “accountid” is stored as the item number ID
  • the parameter “passwd” is stored as the item number PWD.
  • the input unit 301 stores the input target URL in the target URL table 430 of the transition data DB 310.
  • the target URL “http://xxx.com” is stored in the target URL table 430. The processing proceeds to step S102.
  • step S102 the crawling implementation unit 302 selects one record of accounts for which crawling is not performed from the account information table 410 stored in the account information DB 309, and reads out the account ID and the password. The processing proceeds to step S103.
  • step S103 the crawling implementation unit 302 reads the target URL "http://xxx.com" from the target URL table 430 of the transition data DB 310.
  • the crawling execution unit 302 logs in to the web application 203 with the account ID and password of the selected account, and crawls the target URL.
  • the process will be described by way of an example where the crawling implementation unit 302 logs in to the Web application 203 with the account of the item number U01 of the account information table 410.
  • the crawling execution unit 302 transmits an HTTP request to the target URL “http://xxx.com”, and further, “http://xxx.com/login.com” which is a link on “http://xxx.com”. Send an HTTP request to php.
  • the crawling execution unit 302 sets the contents of the HTTP response to the item number URL 01 of the HTTP request / response table 441 of the transition data DB 310. save.
  • the crawling implementation unit 302 sets “http://xxx.com/login.php” as the transition destination URL, “200” as the response code, Header information and body information of the response as the response content, and “http: // transition source URL”. /xxx.com, save "privileges" in the authority.
  • the authority stores the type of authority of the logged-in account.
  • the crawling implementation unit 302 stores the parameter in the parameter table 451 of the transition data DB 310. Although not shown in the parameter table 451 of FIG. 13, it is assumed that parameters are stored.
  • the crawling implementation unit 302 transmits an HTTP request to “http://xxx.com/top.php” which is a link on “http://xxx.com/login.php”.
  • the crawling implementation unit 302 stores the content of the HTTP response in the item number URL 02 of the HTTP request / response table 441.
  • the crawling implementation unit 302 sets “http://xxx.com/top.php” as the transition destination URL, “200” as the response code, Header information and body information of the response as the response content, and “http: // transition source URL”. Save “Privileges" in the permissions, /xxx.com/login.php.
  • the parameters auth and userID are included in the HTTP request sent to the transition destination URL “http://xxx.com/top.php”.
  • the crawling implementation unit 302 sets the parameter name, the value of the parameter, and the value (query part of the URL, the header part or the body part) indicating the position where the parameter is described in the item numbers URL02-01 and URL02-02 of the parameter table 451. save.
  • the item numbers URL02-01 and URL02-02 indicate that the parameters are URL02.
  • the crawling implementation unit 302 assigns item numbers so that the correspondence can be known to which HTTP request the parameter is included. In the present embodiment, correspondence is indicated by item numbers, but other methods may be used.
  • the crawling execution unit 302 follows the target URL “http://xxx.com” and all links under it, collects the page information of the transition destination as described above, and collects the collected information as an HTTP request / response. It is stored in the table 441 and the parameter table 451. When page information is collected until there is no link destination not transitioning even in the transition destination page, the crawling execution unit 302 ends crawling and logs out. The processing proceeds to step S104.
  • step S104 the crawling implementation unit 302 determines whether there is an account for which crawling has not been performed.
  • the crawling execution unit 302 knows whether crawling has been performed for each account in the account information table 410. If there is an account for which crawling has not been performed, the process proceeds to step S102, and crawling execution unit 302 selects an account for which crawling has not been performed and performs crawling.
  • the crawling execution unit 302 repeats the flow of steps S102 to S104 until there is no account for which crawling has not been performed.
  • step S104 It returns to description of the flowchart of FIG. If there is no account for which crawling has not been performed in step S104, the process proceeds to step S105.
  • step S105 the extraction unit 303 performs a process of extracting the difference in the value of the parameter of the HTTP request for the same record with the privilege and the privilege for the same transition destination.
  • the extraction unit 303 selects, from the HTTP request / response table 441, records in which the authority is a privilege and the transition destination URL is the same.
  • the case where item number URL 02 and item number URL 04 are selected will be described as an example.
  • the parameters related to the item number URL 02 and URL 04 are stored in URL 02-01 to URL 02-02 and URL 04-01 to URL 04-02 of the parameter table 451.
  • the extraction unit 303 extracts the difference between these parameters.
  • the extraction unit 303 Since the values of the URL 02-01 and the URL 04-01 have the same value, the extraction unit 303 stores “URL 04-01” as the target of the item number PARAM 02-01 of the fixed parameter table 460 and “fixed” as the fixed. Since the values of the URL 02-02 and the URL 04-02 are different, the extraction unit 303 stores “URL 04-02” as the target of the item number PARAM 02-02 of the fixed parameter table 460 and “variation” as the fixed. The process ends.
  • the parameter of HTTP request is the value of the parameter which is different every time when logging in such as session ID and time, the value of fixed parameter which does not change every time when logging in such as header information such as destination URL and content-type, user ID Such as login does not change every time the account is divided into three different parameter values ,.
  • the extraction unit 303 can extract, from the parameters of the HTTP request, fixed parameters that do not change each time the user logs in.
  • FIG. 14 is a flowchart showing a flow of processing of the comparison unit 304, the request generation unit 305, the request transmission / reception unit 306, the determination unit 307, and the output unit 308 according to the first embodiment.
  • the solid lines indicate the flow path, and the broken lines indicate writing and calling of data to each DB.
  • step S201 the comparison unit 304 selects a record from the HTTP request / response table 441 of the transition data DB 310, and compares it with other records. Details of step S201 will be described using FIG.
  • FIG. 15 is a flowchart showing details of the process of the comparing unit 304 in step S201 of FIG. 14 according to the first embodiment.
  • step S301 the comparison unit 304 selects one record from the HTTP request / response table 441 and determines whether there is another record having the same transition destination URL. If there is no record having the same transition destination URL, the process proceeds to step S302. If there is another record having the same transition destination URL, the process proceeds to step S304.
  • step S302 the comparison unit 304 determines whether the authority of the selected record is a privilege. If the authority of the selected record is a privilege, the process proceeds to step S303. If the authority of the selected record is not a privilege, the comparison unit 304 excludes the transition destination URL of the selected record from the diagnostic target, and the process ends.
  • step S303 the comparison unit 304 stores the transition destination URL of the selected record in the diagnosis result table 470 of the result data DB 312 of FIG. 9, and the process ends.
  • step S304 the comparison unit 304 refers to the parameter table 451 and determines whether the record having the same transition destination URL has parameter names for only records of privileges. If the parameter name exists only for the privilege record, the process proceeds to step S305. If the parameter name is not the only record of the privilege, the process proceeds to step S306.
  • step S305 the comparison unit 304 stores the transition destination URL of the selected record and the parameter name in the diagnosis result table 470 of the result data DB 312, and the process ends.
  • step S306 the comparison unit 304 refers to the parameter table 451 and determines whether the same parameter name exists in the privilege and the general right for the record having the same transition destination URL. If the same parameter name exists for the privilege and the general right, the process proceeds to step S307. If the same parameter name does not exist for the privilege and the general right, the comparison unit 304 excludes the transition destination URL of the selected record from the diagnosis target, and the process ends.
  • step S307 the comparison unit 304 refers to the parameter table 451 and determines whether the same parameter name exists for the privilege and the general right, and the value is the same. If the values are not the same, the process proceeds to step S308. If the values are the same, the comparison unit 304 excludes the transition destination URL of the selected record from the diagnostic target, and the process ends.
  • step S308 the comparison unit 304 refers to the fixed parameter table 460 and determines whether the parameter is fixed. If the parameter is fixed, the process proceeds to step S305. If the parameter is not fixed, the comparison unit 304 excludes the transition destination URL of the selected record from the diagnostic target, and the process ends.
  • step S202 the request generation unit 305 uses the information stored in the account information DB 309 to log in to the Web application 203 with a general rights account. It is assumed that the user logs in with the account "user 1" of item No. U03. The processing proceeds to step S203.
  • step S203 the request generation unit 305 selects a diagnosis target URL from the diagnosis result table 470, and reads from the HTTP request / response table 441 a record in which a transition destination URL that matches the selected diagnosis target URL is stored.
  • the access right of the read record is only privilege, it means that the transition destination URL exists only when the privilege is.
  • the processing proceeds to step S204.
  • the access right of the read record is both a record of privilege and a record of general right, it means that the URL to be diagnosed also exists in the general right.
  • the processing proceeds to step S205.
  • step S 204 the request generation unit 305 outputs the URL to be diagnosed to the Web application 203 via the request transmission / reception unit 306.
  • the request generation unit 305 receives an HTTP request of a general right for the URL to be diagnosed from the Web application 203 via the request transmission / reception unit 306.
  • the request generation unit 305 generates an HTTP request based on the record read from the HTTP request / response table 441.
  • the read record is a privilege record.
  • the request generation unit 305 reads the parameter set in the HTTP request from the record of the parameter table 451 associated with the record read from the HTTP request / response table 441.
  • the read parameters are parameters set in the HTTP request in the case of privilege.
  • the request generation unit 305 refers to the fixed parameter table 460 of the fixed parameter DB 311, and does not change the value of the HTTP request parameter when the read parameter is fixed. If the read parameter is a change, the value of the HTTP request parameter is changed to the value of the HTTP request parameter of the general right received from the Web application 203. Further, the request generation unit 305 stores the URL to be diagnosed and the parameter name whose value has been changed in the result detail table 480 of the result data DB 312. The request generation unit 305 outputs the HTTP request generated in this manner to the request transmission / reception unit 306. The request transmission / reception unit 306 transmits the HTTP request input from the request generation unit 305 to the Web server 201, and outputs an HTTP response from the Web server 201 to the determination unit 307. The processing proceeds to step S206.
  • step S205 the request generation unit 305 outputs the diagnosis target URL to the Web application 203 via the request transmission / reception unit 306, and the Web application 203 via the request transmission / reception unit 306 sends an HTTP request for a general right to the diagnosis target URL.
  • receive. The request generation unit 305 reads the parameter set in the HTTP request from the record of the parameter table 451 associated with the record read from the HTTP request / response table 441 in step S203, in the case of the privilege.
  • the request generation unit 305 refers to the fixed parameter table 460 of the fixed parameter DB 311, and when there is a record corresponding to the parameter included in the HTTP request of the general right and is fixed, the value of the corresponding parameter of the HTTP request is a parameter of the privilege Change to the value of Further, the request generation unit 305 stores the URL to be diagnosed and the parameter name whose value has been changed in the result detail table 480 of the result data DB 312. If there is a record corresponding to the parameter included in the HTTP request of the general right and there is a change, the request generation unit 305 does not change the value of the corresponding parameter of the HTTP request.
  • the fixed parameters are, for example, parameters of authority identification. Parameters of fluctuation are, for example, user ID and time.
  • the request generation unit 305 adds a parameter not included in the HTTP request of the general right among the read parameters of the privilege to the HTTP request.
  • the request generation unit 305 outputs the HTTP request generated in this manner to the request transmission / reception unit 306.
  • the request transmission / reception unit 306 transmits the HTTP request input from the request generation unit 305 to the Web server 201.
  • the request transmission / reception unit 306 outputs the received HTTP response to the determination unit 307. The processing proceeds to step S206.
  • step S206 the determination unit 307 compares the response code of the input HTTP response with the response code of the normal response stored in the HTTP request / response table 441.
  • the determination unit 307 determines the vulnerability by comparing the values of the response code. When the response code is the same, the operation of the privilege can be executed even with the general right, and the determination unit 307 determines that the user is vulnerable. If the response codes are different, the determination unit 307 determines that there is no vulnerability.
  • the determination unit 307 stores the presence or absence of the determined vulnerability in the vulnerability of the record corresponding to the diagnosis target URL in the diagnosis result table 470. The processing proceeds to step S207.
  • step S207 the determination unit 307 determines whether the vulnerability determination process has been completed for all the records in the diagnosis result table 470. If the item of vulnerability is set for all the records of the diagnosis result table 470, the determining unit 307 determines that the process is completed. If it is completed, the process proceeds to step S208. If not completed, the process returns to step S202. The processes in steps S202 to S207 are repeated until the items of vulnerability are set for all the records in the diagnosis result table 470.
  • step S208 the output unit 308 outputs the data of the result data DB 312 to the output interface 104, and the process ends.
  • the received HTTP response and the response code of the normal HTTP response stored in the HTTP request / response table 441 are the same, it is determined that vulnerability exists, but Header information or Body information of the HTTP response
  • the vulnerability may be determined using the value contained in.
  • the parameters included in the HTTP request transmitted to the transition destination URL by the first account of privilege among the parameters included in the HTTP request transmitted to the transition destination URL by the first account of privilege, the parameters included in the HTTP request transmitted to the transition destination URL by the second account of privilege and The extraction unit 303 for extracting fixed parameters having the same value, and the parameters of the HTTP request to the transition destination URL by the general rights account include the fixed parameters extracted by the extraction unit 303, and the value is a privilege If it differs from the value of the account, request generation unit 305 that outputs an HTTP request in which the value of the account of the privilege is set in fixed parameters, and an HTTP request is sent to the transition destination URL by the account of general rights, and an HTTP response is received.
  • the determination unit 307 that determines the vulnerability of the transition destination URL based on the TP response is provided, it is possible to diagnose whether there is a deficiency in authority management without grasping the transition destination URL of the Web application in advance. it can. By checking whether it is possible to execute a transition to a page not displayed on the screen of the general right or an operation that can not be performed, it is diagnosed whether there is a defect in the right management. Human cost can also be reduced because the diagnostic device 200 diagnoses the insufficient authority management.
  • the request generation unit 305 sets the value of the account of the privilege fixed. Since the parameter is added to the HTTP request and the HTTP request to which the fixed parameter is added is output, it is possible to diagnose whether there is a deficiency in authority management for parameters not included in the HTTP request of the general right.
  • the extraction unit 303 is different in value from the parameter included in the HTTP request transmitted to the transition destination URL by the second account.
  • the extraction unit 303 extracts fixed parameters that do not change each time the user logs in, but in the present embodiment, the combination of the transition destination URL and the parameters is An embodiment will be shown which extracts the same parameter whose value changes every time the user logs in. In the present embodiment, after all the configurations described in the first embodiment are provided, additional configurations will be described.
  • FIG. 16 is a diagram showing an example of the HTTP request / response table 442 according to the second embodiment.
  • FIG. 17 is a diagram showing an example of the parameter table 452 according to the second embodiment.
  • step S103 of FIG. 11 the crawling implementation unit 302 crawls with the selected account, logs out, logs in again to the web application 203 with the same account, and performs the second crawling on the target URL.
  • the crawling execution unit 302 logs out.
  • the HTTP request / response table 443 and the parameter table 453 in which the same values as the HTTP request / response table 442 in FIG. 16 and the parameter table 452 in FIG. 17 obtained in the first crawling are stored are obtained. . Note that illustration is omitted because the contents are the same.
  • the extraction unit 303 includes the HTTP request / response table 442 obtained by the first crawling, the parameter table 452, the HTTP request / response table 443 obtained by the second crawling, and the parameter table 453. With reference to each item number of the privilege of the HTTP request / response table 442, the difference between the parameters in the first crawling and the second crawling is extracted.
  • FIG. 18 is a diagram showing an example of the fixed parameter table 462 according to the second embodiment. Since the same value is obtained in the first crawling and the second crawling, all the parameters in the fixed parameter table 461 are fixed.
  • the extraction unit 303 selects a record of which the privilege is a privilege among the records of the HTTP request / response table 442.
  • the extraction unit 303 extracts the difference in the parameters for the same record as the transition destination URL of the selected record, the authority of which is privilege from the HTTP request / response table 442.
  • the extraction unit 303 stores the difference between the extracted parameters in the fixed parameter table 462.
  • FIG. 19 is a diagram showing an example of the fixed parameter table 462 according to the second embodiment. Since the values of the URL and the user ID are the same when comparing the item number URL 03 and the URL 04, “fixed” is stored in the fixed fields of the PARAM 03-01 and PARAM 03-02 of the fixed parameter table 462. On the other hand, since page has a different value, “variation” is stored in the fixed field of PARAM 03-03 in the fixed parameter table 462.
  • FIG. 20 is a diagram showing an example of the HTTP request / response table 444 according to the second embodiment.
  • the extraction unit 303 determines that the parameter page whose “variable” is stored in the fixed field in the fixed parameter table 462 is a parameter necessary to uniquely represent the page.
  • the extraction unit 303 adds the field of transition parameter to the HTTP request / response table 442, and generates the HTTP request / response table 444 in which the value of page is set.
  • step S201 the comparison unit 304 selects a record from the HTTP request / response table 444 of the transition data DB 310, and compares it with other records. Details of the process of step S201 will be described with reference to FIG.
  • FIG. 21 is a flowchart showing details of processing of the comparing unit 304 in step S201 of FIG. 14 according to the second embodiment.
  • FIG. 22 is a diagram showing an example of a diagnosis result table 471 according to the second embodiment.
  • FIG. 23 is a diagram showing an example of the result detail table 481 according to the second embodiment.
  • step S401 in FIG. 21 the comparison unit 304 selects one record from the HTTP request / response table 444, and determines whether there is another record having the same transition destination URL and transition parameter. If there is no record with the same transition destination URL and transition parameter, the process proceeds to step S402. If there is another record with the same transition destination URL and transition parameter, the process proceeds to step S404.
  • step S402 the comparison unit 304 determines whether the authority of the selected record is a privilege. If the authority of the selected record is a privilege, the process proceeds to step S403. If the authority of the selected record is not a privilege, the comparison unit 304 excludes the transition destination URL of the selected record from the diagnostic target, and the process ends.
  • step S403 the comparison unit 304 stores the transition destination URL of the selected record and the transition parameter in the diagnosis result table 471 of the result data DB 312, and the process ends.
  • step S404 the comparison unit 304 refers to the parameter table 452 and determines whether the parameter name exists for the record having the same transition destination URL and transition parameter as to only the record of the privilege. If the parameter name exists only for the privilege record, the process proceeds to step S405. If the parameter name is not the only record of the privilege, the process proceeds to step S406.
  • step S405 the comparison unit 304 stores the transition destination URL of the selected record, the transition parameter, and the parameter name in the result detail table 481 of the result data DB 312, and the process ends.
  • step S406 the comparison unit 304 refers to the parameter table 452 and determines whether the same parameter name exists with the privilege and the general right for the record having the same transition destination URL and transition parameter. If the same parameter name exists for the privilege and the general right, the process proceeds to step S407. If the same parameter name does not exist for the privilege and the general right, the comparison unit 304 excludes the transition destination URL and the transition parameter of the selected record from diagnosis targets, and the process ends.
  • step S407 the comparison unit 304 refers to the parameter table 444, and determines whether the same parameter name exists for the privilege and the general right, and the value is the same. If the values are not the same, the process proceeds to step S305. If the values are the same, the comparison unit 304 excludes the transition destination URL and the transition parameter of the selected record from the diagnostic target, and the process ends.
  • the crawling execution unit 302 stores the information obtained in the first and second crawlings in the HTTP request / response table 442 and the parameter table 452 without identifying the information.
  • Information obtained in the second crawling may be stored for identification.
  • the number of tables may be increased, or the number of columns of the table may be increased.
  • the extraction unit 303 transmits the HTTP request transmitted to the transition destination URL by the second account.
  • the fixed parameter value included in the HTTP request sent from the first account to the transition destination URL is different for the fixed parameter having the same value as the included parameter, the combination of the fixed parameter with the transition destination URL Since the page is extracted as a transition parameter that uniquely indicates the page, it is possible to diagnose deficiencies in authority management even when the page is uniquely indicated by a combination of the URL and the transition parameter.
  • FIG. 24 is a block diagram of the whole including an example of a functional configuration of a diagnosis apparatus 210 according to the third embodiment. The difference from the diagnostic device 200 of the first embodiment is that the unique data DB is deleted.
  • FIG. 25 is a flowchart showing a flow of processing of the input unit 301, the crawling implementation unit 302, and the extraction unit 303 according to the third embodiment.
  • the difference from the flowchart of FIG. 11 of the first embodiment is that the process is output to the transition data DB 310 from step S105.
  • FIG. 26 is a diagram showing an example of the parameter table 454 of the transition data DB 310 according to the third embodiment.
  • the difference from the parameter table 451 of the first embodiment is that fixed fields are added.
  • the extraction unit 303 extracts the difference in the value of the parameter of the HTTP request for the same record with the privilege and the privilege for the same transition destination. Since the values of the URL 02-01 and the URL 04-01 have the same value, the extraction unit 303 stores “fixed” as the item number URL 02-01 of the fixed parameter table 460 and the item number URL 04-01. Further, since the values of the URL 02-02 and the URL 04-02 are different, the extraction unit 303 stores “variation” in the item number PARAM 02-02 of the fixed parameter table 460 and the item number URL 04-02. The process ends.
  • FIG. 27 is a flowchart showing a flow of processes of the comparison unit 304, the request generation unit 305, the request transmission / reception unit 306, the determination unit 307, and the output unit 308 according to the third embodiment.
  • the difference from the flowchart of FIG. 14 of the first embodiment is that information on whether or not the parameter is unique is read out from the parameter table 454 of the transition parameter DB in step S201, step S204 and step S205.
  • a function of performing crawling twice for each account to determine a specific parameter necessary for page transition may be included.
  • the transition data DB 310 since the transition data DB 310 also holds the information of the unique parameter DB 311, the unique parameter DB 311 having the same number of records as the records of the parameter table T 203 of the transition data DB 310 is reduced and used in the unique parameter DB 311 Memory resources can be reduced.
  • the diagnostic device 200 extracts the diagnostic target URL and determines vulnerability, but in the present embodiment, the diagnostic target extraction device extracts the diagnostic target URL.
  • the embodiment which extracts and the vulnerability of the diagnostic object URL which the diagnostic implementation apparatus extracted is shown is shown.
  • FIG. 28 is a block diagram of the whole including one example of a functional configuration of a diagnosis object extraction device 220 relating to the fourth embodiment.
  • the diagnosis object extraction device 220 includes an input unit 301, a crawling implementation unit 302, an extraction unit 303, a comparison unit 304, an account information DB 313, a transition data DB 314, and an output unit 315.
  • the account information DB 313 and the transition data DB 314 hold the same functions as the account information DB 309 and the transition data DB 310 of the third embodiment.
  • the comparison unit 304 is read by the memory 103 and executed by the processor 102.
  • the comparison unit 304 reads the transition data DB 310 from the auxiliary storage device 105.
  • the comparison unit 304 compares the parameters for the same record in which the transition destination URL stored in the transition data DB 310 is the same, and outputs the transition destination URL having different portions as a diagnosis target URL to the output unit 315 together with the parameter.
  • the output unit 315 is read by the memory 103 and executed by the processor 102.
  • the output unit 315 outputs the URL to be diagnosed input from the comparison unit 304 to the output interface 106.
  • FIG. 29 is a block diagram of the whole including an example of a functional configuration of a diagnosis execution device 230 according to the fourth embodiment.
  • the diagnosis execution device 230 includes an input unit 316, a request generation unit 305, a request transmission / reception unit 306, a determination unit 307, an output unit 308, an account information DB 317, a transition data DB 318, and a result data DB 319.
  • Account information DB 317, transition data DB 318 and result data DB 319 hold the same functions as account information DB 309, transition data DB 310 and result data DB 312 of the third embodiment.
  • the input unit 316 is read into the memory 103 and executed by the processor 102.
  • the values input through the input interface 106 are stored in the auxiliary storage device 105.
  • the input unit 316 outputs the input account information (login information, authority information) to the account information DB 317 on the auxiliary storage device 105. Further, the input unit 316 outputs the URL to be diagnosed and the parameters to the transition data DB 318.
  • FIG. 30 is a flowchart showing a flow of processing of the input unit 301, the crawling implementation unit 302 and the extraction unit 303 of the diagnosis object extraction device 220 according to the fourth embodiment.
  • the processes of steps S501 to S505 are the same as the processes of steps S101 to S105 of FIG. 25 of the third embodiment.
  • step S505 the extraction unit 303 outputs, to the comparison unit 304, fixed parameters of the HTTP request for the same record with the same privileges and privileges for the same transition destination.
  • step S506 when the parameter input from the extraction unit 303 exists in the privilege and does not exist in the general right or the values are different, the comparison unit 304 outputs the transition destination URL and the parameter value as the diagnosis target data 320. Output via the unit 315. Also, the output unit 315 outputs the account information stored in the account information DB 313. The process ends.
  • FIG. 31 is a flowchart showing a flow of processing of the input unit 316, the request generation unit 305, the request transmission / reception unit 306, the determination unit 307, and the output unit 308 of the diagnosis execution device 230 according to the fourth embodiment.
  • step S601 account information and diagnostic target data 320 are input to the input unit 316.
  • the input unit 316 stores the input account information in the account information DB 317. Further, the input unit 316 stores the diagnosis target data 320 in the transition data DB 318 and the result data DB.
  • Steps S602 to S608 are the same as steps S202 to S208 in the third embodiment.
  • a function of performing crawling twice for each account to determine a specific parameter necessary for page transition may be included.
  • the information of the diagnosis object output from the diagnosis object extraction device 220 may be collected, and the security diagnosis may use an existing method.
  • information on an object to be diagnosed collected from a web application used in existing security diagnosis may be input to the diagnosis execution device 230.
  • the diagnosis target extraction apparatus 220 includes an extraction unit 303 that extracts a fixed parameter having the same value, and the fixed parameter extracted by the extraction unit 303 is included in the parameter of the HTTP request to the transition destination URL by the general rights account.
  • the HTTP request is output to the transition destination URL by the request generation unit 305 which outputs the HTTP request in which the value of the account of the privilege is set in the fixed parameter Send and receive HTTP response Since the diagnostic execution device 230 is provided with the quest transmission / reception unit 306 and the determination unit 307 that determines the vulnerability of the transition destination URL based on the HTTP response, grasping the transition destination URL of the Web application in advance It is possible to diagnose whether there is a lack of authority management.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Automation & Control Theory (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer And Data Communications (AREA)
  • Debugging And Monitoring (AREA)
  • Storage Device Security (AREA)

Abstract

セキュリティ診断装置は、特権の第１のアカウントにより遷移先ＵＲＬに送信したＨＴＴＰリクエストに含まれるパラメータのうち、特権の第２のアカウントにより遷移先ＵＲＬに送信したＨＴＴＰリクエストに含まれるパラメータと値が同じである固定のパラメータを抽出する抽出部と、一般権のアカウントによる遷移先ＵＲＬへのＨＴＴＰリクエストのパラメータに抽出部で抽出された固定のパラメータが含まれており、値が特権のアカウントの値と異なる場合、固定のパラメータに特権のアカウントの値を設定したＨＴＴＰリクエストを出力するリクエスト生成部と、一般権のアカウントによりＨＴＴＰリクエストを遷移先ＵＲＬに送信し、ＨＴＴＰレスポンスを受信するリクエスト送受信部と、ＨＴＴＰレスポンスに基づいて遷移先ＵＲＬの脆弱性を判定する判定部と、を備えたので、遷移先ＵＲＬを事前に把握することなく権限管理の不備を診断できる。

Description

セキュリティ診断装置およびセキュリティ診断方法
　本発明は、権限管理の不備を診断するセキュリティ診断装置に関する。
　インターネットに公開されているＷｅｂアプリケーションの脆弱性は日々発見されており、悪意のある攻撃者による攻撃は、警戒しなければならない脅威の一つである。Ｗｅｂアプリケーションの脆弱性の有無を確認する方法には、Ｗｅｂアプリケーション診断ツールやセキュリティ診断サービスがある。これらは、Ｗｅｂアプリケーションに対して疑似攻撃を実施することで、既知の脆弱性の有無を診断する。
　Ｗｅｂアプリケーションの脆弱性の一つに、権限管理の不備がある。権限管理の不備とは、異なる権限を持つ２つのアカウントがあった場合、一方のアカウントでのみ遷移可能なページまたは有効な機能が、他方のアカウントでも遷移可能または実行可能なケースである。従来、診断の実施者が目視で遷移可能なページまたは有効な機能についてのアカウント間の差異を確認して、ツールに設定するまたは手動で疑似攻撃を実行することにより、権限管理の不備を診断することが行われている。しかしながら、人的コストが掛かかるため、人的コストを削減することが求められている。
　特許文献１は、オブジェクトに対してアクセスを行った際の、権限要求ＡＰＩの呼出と実際のアクセスＡＰＩの呼出とをトレースすることで、想定されるアクセスＡＰＩを作成し、実際のアクセスＡＰＩの呼出と対応付けられているかを確認している。想定されるアクセスＡＰＩに対して実際のアクセスＡＰＩが対応付けられない場合、特許文献１は最小権限違反と判断している。
特開２０１０－１７６１６７号公報
　しかしながら、特許文献１では、オブジェクトに対する権限の割当てが不明の場合には権限管理の不備があるかどうかを判断することができないという問題点があった。
　本発明は上記のような問題点を解決するためになされたもので、Ｗｅｂアプリケーションの遷移先ＵＲＬを事前に把握することなく権限管理の不備があるかどうかを診断することができるセキュリティ診断装置を得ることを目的としている。
　特権の第１のアカウントにより遷移先ＵＲＬに送信したＨＴＴＰリクエストに含まれるパラメータのうち、特権の第２のアカウントにより遷移先ＵＲＬに送信したＨＴＴＰリクエストに含まれるパラメータと値が同じである固定のパラメータを抽出する抽出部と、一般権のアカウントによる遷移先ＵＲＬへのＨＴＴＰリクエストのパラメータに抽出部で抽出された固定のパラメータが含まれており、値が特権のアカウントの値と異なる場合、固定のパラメータに特権のアカウントの値を設定したＨＴＴＰリクエストを出力するリクエスト生成部と、一般権のアカウントによりＨＴＴＰリクエストを遷移先ＵＲＬに送信し、ＨＴＴＰレスポンスを受信するリクエスト送受信部と、ＨＴＴＰレスポンスに基づいて遷移先ＵＲＬの脆弱性を判定する判定部と、を備えた。
　本発明によれば、Ｗｅｂアプリケーションの遷移先ＵＲＬを事前に把握することなく権限管理の不備があるかどうかを診断することができるセキュリティ診断装置を得ることができる。
実施の形態１に係るセキュリティ診断装置のハードウェア構成の一例を示すブロック図。 実施の形態１に係る診断装置の機能構成の一例を示すブロック図。 実施の形態１に係るアカウント情報テーブルの一例を示す図。 実施の形態１に係るログインパラメータテーブルの一例を示す図。 実施の形態１に係る対象ＵＲＬテーブルの一例を示す図。 実施の形態１に係るＨＴＴＰリクエスト・レスポンステーブルの一例を示す図。 実施の形態１に係るパラメータテーブルの一例を示す図。 実施の形態１に係る固定パラメータテーブルの一例を示す図。 実施の形態１に係る診断結果テーブルの一例を示す図。 実施の形態１に係る結果詳細テーブルの一例を示す図。 実施の形態１に係る入力部、クローリング実施部および抽出部の処理の流れを示すフローチャート。 実施の形態１に係るＨＴＴＰリクエスト・レスポンステーブル４４１の一例を示す図。 実施の形態１に係るパラメータテーブル４５１の一例を示す図。 実施の形態１に係る比較部、リクエスト生成部、リクエスト送受信部、判定部及び出力部の処理の流れを示すフローチャート。 実施の形態１に係る図１４のステップＳ２０１の比較部の処理の詳細を示すフローチャート。 実施の形態２に係るＨＴＴＰリクエスト・レスポンステーブルの一例を示す図。 実施の形態２に係るパラメータテーブルの一例を示す図。 実施の形態２に係る固定パラメータテーブルの一例を示す図。 実施の形態２に係る固定パラメータテーブルの一例を示す図。 実施の形態２に係るＨＴＴＰリクエスト・レスポンステーブルの一例を示す図。 実施の形態２に係る図１４のステップＳ２０１の比較部の処理の詳細を示すフローチャート。 実施の形態２に係る診断結果テーブルの一例を示す図。 実施の形態２に係る結果詳細テーブルの一例を示す図。 実施の形態３に係る診断装置の機能構成の一例を含む全体のブロック図。 実施の形態３に係る入力部、クローリング実施部および抽出部の処理の流れを示すフローチャート。 実施の形態３に係る遷移データＤＢのパラメータテーブルの一例を示す図。 実施の形態３に係る比較部、リクエスト生成部、リクエスト送受信部、判定部及び出力部の処理の流れを示すフローチャート。 実施の形態４に係る診断対象抽出装置の機能構成の一例を含む全体のブロック図。 実施の形態４に係る診断実施装置の機能構成の一例を含む全体のブロック図。 実施の形態４に係る診断対象抽出装置の入力部、クローリング実施部および抽出部の処理の流れを示すフローチャート。 実施の形態４に係る診断実施装置の入力部、リクエスト生成部、リクエスト送受信部、判定部及び出力部の処理の流れを示すフローチャート。
　以下この発明の実施の形態を、図を参照して説明する。なお、参照する図において同一もしくは相当する部分には同一の符号を付している。
　実施の形態１．
　はじめにハードウェア構成について説明する。
　図１は、実施の形態１に係るセキュリティ診断装置（以下、診断装置と称す）２００のハードウェア構成の一例を示すブロック図である。
　診断装置２００は、診断対象のＷｅｂアプリケーションとＨＴＴＰでの通信を行う通信インターフェース１０１、ＨＴＴＰリクエストとＨＴＴＰレスポンスに対する演算処理を行うプロセッサ１０２、演算結果などを保持するメモリ１０３、ユーザからの入力を受け付ける入力インターフェース１０４、データを記憶するための補助記憶装置１０５、および画面に結果を表示する出力インターフェース１０６を備える。
　プロセッサ１０２は、メモリに記憶されたプログラムを実行するＣＰＵ、システムＬＳＩ（Ｌａｒｇｅ　Ｓｃａｌｅ　Ｉｎｔｅｇｒａｔｉｏｎ）等の処理回路により、実現される。プロセッサ１０２は、複数の処理回路が連携して構成されてもよい。メモリ１０３は、例えば、ＲＯＭ（Ｒｅａｄ　Ｏｎｌｙ　Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ）、ＳＳＤ（Ｓｏｌｉｄ　Ｓｔａｔｅ　Ｄｒｉｖｅ）で構成される。補助記憶装置１０５は、例えば、ＨＤＤ（Ｈａｒｄ　Ｄｉｓｋ　Ｄｒｉｖｅ）で構成される。
　次に機能構成について説明する。
　図２は、実施の形態１に係る診断装置２００の機能構成の一例を含む全体のブロック図である。
　Ｗｅｂアプリケーション２０３は、診断装置２００からの指示に基づき、インターネット２０２を介してＷｅｂサーバ２０１にＨＴＴＰリクエストを送信する。Ｗｅｂアプリケーション２０３は、Ｗｅｂサーバ２０１からＨＴＴＰレスポンスを受信し、ＨＴＴＰレスポンスの内容を診断装置２００に出力する。診断装置２００は、Ｗｅｂサーバ２０１からＨＴＴＰレスポンスを受信する場合もある。
　診断装置２００は、入力部３０１、クローリング実施部３０２、抽出部３０３、比較部３０４、リクエスト生成部３０５、リクエスト送受信部３０６、判定部３０７、出力部３０８、アカウント情報データベース（以下、アカウント情報ＤＢと称す）３０９、遷移データデータベース（以下、遷移データＤＢと称す）３１０、固定パラメータデータベース（以下、固定パラメータＤＢと称す）３１１および結果データデータベース（以下、結果データＤＢと称す）３１２を備える。
　入力部３０１、クローリング実施部３０２、抽出部３０３、比較部３０４、リクエスト生成部３０５、リクエスト送受信部３０６、判定部３０７および出力部３０８の各機能を実現するためのプログラム及びデータは、メモリ１０３に記憶される。また、アカウント情報ＤＢ３０９、遷移データＤＢ３１０、固定パラメータＤＢ３１１および結果データＤＢ３１２はそれぞれ補助記憶装置１０５上に配置され、適宜メモリ１０３に展開される。
　入力部３０１は、メモリ１０３に読み出され、プロセッサ１０２で実行される。入力部３０１は、入力インターフェース１０６を介して入力された値を補助記憶装置１０５へ保存する。入力部３０１は、入力された値を補助記憶装置１０５上のアカウント情報ＤＢ３０９と遷移データＤＢ３１０へ出力する。入力部３０１には、診断対象の対象ＵＲＬと、アカウント情報（ログイン情報、権限情報）が入力される。
　アカウント情報ＤＢ３０９は、アカウント情報テーブル４１０およびログインパラメータテーブル４２０の２種類のテーブルを保持する。
　図３は、実施の形態１に係るアカウント情報テーブルの一例を示す図である。
　アカウント情報テーブル４１０は、Ｗｅｂアプリケーション２０３にログイン可能なアカウントのＩＤ、パスワード、アカウントに割り当てられた権限（アカウント権限）を保存するフィールドを持つテーブルである。アカウント権限は、特権と一般権の２種類がある。特権は、全ての操作が可能である管理者権限である。一般権は、一般ユーザが操作可能な範囲のみに操作範囲を制限した権限である。
　アカウント情報テーブル４１０に保存するアカウントの数は各権限で２つ以上とする。同じ権限でアカウントの違いによるパラメータの差異をみるためである。
　図４は、実施の形態１に係るログインパラメータテーブルの一例を示す図である。
　ログインパラメータテーブル４２０は、ログイン時に必要なパラメータ名を保存するフィールドを持つテーブルである。
　遷移データＤＢ３１０は、対象ＵＲＬテーブル４３０、ＨＴＴＰリクエスト・レスポンステーブル４４０およびパラメータテーブル４５０の３種類のテーブルを保持する。
　図５は、実施の形態１に係る対象ＵＲＬテーブルの一例を示す図である。
　対象ＵＲＬテーブル４３０は、入力部３０１で入力された対象ＵＲＬを保存するフィールドを持つテーブルである。
　図６は、実施の形態１に係るＨＴＴＰリクエスト・レスポンステーブルの一例を示す図である。
　ＨＴＴＰリクエスト・レスポンステーブル４４０は、ＨＴＴＰリクエストの送信先である遷移先ＵＲＬ、遷移先ＵＲＬへのＨＴＴＰリクエストに対するレスポンスコード、遷移先ＵＲＬへのＨＴＴＰリクエストに対するレスポンス内容、遷移先ＵＲＬへのＨＴＴＰリクエストの送信元である遷移元ＵＲＬ、および遷移先ＵＲＬへＨＴＴＰリクエストを送信したアカウントの権限を保存するフィールドを持つテーブルである。
　図７は、実施の形態１に係るパラメータテーブル４５０の一例を示す図である。
　パラメータテーブル４５０は、遷移先ＵＲＬ毎にＨＴＴＰリクエストのパラメータ名、パラメータの値、パラメータが記載されている位置を示す値（ＵＲＬのクエリ部、ヘッダ部またはボディ部）を保存するフィールドを持つテーブルである。パラメータが記載されている位置を示す値は、ＨＴＴＰリクエストのＵＲＬ内のクエリ文字列の名前の部分、ＨＴＴＰヘッダ部のヘッダ名、ＨＴＴＰボディ部の変数名である。また、パラメータの値は、パラメータに付与された値の部分である。
　図２の診断装置２００の機能構成の説明に戻る。
　クローリング実施部３０２は、メモリ１０３に読み出され、プロセッサ１０２で実行される。クローリング実施部３０２は、アカウント情報ＤＢ３０９と遷移データＤＢ３１０を補助記憶装置１０５から読み出す。クローリング実施部３０２は、遷移データＤＢ３１０に記憶された対象ＵＲＬに対して、アカウント情報ＤＢ３０９に記憶された各アカウントでログインを行い、ログインしたアカウントで遷移可能なＷｅｂページに対してクローリングを行う。クローリング実施部３０２の指示により、Ｗｅｂアプリケーション２０３はＨＴＴＰリクエストを生成し、インターネット２０２を介してＷｅｂサーバ２０１にＨＴＴＰリクエストを送信する。Ｗｅｂアプリケーション２０３からＨＴＴＰレスポンスを受信すると、ＨＴＴＰリクエストとそれに対するレスポンスをクローリング実施部３０２に出力する。クローリング実施部３０２は、クローリング時に発生するＨＴＴＰリクエストとそれに対するＨＴＴＰレスポンスを補助記憶装置１０５上の遷移データＤＢ３１０に保存する。
　クローリングとは、クローラーと呼ばれるプログラムが、与えられたＵＲＬにある全てのハイパーリンクを辿り、遷移先のページ情報を収集してインデックス化を行う技術である。また、クローリングの実行時にローカルプロキシを介することで、ローカルプロキシから発生したＨＴＴＰリクエストとＨＴＴＰレスポンスの全ての情報を取得することが可能である。
　抽出部３０３は、メモリ１０３に読み出され、プロセッサ１０２で実行される。抽出部３０３は遷移データＤＢ３１０を補助記憶装置１０５から読み出す。遷移データＤＢ３１０に記憶されたレコードのうち、遷移先ＵＲＬが同じであってアカウント権限が同じレコードについて、ＨＴＴＰリクエストのパラメータの差異を補助記憶装置１０５上の固定パラメータＤＢ３１１へ出力する。
　固定パラメータＤＢ３１１は、固定パラメータテーブル４６０を保持する。
　図８は、実施の形態１に係る固定パラメータテーブル４６０の一例を示す図である。固定パラメータテーブル４６０は、遷移先ＵＲＬ毎にＨＴＴＰリクエストのパラメータ名を保存するフィールドと、パラメータが固定か変動かを示すフィールドを持つテーブルである。
　比較部３０４は、メモリ１０３に読み出され、プロセッサ１０２で実行される。比較部３０４は、遷移データＤＢ３１０を補助記憶装置１０５から読み出す。比較部３０４は、遷移データＤＢ３１０に記憶された遷移先ＵＲＬが同じレコードについてパラメータを比較し、異なる部分がある遷移先ＵＲＬを診断対象ＵＲＬとして結果データＤＢ３１２に出力する。
　リクエスト生成部３０５は、メモリ１０３に読み出され、プロセッサ１０２で実行される。リクエスト生成部３０５は、結果データＤＢ３１２と遷移データＤＢ３１０を補助記憶装置１０５から読み出す。リクエスト送受信部３０６は、メモリ１０３に読み出され、プロセッサ１０２で実行される。
　リクエスト生成部３０５は、診断対象ＵＲＬに対するＨＴＴＰリクエストの生成をリクエスト送受信部３０６に指示する。リクエスト送受信部３０６は、診断対象ＵＲＬに対するＨＴＴＰリクエストの生成をＷｅｂアプリケーション２０３に指示する。リクエスト送受信部３０６は、Ｗｅｂアプリケーション２０３が生成したＨＴＴＰリクエストをリクエスト生成部３０５に出力する。リクエスト生成部３０５は、診断対象ＵＲＬに対して一般権と特権と同じ操作が可能かを試行するため、Ｗｅｂアプリケーション２０３が生成したＨＴＴＰリクエストを試行用に書き換え、書き換えたＨＴＴＰリクエストをリクエスト送受信部３０６に出力する。リクエスト送受信部３０６は、インターネット２０２を介してリクエスト送受信部３０６から入力されたＨＴＴＰリクエストをＷｅｂサーバ２０１に送信する。リクエスト送受信部３０６は、インターネット２０２を介してＷｅｂサーバ２０１からＨＴＴＰリクエストに対するＨＴＴＰレスポンスを受信し、受信したＨＴＴＰレスポンスを判定部３０７に出力する。
　判定部３０７は、メモリ１０３に読み出され、プロセッサ１０２で実行される。判定部３０７は、リクエスト送受信部３０６が受信したＨＴＴＰレスポンスと、遷移データＤＢ３１０を補助記憶装置１０５から読み出す。判定部３０７は、ＨＴＴＰレスポンスと遷移データＤＢ３１０に保存された特権でのＨＴＴＰリクエストに対するＨＴＴＰレスポンスから脆弱性の有無を判定して、判定した結果を結果データＤＢ３１２に出力する。
　出力部３０８は、メモリ１０３に読み出され、プロセッサ１０２で実行される。出力部３０８は、補助記憶装置１０５に保存された結果データＤＢ３１２を補助記憶装置１０５から読み出す。出力部３０８は、結果データＤＢ３１２から読み出した判定結果を、出力インターフェース１０６に出力する。
　結果データＤＢ３１２は、診断結果テーブル４７０および結果詳細テーブル４８０の２種類のテーブルを保持する。
　図９は、実施の形態１に係る診断結果テーブル４７０の一例を示す図である。
　図１０は、実施の形態１に係る結果詳細テーブル４８０の一例を示す図である。
　診断結果テーブル４７０は、診断対象ＵＲＬ、判定部３０７の結果を保存するフィールドを持つテーブルである。結果詳細テーブル４８０は、脆弱性があると判定された診断対象ＵＲＬ、使用したパラメータ名を保存するフィールドを持つテーブルである。
　次に動作について説明する。
　図１１は、実施の形態１に係る入力部３０１、クローリング実施部３０２および抽出部３０３の処理の流れを示すフローチャートである。図１１のフローチャートにおいて、実線がフローの経路を示し、破線は各ＤＢに対するデータ書込みと呼出しを示す。
　図１２は、実施の形態１に係るＨＴＴＰリクエスト・レスポンステーブル４４１の一例を示す図である。
　図１３は、実施の形態１に係るパラメータテーブル４５１の一例を示す図である。
　ステップＳ１０４の処理が終了すると図１２のＨＴＴＰリクエスト・レスポンステーブル４４１および図１３のパラメータテーブル４５１が得られる。
　入力インターフェース１０６を介してアカウント情報および対象ＵＲＬが入力されると、入力部３０１は処理を開始する。
　図１１のステップＳ１０１において、入力部３０１は、入力されたアカウント情報をアカウント情報ＤＢ３０９のアカウント情報テーブル４１０とログインパラメータ４２０に保存する。アカウント情報には、Ｗｅｂアプリケーション２０３にログインする際に必要なアカウントＩＤおよびパスワードといったログイン情報とそのアカウントのアカウント権限とログインするために必要なパラメータのパラメータ名とが含まれる。
　入力部３０１は、アカウントＩＤ、パスワードおよびアカウント権限を、アカウント情報テーブル４１０のアカウントＩＤ、パスワード、権限の項目に保存する。図３において、例えば、項番Ｕ０１としてアカウントＩＤ「ｍｎｇ１」、パスワード「１２３４ａｂｃ」および権限「特権」が保存されている。
　入力部３０１は、パラメータ名をログインパラメータテーブル４２０に保存する。図４において、項番ＩＤとしてパラメータ「ａｃｃｏｕｎｔｉｄ」、項番ＰＷＤとしてパラメータ「ｐａｓｓｗｄ」が保存されている。
　また、入力部３０１は、入力された対象ＵＲＬを遷移データＤＢ３１０の対象ＵＲＬテーブル４３０に保存する。図５において、対象ＵＲＬテーブル４３０には、対象ＵＲＬ「http://xxx.com」が保存されている。処理はステップＳ１０２に進む。
　ステップＳ１０２において、クローリング実施部３０２は、アカウント情報ＤＢ３０９に保存されたアカウント情報テーブル４１０から、クローリングが実施されていないアカウントのレコードを１つ選択し、アカウントＩＤおよびパスワードを読み出す。処理はステップＳ１０３に進む。
　ステップＳ１０３において、クローリング実施部３０２は、遷移データＤＢ３１０の対象ＵＲＬテーブル４３０から対象ＵＲＬ「http://xxx.com」を読み出す。クローリング実施部３０２は、選択したアカウントのアカウントＩＤおよびパスワードでＷｅｂアプリケーション２０３にログインし、対象ＵＲＬに対してクローリングを実施する。
　クローリング実施部３０２がアカウント情報テーブル４１０の項番Ｕ０１のアカウントでＷｅｂアプリケーション２０３にログインする場合を例に処理を説明する。クローリング実施部３０２は、対象ＵＲＬ「http://xxx.com」にＨＴＴＰリクエストを送信し、さらに「http://xxx.com」上のリンクである「http://xxx.com/login.php」にＨＴＴＰリクエストを送信する。「http://xxx.com/login.php」へのＨＴＴＰリクエストに対するＨＴＴＰレスポンスを受信すると、クローリング実施部３０２は、遷移データＤＢ３１０のＨＴＴＰリクエスト・レスポンステーブル４４１の項番ＵＲＬ０１にＨＴＴＰレスポンスの内容を保存する。クローリング実施部３０２は、遷移先ＵＲＬに「http://xxx.com/login.php」、レスポンスコードに「200」、レスポンス内容にレスポンスのHeader情報およびBody情報、遷移元ＵＲＬに「http://xxx.com」、権限に「特権」を保存する。権限には、ログインしたアカウントの権限の種類が保存される。また、遷移先ＵＲＬ「http://xxx.com/login.php」に送信したＨＴＴＰリクエストにパラメータが含まれている場合、クローリング実施部３０２は、遷移データＤＢ３１０のパラメータテーブル４５１に保存する。図１３のパラメータテーブル４５１には示していないが、パラメータが保存されたものとする。
　次に、クローリング実施部３０２は、「http://xxx.com/login.php」上のリンクである「http://xxx.com/top.php」にＨＴＴＰリクエストを送信する。ＨＴＴＰレスポンスを受信すると、クローリング実施部３０２は、ＨＴＴＰリクエスト・レスポンステーブル４４１の項番ＵＲＬ０２にＨＴＴＰレスポンスの内容を保存する。クローリング実施部３０２は、遷移先ＵＲＬに「http://xxx.com/top.php」、レスポンスコードに「200」、レスポンス内容にレスポンスのHeader情報およびBody情報、遷移元ＵＲＬに「http://xxx.com/login.php」、権限に「特権」を保存する。遷移先ＵＲＬ「http://xxx.com/top.php」に送信したＨＴＴＰリクエストにパラメータａｕｔｈ、ｕｓｅｒＩＤが含まれている。クローリング実施部３０２は、パラメータ名、パラメータの値、パラメータが記載されている位置を示す値（ＵＲＬのクエリ部、ヘッダ部またはボディ部）をパラメータテーブル４５１の項番ＵＲＬ０２－０１、ＵＲＬ０２－０２に保存する。なお、項番ＵＲＬ０２－０１、ＵＲＬ０２－０２はＵＲＬ０２のパラメータであることを示している。パラメータをパラメータテーブル４５１に保存する際、クローリング実施部３０２は、どのＨＴＴＰリクエストに含まれたパラメータなのか対応付けがわかるように項番を付与している。本実施の形態では、項番で対応づけを示しているが、他の方法でもよい。
　クローリング実施部３０２は、対象ＵＲＬ「http://xxx.com」とその配下にある全てのリンクを辿り、上述したように遷移先のページ情報を収集して、収集した情報をＨＴＴＰリクエスト・レスポンステーブル４４１およびパラメータテーブル４５１に保存する。遷移先のページでも遷移していないリンク先がなくなるまでページ情報を収集すると、クローリング実施部３０２は、クローリングを終了し、ログアウトする。処理はステップＳ１０４に進む。
　ステップＳ１０４において、クローリング実施部３０２は、クローリングが未実施のアカウントがないか判定する。クローリング実施部３０２は、アカウント情報テーブル４１０の各アカウントについてクローリングを実施したかどうかを把握している。クローリングが未実施のアカウントがある場合、処理はステップＳ１０２に進み、クローリング実施部３０２は、クローリングが未実施のアカウントを選択してクローリングを実施する。
　クローリング実施部３０２は、クローリングが未実施のアカウントがなくなるまでステップＳ１０２～Ｓ１０４のフローを繰り返す。
　図１２において、アカウントＩＤ「ｍｎｇ１」のクローリングで項番ＵＲＬ０１～ＵＲＬ０２、アカウントＩＤ「ｍｎｇ２」のクローリングで項番ＵＲＬ０３～ＵＲＬ０４のレコードが保存されたものとする。アカウントＩＤ「ｕｓｅｒ１」のクローリングで項番ＵＲＬ０５～ＵＲＬ０６、アカウントＩＤ「ｕｓｅｒ２」のクローリングで項番ＵＲＬ０７～ＵＲＬ０８のレコードが保存されたものとする。遷移先ＵＲＬと権限が同じレコードは、権限が同じであって異なるアカウントで実施したクローリングで得られた情報である。
　図１３において、アカウントＩＤ「ｍｎｇ１」のクローリングで項番ＵＲＬ０２－０１～ＵＲＬ０２－０２、アカウントＩＤ「ｍｎｇ２」のクローリングで項番ＵＲＬ０４－０１～ＵＲＬ０４－０２のレコードが保存されたものとする。アカウントＩＤ「ｕｓｅｒ１」のクローリングで項番ＵＲＬ０６－０１～ＵＲＬ０６－０２、アカウントＩＤ「ｕｓｅｒ２」のクローリングで項番ＵＲＬ０８－０１～ＵＲＬ０８－０２のレコードが保存されたものとする。
　図１１のフローチャートの説明に戻る。
　ステップＳ１０４において、クローリングが未実施のアカウントがなければ処理はステップＳ１０５に進む。
　ステップＳ１０５において、抽出部３０３は、同じ遷移先に対して権限が特権で同じレコードについてＨＴＴＰリクエストのパラメータの値の差異を抽出する処理を行う。
　抽出部３０３は、ＨＴＴＰリクエスト・レスポンステーブル４４１から、権限が特権であって遷移先ＵＲＬが同じレコードを選択する。項番ＵＲＬ０２と項番ＵＲＬ０４を選択した場合を例に説明する。項番ＵＲＬ０２、ＵＲＬ０４に関するパラメータはパラメータテーブル４５１のＵＲＬ０２－０１～ＵＲＬ０２－０２、ＵＲＬ０４－０１～ＵＲＬ０４－０２に保存されている。抽出部３０３は、これらのパラメータの差異を抽出する。
　ＵＲＬ０２－０１とＵＲＬ０４－０１は値が同じため、抽出部３０３は、固定パラメータテーブル４６０の項番ＰＡＲＡＭ０２－０１の対象に「ＵＲＬ０４－０１」、固定に「固定」を保存する。ＵＲＬ０２－０２とＵＲＬ０４－０２は値が異なるため、抽出部３０３は、固定パラメータテーブル４６０の項番ＰＡＲＡＭ０２－０２の対象に「ＵＲＬ０４－０２」、固定に「変動」を保存する。処理は終了する。
　ＨＴＴＰリクエストのパラメータは、セッションＩＤや時刻などのログインするたびに毎回異なるパラメータの値、宛先ＵＲＬやｃｏｎｔｅｎｔ－ｔｙｐｅ等のヘッダ情報などのログインするたびに変わることがない固定のパラメータの値、ユーザＩＤなどのログインするたびに変わることがないがアカウントによって異なるパラメータの値、の３つに分別される。本実施の形態では、抽出部３０３は、ＨＴＴＰリクエストのパラメータから、ログインするたびに変わることがない固定のパラメータを抽出することが可能である。
　図１４は、実施の形態１に係る比較部３０４、リクエスト生成部３０５、リクエスト送受信部３０６、判定部３０７及び出力部３０８の処理の流れを示すフローチャートである。実線がフローの経路を示し、破線は各ＤＢに対するデータの書込みと呼出しを示す。診断対象ＵＲＬに対して一般権と特権とで同じ操作が可能かを試行するため、一般権のアカウントでログインし、ＨＴＴＰリクエストを診断対象ＵＲＬに送信する。
　ステップＳ２０１において、比較部３０４は、遷移データＤＢ３１０のＨＴＴＰリクエスト・レスポンステーブル４４１からレコードを選択し、他のレコードと比較する。図１５を用いてステップＳ２０１の詳細を説明する。
　図１５は、実施の形態１に係る図１４のステップＳ２０１の比較部３０４の処理の詳細を示すフローチャートである。
　ステップＳ３０１において、比較部３０４は、ＨＴＴＰリクエスト・レスポンステーブル４４１から１つレコードを選択し、遷移先ＵＲＬが同じレコードが他にあるか判定する。遷移先ＵＲＬが同じレコードが他になければ、処理はステップＳ３０２に進み、遷移先ＵＲＬが同じレコードが他にあれば、処理はステップＳ３０４に進む。
　ステップＳ３０２において、比較部３０４は、選択したレコードの権限が特権か判定する。選択したレコードの権限が特権の場合、処理はステップＳ３０３に進む。選択したレコードの権限が特権でない場合、比較部３０４は、選択したレコードの遷移先ＵＲＬを診断対象から除外し、処理は終了する。
　ステップＳ３０３において、比較部３０４は、選択したレコードの遷移先ＵＲＬを図９の結果データＤＢ３１２の診断結果テーブル４７０に保存し、処理は終了する。
　ステップＳ３０４において、比較部３０４は、パラメータテーブル４５１を参照し、遷移先ＵＲＬが同じレコードについてパラメータ名が存在するのは特権のレコードのみか判定する。パラメータ名が存在するのは特権のレコードのみの場合、処理はステップＳ３０５に進む。パラメータ名が存在するのは特権のレコードのみでない場合、処理はステップＳ３０６に進む。
　ステップＳ３０５において、比較部３０４は、選択したレコードの遷移先ＵＲＬとパラメータ名を結果データＤＢ３１２の診断結果テーブル４７０に保存し、処理は終了する。
　ステップＳ３０６において、比較部３０４は、パラメータテーブル４５１を参照し、遷移先ＵＲＬが同じレコードについて特権と一般権で同じパラメータ名が存在するのか判定する。特権と一般権で同じパラメータ名が存在する場合、処理はステップＳ３０７に進む。特権と一般権で同じパラメータ名が存在しない場合、比較部３０４は、選択したレコードの遷移先ＵＲＬを診断対象から除外し、処理は終了する。
　ステップＳ３０７において、比較部３０４は、パラメータテーブル４５１を参照し、特権と一般権で同じパラメータ名が存在し、値が同じか判定する。値が同じでない場合、処理はステップＳ３０８に進む。値が同じ場合、比較部３０４は、選択したレコードの遷移先ＵＲＬを診断対象から除外し、処理は終了する。
　ステップＳ３０８において、比較部３０４は、固定パラメータテーブル４６０を参照し、パラメータが固定か判定する。パラメータが固定の場合、処理はステップＳ３０５に進む。パラメータが固定でない場合、比較部３０４は、選択したレコードの遷移先ＵＲＬを診断対象から除外し、処理は終了する。
　図１４のフローチャートの説明に戻る。ステップＳ２０２において、リクエスト生成部３０５は、アカウント情報ＤＢ３０９に保存されている情報を用いて、一般権のアカウントでＷｅｂアプリケーション２０３にログインする。項番Ｕ０３のアカウント「ｕｓｅｒ１」でログインしたものとする。処理はステップＳ２０３に進む。
　ステップＳ２０３において、リクエスト生成部３０５は、診断結果テーブル４７０から診断対象ＵＲＬを選択し、選択した診断対象ＵＲＬと合致する遷移先ＵＲＬが保存されているレコードをＨＴＴＰリクエスト・レスポンステーブル４４１から読み出す。読み出したレコードのアクセス権が特権のみの場合、遷移先ＵＲＬが特権の場合にのみ存在することを意味する。処理はステップＳ２０４に進む。一方、読み出したレコードのアクセス権が特権のレコードと一般権のレコードの両方がある場合、一般権でも診断対象ＵＲＬが存在することを意味する。処理はステップＳ２０５に進む。
　ステップＳ２０４において、リクエスト生成部３０５は、リクエスト送受信部３０６を介して診断対象ＵＲＬをＷｅｂアプリケーション２０３に出力する。リクエスト生成部３０５は、リクエスト送受信部３０６を介してＷｅｂアプリケーション２０３から診断対象ＵＲＬへの一般権のＨＴＴＰリクエストを受け取る。リクエスト生成部３０５は、ＨＴＴＰリクエスト・レスポンステーブル４４１から読み出したレコードをもとにＨＴＴＰリクエストを生成する。読み出したレコードは特権のレコードである。リクエスト生成部３０５は、ＨＴＴＰリクエスト・レスポンステーブル４４１から読み出したレコードに対応付けられたパラメータテーブル４５１のレコードよりＨＴＴＰリクエストに設定されるパラメータを読み出す。読み出したパラメータは、特権の場合にＨＴＴＰリクエストに設定されるパラメータである。リクエスト生成部３０５は、固定パラメータＤＢ３１１の固定パラメータテーブル４６０を参照し、読み出したパラメータが固定の場合、ＨＴＴＰリクエストのパラメータの値を変更しない。読み出したパラメータが変動の場合、ＨＴＴＰリクエストのパラメータの値をＷｅｂアプリケーション２０３から受け取った一般権のＨＴＴＰリクエストのパラメータの値に変更する。また、リクエスト生成部３０５は、結果データＤＢ３１２の結果詳細テーブル４８０に診断対象ＵＲＬ、値を変更したパラメータ名を保存する。リクエスト生成部３０５は、このようにして生成したＨＴＴＰリクエストをリクエスト送受信部３０６に出力する。リクエスト送受信部３０６は、リクエスト生成部３０５から入力されたＨＴＴＰリクエストをＷｅｂサーバ２０１に送信し、Ｗｅｂサーバ２０１からＨＴＴＰレスポンスを受信すると判定部３０７に出力する。処理はステップＳ２０６に進む。
　ステップＳ２０５において、リクエスト生成部３０５は、リクエスト送受信部３０６を介して診断対象ＵＲＬをＷｅｂアプリケーション２０３に出力し、リクエスト送受信部３０６を介してＷｅｂアプリケーション２０３から診断対象ＵＲＬへの一般権のＨＴＴＰリクエストを受け取る。リクエスト生成部３０５は、ステップＳ２０３においてＨＴＴＰリクエスト・レスポンステーブル４４１から読み出したレコードに対応付けられたパラメータテーブル４５１のレコードより特権の場合にＨＴＴＰリクエストに設定されるパラメータを読み出す。リクエスト生成部３０５は、固定パラメータＤＢ３１１の固定パラメータテーブル４６０を参照し、一般権のＨＴＴＰリクエストに含まれるパラメータに該当するレコードがあって固定の場合、ＨＴＴＰリクエストの該当のパラメータの値を特権のパラメータの値に変更する。また、リクエスト生成部３０５は、結果データＤＢ３１２の結果詳細テーブル４８０に診断対象ＵＲＬ、値を変更したパラメータ名を保存する。一般権のＨＴＴＰリクエストに含まれるパラメータに該当するレコードがあって変動の場合、リクエスト生成部３０５は、ＨＴＴＰリクエストの該当のパラメータの値を変更しない。固定のパラメータは、例えば権限識別のパラメータである。変動のパラメータは、例えば、ユーザＩＤ、時刻である。また、リクエスト生成部３０５は、読み出した特権のパラメータのうち一般権のＨＴＴＰリクエストに含まれていないパラメータをＨＴＴＰリクエストに追加する。リクエスト生成部３０５は、このようにして生成したＨＴＴＰリクエストをリクエスト送受信部３０６に出力する。リクエスト送受信部３０６は、リクエスト生成部３０５から入力されたＨＴＴＰリクエストをＷｅｂサーバ２０１に送信する。リクエスト送受信部３０６は、Ｗｅｂサーバ２０１からＨＴＴＰレスポンスを受信すると受信したＨＴＴＰレスポンスを判定部３０７に出力する。処理はステップＳ２０６に進む。
　ステップＳ２０６において、判定部３０７は、入力されたＨＴＴＰレスポンスのレスポンスコードとＨＴＴＰリクエスト・レスポンステーブル４４１に保存されている正常なレスポンスのレスポンスコードを比較する。判定部３０７は、レスポンスコードの値を比較することで脆弱性を判定する。レスポンスコードが同じ場合、特権の操作が一般権でも実行できているため、判定部３０７は、脆弱ありと判定する。レスポンスコードが異なる場合、判定部３０７は、脆弱なしと判定する。判定部３０７は、判定した脆弱性の有無を診断結果テーブル４７０の診断対象ＵＲＬに該当するレコードの脆弱性に保存する。処理はステップＳ２０７に進む。
　ステップＳ２０７において、判定部３０７は、診断結果テーブル４７０のすべてのレコードについて脆弱性の判定処理を完了したか判定する。判定部３０７は、診断結果テーブル４７０のすべてのレコードについて脆弱性の項目が設定されていれば、完了と判定する。完了した場合、処理はステップＳ２０８に進む。完了していない場合、処理はステップＳ２０２に戻る。診断結果テーブル４７０のすべてのレコードについて脆弱性の項目が設定されるまで、ステップＳ２０２～Ｓ２０７の処理が繰り返される。
　ステップＳ２０８において、出力部３０８は、結果データＤＢ３１２のデータを出力インターフェース１０４へ出力し、処理は終了となる。
　なお、本実施の形態において、受信したＨＴＴＰレスポンスとＨＴＴＰリクエスト・レスポンステーブル４４１に保存されている正常なＨＴＴＰレスポンスのレスポンスコードが同じ場合、脆弱ありと判定したが、ＨＴＴＰレスポンスのＨｅａｄｅｒ情報またはＢｏｄｙ情報に含まれる値を用いて脆弱性を判定するようにしてもよい。
　したがって、本実施の形態では、特権の第１のアカウントにより遷移先ＵＲＬに送信したＨＴＴＰリクエストに含まれるパラメータのうち、特権の第２のアカウントにより遷移先ＵＲＬに送信したＨＴＴＰリクエストに含まれるパラメータと値が同じである固定のパラメータを抽出する抽出部３０３と、一般権のアカウントによる遷移先ＵＲＬへのＨＴＴＰリクエストのパラメータに抽出部３０３で抽出された固定のパラメータが含まれており、値が特権のアカウントの値と異なる場合、固定のパラメータに特権のアカウントの値を設定したＨＴＴＰリクエストを出力するリクエスト生成部３０５と、一般権のアカウントによりＨＴＴＰリクエストを遷移先ＵＲＬに送信し、ＨＴＴＰレスポンスを受信するリクエスト送受信部３０６と、ＨＴＴＰレスポンスに基づいて遷移先ＵＲＬの脆弱性を判定する判定部３０７と、を備えたので、Ｗｅｂアプリケーションの遷移先ＵＲＬを事前に把握することなく権限管理の不備があるかどうかを診断することができる。一般権の画面上には表示されないページへの遷移や実行できない操作を実行できるかを確認することで、権限管理の不備がないかを診断する。診断装置２００が権限管理の不備を診断するため、人的コストを削減することもできる。
　また、リクエスト生成部３０５は、一般権のアカウントによる遷移先ＵＲＬへのＨＴＴＰリクエストのパラメータに抽出部３０３で抽出された固定のパラメータが含まれていない場合、特権のアカウントの値を設定した固定のパラメータをＨＴＴＰリクエストに追加し、固定のパラメータが追加されたＨＴＴＰリクエストを出力するので、一般権のＨＴＴＰリクエストには含まれないパラメータについて権限管理の不備がないかを診断することができる。
　また、抽出部３０３は、第１のアカウントにより遷移先ＵＲＬに送信したＨＴＴＰリクエストに含まれるパラメータのうち、第２のアカウントにより遷移先ＵＲＬに送信したＨＴＴＰリクエストに含まれるパラメータと値が異なる変動のパラメータを抽出し、リクエスト生成部３０５は、一般権のアカウントにより遷移先ＵＲＬに遷移しない場合、特権のアカウントによる遷移先ＵＲＬへのＨＴＴＰリクエストのうち抽出部３０３で抽出された変動のパラメータに一般権のアカウントによる遷移先ＵＲＬへのＨＴＴＰリクエストのパラメータの値を設定し、値を設定したＨＴＴＰリクエストを出力するので、一般権のアカウントでは遷移しない遷移先ＵＲＬについて、権限管理の不備がないかを診断することができる。
実施の形態２．
　以上の実施の形態１においては、抽出部３０３がログインするたびに変わることがない固定のパラメータを抽出するようにしたものであるが、本実施の形態においては、遷移先ＵＲＬとパラメータの組み合わせが同じでログインするたびに値が変わるパラメータと変わらないパラメータを抽出する実施の形態を示す。
　なお、本実施の形態においては、実施の形態１に記載の構成を全て備えた上で、更に付加的な構成について説明する。
　図１６は、実施の形態２に係るＨＴＴＰリクエスト・レスポンステーブル４４２の一例を示す図である。
　図１７は、実施の形態２に係るパラメータテーブル４５２の一例を示す図である。
　まず、図１１のフローチャートについて、実施の形態１と異なる動作を説明する。
　図１１のステップＳ１０３において、クローリング実施部３０２は、選択したアカウントでクローリングを実施し、ログアウトした後、同じアカウントでＷｅｂアプリケーション２０３に再度ログインし、対象ＵＲＬに対して２回目のクローリングを実施する。クローリング実施部３０２は、２回目のクローリングが終了すると、ログアウトする。
　図１６は、アカウントＩＤ「ｍｎｇ１」の１回目のクローリングで項番ＵＲＬ０１～ＵＲＬ０４、アカウントＩＤ「ｕｓｅｒ１」の１回目のクローリングで項番ＵＲＬ０５～ＵＲＬ０７のレコードが保存されたものとする。
　図１７は、アカウントＩＤ「ｍｎｇ１」の１回目のクローリングで項番ＵＲＬ０３－０１～ＵＲＬ０３－０３、ＵＲＬ０４－０１～ＵＲＬ０４－０３のレコードが保存されたものとする。アカウントＩＤ「ｕｓｅｒ１」の１回目のクローリングで項番ＵＲＬ０７－０１～ＵＲＬ０７－０３のレコードが保存されたものとする。
　２回目のクローリングにおいて、１回目のクローリングで得られた図１６のＨＴＴＰリクエスト・レスポンステーブル４４２および図１７のパラメータテーブル４５２と同じ値が保存されたＨＴＴＰリクエスト・レスポンステーブル４４３、パラメータテーブル４５３が得られる。なお、内容が同じため図示は省略する。
　図１１のステップＳ１０５において、抽出部３０３は、１回目のクローリングで得られたＨＴＴＰリクエスト・レスポンステーブル４４２、パラメータテーブル４５２、２回目のクローリングで得られたＨＴＴＰリクエスト・レスポンステーブル４４３、パラメータテーブル４５３を参照し、ＨＴＴＰリクエスト・レスポンステーブル４４２の特権の各項番について、１回目のクローリングと２回目のクローリングでのパラメータの差異を抽出する。
　図１８は、実施の形態２に係る固定パラメータテーブル４６２の一例を示す図である。１回目のクローリングと２回目のクローリングで同じ値が得られているため、固定パラメータテーブル４６１のすべてのパラメータは固定である。
　次に、抽出部３０３は、ＨＴＴＰリクエスト・レスポンステーブル４４２のレコードのうち権限が特権のレコードを選択する。抽出部３０３は、ＨＴＴＰリクエスト・レスポンステーブル４４２から権限が特権であって、選択したレコードの遷移先ＵＲＬと同じレコードについて、パラメータの差異を抽出する。抽出部３０３は、抽出したパラメータの差異を固定パラメータテーブル４６２に保存する。
　図１９は、実施の形態２に係る固定パラメータテーブル４６２の一例を示す図である。項番のＵＲＬ０３とＵＲＬ０４を比較するとＵＲＬおよびｕｓｅｒＩＤは値が同じため、固定パラメータテーブル４６２のＰＡＲＡＭ０３－０１およびＰＡＲＡＭ０３－０２の固定フィールドには「固定」が保存されている。一方、ｐａｇｅは値が異なるため、固定パラメータテーブル４６２のＰＡＲＡＭ０３－０３の固定フィールドには「変動」が保存されている。
　図２０は、実施の形態２に係るＨＴＴＰリクエスト・レスポンステーブル４４４の一例を示す図である。
　抽出部３０３は、固定パラメータテーブル４６２において固定フィールドに「変動」が保存されているパラメータｐａｇｅが、ページを一意に表すのに必要なパラメータであると判定する。抽出部３０３は、ＨＴＴＰリクエスト・レスポンステーブル４４２に遷移パラメータのフィールドを追加し、ｐａｇｅの値を設定したＨＴＴＰリクエスト・レスポンステーブル４４４を生成する。
　次に、図１４のフローチャートについて、実施の形態１と異なる動作を説明する。
　ステップＳ２０１において、比較部３０４は、遷移データＤＢ３１０のＨＴＴＰリクエスト・レスポンステーブル４４４からレコードを選択し、他のレコードと比較する。図２１を用いてステップＳ２０１の処理の詳細を説明する。
　図２１は、実施の形態２に係る図１４のステップＳ２０１の比較部３０４の処理の詳細を示すフローチャートである。
　図２２は、実施の形態２に係る診断結果テーブル４７１の一例を示す図である。
　図２３は、実施の形態２に係る結果詳細テーブル４８１の一例を示す図である。
　図２１のステップＳ４０１において、比較部３０４は、ＨＴＴＰリクエスト・レスポンステーブル４４４から１つレコードを選択し、遷移先ＵＲＬおよび遷移パラメータが同じレコードが他にあるか判定する。遷移先ＵＲＬおよび遷移パラメータが同じレコードが他になければ、処理はステップＳ４０２に進み、遷移先ＵＲＬおよび遷移パラメータが同じレコードが他にあれば、処理はステップＳ４０４に進む。
　ステップＳ４０２において、比較部３０４は、選択したレコードの権限が特権か判定する。選択したレコードの権限が特権の場合、処理はステップＳ４０３に進む。選択したレコードの権限が特権でない場合、比較部３０４は、選択したレコードの遷移先ＵＲＬを診断対象から除外し、処理は終了する。
　ステップＳ４０３において、比較部３０４は、選択したレコードの遷移先ＵＲＬおよび遷移パラメータを結果データＤＢ３１２の診断結果テーブル４７１に保存し、処理は終了する。
　ステップＳ４０４において、比較部３０４は、パラメータテーブル４５２を参照し、遷移先ＵＲＬおよび遷移パラメータが同じレコードについてパラメータ名が存在するのは特権のレコードのみか判定する。パラメータ名が存在するのは特権のレコードのみの場合、処理はステップＳ４０５に進む。パラメータ名が存在するのは特権のレコードのみでない場合、処理はステップＳ４０６に進む。
　ステップＳ４０５において、比較部３０４は、選択したレコードの遷移先ＵＲＬ、遷移パラメータおよびパラメータ名を結果データＤＢ３１２の結果詳細テーブル４８１に保存し、処理は終了する。
　ステップＳ４０６において、比較部３０４は、パラメータテーブル４５２を参照し、遷移先ＵＲＬおよび遷移パラメータが同じレコードについて特権と一般権で同じパラメータ名が存在するのか判定する。特権と一般権で同じパラメータ名が存在する場合、処理はステップＳ４０７に進む。特権と一般権で同じパラメータ名が存在しない場合、比較部３０４は、選択したレコードの遷移先ＵＲＬおよび遷移パラメータを診断対象から除外し、処理は終了する。
　ステップＳ４０７において、比較部３０４は、パラメータテーブル４４４を参照し、特権と一般権で同じパラメータ名が存在し、値が同じか判定する。値が同じでない場合、処理はステップＳ３０５に進む。値が同じ場合、比較部３０４は、選択したレコードの遷移先ＵＲＬおよび遷移パラメータを診断対象から除外し、処理は終了する。
　なお、本実施の形態において、クローリング実施部３０２は、１回目と２回目のクローリングで得られた情報を識別せずにＨＴＴＰリクエスト・レスポンステーブル４４２およびパラメータテーブル４５２に保存したが、１回目と２回目のクローリングで得られた情報を識別できるように保存してもよい。テーブルを増やす、または、テーブルのカラムを増やすようにしてもよい。
　以上のように、本実施の形態では、抽出部３０３は、第１のアカウントにより遷移先ＵＲＬに送信したＨＴＴＰリクエストに含まれるパラメータのうち、第２のアカウントにより遷移先ＵＲＬに送信したＨＴＴＰリクエストに含まれるパラメータと値が同じである固定のパラメータについて、第１のアカウントから遷移先ＵＲＬに複数回送信したＨＴＴＰリクエストに含まれる固定のパラメータ値が異なる場合、固定のパラメータを遷移先ＵＲＬとの組み合わせでページを一意に示す遷移パラメータとして抽出するので、ＵＲＬと遷移パラメータとの組み合わせでページを一意に示す場合でも権限管理の不備を診断することができる。
実施の形態３．
　以上の実施の形態１においては、抽出部３０３が抽出したＨＴＴＰリクエストのパラメータが固定か変動かを固定パラメータＤＢ３１１の固定パラメータテーブル４６０に保存するようにしたものであるが、本実施の形態においては、遷移データＤＢ３１０のＨＴＴＰリクエスト・レスポンステーブルにフィールドを追加して保存する実施の形態を示す。
　図２４は、実施の形態３に係る診断装置２１０の機能構成の一例を含む全体のブロック図である。実施の形態１の診断装置２００との違いは、固有データＤＢが削除されていることである。
　図２５は、実施の形態３に係る入力部３０１、クローリング実施部３０２および抽出部３０３の処理の流れを示すフローチャートである。実施の形態１の図１１のフローチャートとの違いは、ステップＳ１０５から遷移データＤＢ３１０に出力することである。
　図２６は、実施の形態３に係る遷移データＤＢ３１０のパラメータテーブル４５４の一例を示す図である。実施の形態１のパラメータテーブル４５１との違いは固定のフィールドが追加されていることである。
　図２５のステップ１０５において、実施の形態１と異なる動作を説明する。
　抽出部３０３は、同じ遷移先に対して権限が特権で同じレコードについてＨＴＴＰリクエストのパラメータの値の差異を抽出する。ＵＲＬ０２－０１とＵＲＬ０４－０１は値が同じため、抽出部３０３は、固定パラメータテーブル４６０の項番ＵＲＬ０２－０１と項番ＵＲＬ０４－０１の固定に「固定」を保存する。また、ＵＲＬ０２－０２とＵＲＬ０４－０２は値が異なるため、抽出部３０３は、固定パラメータテーブル４６０の項番ＰＡＲＡＭ０２－０２と項番ＵＲＬ０４－０２の固定に「変動」を保存する。処理は終了する。
　図２７は、実施の形態３に係る比較部３０４、リクエスト生成部３０５、リクエスト送受信部３０６、判定部３０７及び出力部３０８の処理の流れを示すフローチャートである。実施の形態１の図１４のフローチャートとの違いは、ステップＳ２０１、ステップＳ２０４、ステップＳ２０５においてパラメータが固有かどうかの情報を遷移パラメータＤＢのパラメータテーブル４５４から読み出すことである。
　なお、本実施の形態において、実施の形態２で示したようにアカウントごとに２回クローリングを実施してページ遷移に必要な特定のパラメータを決定する機能を含めるようにしてもよい。
　したがって、本実施の形態では、遷移データＤＢ３１０が固有パラメータＤＢ３１１の情報も保持するため、遷移データＤＢ３１０のパラメータテーブルＴ２０３のレコードと同じ数のレコードを持つ固有パラメータＤＢ３１１を削減し、固有パラメータＤＢ３１１で使用するメモリリソースを削減することが可能である。
実施の形態４．
　以上の実施の形態１においては、診断装置２００が診断対象ＵＲＬを抽出し、脆弱性の判定を行うようにしたものであるが、本実施の形態においては、診断対象抽出装置が診断対象ＵＲＬを抽出し、診断実施装置が抽出された診断対象ＵＲＬの脆弱性を判定する実施の形態を示す。
　実施の形態３と異なる部分を説明する。
　図２８は、実施の形態４に係る診断対象抽出装置２２０の機能構成の一例を含む全体のブロック図である。診断対象抽出装置２２０は、入力部３０１、クローリング実施部３０２、抽出部３０３、比較部３０４、アカウント情報ＤＢ３１３、遷移データＤＢ３１４および出力部３１５を備える。アカウント情報ＤＢ３１３、遷移データＤＢ３１４は実施の形態３のアカウント情報ＤＢ３０９、遷移データＤＢ３１０と同様の機能を保持する。
　比較部３０４は、メモリ１０３に読み出され、プロセッサ１０２で実行される。比較部３０４は、遷移データＤＢ３１０を補助記憶装置１０５から読み出す。比較部３０４は、遷移データＤＢ３１０に記憶された遷移先ＵＲＬが同じレコードについてパラメータを比較し、異なる部分がある遷移先ＵＲＬを診断対象ＵＲＬとしてパラメータとともに出力部３１５に出力する。
　出力部３１５は、メモリ１０３に読み出され、プロセッサ１０２で実行される。出力部３１５は、比較部３０４から入力された診断対象ＵＲＬを出力インターフェース１０６に出力する。
　図２９は、実施の形態４に係る診断実施装置２３０の機能構成の一例を含む全体のブロック図である。診断実施装置２３０は、入力部３１６、リクエスト生成部３０５、リクエスト送受信部３０６、判定部３０７、出力部３０８、アカウント情報ＤＢ３１７、遷移データＤＢ３１８、結果データＤＢ３１９を備える。アカウント情報ＤＢ３１７、遷移データＤＢ３１８および結果データＤＢ３１９は実施の形態３のアカウント情報ＤＢ３０９、遷移データＤＢ３１０、結果データＤＢ３１２と同様の機能を保持する。
　入力部３１６は、メモリ１０３に読み出され、プロセッサ１０２で実行される。入力インターフェース１０６を介して入力された値を補助記憶装置１０５へ保存する。入力部３１６は、入力されたアカウント情報（ログイン情報、権限情報）を補助記憶装置１０５上のアカウント情報ＤＢ３１７に出力する。また、入力部３１６は、診断対象ＵＲＬとパラメータを遷移データＤＢ３１８に出力する。
　次に動作について説明する。
　図３０は、実施の形態４に係る診断対象抽出装置２２０の入力部３０１、クローリング実施部３０２および抽出部３０３の処理の流れを示すフローチャートである。ステップＳ５０１～Ｓ５０５の処理は、実施の形態３の図２５のステップＳ１０１～Ｓ１０５の処理と同じである。
　ステップＳ５０５において、抽出部３０３は、同じ遷移先に対して権限が特権で同じレコードについてＨＴＴＰリクエストの固定のパラメータを比較部３０４に出力する。
　ステップＳ５０６において、比較部３０４は、抽出部３０３から入力されたパラメータが特権に存在して、一般権に存在しないまたは値が異なる場合、その遷移先ＵＲＬとパラメータの値を診断対象データ３２０として出力部３１５を介して出力する。また、出力部３１５は、アカウント情報ＤＢ３１３に保存されているアカウント情報を出力する。処理は終了する。
　図３１は、実施の形態４に係る診断実施装置２３０の入力部３１６、リクエスト生成部３０５、リクエスト送受信部３０６、判定部３０７及び出力部３０８の処理の流れを示すフローチャートである。
　ステップＳ６０１において、入力部３１６には、アカウント情報および診断対象データ３２０が入力される。入力部３１６は、入力されたアカウント情報をアカウント情報ＤＢ３１７に保存する。また、入力部３１６は、診断対象データ３２０を遷移データＤＢ３１８および結果データＤＢに保存する。
　ステップＳ６０２～Ｓ６０８は、実施の形態３のステップＳ２０２～Ｓ２０８と同様である。
　なお、本実施の形態において、実施の形態２で示したようにアカウントごとに２回クローリングを実施してページ遷移に必要な特定のパラメータを決定する機能を含めるようにしてもよい。
　また、本実施の形態において、診断対象抽出装置２２０から出力される診断対象の情報を収集し、セキュリティ診断は既存の方法を用いるようにしてもよい。また、既存のセキュリティ診断で利用したＷｅｂアプリケーションより収集した診断対象の情報を診断実施装置２３０に入力するようにしてもよい。
　したがって、本実施の形態では、特権の第１のアカウントにより遷移先ＵＲＬに送信したＨＴＴＰリクエストに含まれるパラメータのうち、特権の第２のアカウントにより遷移先ＵＲＬに送信したＨＴＴＰリクエストに含まれるパラメータと値が同じである固定のパラメータを抽出する抽出部３０３を備える診断対象抽出装置２２０と、一般権のアカウントによる遷移先ＵＲＬへのＨＴＴＰリクエストのパラメータに抽出部３０３で抽出された固定のパラメータが含まれており、値が特権のアカウントの値と異なる場合、固定のパラメータに特権のアカウントの値を設定したＨＴＴＰリクエストを出力するリクエスト生成部３０５と、一般権のアカウントによりＨＴＴＰリクエストを遷移先ＵＲＬに送信し、ＨＴＴＰレスポンスを受信するリクエスト送受信部３０６と、ＨＴＴＰレスポンスに基づいて遷移先ＵＲＬの脆弱性を判定する判定部３０７と、を備える診断実施装置２３０と、を備えたので、Ｗｅｂアプリケーションの遷移先ＵＲＬを事前に把握することなく権限管理の不備があるかどうかを診断することができる。
１０１　通信インターフェース
１０２　プロセッサ
１０３　メモリ
１０４　出力インターフェース
１０５　補助記憶装置
１０６　入力インターフェース
１０７　バス
２００、２１０　セキュリティ診断装置
２０１　Ｗｅｂサーバ
２０２　インターネット
２０３　Ｗｅｂアプリケーション
２２０　診断対象抽出装置
２３０　診断実施装置
３０１、３１６　入力部
３０２　クローリング実施部
３０３　抽出部
３０４　比較部
３０５　リクエスト生成部
３０６　リクエスト送受信部
３０７　判定部
３０８、３１５　出力部
３０９、３１３、３１７　アカウント情報ＤＢ
３１０、３１４、３１８　遷移データＤＢ
３１１　固定パラメータＤＢ
３１２、３１９　結果データＤＢ
４１０　アカウント情報テーブル
４２０　ログインパラメータテーブル
４３０　対象ＵＲＬテーブル
４４０、４４１、４４２、４４３、４４４　ＨＴＴＰリクエスト・レスポンステーブル
４５０、４５１、４５２、４５３、４５４　パラメータテーブル
４６０、４６１、４６２　固定パラメータテーブル
４７０、４７１　診断結果テーブル
４８０、４８１　結果詳細テーブル

Claims (7)

  1. 　特権の第１のアカウントにより遷移先ＵＲＬに送信したＨＴＴＰリクエストに含まれるパラメータのうち、特権の第２のアカウントにより前記遷移先ＵＲＬに送信したＨＴＴＰリクエストに含まれるパラメータと値が同じである固定のパラメータを抽出する抽出部と、
    　一般権のアカウントによる前記遷移先ＵＲＬへのＨＴＴＰリクエストのパラメータに前記抽出部で抽出された前記固定のパラメータが含まれており、値が特権のアカウントの値と異なる場合、前記固定のパラメータに特権のアカウントの値を設定したＨＴＴＰリクエストを出力するリクエスト生成部と、
    　一般権のアカウントにより前記ＨＴＴＰリクエストを前記遷移先ＵＲＬに送信し、ＨＴＴＰレスポンスを受信するリクエスト送受信部と、
    　前記ＨＴＴＰレスポンスに基づいて前記遷移先ＵＲＬの脆弱性を判定する判定部と、
    　を備えることを特徴とするセキュリティ診断装置。
  2. 　前記リクエスト生成部は、一般権のアカウントによる前記遷移先ＵＲＬへのＨＴＴＰリクエストのパラメータに前記抽出部で抽出された前記固定のパラメータが含まれていない場合、特権のアカウントの値を設定した前記固定のパラメータをＨＴＴＰリクエストに追加し、前記固定のパラメータが追加されたＨＴＴＰリクエストを出力することを特徴とする請求項１に記載のセキュリティ診断装置。
  3. 　前記抽出部は、前記第１のアカウントにより前記遷移先ＵＲＬに送信したＨＴＴＰリクエストに含まれるパラメータのうち、前記第２のアカウントにより前記遷移先ＵＲＬに送信したＨＴＴＰリクエストに含まれるパラメータと値が異なる変動のパラメータを抽出し、
    　前記リクエスト生成部は、一般権のアカウントにより前記遷移先ＵＲＬに遷移しない場合、特権のアカウントによる前記遷移先ＵＲＬへのＨＴＴＰリクエストのうち前記抽出部で抽出された前記変動のパラメータに一般権のアカウントによる前記遷移先ＵＲＬへのＨＴＴＰリクエストのパラメータの値を設定し、値を設定したＨＴＴＰリクエストを出力することを特徴とする請求項１または２に記載のセキュリティ診断装置。
  4. 　前記抽出部は、前記第１のアカウントにより前記遷移先ＵＲＬに送信したＨＴＴＰリクエストに含まれるパラメータのうち、前記第２のアカウントにより前記遷移先ＵＲＬに送信したＨＴＴＰリクエストに含まれるパラメータと値が同じである固定のパラメータについて、前記第１のアカウントから前記遷移先ＵＲＬに複数回送信したＨＴＴＰリクエストに含まれる前記固定のパラメータ値が異なる場合、前記固定のパラメータを前記遷移先ＵＲＬとの組み合わせでページを一意に示す遷移パラメータとして抽出することを特徴とする請求項１から３のいずれか一項に記載のセキュリティ診断装置。
  5. 　入力されたＵＲＬに対して複数の特権のアカウントによりクローリングを実施し、前記遷移先ＵＲＬと前記遷移先ＵＲＬに送信したＨＴＴＰリクエストに含まれるパラメータと前記遷移先ＵＲＬから受信したＨＴＴＰレスポンスと前記ＨＴＴＰリクエストを送信したアカウントの権限とを対応づけて遷移データデータベースに保存するクローリング実施部と、
    　前記遷移データデータベースに保存された前記複数の特権のアカウントの前記遷移先ＵＲＬと前記パラメータとに基づき、前記遷移先ＵＲＬを診断対象として出力する比較部と、
    　を備えることを特徴とする請求項１から４のいずれか一項に記載のセキュリティ診断装置。
  6. 　特権の第１のアカウントにより遷移先ＵＲＬに送信したＨＴＴＰリクエストに含まれるパラメータのうち、特権の第２のアカウントにより前記遷移先ＵＲＬに送信したＨＴＴＰリクエストに含まれるパラメータと値が同じである固定のパラメータを抽出する抽出部を備えるセキュリティ診断対象抽出装置と、
    　一般権のアカウントによる前記遷移先ＵＲＬへのＨＴＴＰリクエストのパラメータに前記抽出部で抽出された前記固定のパラメータが含まれており、値が特権のアカウントの値と異なる場合、前記固定のパラメータに特権のアカウントの値を設定したＨＴＴＰリクエストを出力するリクエスト生成部と、
    　一般権のアカウントにより前記ＨＴＴＰリクエストを前記遷移先ＵＲＬに送信し、ＨＴＴＰレスポンスを受信するリクエスト送受信部と、
    　前記ＨＴＴＰレスポンスに基づいて前記遷移先ＵＲＬの脆弱性を判定する判定部と、
    　を備えるセキュリティ診断実施装置と、
    　を備えることを特徴とするセキュリティ診断装置。
  7. 　特権の第１のアカウントにより遷移先ＵＲＬに送信したＨＴＴＰリクエストに含まれるパラメータのうち、特権の第２のアカウントにより前記遷移先ＵＲＬに送信したＨＴＴＰリクエストに含まれるパラメータと値が同じである固定のパラメータを抽出するステップと、
    　一般権のアカウントによる前記遷移先ＵＲＬへのＨＴＴＰリクエストのパラメータに抽出された前記固定のパラメータが含まれており、値が特権のアカウントの値と異なる場合、前記固定のパラメータに特権のアカウントの値を設定したＨＴＴＰリクエストを出力するステップと、
    　前記ＨＴＴＰリクエストを前記遷移先ＵＲＬに送信し、ＨＴＴＰレスポンスを受信するステップと、
    　前記ＨＴＴＰレスポンスに基づいて前記遷移先ＵＲＬの脆弱性を判定するステップと、
    　を有するセキュリティ診断方法。
PCT/JP2017/027822 2017-08-01 2017-08-01 セキュリティ診断装置およびセキュリティ診断方法 WO2019026172A1 (ja)

Priority Applications (5)

Application Number Priority Date Filing Date Title
PCT/JP2017/027822 WO2019026172A1 (ja) 2017-08-01 2017-08-01 セキュリティ診断装置およびセキュリティ診断方法
JP2019533770A JP6636222B2 (ja) 2017-08-01 2017-08-01 セキュリティ診断装置およびセキュリティ診断方法
CN201780093329.9A CN110998577A (zh) 2017-08-01 2017-08-01 安全诊断装置以及安全诊断方法
US16/621,338 US20200167478A1 (en) 2017-08-01 2017-08-01 Security diagnosis device and security diagnosis method
EP17919720.7A EP3651045A1 (en) 2017-08-01 2017-08-01 Security diagnostic device and security diagnostic method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2017/027822 WO2019026172A1 (ja) 2017-08-01 2017-08-01 セキュリティ診断装置およびセキュリティ診断方法

Publications (1)

Publication Number Publication Date
WO2019026172A1 true WO2019026172A1 (ja) 2019-02-07

Family

ID=65232390

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2017/027822 WO2019026172A1 (ja) 2017-08-01 2017-08-01 セキュリティ診断装置およびセキュリティ診断方法

Country Status (5)

Country Link
US (1) US20200167478A1 (ja)
EP (1) EP3651045A1 (ja)
JP (1) JP6636222B2 (ja)
CN (1) CN110998577A (ja)
WO (1) WO2019026172A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2020071637A (ja) * 2018-10-31 2020-05-07 株式会社イエラエセキュリティ ウェブサイトの脆弱性診断装置、診断システム、診断方法および診断プログラム

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111125713B (zh) * 2019-12-18 2022-04-08 支付宝(杭州)信息技术有限公司 一种水平越权漏洞的检测方法、装置及电子设备
US11683294B2 (en) * 2019-12-30 2023-06-20 Imperva, Inc. Privacy-preserving learning of web traffic
US20230328091A1 (en) * 2022-04-07 2023-10-12 Vmware, Inc. Automated discovery of vulnerable endpoints in an application server

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010176167A (ja) 2009-01-27 2010-08-12 Fujitsu Ltd 最小権限違反検出プログラム
US20170149782A1 (en) * 2015-11-19 2017-05-25 International Business Machines Corporation Identifying webpages accessible by unauthorized users via url guessing or network sniffing

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101001132B1 (ko) * 2008-02-22 2010-12-15 엔에이치엔비즈니스플랫폼 주식회사 웹 어플리케이션의 취약성 판단 방법 및 시스템
US20170063916A1 (en) * 2015-08-26 2017-03-02 Wegilant Net Solutions Private Limited System and method for automatically identifying broken authentication and other related vulnerabilities in web services

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010176167A (ja) 2009-01-27 2010-08-12 Fujitsu Ltd 最小権限違反検出プログラム
US20170149782A1 (en) * 2015-11-19 2017-05-25 International Business Machines Corporation Identifying webpages accessible by unauthorized users via url guessing or network sniffing

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3651045A4 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2020071637A (ja) * 2018-10-31 2020-05-07 株式会社イエラエセキュリティ ウェブサイトの脆弱性診断装置、診断システム、診断方法および診断プログラム
JP7217400B2 (ja) 2018-10-31 2023-02-03 ＧＭＯサイバーセキュリティｂｙイエラエ株式会社 ウェブサイトの脆弱性診断装置、診断システム、診断方法および診断プログラム

Also Published As

Publication number Publication date
US20200167478A1 (en) 2020-05-28
JPWO2019026172A1 (ja) 2019-11-21
CN110998577A (zh) 2020-04-10
EP3651045A4 (en) 2020-05-13
JP6636222B2 (ja) 2020-01-29
EP3651045A1 (en) 2020-05-13

Similar Documents

Publication Publication Date Title
US20220035930A1 (en) System and method for identifying network security threats and assessing network security
EP3188436B1 (en) Platform for protecting small and medium enterprises from cyber security threats
US8782796B2 (en) Data exfiltration attack simulation technology
CN111400722B (zh) 扫描小程序的方法、装置、计算机设备和存储介质
US7917759B2 (en) Identifying an application user as a source of database activity
CN108989355B (zh) 一种漏洞检测方法和装置
CN112347485B (zh) 多引擎获取漏洞并自动化渗透的处理方法
CN111683047B (zh) 越权漏洞检测方法、装置、计算机设备及介质
US20110283174A1 (en) Optimizing Security Seals on Web Pages
JP2006526221A (ja) ネットワークの脆弱性を検出し、コンプライアンスを評価する装置及び方法
WO2019026172A1 (ja) セキュリティ診断装置およびセキュリティ診断方法
US9059987B1 (en) Methods and systems of using single sign-on for identification for a web server not integrated with an enterprise network
CN113868659B (zh) 一种漏洞检测方法及系统
US20160034690A1 (en) Unused Parameters of Application Under Test
JP5499805B2 (ja) 情報処理装置、情報処理システム、情報処理方法並びに情報処理プログラム
Squarcina et al. Can i take your subdomain? exploring {Same-Site} attacks in the modern web
Serketzis et al. Actionable threat intelligence for digital forensics readiness
JP5549281B2 (ja) 不正侵入検知・防御システム、クライアントコンピュータ、不正侵入検知・防御装置、方法およびプログラム
CN113868669A (zh) 一种漏洞检测方法及系统
Westers et al. SSO-monitor: fully-automatic large-scale landscape, security, and privacy analyses of single sign-on in the wild
Ashari et al. Security Audit for Vulnerability Detection and Mitigation of UPT Integrated Laboratory (ILab) ITERA Website Based on OWASP Zed Attack Proxy (ZAP)
CN113868670A (zh) 一种漏洞检测流程检验方法及系统
Laitinen Vulnerabilities in the wild: Detecting vulnerable Web applications at scale
JP2017045188A (ja) 通信記録確認装置、通信記録確認システム、通信記録確認方法および通信記録確認プログラム
Forsberg Penetration Testing and PrivacyAssessment of Top-RankedHealth and Fitness Apps: An Empirical Study

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17919720

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2019533770

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2017919720

Country of ref document: EP

Effective date: 20200203