Body data of POST
requests with content-type header application/json
are parsed as JSON content and might be blocked by deny rules. Access logging information about blocked JSON requests can be used to configure deny rule exceptions for false positives. This article covers the required steps to create deny rule exceptions for false-positive JSON content blocking.
Identify blocks in the access log
The following instruction focuses on false positive identification of request blocks during productive use but also applies in LogOnly
mode. Consider analyzing potential blocks in LogOnly
mode during integration tasks, as described later in this article.
The different log types, such as access or application logs, can be printed using the kubectl logs
as mixed output. You may filter the printed logs according to your needs for better orientation.
- Use
kubectl logs <POD> -c airlock-microgateway-engine
to print the logs for the engine container in a pod. For more options, see kubectl logs reference. - Use
grep <query>
to filter the log-message output according to your requirements. - With the jq-JSON processor (or equivalent) installed, you may pipe the logs output to the processor for better formatting and readability. See JQ for further information.
- Identify blocked JSON elements in the access logs. The unique JSON path is listed in the log for blocked JSON Elements.
- Use the logged path information to configure deny rule exceptions:
- Deny rule exceptions can be defined for JSON keys or values.
- Additionally, the exception can be restricted to a defined JSONPath. In the JSONPath expressions, wildcards (*) can be used, according to this JSONPath syntax reference.
Example: - For deny rule exceptions, operators
[]
with expressions and script expressions are not supported. For example,$..book[?(@.age)].title
does NOT work as JSONPath expression. - The JSONPath expression must always match a leaf. For example,
$.books[*]
does not contain a leaf and will not work, whereas$.books[*].author
does. - Check the access logs to verify the deny rule exception works as expected.
Analyse potential blocks in LogOnly mode
While integrating an Airlock Microgateway with an existing application, you can use the threatHandlingMode: LogOnly
to analyze the impact of deny rules on an application running in production. This allows for identifying false positives and configuring exceptions without disturbing productive traffic.
The following example shows a typical integration configuration with LogOnly
mode activated for all deny rules:
How JSONPath filtering works
JSON Path can filter JSON content in the body data of requests.
Example:
{ "books": [ { "title": "DevSecOps Starters Guide", "author": "Joe Bloggs", "stars": 723 }, { "title": "JSONPath for Geeks", "author": "Jane Smith", "stars": 27 } ] }
This JSON example contains 6 key-value pairs (aka leaves), 3 pairs for each book.
JSONPath can be used to filter the values of the JSON leaves:
JSONPath | Value ------------------|---------------------------- $.books[0].title | "DevSecOps Starters Guide", $.books[0].author | "Joe Bloggs", $.books[0].stars | 723 $.books[1].title | "JSONPath for Geeks", $.books[1].author | "Jane Smith", $.books[1].stars | 27
- Additional JSONPath examples:
$..author
– matches every leaf of the key author (Joe Bloggs and Jane Smith) in every book.$.books[*].author
– matches every leaf of the keyauthor
in allbooks
.
Further information and links
- Internal links:
- CR DenyRules
- Logging configuration
- External links:
- JSONPath syntax reference
- JQ