API Attacks 101: API’ler Neden Kritik Bir Saldırı Yüzeyi?

Mobil uygulamadan sipariş verirken, bir ödeme sistemiyle işlem yaparken, başka bir uygulamayla giriş yaparken, kargo durumunu kontrol ederken ya da bir panelden müşteri verilerini çekerken aslında çoğu zaman bir API ile konuşuyoruz.

API'ler modern yazılım dünyasının bağlantı noktalarıdır. Sistemlerin birbiriyle veri alışverişi yapmasını sağlarlar. Bu yüzden de hem geliştiriciler hem şirketler için çok değerlidirler.

Ama güvenlik açısından baktığımızda aynı özellik başka bir gerçeği ortaya çıkarır: API'ler, modern uygulamaların en kritik saldırı yüzeylerinden biridir.

API NEDİR?

API, yani Application Programming Interface, farklı yazılım sistemlerinin belirli kurallar çerçevesinde birbiriyle iletişim kurmasını sağlayan arayüzdür.

Basitçe düşünelim, bir e-ticaret uygulamasında ürünleri listeleyen mobil uygulama, ürün bilgisini doğrudan veritabanından almaz. Bunun yerine backend tarafındaki bir API'ye istek gönderir:

"Bana ürünleri getir."

API bu isteği işler, gerekli kontrolleri yapar ve uygun cevabı döner. Bu cevap genellikle JSON formatında olur:

{
  "id": 12,
  "name": "Laptop",
  "price": 25000
}

{
  "id": 12,
  "name": "Laptop",
  "price": 25000
}

Bu yapı sayesinde frontend, mobil uygulama, üçüncü parti servisler ve farklı sistemler aynı veriyle kontrollü şekilde çalışabilir.

En azından teoride kontrollü şekilde.

API'ler Neden Bu Kadar Yaygın?

API'lerin bu kadar yaygın olmasının temel sebebi, modern yazılım mimarisinin artık tek parça sistemlerden çok, birbirine bağlı servislerden oluşmasıdır.

Bir uygulama artık yalnızca kendi içinde çalışan kapalı bir yapı değildir. Ödeme sağlayıcılarıyla, kimlik doğrulama servisleriyle, kargo sistemleriyle, CRM araçlarıyla, raporlama servisleriyle ve üçüncü parti platformlarla konuşur. Bu iletişim çoğunlukla API'ler üzerinden gerçekleşir. API'ler genel olarak iki gruba ayrılabilir: Public ve Private API'ler.

Public API'ler: Dış kullanıcıların, partnerlerin veya geliştiricilerin erişebildiği API'lerdir.

Private API'ler: Sadece kurum içi sistemlerin veya belirli servislerin kullanması için tasarlanmış API'lerdir.

Fakat burada önemli bir nokta var: Bir API'nin "private" olması, onun otomatik olarak güvenli olduğu anlamına gelmez. Yanlış yapılandırılmış, internete açık kalmış ya da yeterli yetkilendirme kontrolü olmayan private API'ler ciddi veri sızıntılarına yol açabilir.

API Mimari Türleri Nelerdir?

API dünyasında farklı mimari yaklaşımlar vardır. En bilinenleri REST, SOAP, GraphQL ve gRPC'dir.

REST, günümüzde en yaygın kullanılan API stilidir. HTTP metotlarıyla çalışır: GET, POST, PUT, PATCH, DELETE gibi. Genellikle JSON formatı kullanılır ve web uygulamalarında sıkça karşımıza çıkar.

SOAP, daha eski ve daha katı standartlara sahip bir yapıdır. XML tabanlıdır. Güvenlik, işlem yönetimi ve hata yönetimi gibi konularda güçlüdür fakat REST'e göre daha karmaşık olabilir.

GraphQL, istemcinin tam olarak hangi veriye ihtiyacı varsa onu istemesine olanak tanır. Gereğinden fazla veya eksik veri alma problemini azaltır. Ancak yanlış yapılandırıldığında farklı güvenlik riskleri oluşturabilir.

gRPC, özellikle mikroservis mimarilerinde kullanılan, performans odaklı bir iletişim yaklaşımıdır. Protocol Buffers ile çalışır ve sistemler arası hızlı veri aktarımı sağlar.

Bu seride ağırlıklı olarak REST API güvenliği üzerinden ilerleyeceğiz. Çünkü hem en yaygın kullanılan yapı bu, hem de OWASP API Security Top 10 başlıklarının çoğunu REST üzerinden anlaşılır şekilde göstermek mümkün.

API'ler Neden Saldırganlar İçin Cazip?

API'ler doğrudan veriyle ve iş mantığıyla konuşur.

Bir web sayfasında kullanıcı yalnızca arayüzü görür. Ama API, çoğu zaman sistemin gerçek veri akışına daha yakındır. Bu yüzden saldırganlar için API'ler çok değerli hedeflerdir.

