Pentest fuer Laravel-Anwendungen: Mass-Assignment, Blade-Injection und Deserialisierungsrisiken

Laravel ist das beliebteste PHP-Framework weltweit und Basis zahlreicher Unternehmensanwendungen, E-Commerce-Systeme und SaaS-Produkte. Seine Eleganz und Entwicklerfreundlichkeit haben jedoch eine Kehrseite: Viele Laravel-spezifische Features wie Eloquent-ORM, Blade-Templates und der Route-Model-Binding-Mechanismus bieten erhebliche Angriffsflaichen, wenn sie nicht korrekt eingesetzt werden. CVE-2024-29291 demonstrierte, wie der aktivierte Debug-Mode in Produktionsumgebungen vollstaendige Umgebungsvariablen exponiert. CVE-2018-15133 -- Deserialisierung ueber den APP_KEY -- bleibt in veralteten oder fehlkonfigurierten Installationen weiterhin ausnutzbar.

Laravel Pentest starten

Geschrieben von Malte Wagenbach

Gründer von Matproof Security. Spezialisiert auf KI-gestützte Penetrationstests und EU-Compliance (DORA, NIS2, BSI Grundschutz, ISO 27001).

Zuletzt überprüft: 17. Mai 2026

Warum Laravel-Anwendungen spezialisierte Sicherheitspruefungen benoetigen

Laravel abstrahiert viele Sicherheitsmechanismen, was Entwicklern hilft, schnell zu bauen -- aber auch dazu fuehrt, dass sicherheitsrelevante Entscheidungen unbewusst getroffen werden. Eloquents '$fillable' und '$guarded'-Mechanismus muss explizit und korrekt konfiguriert sein; ein einzelner fehlender Eintrag kann Mass-Assignment-Angriffe eroeffnen, die Angreifern erlauben, Felder wie 'is_admin', 'role' oder 'password' direkt zu ueberschreiben. Blade-Templates gelten als sicher, aber benutzerdefinierte Blade-Direktiven und eval-basierte Rendering-Pfade eroeffnen Server-Side Template Injection (SSTI), wenn Benutzerinput unkontrolliert in Templates fliesst. Dazu kommen Laravel-spezifische Risiken wie exponierte .env-Dateien, unkonfigurierte Telescope- oder Horizon-Panels und der APP_KEY als Basis fuer kryptographisch signierten, aber deserialisierbaren Session-Payload.

CVE-2024-29291 (Laravel-Debug-Mode-Exposition): Laravel zeigt im Debug-Mode (APP_DEBUG=true in .env) vollstaendige Stack-Traces inkl. Umgebungsvariablen, Datenbankverbindungsdaten und API-Schluesseln. Dieser Modus ist in Entwicklungsumgebungen beabsichtigt, in Produktionssystemen jedoch ein kritischer Konfigurationsfehler, der regelmaessig in Cloud-Deployments gefunden wird.
CVE-2024-52301 (Environment-Unmasking in Laravel): Betrifft Laravel-Versionen vor 11.x mit bestimmten Middleware-Konfigurationen, die es ermoeglichten, Umgebungsvariablen ueber fehlerhafte Exception-Handler-Antworten zu exponieren -- selbst wenn APP_DEBUG deaktiviert war.
CVE-2018-15133 (Deserialisierung ueber APP_KEY): Wenn der Laravel-APP_KEY bekannt oder schwach generiert ist, koennen PHP-Deserialisierungs-Gadget-Chains ueber Cookie-Manipulation oder Session-Daten zu Remote-Code-Execution fuehren. Diese klassische Schwachstelle bleibt relevant, da viele Deployments mit Default- oder aus .env-Backups geleakten APP_KEY-Werten arbeiten.
Eloquent Mass-Assignment in API-Controllern: Laravel-APIs, die 'Model::create($request->all())' oder 'Model::fill($request->all())' ohne explizite '$fillable'-Konfiguration verwenden, erlauben Angreifern, beliebige Modell-Felder zu setzen -- inklusive Rollenzuweisungen, Admin-Flags oder sensiblen internen Feldern.
Route Model Binding und IDOR: Laravels implizites Route-Model-Binding ist komfortabel, erzeugt aber haeufig Insecure Direct Object References, wenn keine Policy-basierte Autorisierung (Laravel Policies / Gates) implementiert ist. Angreifer koennen durch einfache ID-Iteration auf fremde Datensaetze zugreifen.
Blade-Template-Injection bei dynamischen Blade-Direktiven: Anwendungen, die Blade.directive() mit Benutzerinput kombinieren oder Blade::render() mit nicht-bereinigten Strings aufrufen, sind anfaellig fuer SSTI, die in Produktionsumgebungen zur Code-Ausfuehrung eskaliert werden kann.
Oeffentlich zugaengliche Laravel-Debug-Tools (Telescope, Horizon, Debugbar): Laravel Telescope, Horizon und Laravel Debugbar sind leistungsstaerke Entwicklungstools, die aber haeufig in Produktionsumgebungen vergessen und ohne Authentifizierung zugaenglich sind -- sie exponieren vollstaendige Anfragen, Datenbankabfragen, Queue-Jobs und E-Mail-Inhalte.

