-
Notifications
You must be signed in to change notification settings - Fork 116
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
Comments
I will have a look, thanks. |
Is this still an issue ? |
The test still fails. |
How are you using libhtp ? With Suricata ? |
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. |
May be still an issue, 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. |
Yes, but Suricata does not use libhtp multipart code, and has its own (which had similar bugs fixed recently) |
Oh... okay. |
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 acceptname=field1
, without double quotes (for example, Apache/PHP). Libhtp skips such parameters.Steps to reproduce:
(additional spaces were added to keep content length the same. They are not significant for the issue.)
make test
)Expected results:
Test succeeds.
Actual results:
Test fails.
The text was updated successfully, but these errors were encountered: