Hızlı cevap: Mass assignment (aşırı veri bağlama, over-posting), bir uygulamanın gelen istek gövdesini (genelde JSON) otomatik olarak bir nesnenin alanlarına bağlaması ve bu sırada kullanıcının yazmaması gereken alanları da kabul etmesidir. Kullanıcı profilini güncellerken istek gövdesine "role": "admin" veya "isActive": true eklerse ve sunucu tüm alanları körü körüne bağlarsa, kullanıcı kendini yönetici yapabilir ya da fiyatı, bakiyeyi, hesap durumunu değiştirebilir. Bu, OWASP API Top 10'da ayrı bir madde olarak listelenir. Çözüm gelen alanları beyaz listeyle (allowlist) sınırlamak, güvenli bir DTO/girdi şeması kullanmak ve hassas alanları (role, balance, id, createdAt) salt-okunur kabul etmektir. Kara liste (blacklist) yaklaşımı güvenilmezdir.

Mass assignment, modern çerçevelerin sunduğu kolaylığın gölge tarafıdır. "Gelen veriyi tek satırda nesneye bağla" özelliği geliştiriciyi hızlandırır, ama hangi alanların dışarıdan yazılabileceğini açıkça sınırlamazsanız, saldırgan istek gövdesine fazladan alan ekleyerek iç durumunuza doğrudan yazar. Bu rehber açığın neden bu kadar yaygın olduğunu, en tehlikeli örneklerini, nasıl tespit edildiğini ve kalıcı çözümü anlatır.

Açık nasıl çalışır: otomatik bağlamanın gölgesi

Birçok çerçeve, gelen JSON'u veya form verisini doğrudan bir model/nesne örneğine bağlayan kısayollar sunar. Geliştirici user.update(request.body) benzeri tek bir çağrı yazar ve çerçeve gövdedeki her anahtarı eşleşen alana yazar. Niyet "istemci gönderdiği alanları güncellesin"dir. Ama istemci yalnızca ad ve email değil, nesnenin sahip olduğu her alanı gönderebilir.

Tipik akış şöyledir. Profil güncelleme formu normalde sadece ad, email, telefon gönderir. Saldırgan isteği yakalar ve gövdeye "role": "admin", "isAdmin": true, "emailVerified": true veya "balance": 999999 ekler. Sunucu gövdenin tamamını nesneye bağlarsa, bu alanlar da yazılır. Kullanıcı arayüzde bu alanları hiç görmez; açık, arayüzün gösterdiğiyle sunucunun kabul ettiği arasındaki farktadır. Bu yüzden açık yalnızca formu değil, API sözleşmesini test etmeyi gerektirir.

En tehlikeli örnekler

Eklenen alan Etki
role / isAdmin Yetki yükseltme, yönetici olma
isActive / emailVerified Onay/doğrulama adımını atlama
balance / credit / points Bakiye veya puan şişirme
price / discount Sipariş fiyatını değiştirme
userId / ownerId Bir kaydı başka kullanıcıya bağlama (IDOR ile birleşir)
id Kayıt kimliğini ezme, çakışma
createdAt / status İş-mantığı durumunu manipüle etme

Mass assignment sık sık başka açıklarla birleşir. Örneğin userId alanını değiştirebilmek, yetkisiz nesne erişimiyle (IDOR) iç içe geçer. Fiyat alanını değiştirmek bir iş-mantığı açığına dönüşür. Bu yüzden API güvenlik testinde mass assignment, OWASP API Top 10 yazımızda ele aldığımız gibi, yetkilendirme açıklarıyla birlikte değerlendirilir.

Nasıl tespit edilir

Tespit, API'nin kabul ettiği gerçek alan kümesini keşfetmeyi gerektirir. Pentester önce bir nesnenin GET yanıtına bakar: yanıt role, balance, createdAt gibi alanları içeriyorsa, aynı alanların güncelleme/oluşturma isteğinde de kabul edilip edilmediği denenir. Yöntem, meşru bir isteği yakalayıp gövdeye fazladan alan eklemek ve yanıtın ya da sonraki GET'in bu alanı yansıtıp yansıtmadığına bakmaktır.

Otomatik tarayıcılar bunu genelde kaçırır çünkü hangi alanın hassas olduğunu ve beklenen iş-mantığını bilmezler. Güvenilir tespit, API sözleşmesini ve veri modelini anlayan manuel testle yapılır. Burp Suite rehberimizde anlattığımız istek-yakalama ve tekrar-gönderme akışı burada temel araçtır. Önemli olan, eklenen alanın gerçekten yazıldığını kanıtlamaktır; yanıtın 200 dönmesi tek başına yeterli değildir.

