مطالعه موردی مهندسی
فایروال فهرست مجاز Searchwiz
شریک جستوجو کاتالوگ را از چند IP مشخص میخزد. خزیدن مشکلی ندارد. مشکل وقتی است که خزنده سر از افزودن به سبد، پرداخت یا پنل کاربری دربیاورد؛ این مسیرها گراناند، وضعیت دارند و اصلاً برای ترافیک خودکار ساخته نشدهاند. این دروازه همان خط را صریح میکشد.
مسئله تجاری
اگر به خزندهی بیرونی دسترسی عادی بدهی، بالاخره مسیرهایی را پیدا میکند که وضعیت را عوض میکنند یا کش را دور میزنند. سبد و پرداخت از کش تمامصفحه سرو نمیشوند؛ پس خزندهای که رویشان بیفتد با هر نرخی که بخواهد کار PHP بدون کش تولید میکند. وقتی درخواستی اصلاً نباید جواب بگیرد، محدودکردن نرخ جواب مسئله نیست.
آنچه تحویل دادم
- a2-searchwiz-cart-block.php، یک افزونهی MU که فقط روی درخواستهای آمده از IPهای شریک عمل میکند و برای بقیه کاملاً بیاثر است.
- یک فهرست رد قاطع که پیش از هر قانون اجازه بررسی میشود و /cart و /checkout و /my-account را با همهی زیرمسیرهایشان میگیرد.
- قوانین رد برای سطوح AJAX معادل؛ چون بستن صرفِ مسیر صفحه، اکشنهای wc-ajax و admin-ajax را باز میگذارد.
- یک اجازهی صریح برای namespace REST خود شریک، که همان مسیری است که یکپارچهسازی قرار بوده از آن استفاده کند.
- بلاک بیقیدوشرط wp-admin و wp-login.php و xmlrpc.php برای این IPها، فارغ از هر قانون دیگر.
- یک دنبالهی رد پیشفرض: GET و HEAD برای خزش عادی مجازند و هر چیزی که به آخر قوانین برسد رد میشود.
- یک کلید خاموشی مستند در فایل فلگهای زمان اجرا، تا موقع بازبینی بشود موقتاً به مهندسان شریک دسترسی کامل داد، بدون دستبردن در فایروال.
رویکرد فنی
- قوانین رد قبل از قوانین اجازه اجرا میشوند. ترتیب برعکس همان چیزی است که در فهرستهای مجاز سوراخ میسازد: یک اجازهی کلی که بعداً نوشته میشود، بیسروصدا مسیری را که قبلاً بسته بودند باز میکند.
- تطبیق مسیر پیشونداگاه و لنگرخورده است. پس /cart با خودش و با /cart/هرچیزی میخورد، ولی با مسیری که فقط این کلمه را جایی در خودش دارد نه.
- فهرست IPهای مجاز یک آپشن است که با آدرسهای مستند خزندهی شریک ادغام میشود؛ یعنی بدون دیپلوی بهروز میشود.
- پاسخ بلاک ۴۰۳ است با هدرهای کش خاموش، تا لایهی کش یک «رد» را ذخیره و بعداً بازپخش نکند.
- کلید خاموشی یک ثابت در فایل فلگهای زمان اجراست، با کامنتی که تأکید میکند باید برگردانده شود؛ چون bypass موقتی که یادداشتی همراهش نباشد، دائمی میشود.
نتیجه و شواهد
شریک کاتالوگ و همان namespace REST مورد نیازش را میخزد، و سبد و پرداخت و حساب کاربری و ادمین از آن آدرسها اصلاً در دسترس نیستند. دامنهی فایروال آنقدر تنگ است که نمیتواند مشتری واقعی را درگیر کند، چون برای هر IP بیرون فهرست همان اول کنار میرود.
اهمیت برای کارفرما
یکپارچهسازیها دقیقاً چون مورد اعتمادند برای یک سایت تجاری ریسک دائمیاند. وقتی مرز را بهشکل کد بنویسی، توافق قابل اجرا میشود و دیگر به خوشرفتاری شریک بند نیست.
خلاصه اجرایی خوانا
خلاصه_اجرایی {
پروژه: "Searchwiz Allowlist Firewall"
فایل: "mu-plugins/a2-searchwiz-cart-block.php (v1.1.0)"
دامنه: "فقط درخواستهای IPهای شریک؛ در غیر این صورت بیاثر"
ترتیب: "رد قاطع ← اجازهی صریح ← رد پیشفرض"
رد_شده: "/cart /checkout /my-account (+زیرمسیرها)،
اکشنهای wc-ajax و admin-ajax متناظر،
/wp-admin /wp-login.php /xmlrpc.php"
مجاز: "namespace REST شریک؛ خزش GET/HEAD"
پاسخ: "۴۰۳ با هدر nocache، هرگز کش نمیشود"
کلید_خاموشی: "فلگ در 000-a2-runtime-flags.php، مستند"
}ارزش حرفهای این پروژه
جان امنیتی این پروژه در ترتیب قوانین است. «رد قبل از اجازه» با یک دنبالهی رد پیشفرض، تنها ساختاری است که وقتی فردا کسی دیگر قانون تازه اضافه میکند، باز هم درست میماند.
کلید خاموشی را گذاشتم چون حالت بدون آن را دیدهام: مهندسی برای یک تست کل لایهی امنیتی را خاموش میکند و همانطور خاموش میماند. یک فلگ نامدار با کامنت، دیرتر از یاد میرود.