Feature #6290
closedsupport case insensitive testing of HTTP header name existence
Description
Consider the initial opening comment on https://redmine.openinfosecfoundation.org/issues/5774.
Many rules are written with content negations on HTTP header names such as:
http.header_names; content:!"Accept-"; content:!"Referer|0d 0a|";
However, due to HTTP/2 being lowercase header names these content negations fail to provide the desired effect, as they are case sensitive matches.
Yes, we can add nocase to all of these rules, though as discussed within https://redmine.openinfosecfoundation.org/issues/5774, I'm not sure if that is the best option.
One option I did find when looking into supporting Snort 3 is the http_header_test
keyword - https://docs.snort.org/rules/options/payload/http/header_test
# check that the User-Agent field is absent http_header_test:field user-agent,absent;
as per Snort 3's http_header docs, the header name is case insensitive
Snort 3 also allows users the ability to look for content matches in specific HTTP header fields with the optional field header_name argument. This option is specified with a colon character after http_header, followed by the word "field", and lastly followed by the specific header field name (which is case-insensitive).
This request is to introduce a similar capability within Suricata.
Alternatives considered:
1. http.header_names
provides logic to perform the same check while adding the nocase
statement to each content. There are currently 10,000+ rules within the ETPRO ruleset that use the http.header_names
keyword, some of which have multiple content matches/negations against that buffer that would all need updated. Making such a large number of modifications to existing rules is disruptive to our customer base.
Related Issues:
https://redmine.openinfosecfoundation.org/issues/5775 - This feature request stems from a "random thought" I had when talking through.