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

SecRuleScript actions always considered disruptive #3108

Open
theseion opened this issue Mar 16, 2024 · 1 comment
Open

SecRuleScript actions always considered disruptive #3108

theseion opened this issue Mar 16, 2024 · 1 comment
Assignees
Labels
3.x Related to ModSecurity version 3.x bug It is a confirmed bug

Comments

@theseion
Copy link

The following block triggers an error in v3 (nginx):

SecRule REQUEST_FILENAME "@unconditionalMatch" \
  "id:888888,\
  phase:1\
  chain"
  SecRuleScript test.lua "nolog"

The error is:

nginx: [emerg] "modsecurity_rules_file" directive Disruptive actions can only be specified by chain starter rules. in /usr/local/nginx/conf/conf.d/npm.conf:13
nginx: configuration file /usr/local/nginx/conf/nginx.conf test failed

To Reproduce

  1. Lua must be enabled for ModSecurity
  2. Use the rule block above
  3. Create a Lua script file like the following, named "test.lua":
function main()
    return nil;
end
  1. Put the Lua script into the same directory as the rule file
  2. Start / reload nginx

Expected behavior

nolog is not a disruptive action in the source code and should not trigger the error. The reason we even noticed this behaviour is, that the documentation says that actions are optional for SecRuleScript but the parser cannot cope with such a rule and will throw an error while parsing the next rule, because it thinks that the end of the last rule wasn't reached.

Full discussion: coreruleset/body-decompress-plugin#4.

Server

  • ModSecurity version (and connector): v3.0.12; connector v1.0.3
  • WebServer: nginx 1.25.3
  • OS (and distro): Debian Linux

** Additional context**

The actions list of SecRuleScript is currently mandatory, even though the documentation says it isn't. However, the parser throws an error while parsing the next rule, instead of complaining about the missing actions list. This is very confusing to users.

@theseion theseion added the 3.x Related to ModSecurity version 3.x label Mar 16, 2024
@airween airween self-assigned this Mar 16, 2024
@airween airween added the bug It is a confirmed bug label Mar 16, 2024
@airween
Copy link
Member

airween commented Mar 16, 2024

Hi @theseion,

thanks for reporting. I can confirm this is a bug.

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 bug It is a confirmed bug
Projects
None yet
Development

No branches or pull requests

2 participants