Skip to content

Limitations

Cedric HEBERT edited this page Jun 28, 2024 · 4 revisions

Cloud active defense is compiled from Go into WASM. WASM is considered embedded code, meaning that not all Go features can be used. Namely, Go has a JSON parser but does not have JSON encoding. Check this page for a list of supported and unsupported Go packages.

Envoy cannot read from the file system. To fetch data at runtime, you have to rely on a solution such as performing an asynchronous HTTP call. This is one of the reasons why we had to add a configmanager.

There might be some side effect depending on the order in which you apply decoys. For example, if you replace some HTML content with something else, and that a second decoy uses the original HTML content in its 'inject' regular expression, that second one might not trigger.

Decoy injection and detection is quick for a few tokens, but it might occur some performance overhead if you use a large number of decoys at the same time. We did not test this extensively so your feedback is welcome!

Since alerts wait for the application server to send its reply, then preventing the application to reply to Envoy can also prevent a potential alert from being sent. We think that it's a risk worth taking in exchange of more useful alerts (if we send the alert immediately then we'll be missing metadata).

If a decoy detection requires looking at the request body (versus the request headers), it is not possible to immediately divert the request off of the protected application. The reason is that request headers are fully processed by Envoy and sent to the target application before the request body gets looked at. So if a decoy is detected there, there is no chance to re-send the full request to another endpoint instead off the application. This means that whatever response was configured will be applied only to subsequent requests but not to the original one.

Through the same logic, since response headers are forwarded to the user before the response body gets looked at, it is not possible to inject a header decoy (such as a cookie) based on something contained in the body (such as a username). This makes it impossible at the moment to check the content of a page to see if a user is authenticated before injecting a response header. It should be possible to analyse the full request (headers + body) at the same time, then forward to whichever endpoint is appropriate, but this requires reading the requests and responses at the TCP level (TCP filter) instead of the HTTP level (HTTP filter). It can be done, but this requires substancial modification of the code, including a re-implementation of HTTP protocol parsing.

Clone this wiki locally