http: new http.form keyword

[catenacyber]

Link to ticket: https://redmine.openinfosecfoundation.org/issues/
https://redmine.openinfosecfoundation.org/issues/2487

Describe changes:

• DRAFT : begins to add http.form keyword

SV_BRANCH=OISF/suricata-verify#2860

Draft: main question is
Do we want a multi-buffer or a single synthetic buffer ?

• single buffer bodyparam1=value1&bodyparam2=value2&uriparam1=uv1&uriparam2=value2
• multi buffer uri and body
  • uriparam1=uv1&uriparam2=value2
  • bodyparam1=value1&bodyparam2
• multi-buffer by key-value pair
  • uriparam1=uv1
  • uriparam2=uv2
  • bodyparam1=value1
  • bodyparam2=value2

[victorjulien]

Draft: main question is Do we want a multi-buffer or a single synthetic buffer ?

* single buffer `bodyparam1=value1&bodyparam2=value2&uriparam1=uv1&uriparam2=value2`

* multi buffer uri and body
  
  * uriparam1=uv1&uriparam2=value2
  * bodyparam1=value1&bodyparam2

* multi-buffer by key-value pair
  
  * uriparam1=uv1
  * uriparam2=uv2
  * bodyparam1=value1
  * bodyparam2=value2

I think there can be uses for each of these, plus more: raw versions w/o the urldecode normalization.

Could also imagine multibuffer only, with a new way to concat multibuffers into a single http.form; concat:"&"; content:"pattern";

Wondering about the keyword name, we've seen other ideas like http.args and http.query.

Some related tickets:
https://redmine.openinfosecfoundation.org/issues/1194
https://redmine.openinfosecfoundation.org/issues/6914

[catenacyber]

I think there can be uses for each of these, plus more: raw versions w/o the urldecode normalization.

Hmmm... I should start with one, as it is complex already

Could also imagine multibuffer only, with a new way to concat multibuffers into a single http.form; concat:"&"; content:"pattern";

Nice, should we create a ticket about it ?

Wondering about the keyword name, we've seen other ideas like http.args and http.query.

form is used in golang and wireshark. Let me know which you prefer

Some related tickets: https://redmine.openinfosecfoundation.org/issues/1194 https://redmine.openinfosecfoundation.org/issues/6914

Yes I saw, I think the 3 tickets are all duplicates

[catenacyber]

I guess I will start with the multi-buffer key-value pairs

[suricata-qa]

WARNING:

field	baseline	test	%
	IPS_AFP_stats_chk
.decoder.unknown_ethertype	6	52	866.67%
.decoder.event.ethernet.unknown_ethertype	6	52	866.67%
	TREX_GENERIC_stats_chk
.decoder.unknown_ethertype	3	24	800.0%
.decoder.event.ethernet.unknown_ethertype	3	24	800.0%

Pipeline = 29146

[catenacyber]

So, I am getting to the difficulty that we want a keyword which acts on 2 different progresses (request_line and request_body)

Solutions I see so far :

• Divide the field progress of DetectEngineAppInspectionEngine into min_progress and max_progress
• Have 2 DetectEngineAppInspectionEngine, one for each progress, and add some link between them, that either must match (not both)

[victorjulien]

Headers register for 2 states as well, for the headers and the trailers states. Perhaps worth a look.

[suricata-qa]

Information: QA ran without warnings.

Pipeline = 29283

[catenacyber]

Headers register for 2 states as well, for the headers and the trailers states. Perhaps worth a look.

So, I looked and it does not work cf SV test OISF/suricata-verify@f35c611

Same signature except for fast_pattern will not trigger if fast_pattern happens before we reach the progress where we have the trailer...

Do you want a ticket about it ?
(also we see twice the same anomaly on same packet in this SV test)

[catenacyber]

Next draft in #14710 with

Divide the field progress of DetectEngineAppInspectionEngine into min_progress and max_progress