v1.21.0 (unstable)

New features

This new version of libddwaf only introduces one new feature, alongside other fixes and behind-the-scenes changes and improvements.

Exploit prevention: Command injection detection

A new operator cmdi_detector has been introduced for detecting and blocking command injections. This heuristics builds on the shell injection heuristic in order to detect injections on non-shell APIs, including indirect shell injections. This new operator is part of the exploit prevention feature, so it is meant to be used in combination with targeted instrumentation.

The following example rule takes advantage of the new operator to identify injections originating from request parameters:

  - id: rsp-930-005
    name: CMDi Exploit detection
    tags:
      type: cmdi
      category: exploit_detection
      module: rasp
    conditions:
      - parameters:
          resource:
            - address: server.sys.exec.cmd
          params:
            - address: server.request.query
            - address: server.request.body
            - address: server.request.path_params
            - address: grpc.server.request.message
            - address: graphql.server.all_resolvers
            - address: graphql.server.resolver
        operator: cmdi_detector

Release changelog

Changes

• Command injection detection operator (#354) (#356)

Fixes

• Disable a few patterns that caused false positives (#355)

Miscellaneous

• Fix build on macos-14 (#349)
• Support (min|max)_version on verify_rule utility (#350)
• Reorganise tests (#351)
• Auto-retry flaky build steps & downgrade to macos-13 (#357)

v1.20.1 (unstable)

Changes

• Shell injection for array-based resources (#333)

Fixes

• Fix logic error on lfi_detector for windows and introduce lfi_detector@v2 (#346)

v1.20.0 (unstable)

New features

This new version of libddwaf introduces a small set of convenience features and expands some of the existing functionality.

Fingerprint regeneration

Some of the existing fingerprinting processors have been expanded with the ability to regenerate fingerprints as new data becomes available over subsequent evaluations, specifically:

• The body parameter of the http_endpoint_fingerprint is now optional.
• All the parameters of the session_fingerprint are now optional (cookies, session_id, user_id), however a session fingerprint will only be generated if at least one argument is present.

API users must take into consideration that the same fingerprint may be provided in the derivatives section of ddwaf_result over subsequent calls, which should override the previously generated one.

New & negated operators

New operators have now been included in this version of libddwaf, and some others have been expanded:

• greater_than: asserts whether a numeric value in the input data is greater than a specified one.
• lower_than: asserts whether a numeric value in the input data is lower than a specified one.
• exists for key paths: the exists operator is already available to assert the presence of an address, but it has now been expanded to assert the presence of a key path within an address;

In addition, some operators can now be negated, with the following caveats:

• Matches can only be performed on available addresses, as there isn't sufficient information to determine if an address will be provided in a subsequent evaluation. As a consequence, conditions using negated operators can only specify a single input address.
• Due to the above, the negated version of the exists operator (!exists) can only assert the absence of a key path, rather than an address.

The following are the new negated operators: !match_regex, !phrase_match, !exact_match, !ip_match, !equals and !exists.

Min and max version for evaluation primitives

In order to allow for a single ruleset to be used throughout multiple versions of libddwaf, while taking advantage of new features and / or changes to the evaluation primitives schema, two new fields have been added:

• min_version: this can be used to specify the minimum version of libddwaf required to support this evaluation primitive.
• max_version: this can be used to specify the maximum version of libddwaf required to support this evaluation primitive.

Both fields follow the semantic versioning schema x.y.z without a v in front nor any subsequent labels or hashes, the minimum allowed version is 0.0.0 and the maximum 999.999.999. Each new field can be provided in isolation or in combination with its counterpart.

The evaluation primitives supporting this new fields are: rules, exclusion filters, processors and scanners. An example of a rule using a minimum and maximum version can be seen below:

  - id: rsp-930-004
    name: SHi Exploit detection
    tags:
      type: shi
      category: exploit_detection
      module: rasp
    min_version: 1.19.0
    max_version  1.19.999
    conditions:
      - parameters:
          resource:
            - address: server.sys.shell.cmd
          params:
            - address: server.request.query
        operator: shi_detector

Finally, when an evaluation primitive doesn't meet the required version criteria, its ID is included in a new diagnostic field called skipped, within the relevant section, e.g.

rules:
  skipped:
    - rsp-930-004
  loaded: ...

RASP operator versioning

Finally, in order to distinguish multiple versions of our exploit prevention heuristics, RASP operators can now be versioned. Versioning is done with the following schema: operator_name@version, where the operator name is one of the existing RASP operators (lfi_detector, ssrf_detector, sqli_detector, shi_detector) and version consists of a single digit preceded by a v, e.g. sqli_detector@v2.

Operator versioning works as follows:

• When the existing operator version is higher or equal to the required version, the available operator is compatible.
• When the existing operator version is lower than the required version, the operator is incompatible.
• When the operator is incompatible, the rule is silently skipped and added to the skipped section of the diagnostics.

In addition, this release includes a new version of the sqli_detector operator, specifically sqli_detector@v2.

Release changelog

Changes

• Fingerprint regeneration based on availability of optional arguments (#331)
• Expand detections per parameter (#332)
• Extend exists operator to support key paths and negation (#334)
• Negated scalar condition for matchers (#335)
• Greater and lower than matchers (#336)
• Support min_version and max_version on evaluation primitives and RASP operator versioning (#343)
• Introduce sqli_detector@v2 (#343)

Fixes

• Fix false positive on SQLi EOL comments (#330)

Miscellaneous

• Fix many, but not all, clang-tidy complaints (#339)
• Set content:write permissions on release job (#340)

v1.19.1 (unstable)

Fixes

• Split collections by module (#328)

Miscellaneous

• Upgrade arm64 runner (#326)
• Remove noisy scenarios and add new scenario (#327)

v1.19.0 (unstable)

New features

This new version of libddwaf introduces a multitude of new features in order to support new use cases and expand existing ones.

Exploit prevention: Shell injection detection

A new operator shi_detector has been introduced for detecting and blocking shell injections, based on input parameters and the final shell code being evaluated. This new operator is part of the exploit prevention feature, so it is meant to be used in combination with targeted instrumentation.

The following example rule takes advantage of the new operator to identify injections originating from request parameters:

  - id: rsp-930-004
    name: SHi Exploit detection
    tags:
      type: shi
      category: exploit_detection
      module: rasp
    conditions:
      - parameters:
          resource:
            - address: server.sys.shell.cmd
          params:
            - address: server.request.query
            - address: server.request.body
            - address: server.request.path_params
            - address: grpc.server.request.message
            - address: graphql.server.all_resolvers
            - address: graphql.server.resolver
        operator: shi_detector

Attacker & Request Fingerprinting

This release includes a new family of processors which can be used to generate different fingerprints for a request and / or user, depending on available information:

• http_endpoint_fingerprint: this processor generates a fingerprint which uniquely identifies the HTTP endpoint accessed by the request as well as how this endpoint was accessed (i.e. which parameters were used).
• http_headers_fingerprint: generates a fingerprint which provides information about the headers used when accessing said HTTP endpoint.
• http_network_fingerprint: provides a fingerprint containing some information about the network-related HTTP headers used within the request.
• session_fingerprint: this processor generates a specific fingeprint with sufficient information to track a unique session and / or attacker.

Suspicious attacker blocking

Suspicious attackers can now be blocked conditionally when they perform a restricted action or an attack. With the combination of custom exclusion filter actions and exclusion data, it is now possible to change the action of a rule dynamically depending on a condition, e.g. all rules could be set to blocking mode if a given IP performs a known attack.

The following exclusion filter, in combination with the provided exclusion data, changes the action of all rules based on the client IP:

exclusions:
  - id: suspicious_attacker
    conditions:
      - operator: ip_match
        parameters:
          inputs:
            - address: http.client_ip
          data: ip_data
exclusion_data:
  - id: ip_data
    type: ip_with_expiration
    data:
      - value: 1.2.3.4
        expiration: 0

Other new features

• New operator exists: this new operator can be used to assert the presence of at least one address from a given set of addresses, regardless of their underlying value.
• Rule tagging overrides: rule overrides now allow adding tags to an existing rule, e.g. to provide information about the policy used.
• New function ddwaf_known_actions: this new function can be used to obtain a list of the action types which can be triggered given the set of rules and exclusion filters available.

Release changelog

Changes

• Multivariate processors and remove generators (#298)
• Custom rule filter actions (#303)
• SHA256 hash based on OpenSSL (#304)
• Shell injection detection operator (#308)
• Limit the number of transformers per rule or input (#309)
• Validate redirection location and restrict status codes (#310)
• Rule override for adding tags (#313)
• Add support for dynamic exclusion filter data (#316)
• HTTP Endpoint Fingerprint Processor (#318)
• HTTP Header, HTTP Network and Session Fingerprints (#320)
• Exists operator and waf.context.event virtual address (#321)
• Add function to obtain available actions (#324)

Fixes

• Transformer fixes and improvements (#299)

Miscellaneous

• Fix object generator stray container (#294)
• Regex tools & benchmark rename (#290)
• Order benchmark scenarios (#300)
• Upgrade to macos-12 (#312)
• Skip disabled rules when generating ruleset (#314)
• Update default obfuscator regex (#317)

v1.18.0 (unstable)

This version introduces a new operator sqli_detector for the detection of SQL injections. In addition, the ruleset parser has been updated to allow non-string parameter values on action definitions.

Changes

• SQL Injection (SQLi) Detection Operator (#284)

Fixes

• Fix mishandling invalid actions key type (#286)
• Convert non-string object types into string during ruleset parsing (#285)

Miscellaneous

• Use SSE4.1 ceilf when available and add badges to readme (#288)
• SQLi Detector Fuzzer and improvements (#291)

v1.17.0 (unstable)

This new version introduces RASP rules and supporting features, including:

• Multivariate operators for the development of complex rules.
• A new operator lfi_detector for the detection of local file inclusion (LFI) / path traversal attacks.
• A new operator ssrf_detector for the detection of server-side request forgery (SSRF) attacks.
• Better support for rule actions, as well as internal default actions: block, stack_trace and extract_schema.

The upgrading guide has also been updated to cover the new breaking changes.

Changes

• Multivariate operator support (#241)
• Local file inclusion (LFI) operator (#258)
• Server-side request forgery (SSRF) detection operator (#268)
• Action semantics and related improvements (#277)

Fixes

• Reduce benchmark noise (#257, #259, #260)
• Add support for old glibc (e.g. RHEL 6) (#262)
• Add weak ceilf symbol and definition (#263)
• Fix parsing of variadic arguments (#267)

Miscellaneous

• Update node-16 actions to node-20 ones (#266)
• Attempt to build libddwaf on arm64 runner (#270)
• Run tests on arm64 (#271)
• LFI detector fuzzer (#274)
• Remove rpath from linux-musl binary (#282)

v1.17.0-alpha3 (unstable)

Since this release contains breaking changes, the upgrading guide has been updated.

Changes

• Action semantics and related improvements (#277)

Miscellaneous

• LFI detector fuzzer (#274)

v1.16.1 (unstable)

Fixes

• Add support for old glibc (e.g. RHEL 6) (#262)
• Add weak ceilf symbol and definition (#263)

v1.17.0-alpha2 (unstable)

Changes

• Server-side request forgery (SSRF) detection operator (#268)

Miscellaneous

• Attempt to build libddwaf on arm64 runner (#270)
• Run tests on arm64 (#271)