TSE TS 13638 Kapsamında Web Servis ve API Testleri

API Güvenliği Neden Farklı?

Klasik web uygulama testleri büyük ölçüde tarayıcı üzerinden çalışır. Form gönderilir, sayfa yanıtı incelenir, oturum takip edilir. Ancak API testleri bu kalıbın dışında yer alır. Bir arayüz yoktur, görsel bir bağlam da yoktur. Kısacası, her şey istek ve yanıt çiftleri üzerinden yürür.

Bu fark testçinin bakış açısını da değiştirir. Dolayısıyla API güvenliğini klasik yöntemlerle test etmek hem yetersiz hem de yanıltıcı sonuçlar üretir. Bir API uç noktası yüzeysel olarak sağlıklı görünebilir; ama doğru parametre kombinasyonuyla veri sızdırabilir ya da yetkisiz bir işlem gerçekleştirebilir.

Buna ek olarak, API’lerin çoğu farklı istemci türlerine hizmet eder. Web uygulaması, mobil uygulama ve üçüncü taraf entegrasyonlar aynı uç noktayı kullanabilir. Sonuç olarak, bu durum saldırı yüzeyini genişletir. Ayrıca her istemci türü farklı bir risk profili taşır.

TS 13638 API Testlerini Nasıl Ele Alır?

TSE TS 13638, web uygulama güvenlik testleri için ulusal düzeyde bir çerçeve sunar. Nitekim standart, yalnızca klasik web uygulamalarını değil, web servislerini ve API katmanlarını da kapsam içinde ele alır.

Standart, API güvenlik testlerini genel test metodolojisinin bir parçası olarak konumlandırır. Planlama, keşif, tehdit modelleme, teknik test ve raporlama aşamaları API’ler için de geçerliliğini korur. Öte yandan, API’lerin kendine özgü risk kategorileri olduğundan standart bu alanlara özel dikkat çeker.

Özellikle kimlik doğrulama mekanizmaları, veri ifşası riskleri, iş mantığı hataları ve oran sınırlama eksiklikleri API testlerinde ön plana çıkar. Standart bu kategorilerin her birini sistematik biçimde ele almayı zorunlu kılar.

Kimlik Doğrulama Testleri

Günümüzde, API’lerin büyük çoğunluğu token tabanlı kimlik doğrulama kullanır. OAuth 2.0, JWT ve API anahtarları en yaygın mekanizmalar arasındadır. Ancak bu mekanizmaları kullanmak, onları doğru uygulamak anlamına gelmez.

JWT token’ları özellikle dikkatli incelenmesi gereken bir alan. Bu durumda, token’ın imzalama algoritması yanlış yapılandırılmışsa saldırgan kendi token’ını üretebilir. “none” algoritması açığı bunun en bilinen örneğidir. Benzer şekilde, API anahtarları URL parametresi olarak iletildiğinde log dosyalarına düşer ve istem dışı ifşaya yol açar.

Standart bu testler için açık gereksinimler tanımlar. Token’ların güçlü üretilmesi, güvenli iletilmesi ve belirli bir süre sonra geçersiz kılınması kontrol edilir. Özellikle, parola sıfırlama ve hesap doğrulama akışlarında kullanılan token’lar ayrıca test edilir.

Kontrol Edilen Başlıca Noktalar

• JWT imzalama algoritması ve “none” algoritması açığı
• API anahtarlarının URL parametresi yerine header’da iletilmesi
• Token süre aşımı ve geçersiz kılma mekanizmaları
• OAuth 2.0 akışlarında yetki kodu ele geçirme riskleri
• Parola sıfırlama token’larının güçlüğü ve tek kullanımlığı

Yetkilendirme ve Erişim Kontrolü

Şüphesiz, yetkilendirme testleri API güvenliğinin en kritik alanlarından birini oluşturur. Bu alanda iki temel senaryo öne çıkar: nesne düzeyinde yetkilendirme hataları ve işlev düzeyinde yetkilendirme hataları.

Gerçekten de, OWASP API Security Top 10 listesinin ilk iki maddesi bu iki kategoriye aittir. Nesne düzeyinde yetkilendirme hatası şu anlama gelir: bir kullanıcı başka bir kullanıcıya ait veriye yalnızca kaynak kimliğini değiştirerek erişebilir.

Örneğin, /api/orders/1234 uç noktasına yetkisiz bir kullanıcı erişebiliyorsa bu ciddi bir güvenlik açığıdır. Standart, bu tür testlerin farklı rol ve kullanıcı senaryolarıyla sistematik biçimde yürütülmesini gerektirir.

Bunun yanı sıra, işlev düzeyinde yetkilendirme hataları ise bir kullanıcının erişmemesi gereken API işlevlerini çağırabilmesiyle ilgilidir. Standart kullanıcı rolünün yönetici işlevlerini tetikleyip tetikleyemeyeceğini, standart üyenin premium özelliklere erişip erişemeyeceğini test etmeyi kapsam içinde tutar.

Giriş Doğrulama ve Enjeksiyon Testleri

API’ler veri alışverişinin temel kanalı olduğundan giriş doğrulama testleri büyük önem taşır. Bu bağlamda, standart hem içerik hem de format bazlı doğrulama kontrollerini kapsar.

SQL enjeksiyonu API katmanında da etkili olabilir. Özellikle parametre bazlı sorgular hatalı yapılandırıldığında bu risk ortaya çıkar. Aynı zamanda, NoSQL veritabanı kullanan sistemlerde NoSQL enjeksiyon testleri de kapsamın içindedir.

XML tabanlı servislerde XXE (XML External Entity) açığı ayrı bir başlık oluşturur. Dışarıdan gelen XML içeriği güvenli şekilde işlenmezse saldırgan iç sistem dosyalarına erişebilir ya da sunucu tarafı istek sahteciliği gerçekleştirebilir. Ne var ki bu açık hâlâ pek çok SOAP servisinde görülür. Geliştiriciler XML işleyicilerini varsayılan güvenli olmayan ayarlarla bırakır.

Ayrıca, GraphQL gibi modern API teknolojileri de kendine özgü riskler taşır. Sorgu derinliği kontrolü yoksa ağır iç içe sorgularla servis çöktürülebilir. Dahası, introspection özelliği açık bırakıldığında tüm şema yapısı saldırganın eline geçer. Standart bu tür teknolojilere özgü risklerin de değerlendirilmesini gerektirir.

Test Edilen Başlıca Enjeksiyon Vektörleri

• SQL Enjeksiyonu — parametre bazlı sorgu açıkları
• NoSQL Enjeksiyonu — MongoDB ve benzeri sistemlerde operatör manipülasyonu
• XXE — XML işleyicilerinde dış varlık çözümleme
• Komut Enjeksiyonu — sistem komutlarına giriş parametresi ekleme
• GraphQL Sorgu Derinliği — iç içe sorgularla servis tüketimi

Oran Sınırlama ve Kaynak Tüketimi

Gerçek şu ki, API’ler belirli bir oran sınırı olmadan çalıştırılırsa kötüye kullanıma açık hale gelir. Oran sınırlama eksikliği hem kaba kuvvet saldırılarını hem de servis engelleme saldırılarını kolaylaştırır.

Bununla birlikte, oran sınırlamanın varlığı yeterli değildir; doğru uygulanması da gerekir. Sadece IP adresi bazlı sınırlama, saldırganların farklı IP’ler kullanarak kısıtlamayı aşmasına olanak tanır. Oysa kullanıcı kimliği veya kaynak bazlı sınırlama bu açığı kapatır.

Standart kapsamında oran sınırlama testleri birkaç açıdan ele alınır: giriş denemelerinde sınır kontrolü, hassas işlemlerde ek doğrulama zorunluluğu ve aşırı yüklenmeye karşı koruma mekanizmaları.

Veri İfşası Testleri

API yanıtlarının gereğinden fazla veri döndürmesi yaygın bir problemdir. Bu yüzden, standart her API uç noktasının yalnızca gerekli veriyi döndürdüğünü doğrulamayı kapsam içine alır.

Bir kullanıcı profil bilgisini sorgulayan bir istek şifrelenmiş parola alanı, güvenlik sorusu cevabı veya iç sistem metadata’sı döndürüyorsa bu ciddi bir veri ifşası problemidir. Üstelik bazı API’ler hata mesajlarında yığın izi (stack trace) veya veritabanı sorgu detayları döndürür. Bu bilgiler saldırganın sistem hakkında önemli ipuçları edinmesini sağlar.

Bu kapsamda, testler sırasında her uç noktanın döndürdüğü veri yapısı incelenir. Hassas alanların maskelenmesi ya da çıkarılması kontrol edilir. Gerçekten de, bu alan çoğu zaman göz ardı edilen ama önemli sonuçlar doğuran bir test kategorisidir.

Kontrol Edilen Başlıca Veri İfşası Senaryoları

• Yanıtta dönen gereksiz hassas alanlar (parola hash, iç ID, token)
• Hata mesajlarında stack trace veya SQL sorgusu görünümü
• Sunucu versiyon bilgisinin HTTP header’larında yer alması
• Debug modu açık bırakılmış API uç noktaları
• Log dosyalarına düşen API anahtarları veya token’lar

İş Mantığı Testleri

