Project

General

Profile

Actions

Bug #6479

closed

HTTP/2 - when userinfo is in the :authority pseudo header it breaks http.host

Added by Brandon Murphy 12 months ago. Updated 12 months ago.

Status:
Closed
Priority:
Normal
Target version:
Affected Versions:
Effort:
Difficulty:
Label:

Description

When testing the the normalized http.host field when userinfo is included in the :authority pseudo header, only the username field makes it into the http.host buffer.

Sids 2 and 3 fire on the attached pcap.

alert http any any -> any any (msg:"user info in http.host"; flow:established,to_server; http.host; content:"username|3a|password"; sid:1;)
alert http any any -> any any (msg:"user info in http.host"; flow:established,to_server; http.host; content:"username"; sid:2;)
alert http any any -> any any (msg:"user info in http.host"; flow:established,to_server; http.host; bsize:8; content:"username"; sid:3;)

I shouldn't be trusted to read this, but I think this section of code is extracting anything "up to" the first colon in the authority?

https://github.com/OISF/suricata/blob/c8a7204b159553d338a6294218e696a72efdb4db/rust/src/http2/detect.rs#L617-L624

thus resulting in the "username" value making it to http.host;

Expected Behavior: the userinfo should be removed all together, but left in http.host.raw.


Files

http2_userinfo_in_authority_1.pcap (1.05 KB) http2_userinfo_in_authority_1.pcap Brandon Murphy, 11/09/2023 01:01 PM
Actions #1

Updated by Philippe Antoine 12 months ago

  • Assignee changed from OISF Dev to Philippe Antoine

It is only a problem HTTP2, not HTTP1 right ?

Actions #2

Updated by Philippe Antoine 12 months ago

  • Status changed from New to In Review
Actions #3

Updated by Brandon Murphy 12 months ago

Philippe Antoine wrote in #note-1:

It is only a problem HTTP2, not HTTP1 right ?

I think that is correct, though I've not been success in producing HTTP/1 traffic with the userinfo. Every attempt has resulted in it being converted to an authorization header of some form.

For historical sake (or just to document the rabbit hole I went down for a bit)

This is the PR that resulted in the behavior of the username/password for HTTP/1
https://github.com/OISF/suricata/pull/640

pretty interesting reads in the the PR commit message referencing the emerging-sigs mailing list, archive copies can be found here
https://marc.info/?l=emerging-sigs&m=136154463522478&w=2
https://marc.info/?l=emerging-sigs&m=136179090419574&w=2

Actions #4

Updated by Philippe Antoine 12 months ago

  • Status changed from In Review to Closed
  • Target version changed from TBD to 7.0.3

https://github.com/OISF/suricata/pull/9763

Not sure if it deserves a backport

Actions #5

Updated by Philippe Antoine 12 months ago

  • Affected Versions 7.0.2 added
  • Affected Versions deleted (7.0.3)
Actions

Also available in: Atom PDF