Feature request : Filter for (response size - payload size)

[Aetiuss]

Hello there,

Thanks for the amazing work,

My request would be to implement a filter (and a result property, named for example "relative size") to sort out behavior when payloads are simply reflected in the HTTP response from payloads that cause an unexpected behavior from the server and thus an strange response with a size different from "generic" relative size (response size minus payload size,

Of course this feature would be a bit niche (but very useful for fuzzing code injection vulns with a payload directly reflected on the page when not working).

[bsysop]

Are you referring to calculating the size of the fuzzed keyword and then normalizing the response size?

Normal response size (example): 200 bytes
Normalized Response Size = Response Size - Keywords Size

Example:

• For keyword 'ABC' (3 bytes): 200 bytes - 3 bytes = 197 bytes
• For keyword 'ABC123' (6 bytes): 200 bytes - 6 bytes = 194 bytes

If a keyword appears multiple times, subtract its size for each occurrence.

This approach makes sense; however, a significant issue arises when fuzzing common keywords that are always present, such as 'img', 'a', and 'title'.

There are also concerns with other keywords or additional terms that were not introduced by the keyword you are fuzzing but were already present in the response.

Performing a pre-flight request and storing the response might address this issue, but it could significantly impact the fuzzing speed as well as CPU and memory usage since you need to calculate sizes and pre-stored keywords.

Is this what you meant?

[Aetiuss]

Thank you for the answer,

Yes that's exactly what I meant,

I my mind you would only do "response size (R) - keyword size (W) = normalized response size (N)"
(ie W could be computed when loading the keyword from the wordlist) and return N inside the result table as a new column,

Users could then use filters on N to find outlier values which could indicate a server weird behavior/malfunction/vuln,

Like this you don't need to parse the words inside the response and compare them to a preflight response,

This "static" approach has its drawbacks because it assumes the server will only reflect the keyword once in the majority of responses but it would need a lot less resources and would be quite easier to implement,

For an "upgrade" of this feature you would have multiple options for a more dynamic behavior:

• Use preflight queries for every request (very resource intensive)
• Use preflight queries only on a sample of requests to calibrate a function that would determine the relation between W and R (better but that doesn't seems trivial)
• Let the user specify the relation between W and R when launching the FFUF command line (ie with a flag --response-normalized 2W (=response length - keyword length * 2) or even better with a static part --response-normalized 2W-10 (=response length - keyword length * 2 - 10) or --response-normalized 2W+10 (=response length - keyword length * 2 + 10)

For me the last one is the best option but I think I am getting ahead of myself and implementing the "static" behavior with an additional result column and filters would already be very cool !

[joohoi]

A well defined request, but I’m going to throw in a curve ball; did you know you can use the keyword in regex filter? To accomplish same result you could have a regex filter with something like "<p>FUZZ</p>”

…

On Sun 28. Apr 2024 at 11.44, Aetiuss ***@***.***> wrote: Thank you for the answer, Yes that's exactly what I mean, I don't understand issues you are mentioning though, I my mind you would only do "response size (R) - keyword size (W) = normalized response size (N) "(W could be computed when loading the keyword from the wordlist) and return N inside the result table as a new column, Users could then also use filters on N to find outlier values which could indicate a server weird behavior/malfunction/vuln, Like this you don't need to parse the words inside the response and compare them to a preflight response, This "static" approach has its drawbacks because it assumes the server will only reflect the keyword once in the majority of responses but it would need a lot less resources and would be quite easier to implement, For an "upgrade" of this feature you would have multiple options for a more dynamic behavior: - Use preflight queries for every request (very resource intensive) - Use preflight queries only on a sample of requests to calibrate a function that would determine the relation between K and R (better but that doesn't seems trivial) - Let the user specify the relation between K and R when launching the FFUF command line (ie with a flag "--response-normalized 2W" (=response length - keyword length * 2) or even better with a static part "--response-normalized 2W-10" (=response length - keyword length * 2 - 10) or "--response-normalized 2W+10" (=response length - keyword length * 2 + 10) For me the last one is the best option but I think I am getting ahead of myself and implementing the "static" behavior with an additional result column and filters would already be very cool ! — Reply to this email directly, view it on GitHub <#779 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABH6DJPFYBE2HMZQS5PMICDY7SZF7AVCNFSM6AAAAABG3PJKVCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOBRGM4TIOBRGM> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[Aetiuss]

It's no curveball but the contrary if the feature I want already exists haha,

Though I am sorry if I don't understand but here I don't ask for the occurrence of the keyword inside the response,

What I am trying to do is find inconsistencies in the server behavior by looking at the repartition of the responses lengths compared to the keyword length,

For 3 responses with the keyword inside : 2 could only reflect it and the third could reflect it with additional characters showing the server may have interpreted an OS command for example,

That is why looking at the lengths of those elements is interesting,

Maybe I am missing your point and there is a way to do regex with the individual sizes of responses and keywords ?

[joohoi]

Thanks for clearing that up. I do see the value, and it might get added in the future.