Web sitesi ve web uygulaması incelemesi

Web sitesi incelemesi hangi sorulara cevap verir?

İnceleme, kayıtlarla cevaplanabilecek bir teknik soruyla başlar. En sık gelenler:

• İçerik: Bu metin, bu fiyat ya da bu kampanya koşulu iddia edilen tarihte yayında mıydı, ne zaman değişti?
• Altyapı: Alan adı ne zaman alındı, site nerede barındırılıyor?
• İşlem: Üyelik, sipariş, onay kutusu ya da parola değişikliği gerçekten o hesaptan mı yapıldı?
• Yönetim: Panelden bir içeriği kim düzenledi, kim sildi?
• Güvenlik: İddia edilen yetkisiz erişim, sitenin o tarihteki sürümünde mümkün müydü?

Dışarıdan görülen izler, içeriden alınan kayıtlar

Kayıtların bir kısmı herkese açıktır, bir kısmı yalnızca siteyi işleten tarafta bulunur. Site karşı taraftaysa ikinci grup ancak site işleteninden ya da mahkeme eliyle temin edilir.

Alan adı, barındırma ve sertifika kayıtları ne gösterir?

Bu kayıtlar, bir sitenin en geç hangi tarihte kurulduğunu ve hangi altyapıda çalıştığını, siteyi işletenden bağımsız olarak gösterir. Sahte bir alışveriş sitesini tarihlemek için ilk bunlara bakarız.

ICANN, 28 Ocak 2025'ten itibaren genel uzantılı (gTLD) alan adlarında kayıt verisinin yetkili kaynağı olarak WHOIS yerine RDAP'ı esas aldı. RDAP yanıtındaki events dizisi, eventAction değerleriyle (registration, last changed, expiration) alan adının tarih çizelgesini verir. .tr alan adlarını 14 Eylül 2022'den beri BTK bünyesindeki TRABİS yönetir. Kayıt tarihi, alan adının mevcut kaydının tarihidir; süresi dolup yeniden alınmış bir alanda önceki sahiplik görünmez.

Certificate Transparency (RFC 6962), TLS sertifikalarının herkese açık ve yalnızca ekleme yapılabilen (append-only) loglara yazılmasını sağlar; crt.sh gibi arayüzlerle sorgulanır. Bir alt alan adı için verilmiş ilk sertifika, o adın en geç o tarihte kullanıma hazırlandığına dair güçlü ve bağımsız bir işarettir. Pasif DNS ise sensörlerin gördüğü sorgulardan oluşan bir gözlemdir; "ilk görülme" tarihi yapılandırmanın en geç o gün yapıldığını söyler, kesin tarihini değil.

Barındırma (hosting) tarafında IP adresinin hangi ağa ve firmaya ait olduğu, IP kayıt kuruluşlarının (Türkiye için RIPE NCC) kayıtlarından anlaşılır. Paylaşımlı barındırmada aynı IP adresinde çok sayıda site bulunabilir. Site bir CDN'in arkasındaysa görünen adres CDN'e aittir; asıl sunucu (origin) ancak eski DNS kayıtları gibi dolaylı izlerle bulunabilir, bazen hiç bulunamaz. Server ve X-Powered-By yanıt başlıkları sunucu yazılımına dair bir beyandır, gizlenebilir. MX ve SPF kayıtları e-postayı hangi hizmetin taşıdığını gösterir; konu sahte e-postaya uzanıyorsa e-posta incelemesiyle birleşir.

Sitenin belirli bir tarihteki hâli nasıl tespit edilir?

Yayındaki içerik bugün birkaç yolla kayda alınabilir; değişmiş içeriğe ise ancak arşivler ve sitenin kendi kayıtları üzerinden bakılabilir.

Bizce yayındaki bir içerik için en sağlam sonuç, e-Tespit ile teknik edinimin aynı gün yapılmasıyla alınır: biri ekranda görüneni, diğeri onun arkasındaki teknik veriyi kayda geçirir. Tespitin hukuki değerini avukatınız ve mahkeme değerlendirir. Ekran görüntüsünün zayıflıklarını ekran görüntüsünün delil değeri yazımızda anlattık.

