API Testing

API Nedir?

• API'ler (Uygulama Programlama Arayüzleri) yazılım sistemlerinin ve uygulamaların iletişim kurmasını ve veri paylaşmasını sağlar.

• Tüm dinamik web siteleri API'lerden oluşur, bu nedenle SQL enjeksiyonu gibi klasik web güvenlik açıkları API testi olarak sınıflandırılabilir.

Yöntemler

Recon

Github'da arama yaparak bu api için bir sızmış bilgi veya kaynak kod varmı diye bakabiliriz.

Postman Toplama

Postmanda proxy ayarlayın ve foxyproxy ile bütün istekleri postman'a yönlendirin.

Swagger Toplama

Swagger Editor: https://editor.swagger.io/

mitmweb
mitmproxy2swagger -i flows -o spec.yml -p http://api.example.com -f flow

Dökümantasyon Sayfası

Api'nin dökümantasyon veya listeleme sayfasına erişip erişilemediğini kontrol edebiliriz.

/api/update/user -> 200 OK
/api -> 200 OK
/swagger

Parametre Ekleme

Eğer bir api'ye istek atılırken bir nesne gönderiliyor ise bu nesneye yeni parametreler ekleyerek göndermeyi deneyebiliriz.

Bu gönderilmeyen parametreler genellikle başka GET isteklerinde görülebilir.

POST /api/checkout
{
    "product_id":"1",
    "quantity":1
}

POST /api/checkout
{
    "product_id":"1",
    "quantity":1,
    "price":0
}

Server Side Paramater Pollution

Eğer sunucu tarafı parametreleri ayıran & karakterini doğru işlemiyorsa sunucuda çalışan koddaki parametreleri değiştirebiliriz.

POST /api/resetPassword HTTP/2

username=administrator

Öncelikle %26 ile bir parametre eklemeye çalışıyoruz. Eğer sunucu bir hata veriyorsa zafiyet vardır.

POST /api/resetPassword HTTP/2

username=administrator%26foo=bar

Sonrasında %23 karakteri ile sunucuya hata verdirip gizli bir parametre var mı diye kontrol ediyoruz. Eğer varsa muhtemelen hata mesajında yazar.

POST /api/resetPassword HTTP/2

username=administrator%23

Bulduğumuz parametreyi %26 ile ekleyip düzenleyebiliriz.

POST /api/resetPassword HTTP/2

username=administrator%26password=pass123

HTTP Method Değiştirme

Eğer bir api isteği bir http methodu ile yapılıyor ise diğer http methodları denenebilir.

GET /api/user/1 -> 200 OK
PUT /api/user/1 -> 200 OK

GET
POST
HEAD
PUT
TRACE
OPTIONS
DELETE
COPY
DEBUG
MOVE
PATCH
TRACK
UPDATE

Broken Object Level Authorization (BOLA)

Saldırganın kendine ait olmayan bir veriye erişmesini sağlar. Eğer uygulamada düzgün erişim kontrolu yapımıyorsa ortaya çıkar. Web güvenliğinde biz bu zafiyeti IDOR olarak biliriz.

/api/v1/options/100 -> 200 OK
/api/v1/options/101 -> 200 OK

Broken Authentication

Eğer aşağıdaki kurallar yok ise brute force denenebilir.

• Güçlü parola politikası olmalı.

• Login, OTP, password reset gibi isteklerde rate limit olmalı.

Broken Object Property Level Authorization

• Sadece kendi verini görmen gereken bir istekte herkesin verisini görebilirsin.

• Başkasının verisini değiştirebiliyor musun?

Unrestricted Resource Consumption

• Çok kaynak tüketen bir istekte her zaman rate limiting olmalı (Send OTP mail vb.)

• Ayrıca file upload varsa sadece belirli dosya türleri kabul edilmeli. Ayrıca çok büyük dosyalar kabul edilmemeli.

Broken Function Level Authorization

• Sadece belirli rollerin çalıştırabileceğini yazan isteklerde aslında yetki kontrolü yapılmıyor olabilir.

Unrestricted Access to Sensitive Business Flows

• Şirketlerin hassas bilgilerini gösteren istekler olabilir, mesela ürünler hangi tarih arasında indirime giriyor. Genelde bu zafiyet üstteki zafiyetler sonucu çıkar.

Server Side Request Forgery

POST /api/v1/getPhoto HTTP/2
{
    "url":"https://example.com/image.png"
}

POST /api/v1/getPhoto HTTP/2
{
    "url":"file:///etc/passwd"
}

Security Misconfiguration

GET /api/v1/getProduct/1 HTTP/2

GET /api/v1/getProduct/1'+OR+1=1--+- HTTP/2

Improper Inventory Management

Eski api versiyonları halen silinmemiş olabilir. Bu api servislerinde bırakılmış kritik bilgiler olabilir.

GET /api/v2/customers/deleted HTTP/2 -> 403 
GET /api/v0/customers/deleted HTTP/2 -> 200 OK

Unsafe Consumption of APIs

• Insecure Data Transmission: Veriler şifreli TLS ile şifrelenmeli.

• Inadequate Data Validation: Veriler tehlikeli karakterleri kabul etmemeli veya ayrıştırmalı.

• Weak Authentication: Kimlik doğrulama güvenli olmalı.

• Insufficient Rate-Limiting: Çok kaynak tüketen isteklerde rate limit olmalı.

• Inadequate Monitoring: API servisleri güvenlik ihlali olduğunda incelenebilmesi için log bulundurmalı.

Mass Assignment

Mass Assignment zafiyeti, kullanıcıdan gelen verilerin doğrudan model nesnelerine atanarak yetkisiz alanların güncellenmesi riskidir.

Bu gizli parametreleri bulmak için Arjun veya ParamMiner kullanılabilir

POST /api/v1/register HTTP/2
{
    "username":"john",
    "password":"password123"
}

POST /api/v1/register HTTP/2
{
    "username":"john",
    "password":"password123",
    "is_admin":true
}

Önlemler

• API'nizin herkesin erişimine açık olmasını istemiyorsanız belgelerinizin güvenliğini sağlayın.

• İzin verilen HTTP yöntemlerinden oluşan bir izin listesi uygulayın.

• Her istek veya yanıt için içerik türünün beklendiğini doğrulayın.

• Bir saldırgan için yararlı olabilecek bilgileri vermekten kaçınmak için genel hata mesajları kullanın.

• Yalnızca mevcut üretim sürümünde değil, API'nizin tüm sürümlerinde koruyucu önlemler kullanın.

Kaynaklar

Portswigger Academy: https://portswigger.net/web-security/api-testing

HTB API Attacks: https://academy.hackthebox.com/course/preview/api-attacks

APISEC University: https://www.apisecuniversity.com/courses/api-penetration-testing