Was beim Laravel Penetrationstest geprueft wird

Mass-Assignment-Analyse: Vollstaendige Ueberpruefung aller Eloquent-Modelle auf korrekte '$fillable'/'$guarded'-Konfiguration; automatisierte Tests ob privilegierte Felder (Rollen, Berechtigungen, Admin-Flags) durch API-Anfragen gesetzt werden koennen.
Blade-Template-Injection und SSTI: Identifikation aller Stellen, an denen Benutzerinput in Blade-Templates oder Blade::render()-Aufrufe einfliessen kann; Test auf Ausfuehrungs-Eskalation durch PHP-Gadget-Chains in Template-Kontext.
APP_KEY-Sicherheit und Deserialisierungsrisiken: Prufung ob der APP_KEY ausreichend stark ist (min. 32 Bytes, kryptographisch zufaellig), nicht in oeffentlichen Repositories vorkommt und ob bekannte PHP-Deserialisierungs-Gadget-Chains (phpggc) anwendbar sind.
Route Model Binding und Autorisierungsluecken (IDOR): Systematische Tests auf fehlende Policy-Pruefungen bei allen route-bound Modellen; ID-Iteration und UUID-Guessing auf alle Resource-Controller.
Umgebungskonfiguration und .env-Exposition: Prufung auf direkt zugaengliche .env-Dateien, Backup-Dateien (.env.backup, .env.old), Log-Dateien mit sensiblen Daten und oeffentlich zugaengliche Storage-Pfade.
Laravel-Tool-Exposition (Telescope, Horizon, Debugbar): Automated Detection ob /telescope, /horizon, /_debugbar und aehnliche Endpunkte ohne Authentifizierung erreichbar sind; Prufung der Middleware-Konfiguration fuer Produktionsumgebungen.
SQL-Injection in Raw-Query-Verwendung: Identifikation aller DB::raw(), whereRaw() und selectRaw()-Aufrufe; Test ob Benutzerinput korrekt parametrisiert wird oder direkt in SQL-Strings eingefuegt wird.
CSRF-Schutz und Session-Management: Prufung der CSRF-Token-Implementierung fuer alle POST/PUT/DELETE-Endpunkte; Session-Konfiguration (secure, httponly, samesite) und Session-Fixation-Angriffe.
API-Authentifizierung (Sanctum / Passport): Konfigurationsaudit fuer Token-Lifetime, Token-Revocation, Scope-Validierung und Stateless-vs-Stateful-Session-Konfiguration in Multi-App-Setups.
Composer-Abhaengigkeiten und Supply-Chain: Scan aller composer.json-Abhaengigkeiten gegen Packagist Security Advisories und NVD; Identifikation veralteter Laravel-Kernpakete mit bekannten CVEs.

Beispiel-Befund

Kritisch

Eloquent Mass-Assignment ermoeglicht Privilege Escalation (Admin-Flag)

Der User-Registrierungsendpoint (POST /api/v1/register) verwendet 'User::create($request->all())'. Das User-Modell definiert '$guarded = []' (kein Schutz). Im Test war es moeglich, das Feld 'is_admin: true' in der Registrierungsanfrage mitzusenden, wodurch ein neu registrierter Nutzer unmittelbar Admin-Rechte erhielt. Dies ermoeglicherte vollstaendigen Zugriff auf das Admin-Panel (/admin/dashboard), alle Benutzerdaten und Systemkonfigurationen. OWASP API3:2023 Mass Assignment.

