Writing Security Rules on ApiStrike¶

This document is designed to help ApiStrike users create custom rules (attack scenarios) to perform targeted API security tests within the platform.

Rule Structure¶

Each ApiStrike rule is written in YAML format and contains the following main sections:

YAML

id: RULE_ID

info:
  name: "Meaningful Rule Name"
  description: "What is the goal of this test?"
  details: "How the technique works"
  impact: "What happens if the attack is successful?"
  category:
    name: CATEGORY_CODE
    shortName: Short name
    displayName: "Display name in UI"
  subCategory: SUB_CATEGORY_CODE
  severity: LOW | MEDIUM | HIGH | CRITICAL
  tags: [OWASP, Business logic, API Abuse]
  references: ["https://..."]
  cwe: [CWE-123]
  cve: [CVE-2020-XXXX]

auth:
  authenticated: true | false

api_selection_filters:
  method:
    eq | neq: GET | POST | PUT | DELETE
  url:
    contains_either: ["login", "auth"]
  response_code:
    gte: 200
    lt: 300
  query_param:
    for_one:
      key:
        regex: ".*"
        extract: query_key
      value:
        extract: query_value
  request_payload:
    for_one:
      key:
        regex: "(?i)username|email"
        extract: userKey
      value:
        extract: userVal

wordLists:
  payloads:
    - "' OR 1=1 --"
    - "%27%20OR%20%271%27%3D%271"

execute:
  type: single | multiple | parallel
  requests:
    - req:
        - modify_query_param:
            query_key: "${query_value}${payloads}"
        - change_role:
            '${roles.ROLE_NAME}': 1

validate:
  response_code:
    eq: 200
  response_payload:
    length:
      gt: 0
    contains_either: ["token", "login"]
    not_contains: ["unauthorized", "error"]
  response_headers:
    for_one:
      key:
        eq: Injected-Header
      value:
        eq: Injected-Value

Rule Components¶

1. `id`¶

A unique identifier for the rule. Used to track and manage rules.

2. `info`¶

General metadata for the rule:

name: Human-readable name
description: Summary of the rule
details: Technical details
impact: Potential consequences
solution: (Optional) Suggested fix
references: Relevant resources
cwe, cve: Vulnerability codes, if applicable

3. `category`¶

Defines the type of vulnerability based on OWASP/CWE or internal classification:

INJ: Injection
SM: Security Misconfiguration
BOLA: Broken Object Level Authorization
RCE: Remote Code Execution

4. `auth`¶

Specifies whether the test requires authentication.

true: The system must log in and obtain a token before running the rule.
false: Can be run without authentication.

5. `api_selection_filters`¶

Filters determine which API requests the rule applies to:

method: HTTP method filter
url: URL path keywords
query_param / request_payload: Match specific keys or values
response_code: Target response status code ranges
extract: Used to pull values for dynamic use in execution

6. `wordLists`¶

Reusable payloads used for testing scenarios like SQLi, XSS, CRLF, etc.

7. `execute`¶

Defines how the attack is performed:

type: single, multiple, or parallel
requests: Modifications to be applied, such as:
modify_query_param
modify_body_param
change_role

8. `validate`¶

Defines success conditions based on the server's response:

response_code: Expected HTTP status codes
response_payload: Strings or patterns to confirm attack success
response_headers: Validates expected headers

Example Rule: CRLF Injection¶

Below is an example of a vulnerability caused by the response exposing the server version information of the internal system.

YAML

id: SERVER_VERSION_EXPOSED_VIA_RESPONSE_HEADER
info:
  name: Server Version Exposed Via Response Header
  description: Attacker can obtain information about the software version and other
    identifying details of the server software running on a remote system.
  details: >
    "The endpoint appears to be vulnerable to server version disclosure attack. The original request was replayed by modifying it with an invalid url. The server response contained a header named Server  which contained information about the server software and its version number. "<b>Background:</b> Server version disclosure vulnerabilities are often considered low-risk compared  to other types of security flaws. However, they can still provide attackers with valuable information  that aids in the planning and execution of subsequent attacks. For example, knowing the specific version  of a web server software can help an attacker identify publicly known vulnerabilities associated with  that version and exploit them to gain unauthorized access to the server or compromise its integrity.
  impact: Knowing the specific version of a web server software can help an attacker
    identify publicly known vulnerabilities associated with that version and exploit
    them to gain unauthorized access to the server or compromise its integrity
  category: {name: SVD, shortName: Server Version Disclosure, displayName: Server
      Version Disclosure (SVD)}
  subCategory: SERVER_VERSION_EXPOSED_VIA_RESPONSE_HEADER
  severity: LOW
  tags: [Business logic, OWASP top 10, HackerOne top 10]
  references: ['https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/01-Information_Gathering/02-Fingerprint_Web_Server',
    'https://github.com/ASRG/asrg.io/issues/200']
  cwe: [CWE-209]
  cve: [CVE-2020-14183]
api_selection_filters:
  response_code:
    gte: 200
    lt: 600
  url:
    extract: urlVar    
execute:
  type: single
  requests:
  - req:
    - modify_url: ${urlVar}
validate:
  response_code:
    gte: 200
    lt: 600
  response_headers:  
    key:
      regex: "(?i)^server$"
    value: 
      regex: '(?i)([a-z0-9\-_]+)[/ \(]?(\d+(?:\.\d+){1,3}[a-z0-9\-._]*)'

Recommendations¶

Always use extract before referencing variables.
Payloads must be defined in wordLists before being used.
A weak or missing validate block may result in false negatives.

How Can Users Write Their Own Rules?¶

Click “Add New Rule” in the APIStrike interface to create a blank rule template.
Clone existing attack rules and customize them as needed.
Use the payload and regex examples provided in this guide.
Run rules in a testing environment to check for false positives.

Writing Security Rules on ApiStrike¶

Rule Structure¶

Rule Components¶

1. id¶

2. info¶

3. category¶

4. auth¶

5. api_selection_filters¶

6. wordLists¶

7. execute¶

8. validate¶