topic Malformed HTTP Request 5769.0 in Network Security

Malformed HTTP Request 5769.0

m-hansson — Sun, 10 Mar 2019 10:09:15 GMT

Should this signature trigger for:

GET /\r\n

I thought it should trigger for something like:

GET /\rHTTP/1.1\r\n\r\n

Re: Malformed HTTP Request 5769.0

jlimbo — Tue, 08 Aug 2006 07:35:26 GMT

It will trigger on both, as you do not normally see the \r\n in the actual stream but as a terminating character of the request. The first example looks like it has \r\n before you see HTTP version, hence you would assume that the \r\n is premature in the stream.

I hope that helps.

-jonathan

Re: Malformed HTTP Request 5769.0

m-hansson — Tue, 08 Aug 2006 07:47:16 GMT

Thanks.

No this is actually the entire request. Should not trigger in my opinion. Let me guess, you will tell me that is does not follow RFC standards? 😉

Re: Malformed HTTP Request 5769.0

wsulym — Tue, 08 Aug 2006 13:29:14 GMT

HTTP clients *should* send http version information with the exception of HTTP/0.9, which did not include version numbers. RFC 2145 further clarifies the http specification author's intents. HTTP clients adhering to the robusteness principle and RFC 2145, and that are not http/0.9 clients should really have the version information there. I'll agree, it's not a *must*, but its normally there.

Adding a carriage return prior to the http version was also a way to evade Snort's uricontent rules.

I would consider a CR before the http version non standard, you might not, maybe we just agree to disagree on that point. In any case, I'll update the benign triggers section of the alert.

Re: Malformed HTTP Request 5769.0

m-hansson — Tue, 08 Aug 2006 14:01:43 GMT

Thanks Walter.

Once again I want to push for splitting this kind of signature into one that deals with the vulnerability and one with protocol abnormalies.

I'd really like to have this signature enabled because of the snort issue, but with the current amoumt of FP it is not an option.