1. Introduction
Node-config is a Node.js module used for managing application configurations. It allows developers to define settings in separate files, which can be useful but also introduces a security risk if these configuration files are exposed. An attacker gaining access to these files could potentially read sensitive information like passwords and API keys, compromising confidentiality. This affects web applications using the Node-config module, particularly those deployed without proper file permissions or with publicly accessible config directories.
2. Technical Explanation
The vulnerability occurs when Node-config configuration files are deployed alongside an application and are directly accessible via a web server. An attacker can request these files through standard HTTP/HTTPS requests, potentially revealing sensitive data stored within them. The main root cause is improper file permissions or directory configurations that allow public access to the ‘config’ directory (or any custom location where config files are stored).
- Root cause: publicly accessible configuration files due to incorrect server settings.
- Exploit mechanism: An attacker sends an HTTP request to the URL of a configuration file, such as
/config/database.jsonor similar. If access is permitted, the file contents are returned in the response. For example, if a config file contains database credentials, these will be exposed. - Scope: Node.js applications using versions of the node-config module where configuration files are not adequately protected.
3. Detection and Assessment
You can check for this vulnerability by verifying whether configuration files are accessible through a web browser or command line tool. A thorough assessment involves scanning your application’s deployed directories for config files and checking their permissions.
- Quick checks: Use a web browser to attempt access to common config file locations like
/config/default.json,/config/production.jsonor any custom directory you know is used. - Scanning: Nessus plugin ID 16753 and OpenVAS scan script node-config_detect can identify exposed configuration files. These are examples only; results should be verified manually.
- Logs and evidence: Check web server access logs for requests to the ‘config’ directory or any custom config file locations. Look for HTTP status codes 200 (OK) indicating successful retrieval of these files.
curl -I https://your-application.com/config/default.json4. Solution / Remediation Steps
The primary solution is to ensure that Node-config configuration files are not deployed with the application or, if they must be present, are not accessible through a web server. This involves setting appropriate file permissions and directory access controls. If credentials have been exposed, revoke and reset them immediately.
4.1 Preparation
- Ensure you have a rollback plan in place – restoring from backup is usually sufficient.
- Changes should be deployed during a scheduled maintenance window, with approval from relevant IT teams.
4.2 Implementation
- Step 1: Remove configuration files from the public web directory if possible. This is the preferred solution.
- Step 2: If config files must be present, set file permissions to restrict access to only the necessary users (e.g., the application user). Use commands like
chmod 600 /path/to/config/file.jsonon Linux systems. - Step 3: Configure your web server (e.g., Apache, Nginx) to deny direct access to the ‘config’ directory using appropriate directives in your configuration files.
4.3 Config or Code Example
Before
# In Apache .htaccess file (example)
# No restrictions on config directory access
After
# In Apache .htaccess file (example)
Require all denied
4.4 Security Practices Relevant to This Vulnerability
Several security practices can help prevent this type of vulnerability. Least privilege is crucial, limiting the impact if a configuration file is exposed. Secure defaults should be used when configuring your web server and application, avoiding open permissions. Application misconfiguration is a common cause; regular reviews are essential.
- Practice 1: Implement least privilege principles to restrict access to sensitive files and directories.
- Practice 2: Enforce secure default configurations for all servers and applications.
4.5 Automation (Optional)
If using infrastructure-as-code tools, you can automate the configuration of file permissions and web server directives. This ensures consistency across deployments.
# Example Ansible task to set file permissions
- name: Set config file permissions
file:
path: /path/to/config/file.json
mode: '0600'
owner: application_user
group: application_group
5. Verification / Validation
- Post-fix check: Use
curl -I https://your-application.com/config/default.jsonand expect an HTTP status code of 403 (Forbidden). - Re-test: Repeat the quick checks from Section 3 to confirm that configuration files are no longer accessible.
- Smoke test: Verify core application functionality, such as user login and data retrieval, to ensure the changes haven’t introduced regressions.
- Monitoring: Monitor web server access logs for any attempts to access the ‘config’ directory or config files. An increase in 403 errors could indicate ongoing probing.
curl -I https://your-application.com/config/default.json6. Preventive Measures and Monitoring
- Baselines: Update your server and application security baselines to include restrictions on access to sensitive directories like ‘config’.
- Pipelines: Add SAST tools to your CI/CD pipeline to scan for exposed configuration files during development.
- Asset and patch process: Implement a regular review cycle (e.g., monthly) to assess the security of deployed assets, including Node-config module versions and configurations.
7. Risks, Side Effects, and Roll Back
- Roll back: Restore your application code and configuration from backup. Restart the application service.
8. References and Resources
- Vendor advisory or bulletin: https://github.com/node-config/node-config