Speicherung von Dateien mit sensiblen Daten unter dem Web-Root

Beschreibung

Speicherung von Dateien mit sensiblen Daten unter dem Web-Root ist eine Schwachstelle, die auftritt, wenn ein Produkt sensible Daten in Dateien speichert, die sich im Web-Dokumenten-Root-Verzeichnis befinden, ohne ausreichende Zugriffskontrollen zu implementieren. Das Web-Root ist das Verzeichnis, aus dem ein Webserver Dateien an Clients ausliefert, und dort platzierte Dateien können direkt über URL-Anfragen zugänglich sein, sofern sie nicht explizit geschützt werden. Sensible Dateien, die häufig in Web-Roots gefunden werden, umfassen Datenbankdateien, Konfigurationsdateien mit Anmeldedaten, Backup-Archive, Logdateien, Quellcode und temporäre Dateien. Wenn Webserver-Zugriffskontrollen falsch konfiguriert oder nicht angewendet werden, können Angreifer diese Dateien direkt anfordern und herunterladen, wodurch sie Zugang zu Anmeldedaten, persönlichen Daten, Anwendungslogik oder anderen sensiblen Informationen erhalten.

Risiko

Die Speicherung sensibler Daten unter dem Web-Root erzeugt schwere Sicherheitsrisiken, da sie geschützte Informationen nur einen URL-Rateversuch von der Offenlegung entfernt platziert. Datenbankdateien mit Benutzeranmeldedaten, persönlichen Informationen und Geschäftsdaten können heruntergeladen und offline analysiert werden. Konfigurationsdateien können Datenbankverbindungszeichenfolgen, API-Schlüssel und Verschlüsselungsgeheimnisse offenlegen. Backup-Dateien enthalten oft vollständige Kopien von Datenbanken oder Quellcode. Die Offenlegung von Anwendungsquellcode ermöglicht Angreifern, durch Code-Review zusätzliche Schwachstellen zu finden. Logdateien können Session-Tokens, in falsche Felder eingegebene Passwörter oder Debug-Informationen enthalten. Das Risiko wird verstärkt durch Suchmaschinen, die offengelegte Verzeichnisse indexieren, automatisierte Scanner, die gängige Dateinamen entdecken, und Backup-Tools, die vorhersagbar benannte Archive an zugänglichen Orten erstellen.

Lösung

Speichern Sie alle sensiblen Daten außerhalb des Web-Dokumenten-Roots in Verzeichnissen, die nicht über Webanfragen zugänglich sind. Konfigurieren Sie den Webserver so, dass er den Zugriff auf sensible Dateitypen (.sql, .bak, .log, .cfg, .env) explizit verweigert, selbst wenn sie versehentlich im Web-Root platziert werden. Implementieren Sie eine Verzeichnisstruktur, die öffentliche Assets von Anwendungscode, Konfiguration und Daten trennt. Verwenden Sie Web-Application-Frameworks, die diese Trennung standardmäßig durchsetzen. Scannen Sie das Web-Root regelmäßig mit automatisierten Tools nach sensiblen Dateien. Konfigurieren Sie Backup-Prozesse so, dass Dateien außerhalb des Web-Roots mit entsprechenden Dateisystem-Berechtigungen gespeichert werden. Deaktivieren Sie Verzeichnis-Listing in der Webserver-Konfiguration. Implementieren Sie Überwachung, um Zugriffsversuche auf sensible Dateierweiterungen zu erkennen.

Häufige Auswirkungen

Auswirkung	Details
Vertraulichkeit	Bereich: Vertraulichkeit Angreifer können direkt auf sensible Datendateien zugreifen und diese herunterladen, die unter dem Web-Root gespeichert sind. Dies umfasst Datenbankinhalte, Konfigurationsgeheimnisse, persönliche Informationen und Quellcode, was zur vollständigen Kompromittierung der Datenvertraulichkeit führt.

Beispielcode

Anfällige Konfiguration (Verzeichnisstruktur)

Die folgende Verzeichnisstruktur demonstriert ein anfälliges Webanwendungs-Layout:

