Question about code structure

[AshrafIbrahim03]

I'm trying to build a dummy HTTP fuzzer for practice using libafl. I'm particularly stuck where I want to create a feedback that takes in some status codes and its is_interesting function is simply seeing if any HTTP status codes run into are in the set the HTTPFeedback has. I've been looking through this repo's code trying to find the point at which there is communication between the harness and the observer. I found the EndpointCoverageClient in src/coverage_clients and found the IndexMap between the status code, path, method and the coverage type. I'm still confused about where the particular coverage type of the EndpointCoverageClient gets mutated.

Specifically, how does the information that isn't the ExitKind get passed from inside the harness to something outside the harness? I understand fundamentally how the different parts work, it's just very confusing how that data actually leaves the harness.

[grebnetiew]

In our case, we do use the ExitKind to indicate success or failure of the target (normally interpreting 5xx status codes as crashes, as well as deviations of responses from the spec).

The observers in our case are coverage observers (MultiMapObserver in fuzzer.rs), and their coverage maps are (unsafely) shared with the coverage clients. The coverage clients are instructed by the harness when an input test begins and ends, and can thus make sure the coverage map reflects the coverage of an input when the harness finishes running.

[ThomasTNO]

Hi @AshrafIbrahim03, does this answer your question?

[AshrafIbrahim03]

Yes that answers my question, sorry about the late follow up.

Another question about how the project was designed - did the contributors ever consider creating a way to have more finetune control over what types of response data could be considered interesting? For example, instead of using the exitkind to determine what status code was returned, passing a status code type to a feedback in order to assess interestingness from there? Were there any considerations that, if that was implemented, would impact performance or maintainability or some other metric the project targets?

[ThomasTNO]

Good that you point that out. Yes, some initial thought were put into this. It would be great to implement a more fine-grained option for enabling what should be considered interesting. If you go over the good we already distinguish quite some different types of errors, however we currently only support flagging either everything of the list as interesting or only 5xx return codes.

If you have a suggestion on implementing a more fine-grained configuration feel free to contribute.

A starting point would be to create a command-line argument that can be supplied multiple times specifying what is interesting. At the location where requests are validated you should check only for those items in the configured set.