mitigations.md

Mitigation Strategies Analysis for openresty/lua-nginx-module

Mitigation Strategy: LuaJIT Sandboxing and lua-nginx-module Directives

• Mitigation Strategy: Configure lua-nginx-module directives and LuaJIT settings to enforce a strict sandbox.

• Description:

  1. lua_package_path and lua_package_cpath:
     • Within your Nginx configuration (e.g., nginx.conf, or included files), set these directives to absolute paths pointing to a dedicated, read-only directory containing only the necessary, vetted Lua modules. Never use relative paths. Example:

       lua_package_path '/opt/my_app/lua/?.lua;;';
       lua_package_cpath '/opt/my_app/lua/?.so;;';

     • Ensure the directory (e.g., /opt/my_app/lua/) has appropriate permissions (read-only for the Nginx worker user).
  2. lua_code_cache:
     • During development: lua_code_cache off;
     • In production: lua_code_cache on; Must be combined with a deployment process that clears the Nginx cache on Lua code updates (e.g., nginx -s reload).
  3. Timeouts (Directives):
     • Use these lua-nginx-module directives to set timeouts for various operations:
       • lua_socket_connect_timeout: Timeout for establishing socket connections.
       • lua_socket_send_timeout: Timeout for sending data over a socket.
       • lua_socket_read_timeout: Timeout for receiving data over a socket.
       • lua_socket_keepalive_timeout: Timeout for idle keep-alive connections.
       • lua_regex_match_limit: Limit the number of steps the regex engine can take.
       • lua_regex_cache_max_entries: Limit the size of the regex cache.
     • Set reasonable values for these timeouts (e.g., a few seconds) based on your application's needs.

• Threats Mitigated:

  • Unauthorized Resource Access (Medium to High Severity): Restricting package.path and package.cpath prevents Lua scripts from loading unauthorized modules, which could be used to access system resources or execute malicious code.
  • Denial of Service (DoS) (High Severity): Timeouts prevent Lua scripts from hanging indefinitely on network operations or regular expressions, which could lead to resource exhaustion.
  • Code Injection (via cached code) (High Severity): Proper lua_code_cache management prevents attackers from exploiting vulnerabilities in older, cached versions of Lua code.
  • Regular Expression Denial of Service (ReDoS) (Medium Severity): lua_regex_match_limit mitigates ReDoS.

• Impact:

  • Unauthorized Resource Access: Significantly reduces the risk of Lua scripts accessing unauthorized resources.
  • DoS: Reduces the risk of DoS attacks caused by long-running or hanging Lua scripts.
  • Code Injection: Eliminates the risk of exploiting cached, vulnerable code.
  • ReDoS: Prevents attackers from crafting regular expressions that cause excessive CPU usage.

• Currently Implemented:

  • Likely Partially Implemented: Some projects may have basic timeout settings. lua_code_cache is often set to on in production.
  • Location: Check nginx.conf and any included configuration files.

• Missing Implementation:

  • Likely Missing: Strict control of lua_package_path and lua_package_cpath, comprehensive timeout configurations (for all relevant directives), and a robust cache-clearing mechanism on code updates are often overlooked.
  • Location: Review the Nginx configuration files.

Mitigation Strategy: Controlled ffi Usage (Within Lua Code, Managed by lua-nginx-module)

• Mitigation Strategy: Minimize and strictly control the use of LuaJIT's ffi library within Lua code executed by lua-nginx-module.

• Description:

  1. Minimize ffi: Avoid ffi if possible. Use Lua libraries or lua-resty-* libraries instead.
  2. Strict Input Validation (for ffi calls): If ffi must be used, implement extremely rigorous input validation within the Lua code for any data passed to C functions. This is before the data reaches the C code.
     • Use Lua's type checking (type()) and length constraints to ensure data validity.
  3. Code Review (Focused on ffi): Any Lua code using ffi should be subject to intense code review, with a focus on the data passed to C functions and the potential for vulnerabilities in the C code.

• Threats Mitigated:

  • Arbitrary Code Execution (Critical Severity): Vulnerabilities in C functions called via ffi (e.g., buffer overflows) can lead to arbitrary code execution. Lua-side input validation helps prevent these.
  • Privilege Escalation (High Severity): If the C function has access to higher privileges, a vulnerability could be exploited to gain those privileges.

