مشکل بمب دیکد — چرا کدگشایی نامحدود URL میتواند خودش یک آسیبپذیری باشد
یکی از توسعهدهندهها پیشنهاد کرده بود برای مقابله با حملات کدگذاری دوگانه، decoding رو آنقدر تکرار کنیم تا خروجی تغییری نکنه. ولی این راهحل خودش یه مشکل امنیتی تازه به اسم «بمب Decode» ایجاد میکنه: اگه مهاجم یه payload با لایههای زیاد کدگذاری بفرسته، حلقه تکرار decoding میتونه حافظه و پردازنده سرور رو به شکل خطرناکی مصرف کنه.
چرا مهمه؟
آسیبپذیری اولیه یعنی نادیدهگرفتن URL encoding در چکهای امنیتی PHP، خیلی شناختهشدهست. ولی وقتی یه توسعهدهنده میخواد این مشکل رو با روش «decode تکراری» حل کنه، خودش دروازه یه حمله DoS رو باز میکنه. مهاجم کافیه یه رشته چندلایه کدگذاریشده بفرسته تا سرور وسط decode کردن، منابعش تموم بشه. این خبر به توسعهدهندههای وب هشدار میده که هر راهحلی رو بدون بررسی عوارض جانبی پیاده نکنن.
به درد کی میخوره؟
توسعهدهندههای PHP و وب متخصصان امنیت وب (AppSec) تیمهای DevOps و مدیران زیرساخت 審کدهای کد و معماران نرمافزار
تو عمل چی کار کنیم؟
اگه تو کدت از حلقه decode تکراری استفاده میکنی (مثلاً `while` با `urldecode`)، الان وقتشه که برگردی و یه مکانیزم محافظتی اضافه کنی. حداقل تعداد تکرار رو محدود کن، حداکثر اندازه ورودی رو چک کن، و اگه decoding بیش از حد مشخصی ادامه پیدا کرد، ارور برگردون. نکته مهمتر: چکهای امنیتی رو روی خروجی نهایی اعمال کن، نه فقط روی ورودی خام.
نظر Blue IT News
این دقیقاً همون الگوییست که توی امنیت وب همهجا میبینیم: یه مشکل واقعی، یه راهحل سرسری، و یه آسیبپذیری جدید بدتر. قبل از اضافه کردن هر مکانیزم دفاعی، عوارض اون رو هم تست کن.