Pros of ModSecurity

• More comprehensive and feature-rich WAF solution
• Supports multiple web servers (Apache, Nginx, IIS)
• Larger community and more extensive rule sets available

Cons of ModSecurity

• More complex configuration and setup process
• Higher resource consumption
• Steeper learning curve for beginners

Code Comparison

ModSecurity rule example:

SecRule REQUEST_HEADERS:User-Agent "nikto" \
    "id:1000,\
    phase:1,\
    deny,\
    log,\
    msg:'Nikto Scan Detected'"

Naxsi rule example:

MainRule "str:nikto" "msg:Nikto Scan Detected" "mz:$HEADERS_VAR:User-Agent" "s:$UWA:8" id:1000;

Both examples show rules to detect and block Nikto scans based on the User-Agent header. ModSecurity's rule is more verbose and offers more configuration options, while Naxsi's rule is more concise and easier to read at a glance.

ModSecurity provides a more powerful and flexible WAF solution with broader server support, but it comes at the cost of increased complexity and resource usage. Naxsi, on the other hand, offers a simpler, lightweight alternative that's easier to set up and manage, particularly for Nginx users, but with fewer features and a smaller community compared to ModSecurity.

Pros of coreruleset

• More comprehensive and regularly updated rule set
• Broader community support and contributions
• Better documentation and integration guides

Cons of coreruleset

• Higher complexity and potential for false positives
• Requires more fine-tuning and customization
• Steeper learning curve for implementation

Code Comparison

NAXSI rule example:

MainRule "str:select" "msg:sql keywords" "mz:BODY|URL|ARGS|$HEADERS_VAR:Cookie" "s:$SQL:4" id:1000;

CoreRuleSet rule example:

SecRule REQUEST_COOKIES|!REQUEST_COOKIES:/__utm/|REQUEST_COOKIES_NAMES|REQUEST_HEADERS:User-Agent|REQUEST_HEADERS:Referer|ARGS_NAMES|ARGS|XML:/* "@rx (?i:select.+?(?:from|into))" \
    "id:942100,\
    phase:2,\
    block,\
    capture,\
    t:none,t:urlDecodeUni,\
    msg:'SQL Injection Attack Detected via libinjection',\
    logdata:'Matched Data: %{TX.0} found within %{MATCHED_VAR_NAME}: %{MATCHED_VAR}',\
    tag:'application-multi',\
    tag:'language-multi',\
    tag:'platform-multi',\
    tag:'attack-sqli',\
    tag:'OWASP_CRS',\
    tag:'OWASP_CRS/WEB_ATTACK/SQL_INJECTION',\
    tag:'WASCTC/WASC-19',\
    tag:'OWASP_TOP_10/A1',\
    tag:'OWASP_AppSensor/CIE1',\
    tag:'PCI/6.5.2',\
    ver:'OWASP_CRS/3.2.0',\
    severity:'CRITICAL',\
    setvar:'tx.sql_injection_score=+%{tx.critical_anomaly_score}',\
    setvar:'tx.anomaly_score_pl1=+%{tx.critical_anomaly_score}'"

Pros of lua-resty-waf

• Written in Lua, offering better performance and flexibility
• Integrates seamlessly with OpenResty and NGINX
• Provides more granular control over rule sets and configurations

Cons of lua-resty-waf

• Requires OpenResty, which may not be suitable for all environments
• Less mature and potentially less battle-tested than Naxsi
• Smaller community and fewer pre-built rule sets available

Code Comparison

lua-resty-waf:

local waf = require "resty.waf"
local waf_instance = waf:new()
waf_instance:exec()

Naxsi:

location / {
    SecRulesEnabled;
    DeniedUrl "/RequestDenied";
    CheckRule "$SQL >= 8" BLOCK;
}

The lua-resty-waf example shows how to initialize and execute the WAF in Lua, while the Naxsi example demonstrates configuration directly in the NGINX configuration file. lua-resty-waf offers more programmatic control, whereas Naxsi provides a simpler, declarative approach.

Both projects aim to provide web application firewall functionality, but they differ in implementation and integration methods. lua-resty-waf is more flexible and performant but requires OpenResty, while Naxsi is more straightforward to set up but may be less customizable.