Web uygulama sızma testiyle yetkilendirme, oturum, enjeksiyon ve iş mantığı açıklarını gerçek saldırı senaryolarıyla belirliyor, düzeltme yolunu gösteriyoruz.
Son güncelleme: 13.10.2026
Sızma testinde uygulamanızı, gerçek bir saldırganın kullanacağı yöntemlerle ama sizin izninizle ve belirlediğimiz sınırlar içinde inceleriz. Amaç açık saymak değil, hangi açığın işinize gerçekten zarar verebileceğini göstermektir.
Otomatik tarayıcıların bulduklarını elle doğrular, tarayıcıların göremediği iş mantığı hatalarını ayrıca ararız.
Web uygulama sızma testi, internet üzerinden erişilen bir uygulamanın güvenlik kontrollerini gerçekçi saldırı senaryolarıyla değerlendiren kontrollü bir çalışmadır. Test uzmanı; bir saldırganın görebildiği giriş noktalarını, kullanıcı rollerini, oturum akışlarını ve işlevleri inceler. Ancak çalışma yalnızca sistem sahibinin yazılı izniyle, önceden kararlaştırılmış hedefler ve sınırlar içinde yürütülür.
Amaç mümkün olduğunca çok otomatik uyarı üretmek değildir. Asıl amaç, gerçekten kullanılabilen bir açığın hangi veriye, kullanıcıya veya iş sürecine zarar verebileceğini göstermektir. Bu nedenle bulgular yalnızca teknik adlarla sıralanmaz; saldırı ön koşulu, olası etki, yeniden üretme adımları ve uygulanabilir düzeltme önerisiyle birlikte raporlanır.
OWASP Web Security Testing Guide, web uygulaması testlerini bilgi toplama, yapılandırma, kimlik, yetkilendirme, oturum, girdi doğrulama, hata yönetimi, kriptografi, iş mantığı ve istemci tarafı kontrolleri gibi başlıklara ayırır. Biz de kapsamı uygulamanın mimarisine ve risklerine göre bu yaklaşım üzerinden şekillendiririz.
Otomatik tarama araçları bilinen hata kalıplarını hızlı biçimde aramak için değerlidir. Eksik güvenlik başlıkları, bazı enjeksiyon belirtileri veya güncel olmayan bileşenler gibi konularda iyi bir başlangıç sağlar. Fakat araç bir uygulamanın iş kuralını, kullanıcı rollerinin ne anlama geldiğini veya bir adımın neden yalnızca belirli kişilerce gerçekleştirilebilmesi gerektiğini her zaman anlayamaz.
Örneğin bir müşteri kendi faturasını görebiliyor olabilir. İstek içindeki kayıt numarası değiştirildiğinde başka müşterinin faturasına erişilebiliyorsa burada nesne düzeyinde yetkilendirme açığı vardır. Uygulama geçerli bir yanıt verdiği için otomatik tarayıcı bunu normal davranış sanabilir. Benzer biçimde indirimlerin yanlış sırayla uygulanması, onaysız para iadesi, başka kullanıcının sepetine erişim veya yönetici işlevinin gizli bir URL üzerinden açılması bağlam bilgisi ister.
Bu yüzden otomasyonla bulunan sonuçları elle doğrular, yanlış alarmları ayıklarız. Ardından uygulamaya özgü iş mantığı senaryolarını manuel olarak deneriz. Otomasyon hız kazandırır; uzman incelemesi ise bulgunun gerçek riskini ve doğru çözüm yolunu ortaya çıkarır.
Test planı her uygulama için aynı değildir. Bir e-ticaret sitesiyle kurumsal yönetim panelinin varlıkları, kullanıcı rolleri ve saldırı yüzeyi farklıdır. Yine de aşağıdaki başlıklar çoğu web uygulaması için temel kontrol alanlarını oluşturur.
Giriş, kayıt, parola sıfırlama, e-posta doğrulama ve çok adımlı doğrulama akışları incelenir. Kullanıcı adının tahmin edilmesine yol açan mesajlar, zayıf parola politikaları, kaba kuvvet denemelerine karşı eksik kontroller ve süresi dolmayan sıfırlama bağlantıları değerlendirilir. Alternatif giriş kanallarının ana akıştan daha zayıf korunup korunmadığı da kontrol edilir.
Farklı kullanıcı rollerinin yalnızca izinli kayıt ve işlevlere erişmesi gerekir. Test sırasında URL, form alanı, API isteği ve kayıt kimliği değiştirilerek yatay ve dikey yetki kontrolleri sınanır. Böylece bir kullanıcının başka kullanıcıya ait veriyi görmesi veya normal hesabın yönetici işlevini çalıştırması gibi yüksek etkili sorunlar aranır.
Oturum belirteçlerinin tahmin edilebilirliği, çıkış sonrası geçerliliği, süre aşımı ve çerez bayrakları değerlendirilir. Oturum sabitleme, eş zamanlı oturum yönetimi ve kritik işlem öncesinde yeniden doğrulama gibi kontroller incelenir. Amaç yalnızca giriş ekranını değil, girişten sonraki kullanıcı yaşam döngüsünü de güvence altına almaktır.
Kullanıcıdan veya başka sistemlerden gelen verinin SQL sorgularına, HTML çıktısına, işletim sistemi komutlarına, dosya yollarına ve şablonlara nasıl aktarıldığı araştırılır. SQL injection, cross-site scripting (XSS), sunucu taraflı istek sahteciliği ve dosya yolu manipülasyonu gibi riskler yalnızca araç çıktısıyla değil, uygulamanın veri akışı dikkate alınarak doğrulanır.
Dosya türü, boyut, içerik ve saklama konumu kontrolleri gözden geçirilir. Yüklenen dosyanın çalıştırılabilmesi, tahmin edilebilir bağlantılarla özel dosyalara erişim veya yetkisiz indirme gibi senaryolar denenir. Hata mesajlarında, günlüklerde veya API yanıtlarında gereğinden fazla teknik ve kişisel bilgi bulunup bulunmadığı da araştırılır.
Sipariş, ödeme, kupon, bakiye, onay, davet ve rol değişikliği gibi uygulamaya özel süreçler adım adım modellenir. İşlemlerin sırası değiştirildiğinde, aynı istek tekrarlandığında veya beklenmeyen değerler gönderildiğinde güvenlik sınırının aşılıp aşılmadığı kontrol edilir. Bu bölüm çoğu zaman standart taramaların göremediği en değerli bulguları üretir.
İlk aşamada alan adları, uygulama bileşenleri, kullanıcı rolleri, test ortamı ve kapsam dışı işlemler belirlenir. Trafik sınırları, bakım aralıkları, acil iletişim kişileri ve veri güvenliği kuralları yazılı hale getirilir. Hizmet kesintisi veya veri kaybı oluşturabilecek denemeler açık onay olmadan yapılmaz.
Uygulamanın sayfaları, API uçları, parametreleri, yükleme alanları ve kullanılan teknolojileri haritalanır. Farklı rollerle erişilebilen işlevler karşılaştırılır. Unutulmuş yönetim ekranları, eski uçlar ve istemci tarafında görünen gizli parametreler de bu aşamada değerlendirilir.
Kapsama uygun araçlarla kontrollü taramalar yapılır; ardından sonuçlar elle doğrulanır. Uzman, uygulamanın iş akışlarını ve rollerini kullanarak yetkilendirme, oturum, enjeksiyon ve iş mantığı senaryolarını dener. Her testin üretim sistemine etkisi gözetilir ve gereksiz yük oluşturan işlemlerden kaçınılır.
Doğrulanan her bulgu için etkilenen bileşen, teknik açıklama, kanıt, yeniden üretme adımları, olası iş etkisi ve düzeltme önerisi hazırlanır. Bulgular yalnızca teorik şiddete göre değil, uygulamadaki gerçek kullanım koşullarına göre önceliklendirilir. Teknik ekip için ayrıntılı rapor, karar vericiler için anlaşılır bir yönetici özeti sunulur.
Ekip düzeltmeleri tamamladığında ilgili bulgular yeniden test edilir. Yalnızca hatanın görünürde kapanmasına değil, kök nedenin giderilmesine ve değişikliğin yeni bir güvenlik sorunu oluşturmamasına bakılır. Sonuçlar, hangi bulguların kapandığını ve hangilerinin devam ettiğini gösteren doğrulama notlarıyla paylaşılır.
Black-box yaklaşımında test uzmanı uygulamayı dışarıdaki bir saldırgan gibi, sınırlı bilgiyle değerlendirir. İnternete açık saldırı yüzeyini görmek için yararlıdır; ancak oturum açmış rollerin tamamını veya uygulama içindeki karmaşık işlevleri kapsamak daha uzun sürebilir.
Gray-box testte dokümantasyon ve farklı yetki düzeylerine sahip test hesapları paylaşılır. Çoğu web uygulaması için zaman ile kapsam arasında iyi bir denge sağlar. Yetkilendirme sorunları ve rol karşılaştırmaları daha sistemli incelenebilir.
White-box yaklaşımında mimari bilgi ve gerektiğinde kaynak kod erişimi de kullanılır. Karmaşık veri akışları veya kritik uygulamalar için daha derin görünürlük sağlar. Kaynak kodun ayrı ve ayrıntılı değerlendirilmesi gerekiyorsa kaynak kod güvenlik incelemesi hizmetiyle birlikte planlanabilir.
Sızma testi yalnızca bir güvenlik olayı yaşandıktan sonra düşünülmemelidir. Yeni bir uygulama canlıya çıkmadan önce, büyük özellik veya mimari değişikliklerden sonra ve kimlik doğrulama ya da ödeme gibi kritik akışlar yenilendiğinde test yapılması anlamlıdır. Uzun süredir değerlendirilmemiş, yeni bir ekip tarafından devralınmış veya internete yeni açılmış uygulamalar da öncelikli adaydır.
Tek seferlik test, o tarihteki güvenlik durumunun fotoğrafını verir. Uygulama değiştikçe yeni kod, bağımlılık ve yapılandırmalar saldırı yüzeyini değiştirebilir. Bu nedenle test sıklığı; değişiklik hızı, işlenen verinin hassasiyeti, yasal yükümlülükler ve kurumun risk iştahına göre belirlenmelidir. CI kontrolleri, kod incelemesi ve güvenli geliştirme pratikleri sızma testinin yerini almaz; onunla birlikte sürekli güvenlik yaklaşımı oluşturur.
Sağlıklı bir başlangıç için uygulamanın güncel kapsamını, ana kullanıcı rollerini ve kritik iş süreçlerini paylaşın. Mümkünse canlıyla benzer yapılandırılmış bir test ortamı ve her rol için ayrı hesap hazırlayın. API kullanan uygulamalarda güncel dokümantasyon veya istek koleksiyonu süreyi verimli kullanmayı sağlar; API katmanı genişse API güvenlik testi ayrıca kapsamlandırılabilir.
Test verisinin gerçek müşteri verisinden ayrılması, yedeklerin doğrulanması ve acil durumda ulaşılacak teknik kişinin belirlenmesi de önemlidir. Bilinen sorunları saklamak yerine paylaşmak, aynı noktaları tekrar keşfetmeye ayrılan zamanı azaltır ve daha derin senaryolara odaklanılmasını sağlar.
Rapor, güvenlik ekibi dışında geliştiriciler ve yöneticiler tarafından da kullanılabilmelidir. Her bulguda anlaşılır başlık, etkilenen adres veya işlev, riskin nedeni, güvenli biçimde hazırlanmış kanıt ve tekrarlanabilir adımlar bulunmalıdır. Düzeltme önerisi genel bir “girdiyi doğrulayın” ifadesinden ibaret kalmamalı; ilgili teknoloji ve veri akışına uygun yön göstermelidir.
Yönetici özeti; bulgu sayısının ötesinde en önemli iş risklerini, ortak kök nedenleri ve önerilen öncelik sırasını açıklamalıdır. Teknik bölüm ise geliştiricinin sorunu yeniden üretip düzeltebilmesi için yeterli ayrıntıyı vermelidir. Kanıtlar paylaşılırken parola, oturum belirteci ve kişisel veri gibi hassas bilgiler maskelenmelidir.
Etkili bir web uygulama sızma testi, araç raporunu teslim edip biten bir tarama değildir. Uygulamanın nasıl çalıştığını anlayan, otomatik sonuçları doğrulayan ve iş mantığını gerçekçi senaryolarla sınayan bir güvenlik değerlendirmesidir. Sonuçta hangi açıkların önce kapatılması gerektiğini, neden önemli olduklarını ve düzeltmenin nasıl doğrulanacağını gösteren uygulanabilir bir yol haritası elde edersiniz.
BetorBet Güncel Giriş aramasıyla ulaştığınız bu sayfa, BetOrBet Siber Güvenlik’in resmi web uygulama sızma testi hizmetidir. Uygulamanızın kapsamını, kullanıcı rollerini ve takvimini paylaşın; yazılı izin ve güvenli çalışma kurallarıyla uygun test planını birlikte oluşturalım.
Kapsamı ve yöntemi önceden yazılı olarak belirleriz. Veri silen ya da hizmeti kesintiye uğratabilecek denemeleri yalnızca sizin onayınızla ve tercihen test ortamında yaparız.
Süre uygulamanın büyüklüğüne göre değişir. İlk görüşmeden sonra kapsamla birlikte yazılı bir takvim veririz.
Tarayıcılar bilinen kalıpları bulur; yetki atlatma ya da iş mantığı hataları gibi açıkları çoğu zaman göremez. Bu yüzden bulguları elle doğrular ve elle test ederiz.
Kapsama göre test ortamı, farklı kullanıcı rollerine ait hesaplar ve varsa API dokümantasyonu yeterlidir. İhtiyaç duyulan erişimleri çalışma başlamadan önce yazılı olarak netleştiririz.
Hayır. Her doğrulanmış bulgu için kanıt, yeniden üretme adımları, iş etkisi, öncelik ve uygulanabilir düzeltme önerisi sunarız. Düzeltmeler tamamlandıktan sonra doğrulama testi de yaparız.
Diğer hizmetler
API güvenlik testiyle REST ve GraphQL uçlarında yetkilendirme, belirteç, veri sızıntısı, iş akışı ve kaynak tüketimi açıklarını gerçekçi senaryolarla belirliyoruz.
Kaynak kod güvenlik incelemesiyle veri akışı, yetkilendirme, gizli bilgi, kriptografi ve iş mantığı açıklarını satır referanslarıyla belirliyoruz.
Oltalama simülasyonuyla çalışanların şüpheli e-postaları fark etme ve bildirme davranışını güvenli, anonim ve kuruma özel senaryolarla ölçüyoruz.
Uygulamanızı ve beklentinizi birkaç cümleyle yazın; kapsamı birlikte netleştirelim.