Bölüm 36

Laravel Güvenliği

14 dk okuma2.891 kelimePHP 8.1+

Ön koşul

Bölüm 4 (mass assignment), Bölüm 6 (SQLi), Bölüm 7 (XSS), Bölüm 11 (deserialization/phar), Bölüm 17 (CSRF), Bölüm 20 (php://filter/phar, log poisoning), Bölüm 25/26 (sırlar, debug). İleri referans: Bölüm 34 (RCE sonrası).

Bu bölümün kazanımı

Laravel'in güvenli varsayılanlarını (Eloquent, Blade, CSRF, hashing) ve onları bozan kullanımları; ve framework-özgü en büyük riski — üretimde açık debug mode — Ignition RCE (CVE-2021-3129) üzerinden öğreneceksiniz.

1. Giriş

Laravel, PHP'nin en popüler modern framework'lerinden biridir ve güvenliği varsayılan olarak sağlamaya çalışır: Eloquent ORM sorguları parametreler (Bölüm 6), Blade şablon motoru çıktıyı otomatik kaçış yapar (Bölüm 7), CSRF middleware'i formları korur (Bölüm 17), ve parolalar bcrypt/Argon2 ile hash'lenir (Bölüm 13). İyi yazılmış bir Laravel uygulaması, bu kitaptaki birçok açık sınıfına karşı büyük ölçüde dirençlidir.

Ama iki şey bu güvenliği bozar: (1) varsayılanları atlamak — ham sorgular (DB::raw), kaçışsız çıktı ({!! !!}), korumasız mass assignment, devre dışı bırakılmış CSRF; ve (2) yanlış yapılandırma — özellikle üretimde açık bırakılmış debug mode. Bu ikincisi, Laravel'in en meşhur açığının kökenidir.

2021'de Ambionics'in bulduğu Ignition RCE (CVE-2021-3129, Bölüm 11), tam bu yanlış yapılandırmadan doğdu: Laravel'in hata ayıklayıcısı Ignition, APP_DEBUG=true olduğunda güçlü bir uç nokta (_ignition/execute-solution) açığa çıkarıyordu; doğrulanmamış dosya işlemleri + phar deserialization (Bölüm 11) + log poisoning (Bölüm 20) zinciriyle kimlik-doğrulamasız RCE mümkündü. Kitlesel olarak sömürüldü. Ders, bu bölümün ana teması olacak: debug mode üretimde bir felakettir.

Bu bölüm, Laravel'i güvenli kullanmayı ele alır: güvenli varsayılanları koruma, onları atlayan kalıplardan kaçınma ve doğru yapılandırma.

2. Temel Teori

Laravel'in güvenli varsayılanları — ve onları bozan kullanımlar:

Alan	Güvenli varsayılan	Onu bozan (tehlike)
SQL (Bölüm 6)	Eloquent/Query Builder parametreler	`DB::raw`, `whereRaw($input)`
XSS (Bölüm 7)	Blade `{{ }}` otomatik kaçış	`{!! $input !!}` (kaçışsız)
Mass assignment (Bölüm 4)	`$fillable`/`$guarded`	`Model::create($request->all())` korumasız
CSRF (Bölüm 17)	`VerifyCsrfToken` middleware + `@csrf`	Rotaları `$except`'e ekleme
Parola (Bölüm 13)	`Hash::make` (bcrypt/Argon2)	Zayıf/özel hash
Debug (Bölüm 26)	`APP_DEBUG=false` (üretimde)	`APP_DEBUG=true` üretimde

Merkezî risk — debug mode üretimde. Laravel'in APP_DEBUG ayarı, geliştirmede paha biçilmezdir (ayrıntılı hatalar, Ignition çözüm önerileri) ama üretimde felakettir. Açık debug mode: - Ayrıntılı hata sayfaları: dosya yolları, kaynak parçaları, ortam değişkenleri, SQL, yığın izleri sızdırır (Bölüm 26 display_errors ile aynı). - Ignition'ın güçlü uç noktalarını (_ignition/execute-solution) açığa çıkarır — CVE-2021-3129'un yüzeyi.

Ignition RCE zinciri (kavramsal, Bölüm 11/20). CVE-2021-3129, birkaç açık sınıfının birleşimiydi: 1. Debug uç noktası: APP_DEBUG=true ile _ignition/execute-solution erişilebilir. 2. Doğrulanmamış dosya işlemleri: Ignition'daki bir "çözüm" sınıfı (MakeViewVariableOptionalSolution), kullanıcı-kontrollü viewFile ile file_get_contents/file_put_contents'i yol doğrulaması olmadan çağırıyordu. 3. php://filter (Bölüm 20): Saldırgan, Laravel'in log dosyasını (storage/logs/laravel.log) php://filter ile manipüle ediyordu. 4. Log poisoning + phar (Bölüm 11, 20): Log'a bir phar payload'ı enjekte edilip log phar:// ile deserialize edilerek (bir gadget zinciriyle, Bölüm 11) RCE elde ediliyordu.

Bu, kitabın birçok bölümünün (debug/config Bölüm 26, dosya işlemleri/wrapper Bölüm 20, deserialization Bölüm 11) tek bir zincirde birleşmesidir — ve hepsinin ön koşulu açık debug modedur.

Diğer kritik yapılandırmalar: - APP_KEY (Bölüm 25): Şifreleme ve imzalama anahtarı; sızarsa şifreli çerezler/imzalı URL'ler forge edilebilir. Gizli tutulmalı (.env, sır yöneticisi). - .env (Bölüm 25): DB/API sırları; asla commit edilmez, web'de erişilemez.

3. Mimarisel Bakış

 GÜVENLİ VARSAYILANLAR (Laravel):
   Eloquent → parametreli SQL (Böl.6)
   Blade {{ }} → otomatik kaçış (Böl.7)
   VerifyCsrfToken + @csrf → CSRF (Böl.17)
   Hash::make → bcrypt/Argon2 (Böl.13)

 ONLARI BOZAN:
   DB::raw($input) → SQLi   ·   {!! $input !!} → XSS
   create($request->all()) → mass assignment   ·   CSRF $except → CSRF

 IGNITION RCE (CVE-2021-3129) — debug mode zinciri:
   APP_DEBUG=true → _ignition/execute-solution erişilebilir (Böl.26)
        ↓  doğrulanmamış file_get/put_contents (viewFile)
        ↓  php://filter ile log manipülasyonu (Böl.20)
        ↓  log poisoning → phar:// deserialization (Böl.11)
   → kimlik-doğrulamasız RCE

 SAVUNMA: APP_DEBUG=false (üretim) · güncel Ignition · varsayılanları koru
          · APP_KEY/.env gizli (Böl.25)

Kritik gözlem: Laravel güvenli varsayılanlar sunar; risk, onları atlamaktan ve — en kritik — üretimde debug mode'dan gelir.

4. Güvensiz Kod

Güvenli varsayılanları atlayan ve debug açık bırakan kullanım:

<?php
// ⚠️ GÜVENSİZ Laravel kullanımı

// 1) Ham SQL (Eloquent'i atlar — SQLi, Bölüm 6)
$users = DB::select("SELECT * FROM users WHERE name = '" . $request->name . "'");
$q = User::whereRaw("email = '{$request->email}'")->get();

// 2) Kaçışsız Blade çıktısı (XSS — Bölüm 7)
// {!! $request->input('bio') !!}   ← kullanıcı HTML'i çalışır

// 3) Korumasız mass assignment (Bölüm 4)
User::create($request->all());                    // is_admin/role dahil her alan

// 4) CSRF devre dışı (Bölüm 17)
// VerifyCsrfToken $except = ['payment/*'];        ← kritik rotada CSRF kapalı

# ⚠️ GÜVENSİZ .env (üretim)
APP_ENV=production
APP_DEBUG=true          # FELAKET: Ignition RCE + bilgi ifşası (Bölüm 26)
APP_KEY=base64:...      # .env commit edilmişse sızar (Bölüm 25)

5. Açığın Analizi

DB::select("...".$request->name) / whereRaw($input) — SQLi (Bölüm 6). Eloquent varsayılan olarak parametreler, ama ham SQL (DB::select, DB::raw, whereRaw içine string birleştirme) bunu atlar ve SQLi'yi geri getirir. Parametreli binding (?/:name) kullanılmalı.

{!! $input !!} — XSS (Bölüm 7). Blade'in {{ }}'i otomatik kaçış yapar; ama {!! !!} (kaçışsız) kullanıcı girdisiyle kullanılırsa XSS oluşur. Kullanıcı verisi daima {{ }} ile çıkılmalı; HTML gerekiyorsa temizlenmeli (Bölüm 7).

User::create($request->all()) — Mass assignment (Bölüm 4). Tüm istek alanları modele yazılır; saldırgan is_admin/role ekleyerek yetki yükseltir. $fillable beyaz listesi veya açık alan ataması gerekir.

CSRF $except — CSRF (Bölüm 17). Kritik rotaları CSRF korumasından çıkarmak, o rotaları CSRF'e açar. İstisnalar yalnızca gerçekten stateless API rotaları için (ve token-tabanlı auth ile) olmalı.

APP_DEBUG=true (üretim) — En kritik. Ayrıntılı hata ifşası (Bölüm 26) ve Ignition RCE (CVE-2021-3129) yüzeyi. Üretimde daima false.

.env commit'li — Sır sızıntısı (Bölüm 25). APP_KEY ve DB/API sırları sızar; .env asla commit edilmez.

Kök sorun: güvenli varsayılanlar atlanıyor ve debug açık. Çözüm: varsayılanları koru, debug'ı kapat, sırları koru.

6. Hacker Bakış Açısı

Saldırgan bir Laravel uygulamasını nasıl hedefler?

Debug mode'u yoklar. İlk denediklerinden biri, açık debug mode'dur: bir hata tetikleyip Laravel'in ayrıntılı hata sayfasını (yol/kaynak/env ifşası) arar. Açıksa, Ignition sürümünü belirleyip CVE-2021-3129'u dener — kimlik-doğrulamasız RCE.

_ignition/execute-solution'ı test eder. Debug açıksa bu uç noktanın erişilebilirliğini yoklar; savunmasız Ignition sürümünde phar/log-poisoning zinciriyle RCE'ye gider.

Ham sorgu/kaçışsız çıktı arar. Girdilerin ham SQL'e (whereRaw) veya kaçışsız Blade'e ({!! !!}) ulaşıp ulaşmadığını test eder — varsayılanların atlandığı noktalar.

Mass assignment dener. İsteklere is_admin/role gibi alanlar ekleyip create/update'in bunları körü körüne yazıp yazmadığını (Bölüm 4) test eder.

.env/APP_KEY arar. Açıkta kalan .env (Bölüm 25, 27), .git veya debug ifşasından APP_KEY ve DB sırlarını toplar; APP_KEY ile imzalı URL/şifreli çerez forge etmeyi dener.

Savunmacı dersi: Saldırgan için Laravel'de en verimli hedef açık debug modedur — tek bir yanlış yapılandırma kimlik-doğrulamasız RCE verir. Sonra varsayılanların atlandığı noktaları arar.

7. Exploit Mantığı

Bu bölüm çalıştırılabilir exploit içermez. Laravel risklerinin neden bu şekilde ortaya çıktığı kavramsaldır:

Güvenli varsayılan, atlanınca kaybolur. Laravel açık sınıflarının çoğunu varsayılan olarak önler; risk, geliştiricinin varsayılanı atlamasıyla (ham SQL, kaçışsız çıktı, korumasız mass assignment) geri gelir. Yani Laravel'de çoğu açık, "varsayılana geri dön" ile önlenir.
Debug mode = tek yanlış-yapılandırmayla RCE. CVE-2021-3129, açık debug mode'un neden bu kadar tehlikeli olduğunu gösterir: bir bilgi-ifşası ayarı, birkaç açık sınıfının (dosya işlemi Bölüm 20, deserialization Bölüm 11) birleşmesiyle kimlik-doğrulamasız RCE'ye dönüşür.
Zincirleme. Ignition RCE, kitabın birçok dersinin (config Bölüm 26, wrapper/log Bölüm 20, phar/gadget Bölüm 11) tek zincirde birleşmesidir — derinlemesine savunmanın neden gerektiğinin kanıtı.
Sır sızıntısı çarpar. APP_KEY/.env sızıntısı (Bölüm 25), imzalı URL/çerez forge etme gibi ikincil saldırılara yol açar.

Savunmacının çerçevesi: (a) debug üretimde kapalı mı, (b) Ignition/framework güncel mi, (c) varsayılanlar korunuyor mu (ham SQL/kaçışsız çıktı/mass assignment yok), (d) CSRF açık mı, (e) APP_KEY/.env gizli mi. Savunma beşini de sağlar.

8. Güvenli Kod

Güvenli varsayılanları koruyan ve doğru yapılandırılmış Laravel:

<?php
// ✅ GÜVENLİ Laravel kullanımı

// 1) Eloquent/Query Builder — parametreli (Bölüm 6)
$users = User::where('name', $request->name)->get();
$user  = User::where('email', $request->email)->first();
// Ham gerekirse binding kullan:
DB::select('SELECT * FROM users WHERE name = ?', [$request->name]);

// 2) Blade otomatik kaçış (XSS — Bölüm 7)
// {{ $bio }}   ← daima kaçışlı; HTML gerekiyorsa önce temizle (Bölüm 7)

// 3) Mass assignment koruması (Bölüm 4)
class User extends Model {
    protected $fillable = ['name', 'email'];      // beyaz liste; is_admin/role YOK
}
$data = $request->validate([                       // + doğrulama
    'name'  => 'required|string|max:100',
    'email' => 'required|email',
]);
User::create($data);                               // yalnızca doğrulanmış/izinli alanlar

// 4) CSRF açık (Bölüm 17): VerifyCsrfToken $except boş/minimal; formlarda @csrf

# ✅ GÜVENLİ .env (üretim)
APP_ENV=production
APP_DEBUG=false          # KRİTİK: debug kapalı (Ignition RCE + ifşa önlenir)
APP_KEY=base64:...       # gizli; .env ASLA commit edilmez (Bölüm 25)

# Ek (Bölüm 25, 26, 27):
- Ignition ve framework GÜNCEL (CVE-2021-3129 yaması: Ignition >= 2.5.2)
- .env web'de erişilemez + gitignore'lu (Bölüm 25, 27); APP_KEY sır yöneticisinde
- php.ini display_errors=Off (derinlemesine savunma — Bölüm 26)

Öne çıkan modern pratikler: - APP_DEBUG=false (üretimde) — en kritik: Ignition RCE ve bilgi ifşasını (Bölüm 26) kapatır. - Framework/Ignition güncel (Bölüm 30): CVE-2021-3129 yaması; SCA ile izle. - Varsayılanları koru: Eloquent (ham SQL değil), Blade {{ }} ({!! !!} değil), mass assignment koruması ($fillable + validate), CSRF açık. - APP_KEY/.env gizli (Bölüm 25): Commit etme, web'de erişilemez, sır yöneticisi. - Doğrulama (validate) + yetkilendirme (Gate/Policy — Bölüm 14): Girdi ve erişim kontrolü. - php.ini sertleştirme (Bölüm 26): display_errors=Off (ek katman).

9. Patch Analizi

Neden işe yarar? APP_DEBUG=false, Ignition RCE'nin (CVE-2021-3129) ön koşulunu — açık debug uç noktasını — kaldırır ve bilgi ifşasını (Bölüm 26) kapatır; bu tek ayar, Laravel'in en tehlikeli açığını önler. Güncel Ignition, zinciri kodda da kapatır (isSafePath doğrulaması). Varsayılanları korumak (Eloquent, Blade, mass assignment, CSRF), kitabın temel açık sınıflarını (Bölüm 6/7/4/17) Laravel bağlamında önler. APP_KEY/.env koruması (Bölüm 25), sır sızıntısı ve forge saldırılarını engeller.

Debug mode etkisi:

Ayar	Sonuç
`APP_DEBUG=true` (üretim) + savunmasız Ignition	Kimlik-doğrulamasız RCE (CVE-2021-3129)
`APP_DEBUG=true` + yamalı Ignition	Hâlâ bilgi ifşası (yol/kaynak/env)
`APP_DEBUG=false`	İfşa yok + Ignition uç noktası kapalı

Bu tablo, neden APP_DEBUG=false'un tek başına en yüksek-etkili Laravel savunması olduğunu gösterir: hem RCE ön koşulunu hem ifşayı kapatır.

Neden CVE-2021-3129 öğretici: Tek bir yanlış yapılandırma (debug), birkaç açık sınıfının (dosya işlemi Bölüm 20, wrapper Bölüm 20, deserialization Bölüm 11) birleşmesine kapı açtı. Derinlemesine savunma (debug kapalı + güncel framework + varsayılanlar) her katmanı kapatır.

Performans: Güvenli varsayılanların (Eloquent, Blade) performans etkisi ihmal edilebilir; APP_DEBUG=false üretimde zaten daha hızlıdır (debug toplama yok). Güvenlik kazancı çok büyüktür.

10. Gerçek Hayat Senaryosu

Kurgu — bir startup'ın Laravel API'si. Ekip, hızlı hata ayıklama için üretimde APP_DEBUG=true bırakmış ve Ignition'ı güncellememiş. Bir saldırgan, bir hata tetikleyip ayrıntılı hata sayfasını görüyor (debug açık), Ignition sürümünü belirliyor ve CVE-2021-3129 ile kimlik-doğrulamasız RCE elde ediyor (log poisoning + phar — Bölüm 11, 20); sunucuda .env'den DB ve ödeme API sırlarını (Bölüm 25) okuyor. Doğru yapılandırmayla: APP_DEBUG=false (Ignition uç noktası kapalı + ifşa yok) + güncel Ignition → saldırı en baştan engellenirdi. Dersler: (1) debug mode üretimde asla açık kalmamalı — tek ayar, RCE'yi önler; (2) framework/Ignition güncel tutulmalı (Bölüm 30); (3) .env/APP_KEY korunmalı (Bölüm 25).

11. Gerçek CVE Analizi — Laravel Ignition RCE (CVE-2021-3129)

Ambionics/Lexfo bulgusu, MITRE/NVD ve satıcı (Ignition/Laravel) danışmalarıyla doğrulanmıştır. Silahlaştırılmış zincir verilmez.

Özet. Kasım 2020'de Ambionics Security (Lexfo), Laravel'in hata ayıklayıcısı Ignition'da (sürüm < 2.5.2) kimlik-doğrulamasız uzaktan kod çalıştırma açığı buldu; CVE-2021-3129 atandı. Açık, APP_DEBUG=true (debug mode) ile çalışan Laravel <= 8.4.2 kurulumlarını etkiliyordu. Ambionics açığı bir yamayla birlikte bildirdi ve ertesi gün Ignition 2.5.2 yayımlandı; ama debug mode üretimde açık bırakan sayısız kurulum savunmasız kaldı ve açık kitlesel olarak sömürüldü (CISA KEV).

Teknik neden — debug uç noktası + doğrulanmamış dosya işlemleri + phar deserialization. Ignition, geliştiriciye hataları için "çözümler" (solutions) öneren bir özellik sunar; bazı çözümler _ignition/execute-solution uç noktası üzerinden çalıştırılabilir. Bu uç nokta yalnızca debug mode açıkken erişilebilirdir. Açığın kökü, MakeViewVariableOptionalSolution sınıfının kullanıcı-kontrollü viewFile parametresiyle file_get_contents() ve file_put_contents()'i yol/uzantı doğrulaması olmadan çağırmasıydı. Ambionics'in gösterdiği zincir (kavramsal): 1. _ignition/execute-solution'a hazırlanmış bir POST isteği (debug açık olduğundan erişilebilir). 2. Doğrulanmamış file_get_contents/file_put_contents, php://filter (Bölüm 20) ile Laravel'in log dosyasını (storage/logs/laravel.log — her PHP hatasını kaydeder) manipüle etmeye izin verdi. 3. Log poisoning: Saldırgan, log'a bir phar payload'ı (phpggc gibi araçlarla üretilen bir gadget zinciri — Bölüm 11) enjekte etti. 4. Log dosyası php://filter ile bir PHAR'a dönüştürülüp phar:// üzerinden deserialize edildi → gadget zinciri çalıştı → RCE.

Bu zincir, kitabın üç bölümünün tek noktada birleşmesidir: config/debug (Bölüm 26), dosya wrapper'ları ve log poisoning (Bölüm 20), ve phar deserialization (Bölüm 11) — ve hepsinin ortak ön koşulu açık debug modedur. Yama (isSafePath), dosya yollarını/uzantılarını doğrulayarak 2. adımı kapattı; ama asıl ders, debug mode'un üretimde hiç açık olmaması gerektiğidir.

Etki. Kimlik-doğrulamasız RCE; www-data/web kullanıcısı bağlamında (oradan Bölüm 28 yetki yükseltmesine açık). Debug mode açık bırakan çok sayıda Laravel sitesi kitlesel olarak tarandı ve sömürüldü.

Çıkarılacak dersler: 1. Debug mode üretimde felakettir. APP_DEBUG=false; bu tek ayar hem RCE ön koşulunu hem ifşayı kapatır (Bölüm 26). 2. Framework/bağımlılıkları güncel tut (Bölüm 30). Ignition require-dev bir bağımlılıktı; yama (2.5.2) mevcuttu — güncellemeyenler sömürüldü. 3. Zincirler derinlemesine savunma gerektirir. RCE, birkaç açık sınıfının (Bölüm 26, 20, 11) birleşimiydi; her katman ayrı bir savunma fırsatıydı. 4. Debug araçları güçlü uç noktalar açar. Geliştirme kolaylığı sağlayan araçlar (Ignition), üretimde erişilebilir olduğunda birer saldırı yüzeyidir.

12. Detection

Kod/yapılandırma incelemede:

grep -rn 'APP_DEBUG' .env* config/                              # üretimde true mu?
composer show | grep -i ignition                                # Ignition sürümü (>=2.5.2?)
grep -rnE 'DB::(select|statement|raw)|whereRaw|orderByRaw' app/ | grep -vE '\?|\[' # ham SQL
grep -rn '{!!' resources/views/                                 # kaçışsız Blade (XSS)
grep -rn '::create(\$request->all()\|::update(\$request->all()' app/  # mass assignment

Kontroller: APP_DEBUG=false mu (üretim)? Ignition güncel mi? Ham SQL/kaçışsız çıktı/korumasız mass assignment var mı? CSRF açık mı? .env gitignore'lu mu?

SCA (Bölüm 30): composer audit ile Ignition/Laravel bilinen açıklarını (CVE-2021-3129) tespit et.

DAST: Açık debug mode (ayrıntılı hata sayfası), _ignition/execute-solution erişilebilirliği, ham SQL/XSS/mass assignment testleri.

Loglar/SIEM (Bölüm 31): _ignition/execute-solution'a istekler; php://filter/phar:// içeren istekler; log dosyasına anormal yazma; web sürecinden alt süreç (RCE sonrası — Bölüm 28, 34). Ignition uç noktasına dış erişim güçlü bir sömürü işaretidir.

13. Prevention

APP_DEBUG=false (üretim) — en kritik: Ignition RCE + ifşa (Bölüm 26).
Framework/Ignition güncel (Bölüm 30): CVE-2021-3129 yaması; SCA.
Varsayılanları koru: Eloquent (ham SQL değil — Bölüm 6), Blade {{ }} (Bölüm 7), mass assignment koruması $fillable+validate (Bölüm 4), CSRF açık (Bölüm 17).
APP_KEY/.env gizli (Bölüm 25): Commit etme, web'de erişilemez, sır yöneticisi.
Yetkilendirme (Gate/Policy — Bölüm 14) + doğrulama (validate).
php.ini sertleştirme (Bölüm 26): display_errors=Off (ek katman).

14. Mitigation

Acil: APP_DEBUG=false yap; Ignition/Laravel'i yamalı sürüme güncelle; .env'i web'den ve git'ten kaldır; APP_KEY sızmışsa döndür (ve çerezleri/imzalı URL'leri geçersiz kıl).
Geçici: RCE olduysa web shell/kalıcılık tara (Bölüm 34); sızmış sırları döndür (Bölüm 25); kök nedeni (debug) düzelt (Bölüm 32).
Kalıcı: Üretim yapılandırmasını (APP_DEBUG=false) baseline yap; SCA + güncelleme sürecini kur; güvenli varsayılanları kod incelemesinde zorunlu kıl; .env/APP_KEY korumasını standartlaştır.

15. Checklist

[ ] Üretimde APP_DEBUG=false mu (Ignition RCE + ifşa — Bölüm 26)?
[ ] Ignition/Laravel güncel mi (CVE-2021-3129 yaması ≥ 2.5.2 — Bölüm 30)?
[ ] Ham SQL yerine Eloquent/binding mi kullanılıyor (Bölüm 6)?
[ ] Blade çıktısı {{ }} ile kaçışlı mı ({!! !!} kullanıcı verisiyle yok — Bölüm 7)?
[ ] Mass assignment korumalı mı ($fillable + validate — Bölüm 4)?
[ ] CSRF middleware açık mı ($except minimal — Bölüm 17)?
[ ] APP_KEY ve .env gizli mi (commit'siz, web'de erişilemez — Bölüm 25)?
[ ] Yetkilendirme (Gate/Policy — Bölüm 14) ve doğrulama (validate) kullanılıyor mu?
[ ] php.ini display_errors=Off mu (ek katman — Bölüm 26)?

16. Laboratuvar

Lab 36.1 — Debug mode ifşası. İzole bir Laravel'de APP_DEBUG'ı true/false arasında değiştir; bir hatada yol/kaynak/env ifşasını ve _ignition/execute-solution erişilebilirliğini gözlemle. false'a al.

Lab 36.2 — Varsayılanı atlama. whereRaw($input) ve {!! $input !!} ile SQLi/XSS'i göster; Eloquent binding ve {{ }} ile düzelt (Bölüm 6, 7).

Lab 36.3 — Mass assignment. create($request->all()) ile is_admin enjeksiyonunu göster; $fillable + validate ile düzelt (Bölüm 4).

Lab 36.4 — Ignition zinciri (kavramsal). CVE-2021-3129 zincirini (debug uç noktası → doğrulanmamış dosya işlemi → php://filter/log poisoning → phar deserialization) diyagramla; her halkanın hangi bölüme (26/20/11) karşılık geldiğini yaz.

17. Quiz

Laravel'in dört güvenli varsayılanını ve onları bozan kullanımları eşleştirin.
Neden Laravel'de çoğu açık "varsayılana geri dön" ile önlenir?
APP_DEBUG=true üretimde neden felakettir (iki sonuç)?
CVE-2021-3129 zinciri hangi bölümlerin (26/20/11) birleşimidir?
Ignition'ın _ignition/execute-solution uç noktası ne zaman erişilebilir?
Log poisoning + phar deserialization RCE'ye nasıl yol açtı (Bölüm 11, 20)?
DB::raw/whereRaw neden Eloquent'in güvenliğini bozar (Bölüm 6)?
{{ }} ile {!! !!} arasındaki fark nedir (Bölüm 7)?
$fillable mass assignment'ı nasıl önler (Bölüm 4)?
APP_KEY sızarsa hangi saldırılar mümkün olur (Bölüm 25)?
Neden APP_DEBUG=false tek başına en yüksek-etkili Laravel savunmasıdır?
Debug araçları (Ignition) neden üretimde bir saldırı yüzeyidir?

18. Kaynakça

Laravel dokümantasyonu, Security, Eloquent, Blade, CSRF Protection, Mass Assignment, Configuration (APP_DEBUG, APP_KEY).
Ambionics/Lexfo, Laravel <= v8.4.2 debug mode: Remote code execution (CVE-2021-3129); MITRE / NVD CVE-2021-3129; CISA KEV.
MITRE, CWE-502 (Deserialization — Bölüm 11), CWE-73 (External Control of File Name — Bölüm 20), CWE-215 (Information Exposure Through Debug — Bölüm 26).
OWASP, Top 10:2021 A05 Security Misconfiguration; phpggc (phar gadget) referansı (Bölüm 11).
Laravel Ignition deposu ve 2.5.2 yama notları.