İş mantığı hataları teknik açıklardan farklı bir kategori oluşturur. Ne ki, bir tarayıcı ya da otomatik araç bu hataları genellikle tespit edemez. Uygulamanın iş kurallarını anlamak gerekir.

Örneğin, bir e-ticaret API’sinde sipariş onaylanmadan önce stok kontrolü yapılıyor mu? Negatif miktar girildiğinde sistem doğru tepki veriyor mu? Kupon kodu arka arkaya birden fazla kez kullanılabiliyor mu? Bu sorular iş mantığı testlerinin temel gündemini oluşturur.

Bu nedenle iş mantığı testleri tamamen manuel süreçlere dayanır. Testçi uygulamanın işleyişini derinlemesine anlamalı ve olağandışı senaryolar kurgulamalıdır. Bu doğrultuda, TS 13638 bu kapsamdaki testlerin de raporlanmasını zorunlu kılar.

REST ve SOAP: Farklar Önemli mi?

REST ve SOAP farklı teknoloji yaklaşımlarıdır. Ancak güvenlik testleri açısından her ikisi de standart kapsamında aynı temel prensiplerle ele alınır.

SOAP servisleri WSDL belgesi üzerinden çalışır. Bu belge servis yapısını açıkça tanımlar. Dolayısıyla test uzmanı WSDL belgesini analiz ederek tüm uç noktaları ve parametreleri hızlıca tespit edebilir. Bununla birlikte WSDL belgesinin gereksiz yere dışarıya açılması bilgi ifşası riski doğurur.

REST servisleri ise daha esnek bir yapıya sahiptir. Swagger veya OpenAPI belgeleri mevcut olduğunda test süreci kolaylaşır. Öte yandan, bu belgeler güncel tutulmuyorsa belgelenmemiş uç noktalar ortaya çıkabilir. Bu “gizli” uç noktalar çoğu zaman en zayıf güvenlik kontrollerine sahip alanlardır.

Araçlar ve Yaklaşım

Bu süreçte, doğru araç seçimi test sürecinin verimliliğini doğrudan etkiler. API testlerinde Burp Suite, Postman ve özelleştirilmiş betikler en yaygın kullanılan araçlar arasında yer alır.

Bununla birlikte, araçların kapasitesi ne kadar güçlü olursa olsun manuel test adımlarının yerini tutamaz. Otomatik taramalar bilinen açık kalıplarını tespit etmekte etkilidir. Ne var ki iş mantığı hataları, bağlam bağımlı yetkilendirme açıkları ve veri ifşası senaryoları için insan gözü şarttır.

Standart uyumlu bir testte araç kullanımı belgelenir. Hangi araçların hangi aşamada kullanıldığı, oluşturulan trafik miktarı ve test ortamına etkileri raporda yer alır. Böylece müşteri hem testin kapsamını hem de derinliğini değerlendirme imkânı bulur.

Yaygın Kullanılan Test Araçları

• Burp Suite — HTTP/S trafik analizi, aktif tarama, tekrarlayan istek testleri
• Postman / Newman — API koleksiyon yönetimi ve otomatik test koşusu
• OWASP ZAP — Açık kaynak aktif/pasif tarama
• SQLMap — SQL enjeksiyon tespiti ve doğrulama
• jwt_tool — JWT token analizi ve manipülasyon testleri

Raporlama

Bu bağlamda, API güvenlik test raporu klasik web uygulama raporlarından bazı noktalarda ayrışır. Her bulgu için ilgili API uç noktası, HTTP metodu, kullanılan istek yapısı ve sunucu yanıtı belgelenir.

Aynı zamanda her bulgu için etki analizi yapılır. Hangi veriler risk altında, hangi kullanıcı grupları etkilenebilir ve bu açık gerçek bir saldırıda nasıl istismar edilebilir soruları yanıtlanır. Teknik ayrıntıların yanı sıra her bulgu için somut düzeltme önerileri sunulur.

Son olarak, rapor yönetim özeti ile kapatılır. Bu bölüm genel güvenlik durumunu, kritik bulguların sayısını ve öncelikli aksiyon maddelerini özetler. Bu sayede, teknik personel olmayan karar vericilerin de durumu kavramasını sağlar.

Raporda Yer Alan Başlıca Bileşenler

1. Yönetici özeti — teknik olmayan okuyucular için genel durum değerlendirmesi
2. Test kapsamı ve metodoloji — hangi uç noktaların, hangi araçlarla test edildiği
3. Bulgular — uç nokta, HTTP metodu, istek/yanıt örneği, risk seviyesi
4. Etki analizi — etkilenen veri ve kullanıcı grupları
5. Düzeltme önerileri — her bulgu için somut aksiyon maddeleri
6. Doğrulama planı — düzeltme sonrası yeniden test gereksinimleri

Sık Sorulan Sorular