İçerik değişmişse ve site incelemeyi isteyen tarafa aitse, sitenin kendi kayıtları arşivlerden daha güçlüdür. WordPress, yazı ve sayfaların önceki hâllerini wp_posts tablosunda post_type değeri revision olan satırlar olarak saklar; wp-config.php içindeki WP_POST_REVISIONS sabitiyle bu sayı sınırlanmış ya da kapatılmış olabilir. Revizyonlar varsayılan olarak başlık, içerik ve özet gibi alanları izler; bir eklentinin özel alanında tutulan değerin (fiyat, stok) eski hâli revizyonda bulunmayabilir. O zaman yedeklere ve sürüm kontrol geçmişine döneriz.

Erişim logları, oturumlar ve API çağrıları

Sunucu tarafı kayıtlar, sitede kimin ne yaptığına en yakın kanıttır; ama her kayıt yalnızca yapılandırıldığı kadarını tutar. Bu yüzden log dosyasından önce sunucunun log ayarlarını okuruz.

• Apache'nin combined biçimindeki %r alanı yalnızca istek satırıdır (yöntem, yol, sorgu dizesi, protokol). Bir POST isteğinde hangi adrese form gönderildiği görülür, forma ne yazıldığı görülmez.
• Site bir CDN veya ters vekil sunucunun arkasındaysa %h ya da Nginx'teki $remote_addr vekilin adresini gösterebilir. X-Forwarded-For başlığının güvenilir vekilin eklemediği kısımları sahte olabilir.
• Varsayılan log biçimleri istemcinin kaynak portunu yazmaz; oysa CGNAT arkasındaki kullanıcıyı eşleştirmek için port ve saniye hassasiyetli zaman gerekir (IP ve CGNAT analizi).
• Nginx'in $time_local alanı sunucunun yerel saatidir. Kaynaklar karşılaştırılmadan önce hepsi UTC'ye çevrilir.

Oturum kayıtları uygulamanın yapısına göre değişir. WordPress açık oturumları wp_usermeta tablosunda session_tokens anahtarıyla tutar; her oturum için giriş zamanı (login), IP adresi (ip), tarayıcı bilgisi (ua) ve bitiş zamanı (expiration) yazılır. Bu kayıt geçmişin değil o anın fotoğrafıdır: çıkış yapılan ya da süresi dolan oturumlar listeden düşer. JWT gibi sunucuda saklanmayan token'larla çalışan API'lerde ise oturum tablosu hiç olmayabilir; token'ın ne zaman hangi hesaba verildiği yalnızca kimlik doğrulama logunda görünür. Yönetici paneli işlemlerinin ayrı bir etkinlik günlüğü, yaygın içerik yönetim sistemlerinde çoğu zaman ancak bir eklentiyle tutulur; yoksa panel işlemleri erişim logu ve revizyonlardan yeniden kurulur.

API çağrılarında en değerli alan istek kimliğidir (ör. X-Request-ID). Aynı değer ters vekilde, uygulama logunda ve hata kaydında geçiyorsa tek bir isteği katmanlar boyunca izleyebiliriz. Site ile mobil uygulama çoğu zaman aynı API'yi kullanır; çağrının hangi istemciden geldiği User-Agent ve sürüm başlıklarından anlaşılır, ama bu alanlar istemcinin beyanıdır.

Saklama süresi ayrı bir sorudur. 5651 sayılı Kanun m.5/3, yer sağlayıcının (barındırma firmasının) trafik bilgisini bir ile iki yıl arasında yönetmelikte belirlenecek süre kadar saklamasını öngörür; 2007 tarihli Usul ve Esaslar Yönetmeliği (m.7/1-c) ise hâlâ altı ay der. Pratikte asıl soru, logun bugün sunucuda durup durmadığıdır. Diğer log türleri için: log analizi.

Kullanıcı işlemleri teknik olarak nasıl doğrulanır?

Bir kullanıcının sitede bir işlem yaptığı iddiası, aynı olayın birbirinden bağımsız kayıtlarda aynı zamanla ve aynı oturumla görünmesiyle desteklenir. İzlediğimiz sıra:

