Skip to content

Latest commit

 

History

History
80 lines (65 loc) · 4.88 KB

attack-surface.md

File metadata and controls

80 lines (65 loc) · 4.88 KB

Attack Surface Analysis for bkeepers/dotenv

Attack Surface: Direct Exposure of .env File

  • Description: The .env file, containing sensitive environment variables, is directly accessible to attackers via a web request.
  • How dotenv Contributes: dotenv encourages the use of a .env file to store secrets, making this file a central point of vulnerability if its location is exposed.
  • Example: An attacker accesses https://example.com/.env and downloads the file.
  • Impact: Complete compromise of the application and connected services.
  • Risk Severity: Critical
  • Mitigation Strategies:
    • Never place the .env file within the web server's document root.
    • Configure the web server to explicitly deny access to all files starting with a dot (.).

Attack Surface: Source Code Repository Inclusion

  • Description: The .env file is accidentally committed to a source code repository.
  • How dotenv Contributes: Developers using dotenv might mistakenly treat the .env file as a regular project file and commit it.
  • Example: A developer commits the .env file to a public GitHub repository.
  • Impact: Exposure of all secrets to anyone with access to the repository.
  • Risk Severity: Critical
  • Mitigation Strategies:
    • Add .env to the .gitignore file before the initial commit.
    • Use tools like git-secrets to scan for potential secrets before committing.
    • If committed, immediately rotate secrets and rewrite repository history (but assume compromise).

Attack Surface: Insecure Backup Exposure

  • Description: Backups of the application directory include the .env file, and these backups are not secured.
  • How dotenv Contributes: The presence of the .env file makes it susceptible to inclusion in insecure backups.
  • Example: An attacker gains access to an unencrypted backup containing the .env file.
  • Impact: Exposure of all secrets.
  • Risk Severity: High
  • Mitigation Strategies:
    • Exclude the .env file from backups.
    • Store environment variables separately in a secure, encrypted location if backups are needed.

Attack Surface: Insecure File Permissions

  • Description: The .env file has overly permissive file permissions.
  • How dotenv Contributes: Developers might not set appropriate file permissions on the .env file.
  • Example: The .env file is world-readable on a shared hosting environment.
  • Impact: Exposure of secrets to other users on the system.
  • Risk Severity: High
  • Mitigation Strategies:
    • Set file permissions to be as restrictive as possible (e.g., 600 or 400).

Attack Surface: Information Leakage via Logs/Errors

  • Description: Sensitive environment variables loaded by dotenv are accidentally logged.
  • How dotenv Contributes: dotenv makes loading secrets easy, increasing the risk of accidental logging.
  • Example: An application error logs the value of a database password.
  • Impact: Exposure of secrets through log files.
  • Risk Severity: High
  • Mitigation Strategies:
    • Never log sensitive information directly.
    • Use logging libraries with redaction/masking capabilities.
    • Store logs securely.

Attack Surface: Production Use of .env

  • Description: dotenv and .env files are used in a production environment.
  • How dotenv Contributes: dotenv is primarily for development; production use increases exposure risk.
  • Example: A production server is deployed with a .env file.
  • Impact: Increased risk of secret exposure in production.
  • Risk Severity: High
  • Mitigation Strategies:
    • Never use .env files in production. Use proper environment variable setting mechanisms.

Attack Surface: Shell Expansion Vulnerabilities

  • Description: Environment variables loaded by dotenv are used in shell commands without proper escaping.
  • How dotenv Contributes: dotenv loads variables, and if these are used unsafely in shell commands, it creates vulnerabilities.
  • Example: A .env file contains VAR=value; rm -rf /, used unsafely in a shell command.
  • Impact: Remote code execution, system compromise.
  • Risk Severity: Critical
  • Mitigation Strategies:
    • Sanitize and validate environment variables before use in shell commands.
    • Use parameterized queries or libraries that handle escaping.
    • Avoid shell commands when possible.