Behebung: Explizite '$fillable'-Liste im User-Modell definieren: ['name', 'email', 'password']. Niemals '$guarded = []' in Produktionsmodellen verwenden. Bei API-Controllern '$request->only([...])' statt '$request->all()' einsetzen. Laravel-Form-Request-Klassen mit expliziter Feldvalidierung verwenden. Sicherheits-Review aller Eloquent-Modelle auf Mass-Assignment-Konfiguration.

Referenz: CVE-2024-29291 (Laravel Debug) · OWASP API3:2023 Broken Object Property Level Authorization · CWE-915 Improperly Controlled Modification of Dynamically-Determined Object Attributes

Laravel Pentest: Optionen im Vergleich

—	Kostenloser Scan	Matproof Sentinel	Klassische Beratung
Automatisierte Scan-Engine	✓ (3-min Vorschau)	✓ Vollständiger Scan	✗ Nur manuell
OWASP Top 10 Abdeckung	Partiell	✓ Vollständig	✓ Vollständig
Proof-of-Exploit-Evidenz	✗	✓ Pro Befund	✓ Pro Befund
Regulatorisches Mapping (DORA/NIS2/ISO 27001)	✗	✓ Automatisiert	✓ Manuell
Audit-tauglicher PDF-Bericht	✗	✓ Sofort	✓ 2–4 Wochen Lieferzeit
Kontinuierliche / wiederkehrende Scans	✗	✓ Pro Deploy	✗ Jährliches Engagement
Zeit bis zum ersten Ergebnis	~3 Min.	~30 Min. Vollscan	2–4 Wochen
Preis	€0	Ab €149	€8.000–€25.000
Quellcode-Review (SAST)	✗	✓ Im Growth-Plan	✓ Im Scope
API-Testing (REST/GraphQL)	✗	✓ Automatisiert	✓ Manuell

Laravel Pentest Pakete

Einzel-Scan

€149 einmalig

1 vollständiger Pentest-Scan
KI-priorisierte Befunde mit CVSS 3.1
Proof-of-Exploit für jedes Finding
PDF-Bericht (audit-tauglich)
Regulatorisches Mapping (DORA, NIS2, BSI)

Einzel-Scan kaufen →

Haeufige Fragen zum Laravel Penetrationstest

Was ist Mass-Assignment in Laravel und warum ist es sicherheitskritisch?

Mass-Assignment bezeichnet das Befuellen eines Eloquent-Modells mit Daten direkt aus einer HTTP-Anfrage ('Model::create($request->all())'). Wenn das Modell keine '$fillable'-Whitelist oder '$guarded'-Blacklist korrekt konfiguriert hat, kann ein Angreifer beliebige Felder setzen -- einschliesslich interner Felder wie 'is_admin', 'role', 'balance' oder 'email_verified_at'. Der Angriff erfordert kein spezielles Wissen: Ein einfacher JSON-Body mit dem Zielfeld genuegt. Laravel zeigt im Debug-Modus sogar, welche Felder existieren.

Wie erkenne ich ob meine Laravel-Anwendung den Debug-Mode in Produktion aktiv hat?

Senden Sie eine fehlerhafte Anfrage (z.B. GET /nonexistent-route) und beobachten Sie die Antwort. Im Debug-Mode sehen Sie eine detaillierte Whoops-Fehlerseite mit Stack-Trace und Umgebungsvariablen. Im Produktionsmodus erscheint nur eine generische 500-Seite. Zusaetzlich: Pruefen Sie die .env-Datei auf 'APP_DEBUG=true' -- in Produktionsumgebungen muss dieser Wert 'false' sein. Matproof prueft dies automatisch bei jedem Scan.

Welche Laravel-Versionen sind von bekannten CVEs betroffen und wie bleibe ich aktuell?

