Introduce fuzz testing to make sure Radius parsers are robust and not vulnerable.

[nithyatsu]

We use custom parsers to parse Radius-related resource IDs and do not use any other custom parsers. Radius resource ids are a custom string format that can be parsed from untrusted data. The parser is a shared component.

We should use fuzzing to validate that Radius parser does not accept anything other than a valid Radius resource ID and make sure there are no bugs and vulnerabilities.

AB#13777

[brooke-hamilton]

@nithyatsu can you add some acceptance criteria (for example, when does the fuzz testing run, or other questions that would help us understand. Are we trying to prevent DDOS or ensure correctness?)

If this is coming from the threat model, can you link to that part of the model so that we know the impact and motivation for doing this work, which will help us prioritize.

[radius-triage-bot]

👋 @nithyatsu we need more information.

To help us investigate further, we need additional information to reproduce or understand this issue. Please ensure you have steps to reproduce and information about your OS, rad CLI version, and runtime version.

A project maintainer will reply on this issue soon to ask for additional specifics if needed.

For more information on our triage process please visit our triage overview

[lakshmimsft]

Link to Applications RP Threat model PR: radius-project/design-notes#72

[radius-triage-bot]

👍 We've reviewed this issue and have agreed to add it to our backlog. Please subscribe to this issue for notifications, we'll provide updates when we pick it up.

We also welcome community contributions! If you would like to pick this item up sooner and submit a pull request, please visit our contribution guidelines and assign this to yourself by commenting "/assign" on this issue.

For more information on our triage process please visit our triage overview