Misunderstood URIPATHPARAM in scenario?

crowdsec
1

Hello all,
i wrote a parser for a special log type expand from haproxy. example of (simplified) log :

Dec 1 11:22:16 localhost haproxy[10728]: [vhost=ultv.example.fr] [query=GET /jsi18n/ HTTP/1.1]

The GROK parser contains (very simplified here ):

grok:
  pattern: '%{DATA:time} localhost haproxy\[%{INT:process}\]: \[vhost=%{IPORHOST:vhost}\] \[query=%{WORD:verb} %{URIPATHPARAM:http_request} HTTP/%{NUMBER:http_version}\]'

I can run the explain command and it recognize well when the http_request is under this form :

# cscli explain --log 'Dec  1 11:10:27 localhost haproxy[10728]: [vhost=ultv.example.fr] [query=GET /index.php/etc/passwd HTTP/1.1]' --type haproxy -v

But when i use this format (slighly different) :

# cscli explain --log 'Dec  1 11:10:27 localhost haproxy[10728]: [vhost=ultv.example.fr] [query=GET /index.php\?act\=/etc/passwd%00\&id\=3366 HTTP/1.1]' --type haproxy -v

The filter scenario match only on :
filter: evt.Parsed.http_request contains '/etc/passwd'

I don’t understand why in case 1 the scenario match, and why in the second case, it didn’t. In the 2 cases it seems that evt.parsed.http_request “contains” ‘/etc/passwd’ no ?

Can i use another thing that URIPATHPARAM in such scenario ? Because maybe i misundertood URIPATHPARAM …
Thank you.
V.

2

In most parsers we use data you can see a debugger here

3

Great @iiAmLoz !
So yes URIPATHPARAM did not works as expected !
I understand you use %DATA and the 2 cases works.
Thank you again.
.