Kalıcı çözüm: allowlist, DTO, salt-okunur alan

Mass assignment'ın tek güvenilir çözümü, dışarıdan hangi alanların yazılabileceğini açıkça tanımlamaktır:

  • Allowlist (beyaz liste). Gelen gövdeden yalnızca izin verilen alanları alın, gerisini yok sayın. "Şu alanlar güncellenebilir" demek, "şu alanlar güncellenemez" demekten her zaman daha güvenlidir, çünkü yeni bir hassas alan eklendiğinde kara liste güncellenmezse açık geri gelir.
  • Girdi DTO'su / şema. Gelen veriyi doğrudan veritabanı modeline değil, yalnızca izin verilen alanları içeren ayrı bir girdi nesnesine (DTO) veya şemaya (örneğin bir doğrulama kütüphanesiyle) bağlayın. Model ile dış sözleşmeyi ayırmak en sağlam yaklaşımdır.
  • Salt-okunur alanlar. id, role, balance, createdAt, ownerId gibi alanları çerçeve seviyesinde salt-okunur veya korumalı işaretleyin; bu alanlar yalnızca sunucu tarafı mantıkla değişsin.
  • Yetki kontrolünü ayrı yapın. Rol değişimi gibi işlemler ayrı, yetkilendirilmiş bir uç noktadan geçsin; asla genel profil güncellemesiyle aynı yola bağlanmasın.

Bu tasarım aynı zamanda genel güvenlik yanlış-yapılandırmasıyla da bağlantılıdır; varsayılanların güvensiz bırakılması konusunu güvenlik yanlış yapılandırması yazımızda ele aldık.

KAOS ve DSET yaklaşımı

DSET olarak mass assignment'ı API ve web uygulaması testlerinin standart bir kalemi sayarız, çünkü etkisi çoğu zaman doğrudan yetki yükseltme veya finansal manipülasyondur. Testlerimizde bir nesnenin tam alan kümesini çıkarır, güncelleme ve oluşturma uç noktalarına hassas alanları enjekte eder ve açığı yalnızca "kabul edildi" diye değil, alanın gerçekten yazıldığını ve bir yetki/durum değişikliği yarattığını kanıtlayarak doğrularız. Geliştirdiğimiz KAOS aracı, otomatik model-bağlama kalıplarını ve salt-okunur olması gereken hassas alanların güncellenebildiği uç noktaları işaretler, ama son kararı kanıtlanmış yazma davranışına bağlar. API'nizi mass assignment ve ilişkili yetkilendirme açıklarına karşı test ettirmek için Ankara Hacettepe Teknokent'teki ekibimizle DSET ile iletişime geçin.

Sık sorulan sorular

Mass assignment ile IDOR aynı şey mi? Hayır ama sık birlikte çıkar. IDOR (yetkisiz nesne erişimi) başkasının kaydına erişmekle ilgilidir; mass assignment ise kendi isteğinizde olmaması gereken alanları yazmakla. İkisi birleştiğinde, örneğin bir güncelleme isteğine ownerId ekleyerek bir kaydı başka kullanıcıya bağlayabilirsiniz. Bu yüzden ikisi de yetkilendirme testi kapsamında birlikte değerlendirilir.

Kara liste (hassas alanları engelleme) neden yeterli değil? Çünkü kara liste bakım gerektirir ve unutmaya açıktır. Bugün role ve isAdmin'i engellerseniz, yarın eklenen isSuperAdmin veya accountTier alanı listede olmadığı için açığa döner. Beyaz liste tersine çalışır: yalnızca açıkça izin verilenler yazılır, yeni eklenen her alan varsayılan olarak güvende kalır. Güvenli varsayılan ilkesi budur.

GraphQL ve modern API'lerde de olur mu? Evet. Girdi tiplerini çok geniş tanımlayan veya mutasyonlarda tüm nesne alanlarını yazılabilir bırakan GraphQL şemaları da aynı açığa sahiptir. GraphQL'e özgü yetki ve girdi konularını GraphQL API güvenliği yazımızda ele aldık. Çözüm aynıdır: girdi tiplerinde yalnızca gerçekten yazılabilir alanları tanımlayın.

Kaynaklar

  • OWASP API Security Top 10, Broken Object Property Level Authorization ve mass assignment maddeleri.
  • OWASP Web Security Testing Guide, mass assignment test bölümü.
  • CWE-915 (improperly controlled modification of dynamically-determined object attributes).
  • DSET blog: API güvenliği OWASP API Top 10 ve güvenlik yanlış yapılandırması.