Skip to content

Conversation

@catenacyber
Copy link
Contributor

This is not ready yet and needs more testing.

The point of this PR is for libhtp to handle requests/responses ending and beginning in the middle of network provided chunks.
That is the added test case 97-requests-cut.t and 98

So htp_connp_REQ_FINALIZE probes a whole request line to say if we handle it as body or a new request, unless the connection is closed, in which case we complete the request.

Several test cases result change :

  • adding a line return to 91-request-unexpected-body.t so that the probing can restart at the new request
  • EmptyLineBetweenRequests : we do not have any longer tx->request_ignored_lines == 1 as the ignored line is now part of the previous request body
  • LongResponseHeader as the test framework directly returns on error before closing the connection, we do not make it to tx->request_progress == HTP_REQUEST_COMPLETE. Should we rather change the test framework ?
    cf https://github.com/OISF/libhtp/blob/0.5.x/test/test.c#L357 versus https://github.com/OISF/libhtp/blob/0.5.x/test/test.c#L417

See https://redmine.openinfosecfoundation.org/issues/2655 for the latest changes to htp_connp_REQ_FINALIZE

Follows #270 by fixing same bug for responses and using HTTP/1.1 for real test case with pipelining

The problem fixed here comes with multiple requests in the
same session, when the second (or later) request is split over
multiple chunks, and more precisely when the HTTP method in the
request line gets splitted over multiple chunks.

In this case, htp_connp_REQ_FINALIZE probed to recongize a known
HTTP method, and failed, as for instance it only analyzed "GE"
when the final T for "GET" is in the next chunk.

The logic is now to peek enough data to have a full request line.
This way, we can decide if this input is the beginning of a new
request, or if it is the junk body of the previous one.
@victorjulien
Copy link
Member

Does this address #270 (comment) as well?

@victorjulien
Copy link
Member

Not sure. Can you create a pcap based test (SV test) to see how this affects logging/matching in Suricata?

@catenacyber
Copy link
Contributor Author

Does this address #270 (comment) as well?

No but #273 does

LongResponseHeader : Can you create a pcap based test (SV test) to see how this affects logging/matching in Suricata?

I will with #269

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

2 participants