/var/www/html/                    # Web-Root - alle Dateien potenziell zugänglich
├── index.php
├── css/
├── js/
├── images/
├── config.php                    # ANFÄLLIG: Enthält DB-Anmeldedaten
├── database/
│   └── users.db                  # ANFÄLLIG: SQLite-Datenbank
├── backup/
│   └── site_backup_2024.zip      # ANFÄLLIG: Vollständiges Site-Backup
├── logs/
│   └── application.log           # ANFÄLLIG: Logdatei mit sensiblen Daten
├── .env                          # ANFÄLLIG: Umgebungsvariablen
├── .htaccess                     # Kann helfen, aber oft unzureichend
└── admin/
    └── config.ini                # ANFÄLLIG: Admin-Konfiguration

<?php
// /var/www/html/config.php - Anfällig: Direkt zugänglich unter /config.php
// Angreifer besucht: https://example.com/config.php

return [
    'db_host' => 'localhost',
    'db_name' => 'production_db',
    'db_user' => 'app_user',
    'db_pass' => 'SuperSecretPassword123!',  // Offengelegt!
    'api_key' => 'sk-live-xxxxxxxxxxxxx',     // Offengelegt!
    'encryption_key' => 'aes256-key-here'     // Offengelegt!
];

# Angreifer-Entdeckungsmethoden:
curl https://example.com/config.php
curl https://example.com/database/users.db
curl https://example.com/backup/site_backup_2024.zip
curl https://example.com/.env
curl https://example.com/logs/application.log

Korrigierte Konfiguration (Verzeichnisstruktur)

/var/www/                          # Anwendungs-Root (NICHT Web-Root)
├── config/                        # SICHER: Außerhalb Web-Root
│   ├── config.php
│   └── .env
├── data/                          # SICHER: Außerhalb Web-Root
│   └── database/
│       └── users.db
├── logs/                          # SICHER: Außerhalb Web-Root
│   └── application.log
├── backups/                       # SICHER: Außerhalb Web-Root
│   └── site_backup_2024.zip
└── public/                        # Web-Root - nur öffentliche Dateien
    ├── index.php                  # Einstiegspunkt
    ├── css/
    ├── js/
    ├── images/
    └── .htaccess

<?php
// /var/www/public/index.php - Einziger Einstiegspunkt im Web-Root

// Konfiguration wird von außerhalb des Web-Roots geladen
require_once __DIR__ . '/../config/config.php';

// Datenbankdatei ist außerhalb des Web-Roots
$db_path = __DIR__ . '/../data/database/users.db';

// Anfrage verarbeiten...

# /var/www/public/.htaccess - Defense in Depth

# Zugriff auf versteckte Dateien verweigern
<FilesMatch "^\.">
    Require all denied
</FilesMatch>

# Zugriff auf sensible Erweiterungen verweigern falls versehentlich vorhanden
<FilesMatch "\.(sql|db|sqlite|bak|backup|log|cfg|ini|env|yml|yaml|json)$">
    Require all denied
</FilesMatch>

# Zugriff auf PHP-Konfigurationsdateien verweigern (außer index.php)
<FilesMatch "^(?!index\.php$).+\.php$">
    Require all denied
</FilesMatch>

# Verzeichnis-Listing deaktivieren
Options -Indexes

# Nginx-Konfiguration für sichere Dateibehandlung

server {
    listen 443 ssl;
    server_name example.com;

    # Web-Root ist nur das public-Verzeichnis
    root /var/www/public;

    # Zugriff auf versteckte Dateien verweigern
    location ~ /\. {
        deny all;
    }

    # Zugriff auf sensible Dateitypen verweigern
    location ~* \.(sql|db|sqlite|bak|backup|log|cfg|ini|env|yml|yaml)$ {
        deny all;
    }

    # PHP-Ausführung nur über einzelnen Einstiegspunkt erlauben
    location ~ \.php$ {
        # Nur index.php erlauben
        if ($uri !~ "^/index\.php$") {
            return 403;
        }
        fastcgi_pass unix:/var/run/php/php-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
    }

    # Verzeichnis-Listing deaktivieren
    autoindex off;
}

