زیردامنه‌های مشترک، دو ورودی: چه کسی کدام سوابق را می‌بیند؟

کلینیک A و کلینیک B یک پایگاه کد، دو زیردامنه و ترکیبی از بازدیدکنندگان دفتری و VPN را شریک هستند. تیم‌های شبکه معمولاً دو ورودی را جداگانه پیکربندی می‌کنند، و این اشکالی ندارد، تا زمانی که برنامه این کار را نکند. بررسی‌های زیر باید در برنامه باشند و صرف‌نظر از اینکه درخواست از کدام در آمده، یکسان رفتار کنند.

نخست: نام میزبان فقط یک مستأجر را نام می‌برد

نام میزبان درخواستی را با نگاشتی که مدیر نگه می‌دارد تطبیق دهید و هر چیز ناشناخته را رد کنید. به‌جای سرآیند خام از مقدار میزبان اعتبارسنجی‌شدهٔ چارچوب استفاده کنید تا یک Host ساختگی نتواند کلید جستجو را تزریق کند. تطبیق موفق به کد می‌گوید کدام پیکربندی مستأجر و کدام برندینگ بارگذاری شود. اما هیچ نمی‌گوید که آیا فراخوان می‌تواند داده‌های آن مستأجر را ببیند. این پرسش دوم را در تابعی جدا با ورودی جدا نگه دارید.

تابع کمکی مشترکی که هم بافت و هم مجوز را از یک جستجوی نام میزبان برمی‌گرداند، آغاز باگ است.

دوم: عضویت از نشست می‌آید

عضویت‌های فعال کاربر احراز هویت‌شده را جستجو کنید و آن‌ها را با مستأجر حاصل از بررسی اول مقایسه کنید. کاربری که به هر دو کلینیک تعلق دارد می‌تواند جابه‌جا شود، اما جابه‌جایی باید کنشی صریح و ثبت‌شده در بافت درخواست باشد، نه استنتاجی از URL. کاربری که به یک کلینیک تعلق دارد و کلینیک دیگر را درخواست می‌کند رد می‌شود، از جمله برای دانلودها و فراخوانی‌های API.

حالت منفی را با ویرایش یک شناسهٔ سابقه و یک پارامتر مستأجر آزمایش کنید. اگر هر یک از این دو تغییر داده برگرداند، دامنه از درخواست خوانده می‌شود نه از عضویت تأییدشده.

دامنهٔ کوکی و ورود یکپارچه تعیین می‌کنند حساب کجا می‌تواند ارائه شود. تعیین نمی‌کنند که آن حساب چه چیزی می‌تواند بخواند.

سوم: شبکه هیچ چیزی دربارهٔ شخص اثبات نمی‌کند

دروازهٔ VPN یک تونل را احراز هویت می‌کند و فهرست مجاز عمومی یک محدودهٔ نشانی را. هیچ‌کدام شخص را شناسایی نمی‌کند. NAT بسیاری از کاربران را در یک نشانی مبدأ جمع می‌کند و محدودهٔ دفتر همین کار را برای همهٔ افراد ساختمان می‌کند. هر دو را واقعیت انتقال بدانید و مجوزدهی را در برنامه نگه دارید، یا در یکپارچه‌سازی‌ای که هویت را صریحاً تصریح می‌کند و همان‌گونه بازبینی می‌شود.

DNS سومین واقعیت انتقال است. پاسخ خصوصی به مسیر خصوصی نیاز دارد و پیشانهٔ عمومی به مسیر مبدأ پشتیبانی‌شده. هیچ‌کدام از آن‌ها مجوزی حمل نمی‌کند.

یک جمله برای دیوار: شبکه تعیین می‌کند درخواست چگونه می‌رسد و برنامه تعیین می‌کند چه چیزی می‌تواند بخواند.

چهارم: ماتریس را روی هر دو ورودی اجرا کنید

با حساب‌های کنترل‌شده A را در A، B را در B، A را در B، یک نام میزبان ناشناخته و یک حساب احراز هویت‌شدهٔ بدون عضویت را بیازمایید. چهارم و پنجم باید بسته شکست بخورند و هرگز به مستأجر پیش‌فرض برنگردند. همان ماتریس را از ورودی VPN هم اجرا کنید، با یک شیشهٔ نشست برای هر حساب:

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

سپس یک ورودی از فهرست مجاز را تغییر دهید و دوباره اجرا کنید. نتیجه‌ای که جابه‌جا می‌شود یعنی یک کنترل شبکه دارد تصمیم مجوز می‌گیرد.

ماتریس را پس از هر تغییر در پیشانه تکرار کنید، چون دومین مسیر کد که بررسی را دور می‌زند رایج‌ترین راه فرسایش این مرز است. نتیجهٔ مورد انتظار خسته‌کننده است: هر ورودی همان پاسخ‌ها را می‌دهد.