[ MSP, API'ler ve entegrasyonlar ]

API kimlik doğrulaması ve etki alanı verilerine kapsamlı erişim

Kiracıya ve operasyona göre rapor erişimi verin, ardından reddetmeleri de başarılı okumalar kadar dikkatli bir şekilde test edin.

EmailAuth araştırma ekibi tarafından · 2 dakikalık okuma

[ Anahtar noktalar ]

  • Kiracıya ve operasyona göre rapor erişimi verin, ardından reddetmeleri de başarılı okumalar kadar dikkatli bir şekilde test edin.
  • Başarılı bir oturum açma veya rapor okuma, ne kiracılar arası erişime ne de DNS yazma yetkisine izin verir; geciken çalışmayı ve dışa aktarılan yapıları yeniden kontrol edin.
Bu sayfada

Kimlik doğrulama, arayan kişiyle ilgili bir şeyi kanıtlar. Yetkilendirme, arayanın bu müşterinin raporlarını alıp alamayacağını veya bu işlemi gerçekleştirip gerçekleştiremeyeceğini belirler. Geçerli bir API kimlik bilgisi, kiracı sınırlarının etrafında bir kısayol haline gelmemelidir. Uç noktaları veya arka plan işlerini eklemeden önce bir izin matrisiyle başlayın.

Kimliği istenen nesneye bağlayın

Arayanın kimliğini desteklenen kimlik doğrulama mekanizması aracılığıyla çözümleyin, ardından yetkili kiracısını ve işlem kapsamlarını güvenilen sunucu tarafı durumundan alın. Bir URL'deki veya istek gövdesindeki kiracı kimliğini izin kanıtı olarak değil, istenen hedef olarak değerlendirin. Raporu kontrol edin, işi dışa aktarın ve arayanın gerçek iznine göre yapıyı indirin.

OWASP'ın Yetkilendirme Hile Sayfası her istekte en az ayrıcalık, varsayılan olarak reddetme ve izin doğrulamayı önerir. Bu ilkeleri eşzamansız çalışanlara ve indirme bağlantılarının yanı sıra ilk API çağrısına da uygulayın. Yasal olarak oluşturulan bir dışarı aktarmanın, nesne kimliğinin tahmin edilmesi kolay olduğundan, daha sonra farklı bir kiracı tarafından indirilememesi gerekir.

Okuma erişimini değişiklik yetkisinden ayırın

Bir rapor okuyucusu, onaylanmış etki alanı verilerini alabilir ancak otomatik olarak DNS yazma iznini almamalıdır. Bir DNS operatörünün depolanan rapor geçmişine erişmesine gerek olmayabilir. Bir denetçi, ham mesajlar yerine kısıtlı kanıt görünümüne ihtiyaç duyabilir. Her rolün izin verilen nesnelerini ve işlemlerini belgeleyin ve gizli yönetimi sıradan günlüklerin ve dışa aktarmaların dışında tutun.

Bir otomasyon kimlik bilgisinin yalnızca kiracı A'nın raporlarını okumak için onaylandığını varsayalım. Geçerli kimlik doğrulamasına rağmen, kiracı A için bir DNS değişikliğinin ve kiracı B için okunan bir raporun her ikisinin de bu izin kapsamında reddedilmesi gerekir. Ayrı, açıkça onaylanmış bir işletmeci hibesi, kendi nesne ve operasyon kontrollerine ihtiyaç duyacaktır. Bunlar varsayımsal olarak beklenen kararlardır; uygulanan izin matrisi veya EmailAuth rollerinin açıklaması değildir.

Negatif testleri kabulün bir parçası haline getirin

İzin verilen aynı kiracı raporu okumasını çalıştırın ve ardından yalnızca istenen kiracıyı değiştirin. Eksik bir okuma kapsamı ve iptal edilen bir sorumlu ile tekrarlayın. Ayrıca nesne düzeyindeki kimlikler, depolanan dışa aktarmalar, sıraya alınmış işler ve değişen grup üyelikleri için gerçek testler planlayın. Başka bir müşterinin hesabını araştırmak yerine yetkili sentetik kiracıları ve zararsız verileri kullanın.

Yetkili her test için fiili kararı ve açıklanan yanıt alanlarını kaydedin. Reddedilen bir istek, meta veriler, sayımlar, indirme bağlantıları veya önbelleğe alınmış sonuçlar yoluyla özel nesne ayrıntılarını sızdırmamalıdır. Doğru uygulamayı herkesi reddeden bir uç noktadan ayırmak için geçerli bir kapsamlı okuma ekleyin. Burada hiçbir belirteç sistemi, OAuth akışı veya üretim yetkilendirme testi sağlanmaz veya yürütülmez.

Hibeyi yaşam döngüsü boyunca işletin

Hibe sahibini, onaylanan amacı, kiracı kapsamını, sona erme veya inceleme tetikleyicisini ve iptal yolunu kaydedin. Kimlik bilgileri materyalini onaylanmış gizli sistemde saklayın, kontrollü bir prosedür altında dönüşümlü olarak kullanın ve sırrı kaydetmeden kullanımı denetleyin. Geciken işi yürütürken yetkiyi yeniden kontrol edin; sıraya alınmış bir görev, iptalden sonra izinleri süresiz olarak saklamamalıdır.

Temel veri hassasiyetini inceleyin. RFC 9990 açıklar toplu rapor içerik ve güvenlik hususları; rapor meta verileri hâlâ kontrollü açıklamayı hak ediyor. Yetkilendirme hatası durumunda, başka bir kiracının özel nesnelerini onaylamadan uygun bir ret yanıtı verin. Kiracılar arası veriler keşfedilirse, maruz kalmayı kontrol altına alın ve kuruluşun olay prosedürünü başlatın. Sadece kullanıcı arayüzünü değiştirip API'nin güvenli olduğunu varsaymayın.

OWASP'ın çok kiracılı kılavuzu, özellikle eşzamansız çalışma, önbellek/oturum ve dosya depolama bölümleri, kapsamın ilk isteğin ötesinde uygulanmasını ve gecikmeli yürütme sırasında zamana duyarlı izinlerin yeniden kontrol edilmesini destekler.

[ Götürmek ]

Başarılı bir oturum açma veya rapor okuma, ne kiracılar arası erişime ne de DNS yazma yetkisine izin verir; geciken çalışmayı ve dışa aktarılan yapıları yeniden kontrol edin.

[ Role göre ]

Bu sizin için ne anlama geliyor?

Sonraki pratik adımlar için rolünüzü seçin.

BT / Posta Yöneticisi

Nesneleri ilk uç noktanın ötesinde test edin

Dışa aktarmalar ve arka plan çalışmaları erişim yolunu genişletir.

Sonraki adımlar

  1. Artefakt alımını kontrol edin.
  2. Test erişimini iptal edin.
  3. Önbellek bölümlemesini doğrulayın.

CISO / SecOps

Boyunca en az ayrıcalığı kullan

Yetkilendirmenin yeniden denemelerden ve rol değişikliklerinden etkilenmemesi gerekir.

Sonraki adımlar

  1. Kapsam kaymasını gözden geçirin.
  2. Ayrıcalıklı kullanımı denetleyin.
  3. Olayı kontrol altına alma egzersizi yapın.

Kurucu / Teknik Olmayan

İzolasyon testi için bütçe

Kiracı ayrımı müşterinin verdiği bir sözdür.

Sonraki adımlar

  1. Bir izin modelini onaylayın.
  2. Reddetme kanıtı gerektirir.
  3. Hibe sahiplerini atayın.

[ SSS ]

Sık sorulan sorular

Geçerli bir jeton her kiracıya yetki veriyor mu?

Hayır. Yetkilendirmenin arayan kişiyi belirli kiracıya, nesneye ve işleme bağlaması gerekir.

Talepteki kiracı kimliği güvenilir mi?

İstenen hedefi tanımlar; hibe oluşturmaz.

Rapor okuyucuları DNS düzenlemeli mi?

Ayrı bir açık izin bu işleme izin vermediği sürece hayır.

Hangi olumsuz durumlar yer alıyor?

Geçerli kapsamlı bir okumanın yanı sıra kiracılar arası istekleri, eksik rapor kapsamını ve beklenen retler olarak iptal edilen kimliği planlayın. Gerçek servis sonuçlarını gözlemleyin.

Örnek OAuth'u test ediyor mu?

Hayır. Bir kimlik doğrulama uygulaması sağlamadan veya yürütmeden yetkilendirme kararlarını açıklar.

Sıraya alınan işlerin erişimi yeniden kontrol etmesi gerekir mi?

Bunları yalnızca gönderimde değil, yürütme ve yapıt alımında mevcut otoriteyi uygulayacak şekilde tasarlayın.

İndirme bağlantıları incelemeyi atlayabilir mi?

Hizmete uygun kapsam, yaşam süresi ve hedef kitle kontrollerine ihtiyaçları vardır.

Bir önbellek diğer kiracının sonuçlarını sızdırırsa ne olur?

Ana uç nokta izinleri kontrol etse bile bunu bir yetkilendirme kusuru olarak değerlendirin ve kontrol altına alın.

[ Kaynaklar ]

Kaynaklar

  1. OWASP Yetkilendirme Hile Sayfası

    Bölümler En Az Ayrıcalıkları Uygulayın · Varsayılan Olarak Reddedin · Her İstekte İzinleri Doğrulayın · Yetkilendirme Mantığı için Birim ve Entegrasyon Test Senaryoları Oluşturun

  2. RFC 9990 DMARC Toplu Raporlama

    Bölümler §3.1 · §3.1.1.4 · §3.1.2 · §3.5.1 · §3.5.4 · §4 · §7 · §8

  3. OWASP Çok Kiracılı Güvenlik Hile Sayfası

    Bölümler §1. Kiracı Tanımlama ve İçerik Yönetimi · §3. Kiracılar Arası Veri Erişiminin Engellenmesi (IDOR Önleme) · §4. Önbellek ve Oturum Yalıtımı · §5. API, Eşzamansız Çalışma ve Kaynak Kontrolleri · §6. Dosya Depolama ve Blob Yalıtımı · §7. Kiracı Yerleştirme ve Ayrılma Güvenliği

[ Sözlük ]

Sözlük

Nesne düzeyinde yetkilendirme
Talep edilen belirli kaynak için izin kararı.
Kapsam
Bir tür işlem veya kaynak için sınırlı izin.

Kurumsal menşe

Neden en iyi finans kurumları ve hükümetler e-posta güvenlik kontrol panellerini kullanımdan kaldırdı.

Geleneksel e-posta kimlik doğrulama platformları size bir gösterge tablosu satar ve mühendislerinizden bu işi yapmalarını ister. Riskli ortamlarda, manuel gözetim, gecikmeli uygulama, konfigürasyon kayması ve izlenmeyen gölge alanlar anlamına gelir.

EmailAuth aracılı e-posta kaynak platformudur. Temsilcilerimiz uyguluyor p=reject, üçüncü taraf gönderenleri uyumlu tutun ve alan adlarınızı tam sürüme taşıyın RFC 9989 döngüdeki insan tarafından denetlenebilirliğe sahip yeni DMARC standardı uyumluluğu.

Hükümetler Büyük işletmeler 1. Seviye finans kurumları

SaaS · Özel kiracılık · Şirket içi hava boşluklu · BYOK şifrelemesi

Bilgi Bankası