Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

POST (multipart) arguments are skipped when field name is not in quotes #164

Open
i-rinat opened this issue Apr 5, 2018 · 9 comments
Open
Assignees

Comments

@i-rinat
Copy link

i-rinat commented Apr 5, 2018

Multipart/form-data messages have field name listed in Content-Disposition header field. It's something like name="field1". Libhtp parses such messages just fine. However, at least some platforms also accept name=field1, without double quotes (for example, Apache/PHP). Libhtp skips such parameters.

Steps to reproduce:

  1. Change test with the following patch:
diff --git a/test/files/17-multipart-1.t b/test/files/17-multipart-1.t
index 7c083c6..5fface7 100644
--- a/test/files/17-multipart-1.t
+++ b/test/files/17-multipart-1.t
@@ -16,7 +16,7 @@ Content-Disposition: form-data; name="field1"
 
 0123456789
 -----------------------------41184676334
-Content-Disposition: form-data; name="field2"
+Content-Disposition: form-data;   name=field2
 
 9876543210
 -----------------------------41184676334

(additional spaces were added to keep content length the same. They are not significant for the issue.)

  1. Run tests (make test)

Expected results:

Test succeeds.

Actual results:

Test fails.

@victorjulien victorjulien self-assigned this Apr 11, 2018
@victorjulien
Copy link
Member

I will have a look, thanks.

@catenacyber
Copy link
Contributor

Is this still an issue ?

@i-rinat
Copy link
Author

i-rinat commented Apr 25, 2022

Is this still an issue?

The test still fails.

@catenacyber
Copy link
Contributor

How are you using libhtp ? With Suricata ?

@i-rinat
Copy link
Author

i-rinat commented Apr 25, 2022

Oh, so you were asking if that's still an issue for me specifically? If so, then I need to say that I don't use libhtp at the moment. This parsing peculiarity surfaced up when I was evaluating libhtp as a replacement for an in-house security oriented HTTP parser. I don't work on that project anymore, and don't know if they use libhtp or have any code based on libhtp.

@catenacyber
Copy link
Contributor

May be still an issue, but likely not for Suricata's usage

@i-rinat
Copy link
Author

i-rinat commented Apr 7, 2023

but likely not for Suricata's usage

This is a potential bypass vector. Combined with HTTP Parameter Pollution this may be used to feed some innocent parameter values to detectors in Suricata, but allow to pass malicious payloads to the protected application.

@catenacyber
Copy link
Contributor

This is a potential bypass vector.

Yes, but Suricata does not use libhtp multipart code, and has its own (which had similar bugs fixed recently)

@i-rinat
Copy link
Author

i-rinat commented Dec 22, 2023

Suricata does not use libhtp multipart code

Oh... okay.

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

No branches or pull requests

3 participants