Nested messages

[HgAlexx]

Hello, very nice project!

Regarding this:

RASP.Net/src/Rasp.Instrumentation.Grpc/Interceptors/SecurityInterceptor.cs

Line 42 in 458784a

if (field.FieldType != FieldType.String) continue;

What about nested objects in messages (where FieldType = Message)?

Regards,

[JVBotelho]

Hey hey @HgAlexx

thank you for diving into the source code, that's exactly the kind of engagement I'm looking for.

You are absolutely right, the current shallow scan is a significant bypass vector for nested messages.

---

The reason for the current "flat" implementation is the "Reflection Tax".
Iterating through Descriptor.Fields and calling GetValue is already the most expensive part of the interceptor
Adding recursion via reflection

• would exponentially increase latency and GC pressure
• potentially break our sub-microsecond goal.

---

I'm considering some paths for this:

1. Short-term (Reflection + Depth Limit): An iterative approach using a pooled stack (ArrayPool<IMessage>) to avoid recursion overhead, limited to a depth of 3-5 to prevent DoS via deeply nested payloads.
2. Mid-term (AOT/Reflection.Emit): Pre-compiling the accessors for specific message types at startup to bypass the slow descriptor lookup.
3. Long-term (Source Generators ADR 002): This could be the "correct" Tier-1 solution. By generating the inspection logic at compile-time, we can unroll the loops and avoid reflection entirely, keeping the overhead in the low nanoseconds even for nested objects.

---

In your experience, what is your average nesting depth?, Do you often have user-controlled strings hidden more than 2 levels deep?

I'd love to collaborate on a PR if you're interested in testing a recursive implementation against your real-world schemas (or even making a PR yourself hehehe)

Let me know!

[HgAlexx]

Hello,

You are absolutely right, the current shallow scan is a significant bypass vector for nested messages.

The reason for the current "flat" implementation is the "Reflection Tax". Iterating through Descriptor.Fields and calling GetValue is already the most expensive part of the interceptor Adding recursion via reflection

Glad you already though of it :)

I'm considering some paths for this:

1. Short-term (Reflection + Depth Limit): An iterative approach using a pooled stack (`ArrayPool<IMessage>`) to avoid recursion overhead, limited to a depth of 3-5 to prevent DoS via deeply nested payloads.

I would done something like 1. (and part of .2) but with a full analysis of Messages at startup:

• scan for all messages: allow RASP consumer to specify assemblies to scan (much like scrutor)
• compute and cache only "path" to (string) content we want to validate
• since all message types are known I think depth should not be an issue since request types are built by the server developers, not the consumer

2. Mid-term (AOT/Reflection.Emit): Pre-compiling the accessors for specific message types at startup to bypass the slow descriptor lookup.

3. Long-term (Source Generators [ADR 002](https://github.com/JVBotelho/RASP.Net/blob/master/docs/ADR/002-detection-engine-evolution.md)): This could be the "correct" Tier-1 solution. By generating the inspection logic at compile-time, we can unroll the loops and avoid reflection entirely, keeping the overhead in the low nanoseconds even for nested objects.

Messages type are already source generated from .proto files. Last time I checked, a source generator cannot use output from another generator :( except if .NET 10 fixed that.
It might work if the RASP source generator is used in another project witch depends on the one generating the messages (untested).

Another issue I though of is the protobuf Any type which might be a pain to handle.
On our end Any is banned, all messages must be fully typed.

In your experience, what is your average nesting depth?, Do you often have user-controlled strings hidden more than 2 levels deep?

Our project using gRPC is quite young, we don't have many messages at the moment, but already a depth of 3:
ResultEnvelop -> type -> subtype

We are moving away from REST because its flatness complicate a lot of our workflow. We have very complex data structure we want to process inside a single transaction rather that via dozen of rest calls.
Counting the ResultEnvelop, we may have 6 or 7 levels.

I'd love to collaborate on a PR if you're interested in testing a recursive implementation against your real-world schemas (or even making a PR yourself hehehe)

Let me know!

As stated above, our project is young so our current schema is a bit light ;) Also, for now we are only working on our "private" gRPC api, between our own nodes, so not the best test case but I can still run some tests if needed.

But we plan to have a "public" gRPC api where external user (client) can interact. Even then, each client would have its own cluster, fully isolated from any other clients. These cluster would most likely not be internet facing.

Regarding a PR, I won't be allowed to spend time on it, at least not at the moment, as usual, the project is already late :D

Regards,

[JVBotelho]

Hey hey @HgAlexx,

So, we’re currently pivoting to a Source Generator approach in the latest dev branch (as per ADR 002), and the results are ok-ish, for flat props, like the CreateBookRequest, the performance gain is actually negligible—almost "irrisory".

message CreateBookRequest {
  string title = 1;
  string author = 2;
  int32 publication_year = 3;
  int32 pages = 4;
  int32 total_copies = 5;
}

In a deep nesting, 15 levels deep, the source gen unrolled code is roughly 3x faster than reflection on the hot path, in the detection path the gap narrows because the detection engine's overhead becomes the dominant factor but reflection still adds a 30% time penalty, so the gap in this case isn't as impressive as the hot path one but its still faster

message DeepRequest {
  DeepRequest next = 1;
  string value = 2;
}

---

About the points you raised:

• Symbols over Source: You're right that chaining generators is a pain. We’re solving this by having the RASP SG look at Type Symbols. Since the host project references the contracts assembly, Roslyn lets us inspect the compiled metadata of the gRPC messages. We don't need the source code of the .proto output, just the symbols!
• Performance with Unsafe.As: We’ve been testing Unsafe.As<TRequest, ConcreteType> inside the generated interceptor. This gives us 'native' access to fields, bypassing the 'Reflection Tax' entirely and keeping us in the sub-microsecond range.
• Unrolling Nested Messages: This is the core of the new architecture. Instead of a runtime stack, the SG performs compile-time recursion to 'unroll' the message tree during build. For a 7-level nesting, it generates a flat sequence of direct checks.

---

Since you mentioned your project is in a private/early stage, I won't ask for the schema xD, Instead, would you be open to running a test build of RASP against your services once we merge the recursion logic? Your feedback on how it handles the 'ResultEnvelop' and the performance impact on a real-world complex project would be gold for us.

Let me know

[JVBotelho]

Done :P

Implemented the GrpcRecursiveInspectorGenerator

[HgAlexx]

I'll try to do some tests this week ;)