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

Allow REQUEST_BODY to be populated for an unparsable request body type #160

Closed
rcbarnett-zz opened this issue Oct 17, 2013 · 8 comments
Closed
Assignees

Comments

@rcbarnett-zz
Copy link
Contributor

MODSEC-6: REQUEST_BODY is only populated for known parseable types. But sometimes we may need access to this target for content types we know nothing about. Right now, you can set ctl:requestBodyProcessor=URLENCODED and REQUEST_BODY may be used, but there will be warnings/errors parsing the protocol.

There needs to be a way to force buffering the request so that REQUEST_BODY can be used without attempting to parse.

@rcbarnett-zz
Copy link
Contributor Author

Original reporter: brectanus

@ghost ghost assigned zimmerle Oct 17, 2013
@rcbarnett-zz
Copy link
Contributor Author

brectanus: Changeset: 1185

@rcbarnett-zz
Copy link
Contributor Author

ivanr: The code is all right, but I don't think the name of the ctl option is adequate, especially in the light of MODSEC-17. There are two different features here: one is request buffering from an external point of view, and the other is the same but from the internal point of view. I think most users would take request buffering to refer to the former. For example, ModSecurity 2.5.6 always buffers requests, but what we are adding with this ticket is having request data in a continuous buffer.

Being practical, I think we should only change the name of the directive at this point to, say, haveRequestBodyVariable, purely from the perspective that this feature is going to be used by 2.5.x users to inspect traffic that they wouldn't otherwise be able to inspect.

@rcbarnett-zz
Copy link
Contributor Author

brectanus: I agree, but I am not sure that haveRequestBodyVariable makes much sense to the user either. What we are doing is forcing the creation and allowing use of REQUEST_BODY. Some other choices:

  • setRequestBodyVariable
  • forceRequestBodyVariable
  • allowRequestBodyVariable

Any preference?

@rcbarnett-zz
Copy link
Contributor Author

ivanr: I think forceRequestBodyVariable is the best choice.

@rcbarnett-zz
Copy link
Contributor Author

brectanus: Ivan,

I am just waiting a review on this before closing.

Thanks,
-B

@rcbarnett-zz
Copy link
Contributor Author

brectanus: The attached patch adds support for ctl:requestBodyBuffering=on|off to force request body buffering in memory and populating REQUEST_BODY.

@rcbarnett-zz
Copy link
Contributor Author

brectanus: Changed in #1201.

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

No branches or pull requests

2 participants