پیوندهای موقت فهرست مجاز IP: آنچه این اجازه واقعاً می‌پذیرد
پیوندی که یک درگاه دیوار آتش را باز می‌کند، یک نشانی را می‌پذیرد، نه یک شخص را. دامنه را مشخص کنید، تأیید آگاهانه بخواهید و تکرار، انقضا و IPv6 را بیازمایید.
تبدیل یک کلیک به یک قاعدهٔ موقت دیوار آتش راحت است و در همان حال سامانه‌ای برای مجوزدهی می‌سازد که تعیین می‌کند چه کسی می‌تواند به یک سرویس برسد. آنچه صادر می‌کند یک نشانی است نه یک شخص، و این تفاوت همان لحظه‌ای اهمیت پیدا می‌کند که دو نفر یک NAT را شریک می‌شوند. دامنهٔ اجازه را محدود کنید، آن را آگاهانه تأیید کنید و پیش از ساخته‌شدن پیوند، به انقضا معنایی بدهید. تصمیمی که پیش روی شماست این است که مرز کجا باشد، نه اینکه آیا مرزی باید وجود داشته باشد.
تصمیم بگیرید این اجازه به کدام پرسش پاسخ می‌دهد
از نیاز شروع کنید. اگر شخص مشخصی باید به سرویس برسد و برنامه از پیش همان شخص را احراز هویت می‌کند، دروازهٔ احراز هویت‌شده هویت را در نقطهٔ اجرا نگه می‌دارد و به هیچ پذیرش نشانی‌ای نیاز ندارد. اگر هدف یک عامل ساخت، یک درگاه پرش مدیریتی یا دستگاهی باشد که نمی‌تواند در ورود کاربر شرکت کند، اجازهٔ نشانی با دامنهٔ محدود ممکن است تنها کنترل عملی موجود باشد.
انتخاب پذیرش نشانی برای برنامه‌ای که رو به کاربر است، مشکل واقعی مجوزدهی را جای دیگری می‌برد و آنگاه دروازه میراث‌دار تقصیر شکافی می‌شود که هرگز آن را نبست.
درخواست را روی سرور محدود کنید
مرورگر نباید مقصد، درگاه یا پیشوند را انتخاب کند. دروازه سرویس را از سوابق خودش استخراج می‌کند و صلاحیت را با آزمونی در سمت سرور بررسی می‌کند، که همان اصلی است که راهنمای مجوزدهی OWASP آن را بر هر درخواست اعمال می‌کند. استخراج نشانی هم به مرز محافظت‌شده تعلق دارد: وقتی یک پراکسی معکوس نشانی مشتری را گزارش می‌کند، تنها زنجیرهٔ پراکسی پیکربندی‌شده و رفتار مستندشده‌اش با سرآیندها را بپذیرید. سرآیند ارجاعی که بازدیدکننده ارائه می‌کند ادعایی دربارهٔ منشأ است، نه شاهدی بر آن.
سپس بررسی کنید که دروازه و سرویس همان منبع را می‌بینند. تونل تفکیک‌شده، یک پرش پراکسی و IPv4 در برابر IPv6 می‌توانند به دو مقصد دو نشانی متفاوت بدهند، پس اجازه‌ای که از یک مسیر فعال شده ممکن است درخواست بعدی را پوشش ندهد.
اجازه را پیش از نصب نشان دهید
بازکردن یک پیوند باید سرویس پیشنهادی، منبع مشاهده‌شده و مدت را نشان دهد و هنوز چیزی را تغییر ندهد. همین یک گام پیوند ایمیل‌شده را از یک کنش به یک پیشنهاد تبدیل می‌کند و مانع می‌شود ربات پیش‌نمایش یا پویشگر ایمیل تنها با واکشی آن دسترسی بدهد.
تأیید باید درخواستی تغییردهندهٔ وضعیت با دفاع‌های معمول میان‌وبگاهی و مبدأ باشد. توکن باید یکبارمصرف باشد و در همان لحظه‌ای که قاعده نصب می‌شود به‌صورت اتمی مصرف شود، و رکورد باید مالک، سرویس، نشانی، شناسهٔ اجازه و انقضا را ثبت کند بی‌آنکه هرگز توکن خام را در گزارش بنویسد.
تحویل توکن همان اندازهٔ خود قاعده اهمیت دارد. پیوند منقضی یا از پیش مصرف‌شده‌ای که هنوز قاعده‌ای تولید می‌کند، درِ دومی است که با همان کلید نصب شده.
نشانی حتی وقتی اجازه زنده است مشترک است
NAT اداری، NAT اپراتور و خروجی مشترک VPN هر یک چند نفر را پشت یک نشانی قرار می‌دهند. پذیرفتن آن نشانی یعنی پذیرفتن همهٔ کسانی که پشت آن هستند — تا آنجا که به مرز بعدی سرویس مربوط می‌شود —، بی‌آنکه چیزی دربارهٔ اینکه حساب مورد انتظار سرویس دست کیست اثبات کند.
حذف قاعده هم یک قطع ارتباط همگانی نیست. اتصال‌های برقرارشده، توکن‌های نهانگاه برنامه و نشست‌های دیرپا می‌توانند دقیقه‌ها یا بسیار بیشتر از قاعده زنده‌تر بمانند، پس عمری که انتخاب می‌کنید باید بازتاب دهد سرویس پس از پذیرش چه می‌کند، نه فقط اینکه قاعده چه مدت وجود دارد.
چهار حالت و هر دو خانوادهٔ نشانی را بیازمایید
یک اجازه تنها به‌اندازهٔ چهار حالتی ارزش دارد که از سر می‌گذراند: درخواست تازهٔ مجاز، درخواست‌کنندهٔ تأییدنشده، تکرار همان پیوند، و همان درخواست پس از انقضا.
سپس هر خانواده را جداگانه بیازمایید، زیرا نشانی مبدأیی که سرویس می‌بیند می‌تواند میان آنها متفاوت باشد.
dig +short A service.example.com
dig +short AAAA service.example.com
curl -4 -sS -o /dev/null -w "%{http_code}\n" https://service.example.com
curl -6 -sS -o /dev/null -w "%{http_code}\n" https://service.example.comنتیجهٔ سودمند یک تصمیم پذیرش موقت و قابل حسابرسی در زیر مجوزدهی عادی کاربر است، نه گشودگی دائمی که نام کسی را داشته باشد که نخست کلیک کرد.