Paylaşılan alt alan adları, iki giriş: hangi kayıtları kim görüyor?

Klinik A ve Klinik B tek bir kod tabanını, iki alt alan adını ve ofisten ve VPN üzerinden gelen ziyaretçilerin bir karışımını paylaşır. Ağ ekipleri iki girişi genellikle ayrı ayrı yapılandırır ve uygulama bunu yapmadığı sürece bu sorun değildir. Aşağıdaki denetimler uygulamaya aittir ve isteğin hangi kapıyı kullandığından bağımsız olarak aynı davranmalıdır.

Birincisi: ana bilgisayar adı yalnızca bir kiracıyı adlandırır

İstenen ana bilgisayar adını yönetici tarafından tutulan bir eşlemeye göre çözün ve bilinmeyen her şeyi reddedin. Ham başlık yerine çerçevenin doğrulanmış ana bilgisayar değerini kullanın, böylece hazırlanmış bir Host arama anahtarı enjekte edemez. Başarılı eşleşme koda hangi kiracı yapılandırmasının ve hangi markalamanın yükleneceğini söyler. Ancak çağıranın o kiracının verilerini görüp göremeyeceği hakkında hiçbir şey söylemez. Bu ikinci soruyu ayrı girdisi olan ayrı bir işlevde tutun.

Tek bir ana bilgisayar adı aramasından hem bağlamı hem de izni döndüren paylaşılan bir yardımcı işlev, hatanın başlangıcıdır.

İkincisi: üyelik oturumdan gelir

Kimliği doğrulanmış kullanıcının etkin üyeliklerini arayın ve bunları ilk denetimdeki kiracıyla karşılaştırın. Her iki kliniğe de ait bir kullanıcı geçiş yapabilir, ancak geçiş URL'den çıkarılan bir sonuç değil, istek bağlamında kaydedilen açık bir eylem olmalıdır. Bir kliniğe ait olup diğerini isteyen kullanıcı reddedilir; indirmeler ve API çağrıları da buna dahildir.

Olumsuz durumu bir kayıt tanımlayıcısını ve bir kiracı parametresini düzenleyerek test edin. İki değişiklikten biri veri döndürürse kapsam istekten okunuyor, doğrulanmış üyelikten değil.

Çerez kapsamı ve tek oturum açma, bir hesabın nerede sunulabileceğine karar verir. O hesabın neyi okuyabileceğine karar vermez.

Üçüncüsü: ağ, kişi hakkında hiçbir şey kanıtlamaz

Bir VPN geçidi bir tüneli doğrular, genel bir izin listesi bir adres aralığını doğrular. İkisi de bir kişiyi tanımlamaz. NAT birçok kullanıcıyı tek bir kaynak adreste toplar ve ofis aralığı binadaki herkes için aynısını yapar. İkisini de taşıma olgusu olarak ele alın ve yetkilendirmeyi uygulamada veya kimliği açıkça beyan eden ve buna göre incelenen bir entegrasyonda tutun.

DNS üçüncü taşıma olgusudur. Özel bir yanıt özel bir yol gerektirir ve genel bir ön uç desteklenen bir kaynak yolu gerektirir. Hiçbiri bir izin taşımaz.

Duvara asılacak tek cümle: ağ isteğin nasıl geldiğine karar verir, uygulama neyi okuyabileceğine karar verir.

Dördüncüsü: matrisi iki girişte de çalıştırın

A'yı A'da, B'yi B'de, A'yı B'de, bilinmeyen bir ana bilgisayar adını ve üyeliği olmayan kimliği doğrulanmış bir hesabı test etmek için kontrollü hesaplar kullanın. Dördüncü ve beşinci kapalı şekilde başarısız olmalı ve asla varsayılan bir kiracıya düşmemelidir. Aynı matrisi VPN girişinden de çalıştırın, her hesap için bir oturum kavanozuyla:

curl -s -o /dev/null -w '%{http_code}' -b jar.txt https://clinic-b.example.com/records/42
curl -s -o /dev/null -w '%{http_code}' -b jar.txt https://clinic-a.example.com/records/42

Ardından izin listesindeki bir girdiyi değiştirin ve yeniden çalıştırın. Hareket eden bir sonuç, bir ağ denetiminin yetkilendirme kararı verdiği anlamına gelir.

Matrisi ön uçtaki her değişiklikten sonra yineleyin, çünkü denetimi atlayan ikinci bir kod yolu bu sınırın aşınmasının en yaygın yoludur. Beklenen sonuç sıkıcıdır: her giriş aynı yanıtları üretir.