ICACT20220047 Slide.21
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
Finally, I would like to explain the conclusion and future work.
In this presentation, we proposed a vulnerability assessment method repeatedly analyzes WebAPI requests and their responses.
Using the proposed method, we conducted an evaluation experiment to detect a Wordpress article tampering vulnerability, which is difficult to detect with existing vulnerability assessment tools, and successfully detected it.
As future work, we will study the detection method for other vulnerability items of the API vulnerability by OWASP, which was not targeted this time.
We are also planning to conduct evaluation experiments using the actual Wordpress environment.
That's it for the presentation.
Thank you very much for your attention.
|
|
ICACT20220047 Slide.20
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
Next, we will explain the results of the detected Wordpress article tampering vulnerabilities.
No. 5 detection is conducted for endpoints that require authentication and need to set parameters.
In this evaluation experiment, we successfully detected the vulnerability in the POST method /wp/v2/posts/{id}.
In No.5, the vulnerability assessment is conducted by replacing and combining parameters.
For the original parameters to be replaced or combined, use the same data for each parameter for each endpoint saved in the previous step.
In the case of /posts/{id}, the parameters used are "38" for ID and "ArticleName" for Title.
For these parameters, for {id}, which receives a numeric value, replace "38" in the ID with "A" since we are using "A" in this presentation, and combine "38" and "A" to make "38A".
We only use "A" as an any-string because the purpose of this method is to change the value to a value of a different type and not to focus on the content of the string.
Next, for the Title, which receives a string, replace "ArticleName" in the Title with "1" since we are using "1" in this presentation, and combine "ArticleName" with "1" to make "ArticleName1".
As a result of these parameter replacements and combinations, the HTTP status code of the response to the request with the {id} of "38A" and the Title of "ArticleName" was 200 OK, indicating that the request was processed normally.
Therefore, we detected that /posts/{id} is vulnerable to No. 5, which allows processing to bypass authentication under the condition in the second row of the table.
|
|
ICACT20220047 Slide.19
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
Next, send a request to all the extracted endpoints to check if the reference contains accurate information and to obtain various information used for vulnerability assessment.
For example, the first in the table, GET /posts, will generate a request that matches the extracted information.
From the response, check the HTTP status code, and if the request is processed normally, such as 200 OK, determine that it is a valid endpoint.
At this time, the name of the key in the JSON data of the response is saved as a candidate key, and the content of the response to the request is saved in the vulnerability assessment tool with the request content.
This information will be used in each vulnerability assessment.
In this evaluation experiment, we confirmed that the information in the reference was processed correctly and that it was a valid reference.
|
|
ICACT20220047 Slide.18
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
Next, I would like to explain the results of evaluation experiment.
First, we obtain information from the reference.
The first four results extracted from the reference are shown in the table in the center of the slide.
|
|
ICACT20220047 Slide.17
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
Before explaining the evaluation experiment, we will explain the Wordpress article tampering vulnerability.
The Wordpress article tampering vulnerability starts with an attacker using the Wordpress article ID endpoint to obtain a list of articles.
From the obtained article IDs, the attacker selects the articles to be tampered with and sends a query to conduct the tampering using the Wordpress article update endpoint.
For example, if the attacker wants to tamper with the post with ID 38, the attacker sends a request to /wp/v2/posts/38 with the parameters that have been changed to the value of the "id" and the content to be tampered with in the Title and other fields.
Here is an example of a query to change the title of a post with id 38 to "Title Changed".
The tampering of the article is completed when this request is processed successfully.
If we check the tampering using the endpoint that retrieves the list of articles used in the first step, we can see that the title of the article with ID 38 has been changed to "Title Changed", which was set at the time of tampering.
|
|
ICACT20220047 Slide.16
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
I would like to explain the evaluation experiment.
In the evaluation experiment, we will use the Wordpress WebAPI to conduct a vulnerability assessment.
The purpose of the evaluation experiment is to detect the Wordpress article tampering vulnerability, which is difficult to detect by existing vulnerability assessment tools.
The evaluation experiment was conducted with Wordpress version 4. .7.0 on a virtual environment.
The evaluation experiment did not detect any vulnerability corresponding to No. 1.
This is because the vulnerability does not exist in the Wordpress environment.
However, evaluation experiments detected the Wordpress article tampering vulnerability, which corresponds to No. 5, using the proposed method.
|
|
ICACT20220047 Slide.15
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
The purpose of this method is to detect authentication failures caused by casting errors in the processing of programs inside the WebAPI using type conversions in parameters and string combinations.
The parameter replacement process is conducted in the same way as in Method 3 of No.1.
The vulnerability is determined by checking the HTTP status code from the response of the generated request, and if the request is processed normally (e.g., 200 OK), it is determined to be vulnerable.
|
|
ICACT20220047 Slide.14
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
Next, we explain the No.5 vulnerability assessment.
In the No. 5 vulnerability assessment, we conduct parameter substitution for methods and endpoints that require authentication.
This method performs the same processing as method 3 in No.1, with the difference that it limits the target endpoints to methods and endpoints that require authentication and require setting of parameters.
|
|
ICACT20220047 Slide.13
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
The third method is Detecting vulnerable endpoints by replacing parameters.
In this method, parameters that are not described in the reference are estimated by type conversion and combining of numbers and strings in the parameters.
For example, if there is an endpoint /wp/v2/status with parameters, and the parameters id and status are numeric and string types, the replacement and combination processes are performed for each parameter.
The original parameters for the replacement and combination process will be the combination of the parameters used in the reference validation, saved in the previous step.
In the example, 5 is used as the "ID" and Publish is used as the "Status".
The first step in the replacement and combination process for numeric parameters is to replace them with an any string type.
In this presentation, we will use "a" as an any string.
The ID value used, "5", is replaced with "a" to create the parameter.
Next, combine the original ID value of "5" with "a" to generate the parameter "5a".
The generated parameter is used to send a request to determine if there is a vulnerability.
For string type parameters, it replaces any numeric value with the string and combines it.
Use "1" as an any numeric value, and replace the original string "publish" with "1".
Then, combine "publish" with "1" to create the parameter "publish1" and send the request.
|
|
ICACT20220047 Slide.12
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
The second method is Detecting vulnerable endpoints by replacing variables.
The second method estimate the endpoints that are not described in the reference by substituting variables that take any value in the endpoint.
For example, if an endpoint has a variable that takes an arbitrary value, such as {id} in /wp/v2/posts/{id}, vulnerability assessment is conducted by changing the value of this {id}.
Therefore, we need to get the value of the ID being used.
The ID values are obtained from the content of the response to a request sent to /wp/v2/posts, one level above wp/v2/posts/{id}.
For example, if numbers such as 38 and 1 are used as IDs, the maximum value +1, the minimum value -1, and the median value of these numbers are calculated and substituted into the ID value. These values are substituted into the ID value and the request is sent.
The vulnerability is determined from the status code in the response.
|
|
ICACT20220047 Slide.11
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
The first method, endpoint detection by combining paths, combines the base path and candidate keys in order to estimate endpoints that are not described in the reference.
Send a GET request to generated endpoints.
No.1 is a vulnerability caused by the use of an endpoint that is not described in the reference, so make sure that the generated endpoint is not described in the reference.
The vulnerability is determined by checking the response for HTTP status codes other than the 400 series, which indicate that the request was not processed successfully.
|
|
ICACT20220047 Slide.10
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
Next, the No.1 vulnerability assessment uses three methods in order to detect endpoints that are not described in the reference.
The first is Detecting vulnerable endpoints by combining path.
The second is Detecting vulnerable endpoints by replacing variables.
The 3rd is Detecting vulnerable endpoints by replacing parameters.
|
|
ICACT20220047 Slide.09
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
Next, conduct a vulnerability assessment for each vulnerability item.
In this presentation, we will conduct a vulnerability assessment of No. 1 and No. 5.
|
|
ICACT20220047 Slide.08
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
So, in the Validation check of the reference checks that the information is correctly described in the reference and obtains information for use in vulnerability assessment.
In this method, proposed method sends a request query to the WebAPI server and obtains the response.
Send a request to all endpoints extracted from the reference and save the response.
Also, we save the contents of the response.
Then, we define the name of the key in the JSON data contained in the response as a candidate key, and save it.
The candidate key and the saved response will be used in our proposed vulnerability assessment method.
|
|
ICACT20220047 Slide.07
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
This section describes the basic flow of each step of the vulnerability assessment.
First, in order to conduct a vulnerability assessment customized to the WebAPI environment,
we will obtain references describing WebAPI operations.
There are four information to be extracted from the WebAPI reference:
WebAPI endpoint,
HTTP request method
Parameter name and type,
And Whether authentication is required.
An example is shown in the figure.
The information of the reference is stored in the database.
If the WebAPI reference is outdated or does not contain accurate information, the vulnerability assessment in each vulnerability assessment conducted by the proposed method will cause problems that cannot be accurately assessed.
|
|
ICACT20220047 Slide.06
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
Our proposed method uses WebAPI requests and their responses for vulnerability assessment.
The basic policy is to collect the information necessary for vulnerability assessment of the target WebAPI from the WebAPI reference, and conduct the vulnerability assessment process.
The basic flow of the vulnerability assessment is conducted in three steps.
First, obtain information from the WebAPI reference.
Next, in order to obtain information from the WebAPI response, we will check the validity of the reference and obtain the response.
Send a request using the reference information obtained in the previous step, and get a response.
Finally, the vulnerability assessment process.
In this presentation, we will explain the process based on the information obtained in the previous steps to conduct the No.1 and No.5 vulnerability assessment.
|
|
ICACT20220047 Slide.05
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
Here is an overview of No.1 and No.5 vulnerability.
No.1 is a vulnerability that allows users to use functions of an unpublished API.
For example, if an endpoint that is not described in the WebAPI reference is used, this is a No.1 vulnerability.
Next, No. 5 is a vulnerability that allows unauthorized users to use API functions that require authorization.
For example, if an endpoint that requires authentication is used without authentication information, this is a No.5 vulnerability.
|
|
ICACT20220047 Slide.04
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
The guidelines for the 10 API vulnerabilities describe an outline of the vulnerabilities and their simple countermeasures, but do not include examples of actual attacks or details of the countermeasures.
so some vulnerability assessment tool cannot detect vulnerabilities.
Therefore, we propose a vulnerability assessment method that considers the request to the WebAPI and its response.
In this presentation, we focus on No.1 and No.5 of the 10 vulnerabilities of WebAPIs, and we propose a method for vulnerability assessment.
We focus on No. 1 and No.5 because access control vulnerabilities are the most threatening vulnerabilities on the Web.
|
|
ICACT20220047 Slide.03
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
First, I'd like to talk about research background.
OWASP, an organization that works on web application security, has published guidelines on the 10 vulnerabilities of WebAPIs.
There are four categories of API vulnerabilities by OWASP, including access control vulnerabilities and web traditional vulnerabilities that are not limited to WebAPIs.
so the security risks to WebAPIs are attracting a lot of attention.
|
|
ICACT20220047 Slide.02
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
Here is the table of contents.
|
|
ICACT20220047 Slide.01
[Big slide for presentation]
[YouTube] |
Chrome Text-to-Speach Click!! |
 |
Hi, Im Toru Taya from Tokyo university of information scienses. Today I'd like to presentation about An Automated Vulnerability Assessment Approach for WebAPI that Considers Requests and Responses.
|
