How to Pentest?

So you want to pentest using hackingBuddyGPT?

WebAPITesting

In case you do not already have an OpenAPI specification, you can create one using WebAPIDocumentation the following way:

Go to our github repository
Create a config file, which includes the most important information about the API. You can just assign an empty list to 'correct_endpoints' and 'query_params' since these parameters were used for benchmarking.

{
  "name": "name_of_rest_api",
  "password_file": "path_to_best1050.txt",
  "csv_file": "path_to_credentials.csv", 
  "token": "your_api_token_here",
  "host": "host",
  "description": "description_of_rest_api",
  "correct_endpoints": [
    "endpoint_1", "endpoint_2"
  ],
  "query_params": {"endpoint_1": ["param1", "param2"], "endpoint_2":["param3", "param4"]}
}

Run python wintermute.py SimpleWebAPIDocumentation --config_path "path_to_config_file" --strategy_string "cot |tot |icl"
Check the OpenAPI specification and determine if all endpoints and query parameters were found. Adjust the specification if it is necessary. You can also rerun the WebAPIDocumentation and with your own prompt written in a prompt file --prompt_file "path_to_prompt_file". The file has to be a .txt file and look like this:

---
Query root-level resource endpoints.
Find root-level endpoints for {host}.
Only send GET requests to root-level endpoints with a single path component after the root. This means each path should have exactly one '/' followed by a single word (e.g., '/users', '/products').
1. Send GET requests to new paths only, avoiding any in the lists above.
2. Do not reuse previously tested paths.
---
Query Instance-level resource endpoint with id
Look for Instance-level resource endpoint : Identify endpoints of type `/resource/id` where id is the parameter for the id.
Query these `/resource/id` endpoints to see if an `id` parameter resolves the request successfully. Ids can be integers, longs or base62.
---
Query Subresource Endpoints
Identify subresource endpoints of the form `/resource/other_resource`.
Query these endpoints to check if they return data related to the main resource without requiring an `id` parameter.
---
Query for related resource endpoints
Identify related resource endpoints that match the format `/resource/id/other_resource`: First, scan for the follwoing endpoints where an `id` in the middle position and follow them by another resource identifier.
Second, look for other endpoints and query these endpoints with appropriate `id` values to determine their behavior and document responses or errors.
---
Query multi-level resource endpoints
Search for multi-level endpoints of type `/resource/other_resource/another_resource`: Identify any endpoints in the format with three resource identifiers.
Test requests to these endpoints, adjusting resource identifiers as needed, and analyze responses to understand any additional parameters or behaviors.
---
Query endpoints with query parameters
Construct and make GET requests to these endpoints using common query parameters (e.g. `/resource?param1=1&param2=3`) or based on documentation hints, testing until a valid request with query parameters is achieved.

Run python wintermute.py SimpleWebAPITesting --config_path "path_to_config_file" --strategy_string "cot |tot |icl"
A report, a vulnerability report and a python file containing test cases will be generated (the test file needs to be adjusted to properly work)