Skip to content

REQUEST_FILENAME variable is not getting correctly set #2853

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

Closed
PrajwalKrishna opened this issue Dec 30, 2022 · 3 comments
Closed

REQUEST_FILENAME variable is not getting correctly set #2853

PrajwalKrishna opened this issue Dec 30, 2022 · 3 comments
Labels
3.x Related to ModSecurity version 3.x

Comments

@PrajwalKrishna
Copy link

Describe the bug

REQUEST_FILENAME variable is not getting correctly set in Transaction::processURI()

To Reproduce

Steps to reproduce the behavior:

  1. Create a new Transaction variable, define in transaction.h
  2. Call Transaction::processURI("https://fruits.com/mango/apple.txt", "GET", 2.0)
  3. Print the value of Transaction::m_variableRequestFilename::m_value

We are get the value as https://fruits.com/mango/apple.txt, instead of /mango/apple.txt.

Expected behavior

REQUEST_FILENAME variable to be the relative path of the file (without domain name). This can be seen in the definition of the variable as per docs - https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-(v2.x)#request_filename.

Additional context

Solving this issue should be pretty simple, we do later parse the URI to remove the domain information, we should use the parsed URI. Happy to put up the fix, if this indeed is a bug.

@martinhsv
Copy link
Contributor

Hello @PrajwalKrishna ,

Do you have a use case where REQUEST_FILENAME includes the domain when running with nginx and the Connector (ModSecurity-nginx)?

@PrajwalKrishna
Copy link
Author

Hey @martinhsv my use-case is more general where I use it as an edge firewall, I see some false positive when using core-rule sets which can be resolved if the domain name was not there.

@marcstern marcstern added the 3.x Related to ModSecurity version 3.x label Jan 26, 2024
@PrajwalKrishna
Copy link
Author

Bug is fixed in the by - #3048

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

No branches or pull requests

3 participants