Kritische CVEs: CVE-2018-15133 (Deserialisierung via APP_KEY, alle alten Versionen < 5.6.30); CVE-2024-29291 (Debug-Exposition, Konfigurationsproblem, nicht versionsabhaengig); CVE-2024-52301 (Umgebungs-Unmasking, Laravel < 11.x). Laravel folgt einem Minor-Release-Zyklus mit aktiven Security-Fixes fuer die aktuelle Major-Version. Empfehlung: 'composer outdated' und 'composer audit' regelmaessig ausfuehren; Security-Advisories von Packagist beobachten.

Ist Laravel Route Model Binding unsicher? Wie kann ich IDOR verhindern?

Route Model Binding ist nicht inherent unsicher -- aber es ist nur eine Bequemlichkeit fuer das automatische Laden von Modellen, nicht fuer Autorisierung. Ohne explizite Policy-Pruefung laedt Laravel das Modell fuer jeden uebergebenen Identifier, unabhaengig davon, ob der anfragende Nutzer darauf zugreifen darf. Loesung: Laravel Policies mit '$this->authorize()' in jedem Controller verwenden, oder Resource-Controller mit entsprechenden Policy-Methoden ausstatten. UUID statt inkrementelle Integer-IDs reduziert die Angriffsoberflaeche, loest aber das Autorisierungsproblem nicht.

Wie sichere ich Laravel-API-Authentifizierung mit Sanctum korrekt ab?

Fuer Sanctum-basierte APIs: (1) Token-Lebensdauer explizit setzen ('expiration' in config/sanctum.php, kein 'null'); (2) Token-Abilities (Scopes) granular definieren und in jedem Controller pruefen; (3) Bei SPA-Authentifizierung: CSRF-Schutz fuer Sanctum-Stateful-APIs aktivieren ('stateful' domain-Liste konfigurieren); (4) Sanctum-API-Rate-Limiting ('throttle:api' Middleware) aktivieren; (5) Token-Revocation bei Logout implementieren ('$request->user()->currentAccessToken()->delete()').

Was macht Laravel-Anwendungen fuer Supply-Chain-Angriffe anfaellig?

Laravel-Projekte nutzen typischerweise 50-200 Composer-Abhaengigkeiten. Jede Abhaengigkeit ist ein potentieller Supply-Chain-Angriffspfad. Bekannte Risikofaktoren: veraltete Pakete mit CVEs (z.B. phpmailer, guzzlehttp/guzzle), Pakete mit wenigen Maintainern und hohem Zugriff, und Transitivabhaengigkeiten die selten auditiert werden. 'composer audit' prueft gegen die Packagist Security Advisory Database. Zusaetzlich: Composer.lock in Git versionieren und Abhaengigkeiten mit 'composer install --no-dev' in Produktion deployen.

Wie verhindere ich SQL-Injection trotz Eloquent-ORM in Laravel?

Eloquent-ORM und Laravel Query Builder verwenden standardmaessig parametrisierte Abfragen -- das schuetzt vor den meisten SQL-Injection-Angriffen. Das Risiko entsteht durch explizite Raw-Queries: 'DB::select(DB::raw("SELECT * FROM users WHERE id = $id"))' ist gefaehrdet. Korrekte Verwendung: 'DB::select("SELECT * FROM users WHERE id = ?", [$id])' oder 'whereRaw("column = ?", [$value])'. Beim Pentest suchen wir systematisch nach allen Raw-Query-Verwendungen in der Codebasis.

Wie oft sollte eine Laravel-Anwendung einem Penetrationstest unterzogen werden?

Empfehlung fuer produktive Laravel-Anwendungen: Vollstaendiger Pentest mindestens einmal jaehrlich und nach jeder Major-Version-Migration. Bei Anwendungen mit personenbezogenen Daten (DSGVO) oder Zahlungsverarbeitung (PCI DSS) ist ein haeufigerer Rhythmus (halbjaaehrlich) empfehlenswert. Matproof Sentinel ergaenzt den Jahrespentest mit kontinuierlichen Scans, die neue Composer-CVEs und Konfigurationsdrifts erkennen.

Vertiefen — verwandte Artikel aus unserem Blog

Laravel Penetrationstest jetzt starten

Ermitteln Sie in wenigen Minuten, ob Ihre Laravel-Anwendung durch Mass-Assignment, Blade-Injection oder fehlerhafte Konfiguration gefaehrdet ist. Audit-bereiter Bericht auf Deutsch, keine Installation erforderlich.