Suricata

Conversely, the http.url field is only matching up until the first space resulting in something like:

"http":{"url":"/uid=0(root)"}

which leads me to believe those fields are created by splitting the line by spaces.

I think uri's are not supposed to have spaces, but I think it would be good to address this anyway.

Thanks Chris.
Indeed, Uris are not supposed to have spaces, but the protocol field is even less supposed to have spaces.
So I think we can take the last space in the request line as the uri end, instead of the second one.

https://github.com/OISF/suricata/pull/5599 for 6.0.1

For 7 :
changing the handling in 7 would be good, but I'm not sure it should be optional.

https://github.com/OISF/suricata/pull/5614 merged for 6.0.1

Still work to do for 7

https://github.com/OISF/suricata/pull/6884 is latest PR to review

https://github.com/OISF/suricata/pull/8509 currently

Thanks @Brandon Murphy for this report.

Would not the solution rather be to consider the URI before the last block of spaces ? (even the raw one)

Otherwise, SCHTPGenerateNormalizedUri needs to add this normalization step (stripping spaces on the right)

Would not the solution rather be to consider the URI before the last block of spaces ? (even the raw one)

When inconstancies or typos like a double space occur in malicious network traffic, we often use them when creating a rule. The ability to write signatures which can make use of these typos, such as the use of the double space, can provide for good fast_patterns in a rule, along with a low FP rate and the ability to very confidently attribute the traffic to a specific malware family/actor, etc.

I'm not sure where/how the best place to allow that to occur is (if not http.uri.raw). Perhaps http.start is the answer here? Based on https://github.com/OISF/suricata/pull/8869 it appears to have not been selected for "overloading" so that limits our use of http.start

When inconstancies or typos like a double space occur in malicious network traffic, we often use them when creating a rule.

Indeed

Could http.request_line be used in this case ?