1. Sorudaki işlemin veri tabanı kaydını ve tarih alanlarını alırız. Bu alanları çoğunlukla uygulama yazar ve yetkili bir kullanıcı değiştirebilir; tek başına kanıt saymayız (veri tabanı incelemesi).
2. Uygulama logunda aynı işlemin API çağrısını, istek kimliğini ve kullanıcı kimliğini buluruz.
3. Erişim logunda isteği yapan IP'yi, varsa portu ve User-Agent bilgisini oturumla eşleriz.
4. Oturumun parolayla mı, SMS koduyla mı, hatırlanan cihazla mı açıldığına ve başka bir adresten de kullanılıp kullanılmadığına bakarız.
5. Dış teyitleri ekleriz: e-posta bildirimleri, ödeme kuruluşu ve SMS gönderim kayıtları.
6. Bütün zamanları UTC'ye çevirip tek bir zaman çizelgesinde birleştiririz.

Bu adımlar işlemin hangi hesaptan ve hangi oturumdan yapıldığını gösterebilir. Hesabı o anda klavyenin başında kimin kullandığı ise teknik kayıtların tek başına cevaplayamayacağı bir sorudur.

Kaynak kod, yetkilendirme ve güvenlik açıkları

Kaynak kod, sitede bir işlemin nasıl gerçekleştiğini ve bir yetki kontrolünün o tarihte var olup olmadığını gösterir. Tipik soru: kullanıcı adres çubuğundaki sipariş numarasını değiştirerek başkasının siparişini görebiliyor muydu? Bu, OWASP Top 10:2025 listesinin ilk sırasındaki "Broken Access Control" türüdür; bulguları bu listenin kategorileriyle sınıflandırırız.

Cevap bugünkü koda değil, o tarihte yayında olan sürüme bakılarak verilir; bunun için dağıtım kayıtları, Git etiketleri ve CI/CD geçmişi gerekir. Kodun ayrıntılı incelemesi yazılım ve kaynak kod incelemesi kapsamındadır. Güvenlik testini yalnızca incelemeyi isteyenin kendi sisteminde ya da yazılı izinle yaparız; başkasına ait sisteme izinsiz erişim TCK m.243 ve 244'ün konusudur. Yaşanmış bir saldırı için doğru başlangıç siber olay incelemesidir.

İnceleme için hangi materyal gerekir?

• İncelenecek adresler (tam URL) ve tarih aralığı, saat dilimiyle birlikte.
• Varsa ekran görüntüleri, e-Tespit tutanağı, ilgili e-postalar.
• Site sizinse: erişim ve hata logları (sıkıştırılmış eski dosyalar dahil, ör. access.log.2.gz), veri tabanı yedeği, kaynak kod deposu, CDN ve WAF panel kayıtları.
• Site karşı taraftaysa herkese açık kaynaklarla çalışırız; içerideki kayıtların nasıl isteneceğini avukatınız belirler, biz hangi kaydın hangi soruyu cevaplayacağını listeleriz.

Raporda neler yer alır, neler yer almaz?

Rapor; soruyu, materyal listesini ve hash değerlerini, edinim adımlarını ve araç sürümlerini, bulguları ve zaman çizelgesini, alternatif açıklamaları ve sınırları içerir. Erişilemeyen kaydın hangi soruyu cevapsız bıraktığı ayrıca yazılır.

Hukuki nitelendirme yapmayız: "haksız rekabet yapılmıştır" demeyiz, "koşullar metni 14.07 UTC'de şu oturumdan değiştirilmiştir" deriz. Dava sürecinde mahkeme bu konuda bilirkişi görevlendirebilir; Bilirkişilik Daire Başkanlığının uzmanlık listesinde "Web, İnternet ve Multimedya" (18.01) ayrı bir alt alandır. Biz bilirkişi değiliz; taraflardan biri için uzman görüşü hazırlar ya da dosyadaki bilirkişi raporunu teknik yönden değerlendiririz. Raporumuz avukatınız tarafından dosyaya sunulabilir.