[APPSEC-10967] ASM API security. Schema extraction#3131
Conversation
95c40cb to
3837125
Compare
b82f8e7 to
df79586
Compare
lloeki
left a comment
There was a problem hiding this comment.
LGTM, a few notes but nothing consequential or worth a block.
There was a problem hiding this comment.
I'd call that DEFAULT_WAF_PROCESSORS to materialize the distinction with AppSec::Processor
There was a problem hiding this comment.
I would also refrain from reading+parsing that file + setting that constant at file load time. I'd rather have that be a memoized method.
There was a problem hiding this comment.
Ha our Appsec::Processor naming is a bit unfortunate. Let's make sure there's no confusion in our code.
There was a problem hiding this comment.
Make sure to update libddwaf signatures in vendor/rbs
There was a problem hiding this comment.
I'm confused by this, the extracted schema is a waf result, and stored in the events list?
There was a problem hiding this comment.
Hmm I think I get it now, but coming back to this after a long time I feel some confusion.
There was a problem hiding this comment.
This libddwaf API looks very strange, which might be the root cause of my confusion.
append information as part of the top level span
2e003b0 to
b47295e
Compare
What does this PR do?
This PR adds the necessary bits to enable API Security's new feature. Schema Extraction 🎉
To enable that, we need the latest version of libddwaf 1.14.0. At the end request lifecycle, we would call the WAF to extract the schema of the different WAF addresses. Calling schema extraction is gated via specific configuration:
DD_EXPERIMENTAL_API_SECURITY_ENABLEDandDD_API_SECURITY_REQUEST_SAMPLE_RATEThe schema extraction information is appended to the top-level span attributes so the backend can later process it.
At the moment, the processor configuration is not part of the static WAF rules, so we need to make sure we always include it as part of the Handle rules. We store the processor configuration at the same pace as the WAF rule.
To better review the changes, I split the work into separate commits. I recommend reading individual commits to make it easier to understand the changes. Another suggestion is to filter out all the
.lockfile changes. Here is a handy link to filter out those filesMotivation:
Additional Notes:
There are a few missing features of the API Secuirty RFC that would be implemented on the following PRs
server.response.bodyHow to test the change?
For Datadog employees:
credentials of any kind, I've requested a review from
@DataDog/security-design-and-guidance.Unsure? Have a question? Request a review!