Bir agent ne yapabilir? Yetkiyi görev metninden ayır

Bir bilgi asistanı düşün: üç kaynağı okuyabiliyor, bir özet hazırlıyor ve sonucu e-postayla gönderebiliyor. Kullanıcının “haftalık özeti hazırla” demesi, bu üç işlemin aynı yetkiyle yürütülmesini gerektirmez. Okuma hakkı, taslak yazma hakkı ve gerçek alıcıya gönderme hakkı farklı sınırlar olabilir. Bu yazı, bu sınırları kişisel bir otomasyon örneğiyle görünür kılan tasarım yaklaşımıdır; belirli bir ürünün güvenlik değerlendirmesi değildir.

Görev ile yetkiyi ayrı satırlara yaz

Görev metni beklenen sonucu anlatır. Yetki kartı ise hangi veriye hangi işlemin uygulanabileceğini açıklar. “Özeti hazırla” görevine karşılık, yalnızca seçilmiş kaynakları okuma ve yöneticiye açık bir taslak oluşturma yetkisi verilebilir. Gönderim bu karta dahil olmayabilir. Böylece aracın neyi yapabilecek durumda olduğu ile o anda neyi yapmasına izin verildiği birbirine karışmaz.

Kartta kullanıcı, hedef kayıt, izin verilen işlem ve kapsamın geçerliliği bulunsun. “Bütün dosyalar” yerine ilgili klasör, “bütün alıcılar” yerine seçilmiş adres gibi somut bir sınır düşün. Bunlar evrensel bir izin şeması önerisi değil, kendi akışındaki belirsizliği yakalamak için sorulardır. Bir veri alanını neden açtığını açıklayamıyorsan önce daha dar kapsamla dene.

Yetkisiz durumda varsayılan sonucu tanımla

Bir işlem için açıkça izin bulunmuyorsa ne olacağını koddan önce yaz. Sessizce devam etmek, başka bir araçla aynı işi denemek veya yetkiyi tahmin etmek yerine anlaşılır bir ret sonucu üretilebilir. Bu sonuç kullanıcıyı çıkmaza sokmamalı: hangi kapsamın eksik olduğunu ve güvenli sonraki adımı açıklamalı. Ancak ret mesajı gereksiz özel veri veya başka hesapların varlığını da açığa çıkarmamalı.

OWASP’ın yetkilendirme rehberi en az ayrıcalık, varsayılan ret ve her istekte izin denetimi gibi ilkeleri ele alır. Bunları kendi örneğine çevir: kaynak okuma izinli, taslak kaydı ayrı bir kapsamda, dış gönderim güncel onaya bağlı olsun. Bu ilkeler bir kütüphane adı seçmekle tamamlanmaz; davranışın gerçekten uygulandığını gözlemek gerekir.

Onayı belirli bir dış etkiye bağla

Gönderim için onay istendiğinde kişi hangi metni, hangi alıcıyı ve hangi işlemi onayladığını görebilsin. Sonra metin değişirse eski onayın yeni sürümü kapsayıp kapsamadığını sorgula. “Daha önce evet demişti” ifadesi yeterli bir işlem kaydı değildir. Aynı şekilde bir taslağın kaydedilmesi, onun yayımlanmasına veya başka bir hizmete gönderilmesine otomatik izin oluşturmaz.

Bu ayrımı arayüzde de koru. Önizleme, taslak kaydı ve gönderim aynı etiketle sunulursa kullanıcı farklı dış etkileri ayırt etmekte zorlanır. Her kontrolün sonucu açık olsun. İptal veya ret durumunda metnin korunması da önemlidir; kişi çalışmasını kaybetmeden kapsamı yeniden gözden geçirebilmeli. Bir onay düğmesini kullanışlı yapan şey yalnızca belirgin rengi değildir.

Denetimi doğru sınırda uygula

Tarayıcıdaki bir düğmeyi gizlemek, doğrudan isteğin engellendiğini göstermez. Gerçek uygulamada sunucu da kullanıcıyı, kayıt sahipliğini ve izin verilen işlemi değerlendirmeli. İstemciden gelen “onaylı” alanını tek başına güvenilir sayma. Onay kaydının hangi iş sürümüne ait olduğu, hedefin değişip değişmediği ve kaydın hâlâ geçerli olup olmadığı birlikte incelenebilir olmalı.

Karmaşık bir akışta aynı kapsamın farklı katmanlarda farklı yorumlanması mümkündür. Bunu küçük bir tabloyla yakala: arayüzün gösterdiği işlem, API’nin kabul ettiği işlem ve dış serviste oluşan etki. Üçü aynı işi mi anlatıyor? Gönderim reddedilirken taslak siliniyorsa veya başka hedefe yöneliyorsa sınırın yalnızca bir kısmı korunuyor olabilir.

İzin verilmeyen örneği de çalıştır

Test kümesinde yalnızca doğru kullanıcı ve doğru kayıt bulunmasın. Başka bir kayıt kimliği, süresi geçmiş onay ve onaydan sonra değişmiş alıcı için beklenen sonucu yaz. Kontrollü ortamda her durumda dış etkinin oluşmadığını bağımsız kayıtla kontrol et. Ekrandaki hata mesajı tek başına gönderim yapılmadığını kanıtlamaz. Tersine, zaman aşımı da işlemin kesin başarısız olduğunu göstermez.

Deney alanında üç yetki kartını dört işlemle eşleştirebilirsin. Bu sade modelde kalıcı silme her zaman reddedilir; gerçek bir servise çağrı yapılmaz. Sonucu PDF indirerek kendi tasarım notlarınla karşılaştır. Bir sonraki gerçek uygulama turunda tek bir izinli ve tek bir reddedilen örnek seçmek, henüz gözlenmemiş geniş bir güvenlik iddiasından daha somut başlangıç sağlar.

Küçük bir kabul kaydı örneği

Haftalık özet için bir deneme kaydı oluşturduğunu düşün. İlk satırda kaynak okuma işlemi, ikinci satırda taslağın kaydı, üçüncü satırda dış gönderim yer alsın. Her satıra beklenen sonucu ve bağımsız kanıtı yaz. İlk ikisi başarılı olsa bile üçüncü adım onaysızsa gönderimin oluşmadığını görmelisin. Aynı tabloyu onaydan sonra alıcıyı değiştirerek yeniden dene. Eski onay işaretinin yeni hedefe taşınması beklenen bir başarı değildir.

Kayıt yalnızca bir tarih ve yeşil simgeden oluşmasın. Denenen sürüm, kullanılan yapay kayıt, işlem kapsamı ve gözlenen sonuç birbirine bağlansın. Böylece daha sonra araç değiştiğinde önceki sonucun hangi koşula ait olduğunu anlayabilirsin. Gerçek kişi veya müşteri verisini test kanıtına eklemek zorunda değilsin. Bu örnek için takma bir alıcı ve gönderimsiz test yolu yeterlidir. Sonuç belirsizse bunu başarılı diye işaretlemek yerine eksik kanıt olarak bırak.

Kaynak

• OWASP — Authorization Cheat Sheet