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

Fix FILES_TMP_CONTENT collection key naming mechanism #2831

Merged

Conversation

airween
Copy link
Member

@airween airween commented Nov 14, 2022

It seems that in v3 the FILES_TMP_CONTENT collection key names get wrong value: it's the name of the user's file, not the name of the multipart part's name.

The documentation is a bit poor both in v2 and v3, none of them mentioned the keys.

I just realized this behavior when I tested a rule, where I wanted to inspect a specified field in multipart request.

For eg. take a look to the v3's relevant regression test:

        "----------------------------756b6d74fa1a8ee2",
        "Content-Disposition: form-data; name=\"filedata\"; filename=\"small_text_file1.txt\"",
        "Content-Type: text/plain",
        "",
        "This is a very small test file..",

The test uses this rule:

        SecRule FILES_TMP_CONTENT:small_text_file1.txt "small" "id:1,phase:3,pass,t:trim,msg:'s'"

In ModSecurity v2, this example works with FILES_TMP_CONTENT:filedata. Btw I think using the file name specified by the user as keys makes no sense.

@martinhsv
Copy link
Contributor

Hi @airween. Thanks for that finding and the PR.

I agree. Although superficially one could argue that either the "name" or the "filename" could be a reasonable key for the file content, in practice the part "name" is almost always going to be the more meaningful from an application protection perspective.

@martinhsv martinhsv merged commit 40f7a50 into owasp-modsecurity:v3/master Nov 19, 2022
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

Successfully merging this pull request may close these issues.

2 participants