چگونه از آسیب پذیری های آپلود فایل جلوگیری کنیم

ماژول های آپلود فایل یکی از ضعیف ترین لینک ها در برنامه های تحت وب هستند. هر گونه اشتباهی، حتی اشتباهاتی که شما آنها را کوچک می دانید، می تواند منجر به افتادن مستقیم کنترل سرور به دست مهاجمان سایبری شود. به همین دلیل، توسعه دهندگان نرم افزار باید رایج ترین اشتباهات و برخی روش های حمله ای را که ممکن است رخ دهد، بدانند. بنابراین دستکاری سمت کلاینت چیست؟ چگونه می توانید با این امر مبارزه کنید تا سایت های خود و کاربران خود را ایمن نگه دارید؟

دستکاری سمت کلاینت چیست؟

دستکاری سمت کلاینت مفهوم اصلی حملات برنامه های وب به عنوان یک کل است. به عبارت ساده، به این معنی است که دیگر نمی توانید به هیچ یک از داده هایی که برای کاربر ارسال می کنید، اعتماد کنید. علاوه بر این، دستکاری سمت کلاینت یکی از پایه های توسعه برنامه های کاربردی امن است. اگر ماژول آپلود فایلی که با آن سروکار دارید را بررسی کنید و دستکاری سمت کلاینت را در نظر بگیرید، داده هایی که نمی توانید به آنها اعتماد کنید شامل موارد زیر است:

• نام فایل آپلود شده
• نوع محتوا فایل آپلود شده

این دو مورد جایی است که شما این فرصت را دارید که به عنوان یک توسعه دهنده نرم افزار در لیست سفید قرار بگیرید. داده های نام فایل آپلود شده می تواند حاوی هر چیزی با دستکاری سمت کلاینت باشد. با داده‌های Content-Type فایل آپلود شده، حتی اگر مهاجم در حال آپلود یک فایل exe. باشد، این فایل ممکن است به صورت تصویر/jpeg در سیستم ظاهر شود.

پسوند فایل و لیست سفید

در حین توسعه ماژول های آپلود فایل، اولین کاری که باید انجام دهید فرآیند لیست سفید برای پسوند فایل است. به عنوان مثال، کاربر می خواهد فایلی به نام “muo.jpeg” را آپلود کند. باید مطمئن شوید که پسوند فایلی که کاربر می خواهد آپلود کند .jpeg باشد. برای این کار، سیستم باید فایل آپلود شده را بررسی کند و ببیند آیا یکی از پسوندهای مجاز فایل است یا خیر. برای درک اینکه چگونه می توانید این کار را انجام دهید، کد PHP ساده زیر را بررسی کنید:

$file_parts = pathinfo($filename);
switch($file_parts['extension'])
{
case "jpg":
break;

case "bat": // Or exe, dll, so, etc.
break;

case "":
case NULL: // No file extension
break;
}

شما می توانید این کار را با یک بلوک کد مشابه با بلوک بالا انجام دهید، یا می توانید از کلاس ها و توابع ارائه شده توسط فریمورک مورد استفاده خود استفاده کنید.

اطلاعات نوع محتوا چیست؟

اطلاعات نوع محتوا (Content-Type) بخشی از اطلاعات است که در درخواست HTTP برای هر بارگذاری فایل ارسال می شود. مرورگر اینترنت این اطلاعات را شناسایی کرده و به درخواست ارسال شده اضافه می کند. مهاجم می تواند سعی کند اطلاعات را با دستکاری سمت کلاینت تغییر دهد و اعتبارسنجی سمت سرور را دور بزند. در این مرحله، توسعه‌دهندگان به یک مکانیسم کنترلی برای اعتبارسنجی اطلاعات Content-Type نیاز دارند. این به تنهایی کافی نخواهد بود. هنوز، این یک موضوع مهم برای توسعه دهندگان است که باید به آن توجه کنند.

فرض کنید مکانیزمی را برای بررسی صحیح پسوند فایل کدگذاری می کنید و فقط فایل هایی با پسوند jpeg. می پذیرید. علاوه بر این مکانیسم احتیاطی، می‌توانید اطلاعات نوع محتوا را در هر صورت بررسی کنید و فقط فایل‌هایی را با اطلاعات تصویر/jpeg بپذیرید، که یک سطح حفاظتی اضافی در برابر حملات سایبری می شود.

فایل های فلش SWF و گام های حمله