Bir API açığı şu sonuçlara yol açabilir:

Başka kullanıcıların verilerine erişim
Yetkisiz işlem yapabilme
Hesap ele geçirme
Hassas iş süreçlerini manipüle etme
Rate limit eksikliğiyle sistemi yorma
Eski API versiyonlarından veri sızdırma
Sunucu tarafında istenmeyen istekler yaptırma
SQL Injection gibi klasik zafiyetleri API üzerinden tetikleme

Yani API güvenliği sadece "endpoint çalışıyor mu?" sorusuyla sınırlı değildir.

Asıl soru şudur:

Bu endpoint gerçekten sadece erişmesi gereken kişiye, sadece görmesi gereken veriyi, sadece yapmasına izin verilen işlem kadar mı sunuyor?

OWASP API Security Top 10

API güvenliği alanında en önemli referanslardan biri OWASP API Security Top 10 listesidir. Bu liste, API'lerde en sık karşılaşılan ve en kritik güvenlik risklerini sınıflandırır.

2023 listesinde öne çıkan başlıklar şunlardır:

Broken Object Level Authorization
Broken Authentication
Broken Object Property Level Authorization
Unrestricted Resource Consumption
Broken Function Level Authorization
Unrestricted Access to Sensitive Business Flows
Server Side Request Forgery
Security Misconfiguration
Improper Inventory Management
Unsafe Consumption of APIs

İsimler ilk bakışta uzun ve teknik gelebilir. Fakat her biri aslında çok pratik bir probleme karşılık gelir.

Mesela Broken Object Level Authorization, bir kullanıcının kendisine ait olmayan bir kaynağa erişebilmesi anlamına gelir.

Broken Authentication, kimlik doğrulama mekanizmasının zayıf ya da atlatılabilir olmasıdır.

Improper Inventory Management ise eski, unutulmuş veya belgelenmemiş API versiyonlarının hala erişilebilir durumda kalmasıdır.

Bu seride bu başlıkları tek tek ele alacağız. Her yazıda bir veya birkaç saldırı tipini sade bir senaryo üzerinden inceleyeceğiz.

API Güvenliğinde En Büyük Yanılgı

API güvenliğinde sık yapılan hatalardan biri, kimlik doğrulama yapıldığı için sistemin güvenli olduğunu varsaymaktır. Bir kullanıcının sisteme giriş yapmış olması, her veriye erişebileceği veya her işlemi yapabileceği anlamına gelmez. Authentication ve authorization birbirinden farklıdır.

Authentication: Kullanıcı kim? Authorization: Bu kullanıcı ne yapabilir?

Bir API, kullanıcıyı doğru şekilde tanıyor olabilir. Ama o kullanıcının hangi veriye erişebileceğini doğru kontrol etmiyorsa sistem yine de savunmasızdır.

Bu yüzden API güvenliğinde sadece login mekanizmasına bakmak yeterli değildir. Her endpoint, her parametre, her veri alanı ve her iş akışı ayrı ayrı değerlendirilmelidir.

Bu Seride Ne Yapacağız?

Bu seride API saldırılarını teorik tanımlarla bırakmayacağız. Her yazıda şu yapıyı takip edeceğiz:

Önce zafiyetin ne olduğunu açıklayacağız.
Sonra gerçekçi bir API senaryosu üzerinden nasıl ortaya çıkabileceğini inceleyeceğiz.
Ardından bunun iş etkisini konuşacağız.
Son olarak da nasıl önlenebileceğine bakacağız.

Amaç yalnızca saldırı tekniklerini göstermek değil. Asıl amaç, API güvenliğine doğru yerden bakabilmek.

Çünkü güvenli API tasarımı, sadece firewall veya token kullanmakla çözülmez. Güvenli API tasarımı; veri modeli, yetki kontrolü, iş mantığı, hata yönetimi, rate limit, versiyonlama ve üçüncü parti entegrasyonların tamamını kapsar.

Kapanış

API'ler modern yazılımın taşıyıcı kolonlarından biri haline geldi. Bu yüzden API güvenliği artık opsiyonel bir konu değil. Bir uygulamanın frontend'i ne kadar iyi korunursa korunsun, backend API'leri yanlış tasarlanmışsa saldırgan için yeterli alan oluşabilir.

Bu serinin sonraki yazısında ilk ciddi API güvenlik risklerinden biriyle başlayacağız:

Broken Object Level Authorization, yani kullanıcıların kendilerine ait olmayan nesnelere erişebilmesi. Kısaca şunu soracağız:

Bir kullanıcı sadece kendi verisini mi görüyor, yoksa URL'deki ID'yi değiştirerek başkalarının verilerine de ulaşabiliyor mu?