Yapay zeka ile birkaç saatte çalışan bir web uygulaması çıkarabiliyoruz. Login var, dashboard açılıyor, API cevap veriyor, veritabanına kayıt gidiyor, hatta ödeme bile alabiliyoruz. Ekranda her şey yerli yerinde görünüyor.
Tam burada çok pahalı bir yanılgı başlıyor: bir uygulamanın çalışıyor olması, güvenli olduğu anlamına gelmez.
Bu iki cümlenin arasındaki mesafe, çoğu vibe coding projesinin gerçek risk yüzeyidir. Aşağıda önce bu mesafenin neden görünmez olduğunu, sonra da kapatmak için kullandığımız denetim yönteminin tamamını bulacaksınız. Yazının sonunda promptun tam metni var; kopyalayıp kendi projenizde çalıştırabilirsiniz.
"Çalışıyor, demek ki tamam" yanılgısı
Bir fonksiyonel hata kendini gösterir. Buton çalışmaz, sayfa açılmaz, kayıt düşmez. Geri bildirim anında gelir ve düzeltirsiniz.
Güvenlik açığı böyle davranmaz. Neredeyse hiçbiri uygulamanın çalışmasını engellemez. Butona basarsınız, çalışır. Login olursunuz, çalışır. Sipariş oluşturursunuz, çalışır. Ama aynı anda, URL'deki user_id değerini elle değiştiren başka bir kullanıcı sizin verinizi okuyor olabilir. Sistem bu sırada hiçbir hata vermez, çünkü kendi açısından doğru çalışmaktadır: kendisine sorulan kaydı getirmiştir. Sorulan kaydın soranın olup olmadığını kimse kontrol etmemiştir.
Yapay zeka destekli geliştirmede bu boşluk sistematik olarak büyür. Model sizden bir özellik ister, siz özelliği alırsınız. Model "bu endpoint'e yetki kontrolü de eklemeli miyim" diye sormaz, çünkü siz sormadınız. Üretilen kod çalışır, testleri geçer, demoda kusursuz görünür. Eksik olan şey koda yazılmayan şeydir ve kodda olmayan bir şeyi gözle görmek zordur.
Arka planda sizi bekleyen risk sınıfları
Aşağıdaki tablo, kod incelemelerinde en sık karşılaştığımız açık ailelerini toplar. Ortak özellikleri şudur: hiçbiri uygulamanın çalışmasını engellemez.
| Risk sınıfı | Pratikte ne demek |
|---|---|
| IDOR / BOLA | Nesnenin sahipliği doğrulanmıyor. Kimlik numarasını değiştiren kullanıcı başkasının kaydını görüyor. |
| Broken Access Control | Yetki kontrolü yalnızca arayüzde var. Sunucu, isteği kimin gönderdiğine bakmadan işliyor. |
| SQL / NoSQL Injection | Kullanıcı girdisi sorguya birleştirilerek ekleniyor. Sorgunun anlamı dışarıdan değiştirilebiliyor. |
| XSS / CSRF | Kullanıcı içeriği kaçışsız basılıyor veya durum değiştiren istekler köken doğrulaması olmadan kabul ediliyor. |
| Açık API uçları | Kimlik doğrulaması istemeyen, unutulmuş veya iç kullanım sanılan uçlar dışarıya açık. |
| Hatalı authorization | Kimlik doğrulama yetkilendirme sanılıyor. Giriş yapmış olmak, o kaydı görmeye hak kazanmak sayılıyor. |
| Token ve oturum sorunları | Süre yok, rotasyon yok, iptal yok. Bir kez sızan token süresiz geçerli. |
| Sızdırılmış anahtarlar | Tarayıcıya giden pakette API anahtarı bulunuyor. Tarayıcıya gönderilen sır artık sır değildir. |
| Güvensiz dosya yükleme | Yalnızca uzantıya bakılıyor. İçeriğin gerçekte ne olduğu, nereye yazıldığı ve kimin indirebildiği denetlenmiyor. |
| Rate limit eksikliği | Kaba kuvvet, OTP deneme ve maliyetli uçların tüketimi serbest. |
| Rol yükseltme | Normal kullanıcı, kendi rolünü veya başkasının rolünü değiştirebiliyor. |
| Bağımlılık açıkları | Bilinen CVE taşıyan, uzun süredir güncellenmeyen veya terk edilmiş paketler. |
| SSRF | Sunucu, kullanıcının verdiği adrese istek atıyor ve iç ağa veya bulut metadata ucuna zorlanabiliyor. |
| Webhook açıkları | İmza doğrulanmıyor, zaman damgası kontrol edilmiyor, aynı istek tekrar oynatılabiliyor. |
| İş mantığı suistimali | Kupon tekrar kullanılıyor, fiyat manipüle ediliyor, ödeme adımı atlanıyor. |
| Yapay zeka maliyet saldırıları | Saldırgan sizin adınıza token yakıyor. Fatura sizin, kullanım onun. |
Yapay zekaya "açık var mı" diye sormak neden yetmez?
Kod tabanınızı bir modele verip "güvenlik açığı var mı" diye sorduğunuzda genellikle nazik ve yüzeysel bir cevap alırsınız. Model birkaç genel öneri sıralar, bir iki iyi uygulamadan bahseder ve çoğu zaman iyimser bir sonuç cümlesi kurar. Bunun nedeni modelin yetersiz olması değil, sorunun yetersiz olmasıdır.
İşe yarayan yöntem üç şeyi aynı anda yapmaktır:
- Rol vermek. Modeli Senior Application Security Engineer, Security Architect ve savunma amaçlı sızma testi uzmanı rolüne birlikte sokmak. Kod kalitesi incelemesi değil, güvenlik denetimi istediğinizi baştan netleştirmek.
- Fazlara bölmek. Tek bir büyük soru yerine, saldırı yüzeyi haritasından üretim yapılandırmasına kadar sırayla ilerleyen kapalı uçlu fazlar tanımlamak.
- Doğrulanamayanı işaretletmek. Modelin göremediği bir kontrolü varmış gibi kabul etmesini açıkça yasaklamak.
Üçüncü madde en kritik olanıdır ve genellikle atlanır. Bir güvenlik denetiminde en tehlikeli çıktı, bulunan açık değildir. Kontrol edilmediği halde kontrol edilmiş gibi sunulan alandır. Bu yüzden promptun içinde doğrulanamayan her şeyin NOT VERIFIED olarak işaretlenmesi zorunlu tutulur.
Denetimin kapsadığı alanlar
Prompt, uygulamayı katman katman inceletir. Kapsanan alanlar ve her birinde asıl aranan soru:
1. Saldırı yüzeyi ve güven sınırları
Frontend, API, backend, veritabanı ve dış servisler arasındaki akış çıkarılır. Sisteme dışarıdan veri giren bütün noktalar işaretlenir. Denetimin geri kalanı bu haritanın üzerinde yürür.
2. Kimlik doğrulama
Giriş, kayıt, parola sıfırlama, e-posta doğrulama, çok adımlı doğrulama, kaba kuvvet koruması, hesap sayımı ve parola saklama. Parolalar Argon2id, bcrypt veya scrypt ile saklanmıyorsa bulgu doğrudan kritik sayılır.
3. Yetkilendirme
Denetimin en yüksek öncelikli bölümü. Kimlik doğrulamanın yetkilendirme sanılması, yatay ve dikey rol yükseltme, kiracı izolasyonu ve nesne sahipliği. Tek bir soruya indirgenir: A kullanıcısı, B kullanıcısının verisine erişebilir, değiştirebilir, silebilir veya indirebilir mi?
4. API güvenliği
Her uç için dört soru: kimlik doğrulaması var mı, yetkilendirme var mı, hız sınırı var mı, gereğinden fazla veri dönüyor mu? Buna eski API sürümleri, hata ayıklama uçları ve gevşek CORS yapılandırması eklenir.
5. Oturum ve token güvenliği
JWT, çerezler, yenileme token'ları, süre, rotasyon, iptal, çıkışta geçersiz kılma, HttpOnly, Secure ve SameSite. JWT tarafında imza doğrulaması, algoritma yapılandırması ve yük içinde taşınan hassas bilgi ayrıca incelenir.
6. Girdi doğrulama ve enjeksiyon
SQL, NoSQL, komut enjeksiyonu, dizin geçişi, SSRF ve toplu atama. Burada değişmez bir kural vardır: arayüz tarafındaki doğrulama bir güvenlik önlemi değildir. Sunucu, kendisine gelen her şeyi güvenilmez kabul etmek zorundadır.
7. XSS ve CSRF
Depolanmış, yansıtılmış ve DOM tabanlı XSS; durum değiştiren isteklerde token, SameSite ve köken doğrulaması. Parola değişikliği, e-posta değişikliği, ödeme ve hesap silme işlemleri ayrıca ele alınır.
8. Dosya yükleme
MIME türü, sihirli baytlar, boyut, çalıştırılabilir içerik, SVG ve HTML yüklemeleri, depolama konumu, herkese açık erişim ve indirme öncesi yetki kontrolü. Sorulan soru şudur: saldırgan, başka bir kullanıcının tarayıcısında veya sunucuda çalışan bir içerik yükleyebilir mi?
9. Sır yönetimi
Ortam dosyaları, kaynak kod, arayüz paketleri, yapılandırma, CI/CD ve konteyner dosyaları taranır. Tarayıcıya ulaşan her sır, aksi açıkça tasarlanmadıysa sızmış kabul edilir.
10. Bağımlılıklar ve tedarik zinciri
Bilinen açık taşıyan paketler, ciddi biçimde geride kalmış sürümler, terk edilmiş kütüphaneler, gereksiz bağımlılıklar ve kurulum betikleri.
11. Kayıt ve izleme
Başarısız girişler, yetki değişiklikleri, yönetici işlemleri ve izin hataları kayda giriyor mu? Diğer taraftan aynı derecede önemli olan ters soru: parola, token veya kişisel veri yanlışlıkla kayıtlara düşüyor mu?
12. Yedekleme ve kurtarma
Yedek almakla geri dönebilmek aynı şey değildir. Üretim veritabanı bugün tamamen silinse sistemi gerçekten ayağa kaldırabilir misiniz? Yedeklerin şifrelenmesi, erişim denetimi ve geri yükleme testi bu bölümde sorgulanır.
13. İş mantığı ve yarış koşulları
Saldırgan her zaman sistemi kırmak zorunda değildir. Meşru işlevi suistimal etmek çoğu zaman daha ucuzdur. Kupon tekrar kullanılabiliyor mu, fiyat değiştirilebiliyor mu, ödeme adımı atlanabiliyor mu, eşzamanlı istekler bir kotayı aşabiliyor mu?
14. Yapay zeka güvenliği
Uygulamanızda bir model çağrısı varsa yüzey genişler: prompt enjeksiyonu, dolaylı prompt enjeksiyonu, sistem promptunun sızması, kullanıcılar arası bağlam sızıntısı, araç yetkilendirmesi ve maliyet suistimali. Değişmeyen kural: bir model çıktısı hiçbir zaman yetkilendirme yerine geçmez.
Bulgudan ne istemeli?
Açıkların listesi tek başına işe yaramaz. Denetimin çıktısı, üzerinde iş yapılabilir bir kayıt olmalıdır. Her bulgu için şu alanlar istenir:
| Alan | Neden gerekli |
|---|---|
| Severity ve Confidence | Aciliyeti ve bulgunun ne kadar kesin olduğunu ayırır. |
| CWE ve OWASP kategorisi | Bulguyu ortak bir dile bağlar, tekrar aranabilir yapar. |
| Etkilenen dosya, bileşen ve uç | Düzeltmeyi arama işi olmaktan çıkarır. |
| Evidence | İddiayı koda dayandırır. Kanıtı olmayan bulgu tahmindir. |
| Attack Scenario | Açığın gerçekte nasıl kullanılacağını gösterir. |
| Business Impact | Teknik bulguyu karar verilebilir bir riske çevirir. |
| Remediation ve kod önerisi | Ne yapılacağını değil, nasıl yapılacağını söyler. |
| Verification | Düzeltmenin gerçekten işe yaradığını nasıl doğrulayacağınızı yazar. |
Bulgular sonunda dört kovaya ayrılır: P0 hemen düzelt, P1 üretime çıkmadan düzelt, P2 en kısa zamanda düzelt, P3 sertleştirme. Bu ayrım olmadan uzun bir liste, sırası belli olmadığı için hiç düzeltilmez.
Sonunda net cevap istenen 12 soru
Rapor ne kadar uzun olursa olsun, denetimin sonunda şu soruların açık cevabı istenir. Bunlar denetimi kapatan sorulardır:
- Bu uygulamayı bugün üretime çıkarır mıydın?
- A kullanıcısı, B kullanıcısının verisine erişebilir mi?
- Normal bir kullanıcı yönetici işlevlerine ulaşabilir mi?
- Sızmış bir sır var mı?
- Kimlik doğrulama ve oturum yönetimi üretime uygun mu?
- Kritik uçlarda hız sınırı var mı?
- Dosya yükleme güvenli mi?
- Bağımlılıklar makul ölçüde güvenli mi?
- Hassas veriler yeterince korunuyor mu?
- Saldırgan ciddi bir API veya yapay zeka maliyeti oluşturabilir mi?
- Veri kaybından sonra sistem kurtarılabilir mi?
- Üretim öncesi çözülmesi gereken ilk beş açık ne?
Bu denetimin sınırları
Açık olalım: bu prompt uygulamanızı güvenli yapmaz. Yapay zeka destekli bir kod denetimi; profesyonel sızma testinin, altyapı denetiminin, çalışma zamanı testlerinin ve insan gözden geçirmesinin yerine geçmez. Model yalnızca kendisine verilen kodu ve yapılandırmayı görür. Sunucu yapılandırmanızı, ağ kurallarınızı, bulut izinlerinizi ve üretimde gerçekten ne olduğunu göremez.
Yaptığı şey daha mütevazı ama gerçek: çok güçlü bir ilk savunma hattı kurar. Kimsenin bakmadığı yerlere sistematik olarak bakar ve sizi kendi kör noktalarınızla yüzleştirir. Çoğu vibe coding projesinde bugün eksik olan tam olarak budur.
Çünkü güvenlikte en pahalı açık, bulduğunuz açık değildir. Varlığından bile haberiniz olmayan açıktır.
Promptun tam metni
Aşağıdaki metnin tamamını olduğu gibi kopyalayın ve projenizin kod tabanına erişimi olan bir yapay zeka aracında çalıştırın. Metin serbestçe paylaşılabilir.
Bu web uygulamasının kurumsal seviyede güvenlik denetimini yapan bir Senior Application Security Engineer, Security Architect ve savunma amaçlı sızma testi uzmanı olarak davran.
Amacın kod kalitesini gözden geçirmek DEĞİLDİR.
Amacın; uygulamanın TAMAMINDA güvenlik açıklarını, kırılmış güven sınırlarını, yetkilendirme hatalarını, veri sızıntısı risklerini, güvensiz mimariyi, yapılandırma hatalarını, bağımlılık risklerini ve üretim güvenliği zayıflıklarını tespit etmektir.
Bu uygulamanın ileride gerçek kullanıcılar, kişisel veriler, kimlik doğrulama, ödemeler, yüklenen dosyalar, API entegrasyonları ve yönetici işlevleri barındırabileceğini varsay.
TEMEL KURALLAR
1. Uygulama çalışıyor diye güvenli olduğunu varsayma.
2. Arayüz tarafındaki doğrulamaya ve arayüz tarafındaki yetkilendirmeye güvenme.
3. İstemcinin kontrol ettiği bütün veriyi güvenilmez kabul et.
4. Önemli güvenlik kontrollerini arayüzden API'ye, API'den backend'e, backend'den veritabanına ve dış servislere kadar uçtan uca izle.
5. Kontrolleri mümkün olan her yerde gerçek koddan veya yapılandırmadan doğrula.
6. Riski oluşturan somut kod yolunu veya yapılandırmayı açıklamadan teorik açık bildirme.
7. Üretim verisini değiştirme ve yıkıcı test yapma.
8. Raporunda gerçek sırları açığa çıkarma. Bir sır bulursan maskele.
9. Depodan doğrulanamayan bir şey varsa bunu açıkça "NOT VERIFIED" olarak işaretle.
10. Şu ayrımı net biçimde yap:
- Doğrulanmış açık
- Muhtemel açık
- Güvenlik zayıflığı
- Sertleştirme önerisi
- Doğrulanamadı
Referans olarak OWASP Top 10, OWASP API Security Top 10, CWE, tasarımdan güvenli olma ilkesi, en az yetki, katmanlı savunma ve sıfır güven varsayımlarını kullan.
FAZ 1 - UYGULAMA VE SALDIRI YÜZEYİ HARİTASI
Açık bildirmeden önce uygulamayı anla.
Şunları belirle:
- Uygulama mimarisi
- Arayüz çatısı
- Backend çatısı
- API mimarisi
- Veritabanları
- Kimlik doğrulama sistemi
- Yetkilendirme modeli
- Oturum ve token mekanizması
- Yönetici işlevleri
- Kullanıcı rolleri
- Dosya yükleme işlevi
- Dış API'ler
- Webhook'lar
- Arka plan işleri
- Ödeme entegrasyonları
- E-posta ve SMS entegrasyonları
- Depolama servisleri
- CDN ve proxy altyapısı
- Ortam yapılandırması
- Kayıt ve izleme sistemleri
- Yedekleme mekanizmaları
- CI/CD yapılandırması
- Üretim ve geliştirme farkları
Bir GÜVEN SINIRI HARİTASI çıkar.
Güvenilmez verinin sisteme girdiği her noktayı işaretle.
FAZ 2 - GİRDİ DOĞRULAMA
Dışarıdan gelen BÜTÜN girdileri denetle:
- Formlar
- URL parametreleri
- Sorgu parametreleri
- JSON gövdeleri
- Başlıklar
- Çerezler
- Dosya yüklemeleri
- Webhook'lar
- API istekleri
- Arama alanları
- Filtreler
- Kimlik numaraları
- Sayfalama
- Yönlendirme adresleri
- Zengin metin ve HTML girdileri
Şunları kontrol et:
- Sunucu tarafı doğrulama
- Tür doğrulaması
- Uzunluk sınırları
- İzin listesi yaklaşımı
- Temizleme
- Kodlama
- Beklenmeyen iç içe nesneler
- Toplu atama ve fazla alan gönderimi
- Uygulanabiliyorsa prototype pollution
- Komut ve dizin geçişi riskleri
- SQL ve NoSQL enjeksiyon riskleri
Arayüz tarafındaki doğrulama bir güvenlik kontrolü SAYILMAMALIDIR.
FAZ 3 - KİMLİK DOĞRULAMA
Şunları denetle:
- Giriş
- Kayıt
- Parola sıfırlama
- E-posta doğrulama
- Varsa çok adımlı doğrulama
- Hesap kurtarma
- Kaba kuvvet koruması
- Credential stuffing dayanıklılığı
- Hesap sayımı
- Varsayılan kimlik bilgileri
- Parola politikaları
- Parola saklama
Parolaların modern ve uygun bir özetleme algoritmasıyla saklandığını doğrula:
- Argon2id
- bcrypt
- scrypt
Güvensiz özetlemeyi veya geri çevrilebilir parola saklamayı KRİTİK olarak işaretle.
FAZ 4 - OTURUM VE TOKEN GÜVENLİĞİ
Şunları incele:
- Çerezler
- JWT
- OAuth token'ları
- Yenileme token'ları
- API token'ları
- Oturum kimlikleri
Şunları doğrula:
- Süre sonu
- Rotasyon
- İptal
- Güvenli saklama
- HttpOnly
- Secure
- SameSite
- Çıkışta geçersiz kılma
- Oturum sabitleme koruması
- Token sızıntısı ihtimalleri
- Tekrar oynatma riskleri
JWT için ayrıca şunları incele:
- İmza doğrulaması
- Algoritma yapılandırması
- Süre sonu
- Issuer
- Audience
- Anahtar yönetimi
- Yük içinde saklanan hassas bilgiler
FAZ 5 - YETKİLENDİRME VE ERİŞİM KONTROLÜ
BU BÖLÜM YÜKSEK ÖNCELİKLİDİR.
Kimlik doğrulamanın yetkilendirme anlamına geldiğini varsayma.
Rolleri ve izinleri çıkar.
Hassas olan HER backend ve API işleminde sunucu tarafı yetkilendirme kontrolü yap.
Özellikle şunları araştır:
- IDOR
- BOLA
- Broken Function Level Authorization
- Yatay rol yükseltme
- Dikey rol yükseltme
- Kiracı izolasyonu hataları
- Kullanıcıdan yöneticiye yükselme
- Nesne sahipliği doğrulaması
Şu biçimde kimlik numarası kullanan her uç için:
/users/{id}
/orders/{id}
/files/{id}
/appointments/{id}
/messages/{id}
numarayı değiştirmenin başka bir kullanıcının kaynağını açığa çıkaramadığını doğrula.
Şunu sor:
"A kullanıcısı, B kullanıcısının kaynaklarına erişebilir, bunları değiştirebilir, silebilir, indirebilir veya listeleyebilir mi?"
FAZ 6 - YÖNETİCİ GÜVENLİĞİ
BÜTÜN yönetici işlevlerini belirle.
Şunları doğrula:
- Kimlik doğrulama
- Yetkilendirme
- Rol doğrulaması
- Sunucu tarafında zorlama
- Hassas işlem koruması
- Denetim kaydı
Arayüzdeki şu ifadeyi asla yeterli yetkilendirme olarak kabul etme:
if (user.role === "admin")
Zorlamanın sunucuda yapıldığını doğrula.
FAZ 7 - API GÜVENLİĞİ
BÜTÜN API uçlarını çıkar.
Her uç için şunları belirle:
- Kimlik doğrulama şartı
- Yetkilendirme şartı
- İzin verilen HTTP metotları
- Girdi şeması
- Hız sınırları
- Dönen hassas veriler
- Nesne sahipliği şartları
Şunları ara:
- Kimlik doğrulaması olmayan uçlar
- Aşırı veri ifşası
- Toplu atama
- BOLA
- BFLA
- Eksik hız sınırları
- Sayım
- Güvensiz CORS
- Ayrıntılı hata mesajları
- Gizli ve hata ayıklama uçları
- Eski API sürümleri
- Varsa GraphQL introspection ve ifşası
FAZ 8 - HIZ SINIRI VE SUISTIMAL KORUMASI
Şunlar için hız sınırını doğrula:
- Giriş
- Kayıt
- Parola sıfırlama
- OTP
- E-posta doğrulama
- Arama
- İletişim formları
- Yorumlar
- Dosya yüklemeleri
- Yapay zeka uçları
- Maliyetli sorgular
- Herkese açık API'ler
- Uygunsa webhook'lar
Şunları değerlendir:
- IP bazlı sınırlar
- Hesap bazlı sınırlar
- Uç bazlı sınırlar
- Dağıtık suistimale dayanıklılık
- Uygun yerlerde CAPTCHA ve bot koruması
FAZ 9 - ENJEKSİYON SALDIRILARI
Şunları denetle:
- SQL Injection
- NoSQL Injection
- Command Injection
- LDAP Injection
- Template Injection
- Header Injection
- CRLF Injection
- Path Traversal
- SSRF
Veritabanı sorgularını ve ORM kullanımını incele.
Güvenilmez girdi içeren güvensiz metin birleştirmelerini işaretle.
FAZ 10 - XSS
Şunları kontrol et:
- Stored XSS
- Reflected XSS
- DOM XSS
Şunları incele:
- Kullanıcı üretimi içerik
- Yorumlar
- Profiller
- Arama
- Zengin metin editörleri
- HTML işleme
- Tehlikeli HTML API'leri
- Güvensiz şablon işleme
Uygunsa Content Security Policy yapılandırmasını değerlendir.
FAZ 11 - CSRF
Durum değiştiren işlemleri incele.
Korumanın şunlardan biriyle sağlandığını doğrula:
- CSRF token'ları
- SameSite çerezler
- Köken doğrulaması
- Çatı düzeyinde korumalar
Özellikle şunlara dikkat et:
- Parola değişiklikleri
- E-posta değişiklikleri
- Ödemeler
- Hesap silme
- Yönetici işlemleri
FAZ 12 - DOSYA YÜKLEME GÜVENLİĞİ
Yükleme varsa şunları incele:
- MIME doğrulaması
- Uzantı doğrulaması
- Sihirli bayt ve içerik doğrulaması
- Dosya boyutu sınırları
- Dosya adı işleme
- Dizin geçişi
- Depolama konumu
- Herkese açıklık
- Çalıştırılabilir dosyalar
- SVG ve HTML yüklemeleri
- Zararlı yazılım taraması
- Görsel işleme
- Meta veri
- İmzalı adresler
- İndirme öncesi yetkilendirme
Saldırganın, başka bir kullanıcının tarayıcısında veya sunucuda çalışan bir içerik yükleyip yükleyemeyeceğini belirle.
FAZ 13 - SIR YÖNETİMİ
Depoda ve yapılandırmada şunları ara:
- API anahtarları
- Veritabanı kimlik bilgileri
- JWT sırları
- OAuth sırları
- Bulut kimlik bilgileri
- Özel anahtarlar
- SMTP kimlik bilgileri
- Ödeme sırları
- Webhook sırları
- Servis hesabı kimlik bilgileri
Şunları incele:
.env dosyaları
kaynak kod
arayüz paketleri
yapılandırma dosyaları
CI/CD
Docker dosyaları
örnek dosyalar
kayıtlar
erişilebiliyorsa Git ile ilgili dosyalar
KRİTİK:
Tarayıcıya veya istemci tarafı JavaScript'e ulaşan sırlar, açıkça herkese açık olacak şekilde tasarlanmadıysa sızmış kabul edilmelidir.
Bulduğun sırları yazma.
Maskele.
FAZ 14 - BAĞIMLILIK VE TEDARİK ZİNCİRİ GÜVENLİĞİ
Bağımlılık listelerini ve kilit dosyalarını incele.
Şunları belirle:
- Bilinen açığı olan bağımlılıklar
- Ciddi biçimde geride kalmış paketler
- Terk edilmiş kütüphaneler
- Şüpheli paketler
- Gereksiz bağımlılıklar
- Dependency confusion riskleri
- Güvensiz kurulum betikleri
Araç varsa uygun bağımlılık ve güvenlik denetim araçlarını çalıştır.
FAZ 15 - GÜVENLİK BAŞLIKLARI VE TARAYICI GÜVENLİĞİ
Şunları gözden geçir:
- Content-Security-Policy
- Strict-Transport-Security
- X-Content-Type-Options
- Referrer-Policy
- Permissions-Policy
- Çerçeve koruması ve frame-ancestors
Ayrıca şunları incele:
- CORS
- Çerez güvenliği
- HTTPS zorlaması
- Karışık içerik
- Hassas verinin önbelleğe alınması
FAZ 16 - VERİ KORUMA
Uygulamanın işlediği hassas bilgileri belirle.
Şunları kontrol et:
- Hassas veri ifşası
- Kişisel veri sızıntısı
- Kayıtlardaki sırlar
- Aşırı API yanıtları
- Aktarımda şifreleme
- Gerekiyorsa durağan halde şifreleme
- Veri saklama süresi
- Hesap silme
- Yedek ifşası
- Veritabanı erişim kontrolleri
Veri minimizasyonu ilkesini uygula.
FAZ 17 - KAYIT, İZLEME VE DENETİM
Güvenlikle ilgili olayların kayda geçip geçmediğini belirle:
- Başarısız girişler
- Parola değişiklikleri
- E-posta değişiklikleri
- Yetki değişiklikleri
- Yönetici işlemleri
- Hesap silme
- Şüpheli API etkinliği
- İzin hataları
- Güvenlik yapılandırması değişiklikleri
Kayıtların yanlışlıkla şunları içerip içermediğini kontrol et:
- Parolalar
- Token'lar
- API anahtarları
- Hassas kişisel bilgiler
Anormal davranış için uyarı ve izleme olup olmadığını değerlendir.
FAZ 18 - YEDEKLEME VE KURTARMA
Şunları belirle:
- Yedek alınıp alınmadığı
- Yedekleme sıklığı
- Şifreleme
- Erişim kontrolü
- Saklama süresi
- Geri yükleme testi
- Gerekiyorsa coğrafi veya sağlayıcı ayrımı
Şunu sor:
"Üretim verisi bugün kaybolsa bu sistem gerçekten geri getirilebilir mi?"
FAZ 19 - İŞ MANTIĞI GÜVENLİĞİ
Denetimi klasik teknik açıklarla sınırlama.
Kullanıcıların meşru işlevi suistimal edip edemeyeceğini analiz et.
Örnekler:
- Kuponu tekrar kullanmak
- Fiyatı manipüle etmek
- Ödeme adımlarını atlamak
- Adetleri değiştirmek
- İstekleri tekrar oynatmak
- İş akışı durumlarını atlamak
- Sınırsız kaynak oluşturmak
- İadeleri suistimal etmek
- Randevu sahipliğini manipüle etmek
- Kullanım sınırlarını aşmak
Geçerli işlevi suistimal eden bir saldırgan gibi düşün.
FAZ 20 - YARIŞ KOŞULLARI
Kritik işlemlerde eşzamanlılık sorunlarını incele:
- Ödemeler
- Kuponlar
- Stok
- Krediler
- Hesap bakiyeleri
- Randevu saatleri
- Kaynak sınırları
Eşzamanlı isteklerin iş kurallarını atlatıp atlatamayacağını belirle.
FAZ 21 - SSRF VE DIŞ İSTEK GÜVENLİĞİ
Sunucu, kullanıcının doğrudan veya dolaylı olarak verdiği adreslere istek atıyorsa SSRF açısından incele.
Şunlara erişime karşı korumayı doğrula:
- localhost
- özel ağlar
- bulut metadata uçları
- iç servisler
FAZ 22 - WEBHOOK GÜVENLİĞİ
Her webhook için şunları doğrula:
- İmza doğrulaması
- Zaman damgası doğrulaması
- Tekrar oynatma koruması
- Sır yönetimi
- Idempotency
- Yetkilendirme varsayımları
FAZ 23 - ÜRETİM YAPILANDIRMASI
Şunları ara:
- Hata ayıklama modu
- Yığın izleri
- Kaynak haritaları
- Geliştirme uçları
- Test hesapları
- Varsayılan parolalar
- Dışarı açık veritabanı ve yönetim arayüzleri
- Ayrıntılı hata mesajları
- Dizin listeleme
- Herkese açık depolama kovaları
- Yanlış yapılandırılmış ters proxy'ler
FAZ 24 - SERVİS DIŞI BIRAKMA VE KAYNAK TÜKETİMİ
Aşırı tüketim yapabilecek işlemleri belirle:
- CPU
- Bellek
- Veritabanı bağlantıları
- Disk
- Bant genişliği
- Üçüncü taraf API kredileri
- Yapay zeka ve API token'ları
Maliyetli dış servisleri tetikleyen uçlara özellikle dikkat et.
FAZ 25 - YAPAY ZEKAYA ÖZGÜ GÜVENLİK
Bu uygulamada yapay zeka veya LLM işlevi varsa ayrıca şunları denetle:
- Prompt injection
- Dolaylı prompt injection
- Sistem promptunun sızması
- Hassas bağlamın ifşası
- Kullanıcılar arası bağlam sızıntısı
- Araç ve fonksiyon yetkilendirmesi
- Aşırı özerklik
- Güvenilmez model çıktısı
- Dış yapay zeka sağlayıcılarına gönderilen veri
- Maliyet ve kaynak suistimali
- Hız sınırı
- Modelin ürettiği güvensiz veritabanı ve API işlemleri
Bir LLM yanıtını asla yetkilendirme olarak kabul etme.
NİHAİ ÇIKTI
Bir ENTERPRISE SECURITY AUDIT REPORT üret.
Şununla başla:
EXECUTIVE SUMMARY
Şunları içer:
- Genel güvenlik duruşu
- Önem derecesine göre bulgu sayısı
- En tehlikeli saldırı yolları
- Üretime hazırlık değerlendirmesi
Şu önem derecelerini kullan:
CRITICAL
HIGH
MEDIUM
LOW
INFORMATIONAL
HER bulgu için şunları ver:
ID:
TITLE:
SEVERITY:
CONFIDENCE:
CWE:
OWASP CATEGORY:
AFFECTED COMPONENT:
AFFECTED FILE(S):
AFFECTED ENDPOINT(S):
DESCRIPTION:
Tam olarak neyin yanlış olduğunu açıkla.
EVIDENCE:
Gerçek sırları açığa çıkarmadan ilgili kodu veya yapılandırmayı göster.
ATTACK SCENARIO:
Zayıflığın gerçekçi biçimde nasıl suistimal edilebileceğini açıkla.
BUSINESS IMPACT:
Bunun kullanıcılar, şirket ve veriler için ne anlama geldiğini açıkla.
REMEDIATION:
Önerilen düzeltmeyi ver.
CODE-LEVEL RECOMMENDATION:
Güvenli uygulama için kod düzeyinde yönlendirme ver.
VERIFICATION:
Geliştiricilerin düzeltmeyi nasıl doğrulayabileceğini açıkla.
ÖNCELİK MATRİSİ
Son olarak şunu oluştur:
P0 - HEMEN DÜZELT
P1 - ÜRETİM ÖNCESİ DÜZELT
P2 - EN KISA ZAMANDA DÜZELT
P3 - SERTLEŞTİRME
SON SORULAR
Sonda şu soruları açıkça cevapla:
1. Bu uygulamanın bugün üretime çıkmasına izin verir miydin?
2. A kullanıcısı, B kullanıcısının verisine erişebilir mi?
3. Normal bir kullanıcı yönetici işlevlerine ulaşabilir mi?
4. Açığa çıkmış bir sır var mı?
5. Kimlik doğrulama ve oturum mekanizmaları üretime uygun mu?
6. Kritik uçlarda hız sınırı var mı?
7. Dosya yüklemeleri güvenli mi?
8. Bağımlılıklar makul ölçüde güvenli mi?
9. Hassas veriler yeterince korunuyor mu?
10. Bir saldırgan ciddi düzeyde finansal veya API maliyeti oluşturabilir mi?
11. Uygulama veri kaybından kurtulabilir mi?
12. İlk olarak düzeltilmesi gereken EN ÖNEMLİ 5 açık nedir?
Bariz bir açık bulunmadı diye "her şey güvenli görünüyor" deme.
Gerçekte neyin doğrulandığını, neyin doğrulanmadığını ve neyin çalışma zamanı veya altyapı testi gerektirdiğini belirt.
Amaç raporun iyi görünmesi değildir.
Amaç, bu uygulamanın gerçek kullanıcılara ve düşman trafiğe güvenle dayanıp dayanamayacağını belirlemektir.