پسوند فایل و داده‌های Content-Type برای مرورگرهای اینترنتی که از افزونه‌هایی مانند Adobe Flash Player پشتیبانی می‌کنند، معنی ندارد. اگرچه پشتیبانی از آن پخش‌کننده دیگر در دسترس نیست، ولی هنوز هم می‌توان آن فایل‌های مرتبط را روی بسیاری از سیستم‌ها نصب کرد، حتی اگر Flash همچنان یک خطر امنیتی است. در سیستمی که اقدامات احتیاطی مربوطه را انجام نداده، می توان یک فایل فلش را با تگ <object> بدون توجه به پسوند آن فراخوانی کرد. این یک مشکل امنیتی جدی دیگر ایجاد خواهد کرد.

• به منظور اقدام، توسعه دهندگان باید مسیرهایی را که مجرمان سایبری می توانند طی کنند، بدانند. در اینجا نحوه وقوع آن آمده است: مهاجم مخرب یک SWF (فرمت فایل Adobe Flash) به نام “image.jpeg” را در وب سایت مورد نظر آپلود می کند. در طی فرآیند آپلود، در تأیید لیست سفید تأیید می شود که فایل آپلود شده توسط مهاجم دارای پسوند jpeg. است. تأیید نوع محتوا با دستکاری سمت مشتری دور می‌شود. تصور کنید این فایل که توسط عامل تهدید آپلود شده است به «www(dot)target-site(dot)com/images/images.jpeg» می رود.
• فرض کنید مهاجم یک وب سایت به نام attacker(dot)com دارد. مهاجم با استفاده از تگ <object> با انتساب نوع application/x-shockwave-flash، فایل image.jpeg آپلود شده در سایت هدف را در این وب سایت فراخوانی می کند.
• یک کاربر بی گناه وارد attacker(dot)com می شود. آن سایت فایل SWF را در www(dot)target-site(dot)com/images/image.jpeg فراخوانی می کند و دستورات داده شده به SWF را اجرا می کند.
• از این طریق، مهاجم سایبری می تواند اقدامات درخواست HTTP را برای آدرس site(dot)com هدف بدون توجه کاربران عادی ایجاد کند. با این درخواست‌ها، مهاجم از جلسه کاربر بی‌گناه استفاده می‌کند و چک CSRF را دور می‌زند.

برای درک واضح تر این سناریوی حمله، کد زیر را در محتوای <object> زبان HTML ارسال شده توسط attacker(dot)com به کاربر در نظر بگیرید:

style="height:1px;width:1px;" data="www.target-site.com/images/image.jpeg" type="application/x-shockwave-flash" allowscriptaccess="always" flashvars="c=read&u=somethings"

یکی از بهترین راه حل ها دسترسی به فایل های آپلود شده با آپلود فایل از طریق یک زیر دامنه متفاوت است. در سناریوی فوق، می توانید به فایل های استاتیک نه از یک دامنه، بلکه از یک زیر دامنه متفاوت به صورت زیر دسترسی داشته باشید: “http(colon)//file.target-site(dot)com/images/image.jpeg”.

راه حل دیگر اضافه کردن Content-Disposition: اطلاعات پیوست به پاسخ HTTP زمانی است که درخواست دسترسی به فایل هایی را که می خواهید آپلود کنید دریافت می کنید.

اقدامات احتیاطی را برای آسیب پذیری های آپلود فایل انجام دهید

هر گونه آپلود فایلی که کاربران می توانند در یک وب سایت ایجاد کنند خطرناک است، بنابراین این یکی از مسائلی است که توسعه دهندگان باید بیشترین توجه را به آن داشته باشند. اگر مهاجمان چنین آسیب پذیری را کشف کنند، می توانند پوسته ای را در سایت باز کنند و به راحتی از اطلاعات روی سرور سوء استفاده کنند. کنترل همه فایل‌های آپلود شده توسط کاربران، اعمال روش‌های لیست سفید و پنهان کردن مکان دایرکتوری آپلود شده در صورت امکان بسیار مهم است.

و البته، اقدامات اضافی دیگری نیز وجود دارد که باید برای محافظت از سایت خود انجام دهید، حتی اگر تمام اقدامات احتیاطی توصیه شده را برای آپلود ماژول های فایل انجام دهید. استفاده از هدرهای امنیتی HTTP یکی از این اقدامات است که می توانید بردارید.