--- title: 'Sicherheitslücken in Webanwendungen & Abhilfemaßnahmen: SQLi, Command Injection, XSS, CSRF & IDOR | DevSense' description: 'Schützen Sie Ihre PHP-Anwendungen vor häufigen Web-Sicherheitslücken. Erfahren Sie, wie Sie SQL-Injection, Command Injection, XSS, CSRF und IDOR mit sicheren Codebeispielen verhindern.' faq: - { question: 'Warum sind Prepared Statements sicher gegen SQL-Injection?', answer: 'Prepared Statements senden das SQL-Abfragetemplate und die Parameterdaten separat an die Datenbank-Engine. Die Engine kompiliert zuerst die SQL-Abfrage, wodurch sichergestellt wird, dass Parameterdaten niemals als SQL-Befehle geparst oder ausgeführt werden, unabhängig davon, welche Zeichen sie enthalten.' } - { question: 'Wann ist es sicher, Laravels unmaskierte Blade-Direktive {!! $var !!} zu verwenden?', answer: 'Die Verwendung von `{!! $var !!}` ist nur dann sicher, wenn die Variable rohes HTML enthält, das Sie selbst generiert oder mit einer sicheren HTML-Bereinigungsbibliothek wie HTMLPurifier bereinigt haben. Sie sollten niemals rohe Benutzereingaben über diese Direktive ausgeben.' } - { question: 'Wie verhindert eine auf Beziehungen eingegrenzte Abfrage (Relation-scoped Lookup) IDOR?', answer: "Eine auf Beziehungen eingegrenzte Abfrage (z. B. `$user->orders()->findOrFail($id)`) stellt sicher, dass die Datenbankabfrage die Ergebnisse automatisch nach der ID des authentifizierten Benutzers filtert. Ein Angreifer, der versucht, auf die ID eines anderen Benutzers zuzugreifen, erhält einen Fehler '404 Not Found', da der Datensatz innerhalb der eingegrenzten Beziehung nicht existiert." } published: '2026-06-19' --- # Sicherheitslücken in Webanwendungen & Abhilfemaßnahmen: SQLi, Command Injection, XSS, CSRF & IDOR Das Erstellen sicherer Webanwendungen besteht nicht darin, die Sicherheit am Ende der Entwicklung hinzuzufügen. Es erfordert das Verständnis dafür, wie Schwachstellen auf Code-Ebene entstehen, und das Entwerfen von Grenzen, um sie zu verhindern. In diesem Leitfaden werden wir fünf kritische Sicherheitslücken in Webanwendungen (SQL-Injection, Command Injection, Cross-Site Scripting, CSRF und IDOR) in PHP und Laravel analysieren, sehen, wie sie ausgenutzt werden, und sichere Abhilfemaßnahmen implementieren. **Verwandte Leitfäden:** [Monolith to microservices architecture](monolith-to-microservices-architecture) · [Observability & monitoring](observability-monitoring-laravel) ## Inhalt * [SQL-Injection (SQLi)](#sql-injection) * [Command Injection](#command-injection) * [Cross-Site Scripting (XSS)](#xss) * [Cross-Site Request Forgery (CSRF)](#csrf) * [Insecure Direct Object References (IDOR)](#idor) * [Häufige Fehler](#common-mistakes) * [Checkliste](#checklist) * [Zusammenfassung](#summary) * [Selbsttest-Quiz](#self-test-quiz) --- ## SQL-Injection (SQLi) Eine **SQL-Injection** tritt auf, wenn nicht vertrauenswürdige Benutzereingaben direkt mit SQL-Abfrage-Strings verkettet werden. Dies ermöglicht es Angreifern, die Abfragestruktur zu manipulieren, Authentifizierungen zu umgehen, sensible Datenbankinhalte auszulesen oder Datensätze zu löschen. ### Der schlechte Weg: String-Verkettung und unsichere Sortierung Hier verkettet der Entwickler Eingabevariablen direkt in der Abfrage und verwendet unbereinigte Eingaben zur Definition der Sortierspalte. ```php // app/Http/Controllers/ProductController.php declare(strict_types=1); namespace App\Http\Controllers; use Illuminate\Http\Request; use Illuminate\Support\Facades\DB; class ProductController { public function search(Request $request): array { $search = $request->input('q'); $sortBy = $request->input('sort', 'id'); // VULNERABLE: SQL Injection via both search input and sorting column $sql = "SELECT * FROM products WHERE name LIKE '%{$search}%' ORDER BY {$sortBy} ASC"; return DB::select($sql); } } ``` ### Der gute Weg: Prepared Statements und Spalten-Allowlist Um dies zu beheben, müssen wir **Prepared Statements (Parameterbindung)** für Abfragedatenwerte verwenden. Da Sortierspalten nicht parametrisiert werden können, müssen wir sie anhand einer strengen **Allowlist** validieren. ```php // app/Http/Controllers/ProductController.php declare(strict_types=1); namespace App\Http\Controllers; use Illuminate\Http\Request; use Illuminate\Support\Facades\DB; class ProductController { private const ALLOWED_SORT_COLUMNS = ['id', 'name', 'price', 'created_at']; public function search(Request $request): array { $search = $request->input('q', ''); // Strict sorting column allowlist fallback $sortBy = in_array($request->input('sort'), self::ALLOWED_SORT_COLUMNS, true) ? $request->input('sort') : 'id'; // SECURE: Parameter binding for data, strict validation for identifiers return DB::select( "SELECT * FROM products WHERE name LIKE :search ORDER BY {$sortBy} ASC", ['search' => "%{$search}%"] ); } } ``` --- ## Command Injection Eine **Command Injection** tritt auf, wenn Benutzereingaben direkt an System-Shell-Funktionen wie `exec()`, `shell_exec()` oder `system()` übergeben werden. Dies ermöglicht es Angreifern, beliebige Shell-Befehle auf dem Server unter den Benutzerberechtigungen des Webservers auszuführen. ### Der schlechte Weg: Shell-Ausführung mit String-Verkettung In diesem Beispiel versuchen wir, eine PDF-Datei mit einem Befehlszeilen-Tool in ein PNG-Vorschaubild (Thumbnail) zu konvertieren, übergeben den Dateinamen jedoch direkt an die Shell. ```php // app/Services/ThumbnailGenerator.php declare(strict_types=1); namespace App\Services; class ThumbnailGenerator { public function generate(string $filename): string { $outputPath = "/tmp/" . uniqid('thumb_', true) . ".png"; // VULNERABLE: Command injection if filename contains shell operators (e.g. "; rm -rf /;") $cmd = "pdftoppm -png -r 150 {$filename} {$outputPath}"; shell_exec($cmd); return $outputPath; } } ``` ### Der gute Weg: Process-Komponente mit Argument-Arrays Rufen Sie die Shell niemals direkt auf und übergeben Sie keine verketteten Argumente. Verwenden Sie Process-Wrapper-Bibliotheken (wie die Symfony Process-Komponente), die das Escaping von Argumenten und die Ausführung sicher handhaben, ohne eine Shell-Umgebung zu nutzen. ```php // app/Services/ThumbnailGenerator.php declare(strict_types=1); namespace App\Services; use Symfony\Component\Process\Process; use Symfony\Component\Process\Exception\ProcessFailedException; class ThumbnailGenerator { public function generate(string $filePath): string { $outputPath = "/tmp/" . uniqid('thumb_', true) . ".png"; // SECURE: Arguments are passed as an array, bypassing the shell shell interpreter $process = new Process(['pdftoppm', '-png', '-r', '150', $filePath, $outputPath]); $process->run(); if (!$process->isSuccessful()) { throw new ProcessFailedException($process); } return $outputPath; } } ``` --- ## Cross-Site Scripting (XSS) **Cross-Site Scripting (XSS)** tritt auf, wenn eine Anwendung nicht vertrauenswürdige Benutzerdaten ohne ordnungsgemäße Maskierung (Escaping) in eine Webseite einbindet. Der Browser des Angreifers führt bösartiges JavaScript aus, das Session-Cookies stehlen, Eingaben erfassen (Keylogging) oder Benutzer umleiten kann. Es gibt drei Arten von XSS: - **Reflektiertes XSS (Reflected XSS):** Das Skript ist Teil der Anfrage-Payload und wird sofort in der Antwort zurückgespiegelt. - **Gespeichertes XSS (Stored XSS):** Das Skript wird in der Datenbank gespeichert (z. B. Kommentartext) und ausgeführt, wenn andere Benutzer die Seite aufrufen. - **DOM-basiertes XSS (DOM-based XSS):** Die Sicherheitslücke existiert rein im clientseitigen JavaScript, das nicht vertrauenswürdige DOM-Variablen verarbeitet. ### Der schlechte Weg: Ausgabe unmaskierter Benutzerinhalte Laravels `{!! $var !!}` gibt rohes HTML aus und umgeht die Standard-XSS-Maskierung von Blade. ```blade
{!! $user->bio !!}
``` ### Der gute Weg: Standardmäßig maskieren und Rich-Text bereinigen Verwenden Sie immer `{{ $var }}`, was automatisch `e()` (PHPs `htmlspecialchars`) ausführt, um die Ausgabe zu maskieren. Wenn Sie vom Benutzer bereitgestellten Rich-Text ausgeben müssen, leiten Sie ihn durch eine sichere HTML-Bereinigungsbibliothek (wie HTMLPurifier). ```blade
{{ $user->bio }}
{!! clean($user->rich_description) !!}
``` --- ## Cross-Site Request Forgery (CSRF) **Cross-Site Request Forgery (CSRF)** zwingt den Browser eines authentifizierten Benutzers, zustandsändernde Aktionen (wie das Ändern des Passworts oder das Initiieren von Zahlungen) in einer Anwendung auszuführen, bei der er derzeit angemeldet ist. Der Browser hängt Session-Cookies automatisch an cross-site Anfragen an, wodurch die Anfrage validiert wird. ### Der schlechte Weg: Zustandsändernde Aktionen bei GET-Anfragen GET-Anfragen müssen immer **idempotent** sein (sicher mehrmals ausführbar, ohne den Zustand zu ändern). Das Ausführen von Aktualisierungen über GET-Routen macht CSRF trivial. ```php // routes/web.php // VULNERABLE: Anyone can link to /profile/delete in an img tag to delete an account Route::get('/profile/delete', [ProfileController::class, 'destroy']); ``` ### Der gute Weg: POST/DELETE-Routen mit CSRF-Token Verwenden Sie immer zustandsändernde HTTP-Methoden (POST, PUT, DELETE) und verlangen Sie ein geheimes, kryptografisch sicheres Token, das von externen Websites nicht erraten werden kann. ```blade
@csrf @method('DELETE')
``` --- ## Insecure Direct Object References (IDOR) **IDOR (Insecure Direct Object Reference)** tritt auf, wenn eine Anwendung einen Datenbankschlüssel oder eine Ressourcen-ID direkt für Benutzer offenlegt und nicht überprüft, ob der anfordernde Benutzer die Berechtigung hat, auf diese spezifische Ressource zuzugreifen. ### Der schlechte Weg: Globale Abfragesuche ohne Autorisierung In diesem Beispiel kann jeder angemeldete Benutzer auf die Rechnungsdetails eines anderen Benutzers zugreifen, indem er einfach die `{id}` im URL-Parameter ändert. ```php // app/Http/Controllers/InvoiceController.php declare(strict_types=1); namespace App\Http\Controllers; use App\Models\Invoice; use Illuminate\Http\Request; class InvoiceController { public function show(int $id): \Illuminate\Http\JsonResponse { // VULNERABLE: Retrieves invoice without checking user relationship or authorization $invoice = Invoice::findOrFail($id); return response()->json($invoice); } } ``` ### Der gute Weg: Auf Beziehungen eingegrenzte Abfragen und Gate-Autorisierung Entkoppeln Sie den Abruf von Ressourcen, indem Sie diese über den Beziehungsmodell-Scope des Benutzers laden, oder überprüfen Sie die Berechtigungen mithilfe von Autorisierungs-Gates/-Policies. ```php // app/Http/Controllers/InvoiceController.php declare(strict_types=1); namespace App\Http\Controllers; use App\Models\Invoice; use Illuminate\Http\Request; use Illuminate\Support\Facades\Gate; class InvoiceController { public function show(Request $request, int $id): \Illuminate\Http\JsonResponse { // SECURE Method A: Query scoped directly to the authenticated user $invoice = $request->user()->invoices()->findOrFail($id); // SECURE Method B: Global lookup but validated with a Laravel Policy // $invoice = Invoice::findOrFail($id); // Gate::authorize('view', $invoice); return response()->json($invoice); } } ``` --- ## Häufige Fehler 1. **Maskierung statt Parametrisierung:** Die Annahme, dass die Verwendung von `addslashes()` oder einfachen regulären Ausdrücken auf Variablen Abfragen schützt. Parametrisieren Sie immer. 2. **Zustandsänderungen per GET:** Erstellen von API- oder Web-Endpunkten, die Lösch- oder Aktualisierungsaktionen mittels HTTP GET durchführen. 3. **Mega-Gateways mit integrierter Validierung:** Überlassen der XSS-/SQLi-Validierung an WAFs oder Gateways, anstatt eine robuste Validierung direkt im Anwendungs-Controller zu implementieren. 4. **IDOR bei AJAX-Anfragen:** Sichern der primären HTML-Seitenrouten, aber Offenlegen unautorisierter Ressourcen-IDs in AJAX-/API-JSON-Endpunkten. --- ## Checkliste 1. **Abfragesicherheit:** Verketten Sie Variablen innerhalb von rohen `DB::select`- oder `whereRaw`-Anweisungen? 2. **Shell-Ausführung:** Können Sie Shell-Befehle durch Standard-PHP-Bibliotheken ersetzen? Wenn nicht, werden die Argumente in einem Array übergeben? 3. **Blade-Ausgabe:** Verwenden Sie `{!! !!}` irgendwo in Blade-Templates ohne HTMLPurifier-Validierung? 4. **Autorisierungsprüfung:** Überprüft jede Controller-Methode, die eine Ressource lädt, ob die Ressource dem aktuellen Benutzer gehört? --- ## Zusammenfassung Sichere Webanwendungen validieren Eingaben streng und wenden das Prinzip der tiefgestaffelten Verteidigung (Defense-in-Depth) an. Verhindern Sie **SQL-Injection** durch Prepared Statements und Spalten-Allowlists. Vermeiden Sie **Command Injection**, indem Sie Array-Argumente innerhalb von Process-Wrappern verwenden. Blockieren Sie **XSS**, indem Sie Variablenausgaben mithilfe von Template-Engines maskieren. Stoppen Sie **CSRF**, indem Sie Zustandsänderungen auf POST/DELETE-Anfragen beschränken, die mit Tokens geschützt sind. Verhindern Sie **IDOR**, indem Sie Suchen auf Beziehungen authentifizierter Benutzer eingrenzen oder Policy-Prüfungen durchführen. --- ## Selbsttest-Quiz ### Frage 1: Was ist der Hauptunterschied zwischen Maskierung (Escaping) und Parametrisierung bei SQL-Abfragen? - A) Maskierung wird auf dem Datenbankserver ausgeführt, während Parametrisierung innerhalb der PHP-Engine verarbeitet wird. - B) Maskierung ändert Sonderzeichen innerhalb von Abfragestrings, um sie sicher zu machen, während Parametrisierung die Abfragestruktur und die Parameter separat an die Datenbank-Engine sendet. - C) Parametrisierung ist nur mit PostgreSQL-Datenbanken kompatibel.
Klicken Sie hier, um die Antwort anzuzeigen **Antwort: B** Maskierung ist ein String-Manipulationsprozess, der anfällig für Parser-Fehler und Umgehungen (Bypasses) is. Parametrisierung ist ein Protokoll-Feature, bei dem SQL-Struktur und Datenwerte unabhängig voneinander gesendet werden, was garantiert, dass Daten das Abfragetemplate niemals verändern können.
### Frage 2: Warum sind GET-Anfragen anfällig für CSRF, selbst wenn sie durch Token geschützt sind? - A) Browser unterstützen keine GET-Formulare. - B) GET-Anfragen legen Token im URL-Verlauf, in Browser-Protokollen und Referer-Headern offen und sollten ohnehin niemals für zustandsändernde Operationen verwendet werden. - C) GET-Anfragen umgehen automatisch Laravels Middleware zur CSRF-Token-Überprüfung.
Klicken Sie hier, um die Antwort anzuzeigen **Antwort: B** GET-Anfragen sind so konzipiert, dass sie idempotent sind (sicheres Lesen). Wenn eine GET-Anfrage den Zustand ändert, können Angreifer die Ziel-URL in Cross-Site-Links oder Image-Tags einbetten und so die Zustandsänderung automatisch ohne Zustimmung des Benutzers auslösen.
### Frage 3: Wie verhindert die Eingrenzung einer Datenbankabfrage auf eine Benutzerbeziehung IDOR? - A) Es verschlüsselt die Primärschlüssel der Datenbank. - B) Es blockiert die Anfrage auf Firewall-Ebene. - C) Es garantiert, dass die SQL-Abfrage Datensätze automatisch filtert, indem die ID des authentifizierten Benutzers als Suchbedingung verwendet wird, wodurch die Datensätze anderer Benutzer unerreichbar werden.
Klicken Sie hier, um die Antwort anzuzeigen **Antwort: C** Die Eingrenzung von Abfragen (z. B. `$user->invoices()->findOrFail($id)`) fügt der SQL-Abfrage eine `WHERE user_id = ?`-Klausel hinzu. Wenn ein Angreifer versucht, eine Ressourcen-ID abzurufen, die jemand anderem gehört, gibt die Abfrage null Datensätze zurück, was zu einem sicheren 404-Fehler führt.