• Impact:

  • Arbitrary Code Execution: Minimizing ffi and implementing strict Lua-side input validation significantly reduces the risk.
  • Privilege Escalation: Reduces the potential for attackers to gain higher privileges.

• Currently Implemented:

  • Likely Partially Implemented: Some projects may avoid ffi altogether. Others may use it with some basic input validation.
  • Location: Search the Lua code for ffi.cdef and ffi.new.

• Missing Implementation:

  • Likely Missing: Comprehensive, Lua-side input validation specifically tailored to the C functions being called is often missing.
  • Location: Review all instances of ffi usage in the Lua code.

Mitigation Strategy: Safe External Interaction Libraries (Using lua-resty-* within Lua)

• Mitigation Strategy: Utilize the lua-resty-* libraries provided for lua-nginx-module for safe interaction with external resources.

• Description:

  1. Prefer lua-resty-* Libraries: Instead of using generic Lua libraries or attempting to roll your own solutions, use the lua-resty-* libraries (e.g., lua-resty-http, lua-resty-mysql, lua-resty-redis, lua-resty-memcached) for interacting with external services. These libraries are specifically designed for use within lua-nginx-module and are generally more secure and performant.
  2. Use Parameterized Queries: When interacting with databases (e.g., using lua-resty-mysql), always use parameterized queries or prepared statements to prevent SQL injection vulnerabilities. The lua-resty-* libraries typically provide mechanisms for this.
  3. Keep Libraries Updated: Ensure that you are using the latest versions of the lua-resty-* libraries to benefit from security patches and bug fixes.

• Threats Mitigated:

  • SQL Injection (High Severity): Using parameterized queries in lua-resty-mysql (or similar libraries) prevents SQL injection.
  • Other Injection Attacks (Medium to High Severity): Using safe libraries for other external services (HTTP, Redis, etc.) prevents various injection vulnerabilities specific to those services.
  • Denial of Service (DoS) (Medium Severity): lua-resty-* libraries often have built-in timeout and connection pooling mechanisms, which can help prevent DoS attacks.

• Impact:

  • Injection Attacks: Significantly reduces the risk of various injection attacks by using safe, purpose-built libraries.
  • DoS: Improves resilience to DoS attacks.

• Currently Implemented:

  • Likely Partially Implemented: Many projects will use some lua-resty-* libraries.
  • Location: Check the Lua code for imports and usage of lua-resty-* libraries.

• Missing Implementation:

  • Likely Missing: Consistent use of lua-resty-* libraries for all external interactions, and ensuring they are kept up-to-date, are often areas for improvement.
  • Location: Review all Lua code that interacts with external resources.

Mitigation Strategy: Secure Logging with ngx.log (Within Lua Code)

• Mitigation Strategy: Use ngx.log within your Lua code to securely log security-relevant events to the Nginx error log.

• Description:

  1. Use ngx.log: Within your Lua scripts, use the ngx.log function to write log messages. This ensures that log entries are properly handled by Nginx's logging infrastructure. Example:

     ngx.log(ngx.ERR, "Error: Invalid input received from ", ngx.var.remote_addr)

  2. Log Security-Relevant Events: Log errors, unexpected behavior, access to sensitive resources, input validation failures, and any other events that could indicate a security issue.
  3. Include Context: Include relevant context in log messages, such as user IDs, request IDs, timestamps, and IP addresses.
  4. Avoid Sensitive Data: Do not log sensitive data, such as passwords, API keys, or personally identifiable information (PII), directly in the logs.

• Threats Mitigated:

  • All Attacks (Variable Severity): Logging provides visibility into attacks, allowing for detection and response. It doesn't prevent attacks, but it's crucial for incident response.

• Impact:

  • Detection and Response: Improves your ability to detect and respond to attacks quickly.

• Currently Implemented:

  • Likely Partially Implemented: Some projects may use ngx.log for basic error logging.
  • Location: Check the Lua code for ngx.log calls.

• Missing Implementation:

  • Likely Missing: Comprehensive logging of security-relevant events, including sufficient context, and avoiding logging sensitive data are often areas for improvement.
  • Location: Review all Lua code and ensure that ngx.log is used appropriately.