Project

General

Profile

Actions

Bug #6779

open

http.header_names behavior when encountering duplicate header names

Added by Brandon Murphy 2 months ago. Updated 3 days ago.

Status:
New
Priority:
Normal
Assignee:
Target version:
Affected Versions:
Effort:
Difficulty:
Label:

Description

Recreation and Context:

Consider the attached pcap which contains the following HTTP Request. Take note of the double, though cased differently Content-Type headers.

POST /foo.php HTTP/1.1
Host: foobar.com
Content-Type: text/html
User-Agent: GoogleBot
Content-type: image/gif
Content-Length: 17

user=foo&pass=bar

Current Behavior:

Based on analysis (by adding new debug statements to 7.0.0) the buffer used by http.header_names contains the following

00000000  0d 0a 48 6f 73 74 0d 0a 43 6f 6e 74 65 6e 74 2d  |..Host..Content-|
00000010  54 79 70 65 0d 0a 55 73 65 72 2d 41 67 65 6e 74  |Type..User-Agent|
00000020  0d 0a 43 6f 6e 74 65 6e 74 2d 4c 65 6e 67 74 68  |..Content-Length|
00000030  0d 0a 0d 0a                                      |....|

Notice the lack of a second Content-Type header within this buffer.

For testing, this rule currently fires

alert http any any -> any any (msg:"http.header_names - Missing Second CT"; flow:established,to_server; http.header_names; content:"|0d 0a|Host|0d 0a|Content|2d|Type|0d 0a|User-Agent|0d 0a|Content-Length|0d 0a 0d 0a|"; classtype:command-and-control; sid:3; rev:1;)

Expected Behavior:

Based on documentation for the http.header_names keyword, I expected the second Content-type header to be present within the buffer for http.header_names and that the order of the header names would persist.

I had expected the buffer to contain the following

00000000  0d 0a 48 6f 73 74 0d 0a 43 6f 6e 74 65 6e 74 2d  |..Host..Content-|
00000010  54 79 70 65 0d 0a 55 73 65 72 2d 41 67 65 6e 74  |Type..User-Agent|
00000020  0d 0a 43 6f 6e 74 65 6e 74 2d 74 79 70 65 0d 0a  |..Content-type..|
00000030  43 6f 6e 74 65 6e 74 2d 4c 65 6e 67 74 68 0d 0a  |Content-Length..|
00000040  0d 0a                                            |..|

The expected behavior allows for the following rule to fire

alert http any any -> any any (msg:"http.header_names - Includes Second Type"; flow:established,to_server; http.header_names; content:"|0d 0a|Host|0d 0a|Content|2d|Type|0d 0a|User-Agent|0d 0a|Content-type|0d 0a|Content-Length|0d 0a 0d 0a|"; classtype:command-and-control; sid:4; rev:1;)


Files

11825c7829cba74.pcap (528 Bytes) 11825c7829cba74.pcap Brandon Murphy, 02/13/2024 07:56 PM

Related issues 1 (1 open0 closed)

Related to Suricata - Documentation #5485: userguide: explain that the http.header_names buffer is normalizedNewJason TaylorActions
Actions #1

Updated by Juliana Fajardini Reichow 16 days ago

  • Related to Documentation #5485: userguide: explain that the http.header_names buffer is normalized added
Actions #2

Updated by Jason Taylor 3 days ago

I have the related documentation ticket about making more clear on what normalizations happen to buffer contents. Since what is being described here is expected albeit not clear in the docs, are we looking for a new keyword like http.header_names.raw?

Actions #3

Updated by Brandon Murphy 3 days ago

I would think that there should be some way to detect duplicate header names. but maybe that's just http.header.raw in this case?

Actions

Also available in: Atom PDF