Die Korrektur platziert alle sensiblen Dateien außerhalb des Web-Roots, konfiguriert Webserver-Regeln, um den Zugriff auf sensible Dateitypen als Defense in Depth zu verweigern, und verwendet eine Single-Entry-Point-Architektur.

Ausgenutzt in der Praxis

Git-Repository-Offenlegung (.git-Ordner, Fortlaufend)

Millionen von Websites haben ihren vollständigen Quellcode und Commit-Verlauf offengelegt, indem sie Anwendungen mit unter dem Web-Root zugänglichen .git-Verzeichnissen deployt haben. Angreifer verwenden automatisierte Tools, um diese Repositories zu erkennen und zu klonen, wobei sie Anmeldedaten, API-Schlüssel und schwachstellenoffenlegenden Code extrahieren. Die Dateien .git/config und .git/logs/HEAD werden besonders für Aufklärung gezielt.

https://www.internetwache.org/dont-publicly-expose-git-or-how-we-downloaded-your-websites-sourcecode-an-analysis-of-alexa-1m-sites-07-07-2015/

SQLite-Datenbank-Downloads (Mehrere CMS-Plattformen, Fortlaufend)

Content-Management-Systeme und Webanwendungen, die SQLite verwenden, haben Datenschutzverletzungen erlitten, wenn Datenbankdateien in webzugänglichen Verzeichnissen gespeichert wurden. Angreifer entdeckten Datenbankstandorte durch Fehlermeldungen, Standardpfade oder Verzeichnis-Scanning. Vollständige Benutzerdatenbanken einschließlich gehashter Passwörter wurden heruntergeladen und offline geknackt.

https://www.acunetix.com/websitesecurity/sql-injection/

WordPress-Backup-Offenlegung (Tausende von Sites, 2019)

Sicherheitsforscher entdeckten Tausende von WordPress-Sites, die Datenbank-Backups in vorhersagbar benannten Dateien unter dem Web-Root offenlegten. Dateien wie backup.sql, database.sql und wp-content/backups/ enthielten vollständige Datenbank-Dumps mit Benutzeranmeldedaten und Inhalten. Plugins, die automatische Backups erstellen, speicherten diese häufig an webzugänglichen Orten.

https://www.wordfence.com/blog/2019/09/exposed-backups-databases-wordpress/

Tools zum Testen/Ausnutzen

DirBuster / GoBuster — Verzeichnis-Brute-Forcing-Tools zum Entdecken offengelegter Dateien und Verzeichnisse unter dem Web-Root.
GitTools — Tools zum Finden und Extrahieren offengelegter Git-Repositories von Webservern.
Nuclei — Schwachstellen-Scanner mit Vorlagen zur Erkennung offengelegter sensibler Dateien.

CVE-Beispiele

CVE-2005-1835 — Anwendung speicherte Datendatei mit sensiblen Informationen unter dem Web-Root.
CVE-2002-1449 — Benutzername und Passwort in zugänglicher Datendatei unter dem Web-Root gespeichert.
CVE-2002-0943 — Unter dem Web-Root zugängliche Datenbankdatei ermöglichte das Herunterladen aller Benutzerdaten.
CVE-2005-1645 — Unter dem Web-Root gespeicherte SQLite-Datenbankdatei für direkten Download offengelegt.

Referenzen

MITRE Corporation. "CWE-219: Storage of File with Sensitive Data Under Web Root." Common Weakness Enumeration. https://cwe.mitre.org/data/definitions/219.html
OWASP Foundation. "Sensitive Data Exposure." OWASP Top 10. https://owasp.org/www-project-top-ten/
Apache HTTP Server Documentation. "Access Control." https://httpd.apache.org/docs/2.4/howto/access.html
Nginx Documentation. "Restricting Access." https://docs.nginx.com/nginx/admin-guide/security-controls/controlling-access-proxied-http/