Managed actions

When creating an event driven or scheduled action you can choose to set up a managed action. These are out-of-the-box integrations provided by FireTail. There a various types of managed actions available:

• API Contract Testing - Test that your API's endpoints behave as defined in the OpenAPI specification.
• GraphQL Testing - Test your GraphQL API for vulnerabilities.
• API CVE Detection - Scan the entered endpoint for CVEs.
• SSL Vulnerabilities Detection - Scan the entered endpoint for SSL vulnerabilities.
• Data Exposure Detection - Scan the entered endpoint for data exposure.
• Default Login Detection - Scan the entered endpoint to check if you are hosting any services using default login credentials.
• Fuzzing Detection - Fuzz the entered endpoint.

GraphQL testing

This managed action will test your GraphQL API for vulnerabilities. The following tests are conducted:

• Alias Overloading (DoS) - The alias_overloading function checks for potential Denial of Service (DoS) vulnerabilities in a GraphQL API by sending a query with over 100 aliases. If the API can process the request and return data for alias100, it indicates that the server may be susceptible to resource exhaustion.
• Batch Queries (DoS) - The batch_query function tests a GraphQL API for potential Denial of Service (DoS) vulnerabilities by sending a request with 10 or more simultaneous queries. If the API can process and return results for these batch queries, it indicates that the server may be vulnerable to performance issues under heavy loads.
• GET based Queries (CSRF) - The get_method_support function tests if a GraphQL endpoint supports queries via HTTP GET, which could expose it to CSRF risks. It sends a basic query using the GET method and checks for a valid response.
• POST based Queries using url encoded payloads (CSRF) - The post_based_csrf function tests whether a GraphQL endpoint accepts queries via POST in a non-JSON format, which could make it vulnerable to CSRF attacks. It sends a URL-encoded query as POST data and checks if the server processes it successfully.
• GraphQL Tracing / Debug Modes (Info Leak) - The trace_mode function checks if a GraphQL server has tracing enabled, which could reveal additional metadata about query processing. It sends a query and examines the response for tracing data under extensions.
• Field Duplication (DoS) - The field_duplication function tests a GraphQL API for handling excessive repetitions of the same field within a query. Specifically, it checks if the API can manage a query containing 500 duplicate instances of the __typename field. If the API successfully processes this query and returns data, it indicates a potential vulnerability that could lead to a Denial of Service (DoS) by overloading the server with redundant data requests.
• Field Suggestions (Info Leak) - The field_suggestions function checks if a GraphQL API exposes field suggestions, which can lead to information leaks. It sends a query to the API and looks for responses with the phrase "Did you mean" in error messages, indicating that the API hints at possible field names, posing a risk of exposing schema details.
• GraphiQL (Info Leak) - The detect_graphiql function checks if the GraphiQL interface or other GraphQL IDEs (e.g., GraphQL Playground) are accessible on a given endpoint, which could indicate information leakage. It sends a request with modified headers to detect the presence of these tools by looking for specific keywords in the response.
• Introspection (Info Leak) - The introspection function tests whether the GraphQL endpoint allows introspection queries, which could expose the schema and types used in the GraphQL service. It sends a query to check for the presence of schema details, and if the introspection is enabled, it flags the endpoint for information leakage.
• Directives Overloading (DoS) - The directive_overloading function tests a GraphQL API to check if it can handle queries with excessive or repeated custom directives, which may lead to Denial of Service (DoS) conditions. If the API returns 10 errors in response to a query with repeated directives, this indicates a potential vulnerability where the server could be overwhelmed or affected by such malformed queries.
• Circular Query using Introspection (DoS) - The circular_query_introspection function tests if a GraphQL endpoint is vulnerable to denial-of-service via recursive introspection queries. It sends a deeply nested query that repeatedly traverses type fields, assessing the server's response to detect potential weaknesses.
• ‍Mutation support over GET methods (CSRF) - The get_based_mutation function tests if GraphQL mutations can be executed using the HTTP GET method, which could potentially expose the API to Cross-Site Request Forgery (CSRF) attacks. It sends a mutation query as a GET request and checks for a successful response, indicating that mutation support over GET is enabled.

API contract testing

This managed action tests that your endpoints behave as defined in the OpenAPI specification. 

Request Validation

Testing involves sending various types of requests to your API's endpoints and validating the responses. For instance, if an endpoint requires a request parameter to be an integer within the range of 0 to 1000, then contract testing will test by sending correct requests such as: 

• A value of 0
• A value of 1000
• A value such as 634

To ensure robustness, the test will also send incorrect requests that fall outside the specified parameters. Examples include:

• A value of -1
• A value of -729
• A value of 5007
• A value of "foobar" (a string instead of an integer)

Response Validation

For each request, the test will check the received response against the responses defined in the OpenAPI specification. This includes:

• Verifying that the response status codes and formats match those listed in the specification.
• Ensuring that undefined responses, such as a "404 Not Found" when only "400 Bad Request" is specified, are flagged as findings.
• Any server errors (5xx responses) will also be flagged as findings, even if they are listed in the specification, as well-designed servers should not throw errors under normal circumstances.

Findings

If any of the requests result in responses not defined in the specification, such as a "404 Not Found" instead of "400 Bad Request", this will create a finding. Similarly, any server error responses (5xx) will also be reported as findings, indicating potential issues in the API's design or implementation.

API CVE detection

This managed action scans your endpoint for CVEs (common vulnerabilities and exposures) and generates observations. CVEs are identified by the year in which the vulnerability was discovered or publicly disclosed. Each CVE entry receives a unique identifier number. In total, 2302 checks are made. See the table below for some examples of CVEs that are scanned for in this managed action.

‍

SSL Vulnerabilities detection

This managed action will scan your endpoint for SSL Vulnerabilities and generate observations. SSL (Secure Sockets Layer) vulnerabilities refer to weaknesses or flaws in the SSL protocol or implementations that could potentially compromise the security of data transmitted over the internet. SSL is a cryptographic protocol used to establish secure connections between a web server and a client, typically a web browser, ensuring that data exchanged between them is encrypted and protected from interception or tampering. In total, 24 SSL checks are made. See the table below for examples of SSL vulnerability detections:

SSL examples:

‍

Data exposure detection

This managed action will scan your endpoint for data exposure and generate observations. In total, 467 data exposure checks are made. See the table below for examples of data exposure detections:

‍

Default login detection

This managed action will scan your endpoint to see if you are hosting any services using default login credentials and generate observations. In total, 173 default login checks are made. See the table below for some examples of default login detections:

‍

FUZZING detection

This managed action will fuzz your endpoint and generate observations.

Fuzzing an endpoint involves sending a large volume of invalid, unexpected, or random data inputs to the endpoint, to identify vulnerabilities, crashes, or unexpected behavior. This technique aims to discover security flaws, such as buffer overflows, injection vulnerabilities, or parsing errors, that may not be identified through traditional testing methods. In total, 11 fuzzing checks are made. See the table below for some examples: