6 نکته امنیتی مهم در برنامه نویسی بک اند Back-End

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

سمت سرور (Server-Side)، جایی که دیتا در آنجا ذخیره و تحلیل می شود در معرض خطرناکترین حملات وب قرار دارد. در ادامه با بررسی مفهوم بک اند (Back-End) برخی از نکات امنیتی مهم در این حوزه را مرور خواهیم کرد.

بک اند (Back-End) چیست؟

به طور کلی هر وب اپلیکیشن به دو بخش فرانت اند (Front-End) و بک اند (Back-End) تقسیم می شود :

• فرانت اند در حقیقت سمت کاربر (Client-Side) است. به عبارت دیگر بخشی است که عمدتاً با کاربر در تعامل است و توسط زبان های HTML ،CSS و جاوا اسکریپت ساخته می شود و به طور خلاصه هرآنچه که کاربر آن را می بیند در بخش فرانت اند قرار دارد.

• بک اند یا همان توسعه سمت سرور (Server side)، در حقیقت کدهایی هستند که به منظور کنترل منطق و مغز متفکر سایت، توسط برنامه نویسان بک اند در هسته آن نوشته می شود و کاربر هیچ دسترسی به آنها ندارد. در حقیقت بخش back end نیمه پنهان یک وبسایت است که با کمک برقراری ارتباط میان سرور و سمت کاربر یا همان فرانت اند به تمامی المان های رابط کاربری یک سایت جان می بخشد.

نکاتی درباره تفاوت احراز هویت، کنترل دسترسی و مدریت Session

برنامه نویسان معمولاً این 3 واژه را با یکدیگر اشتباه می گیرند بنابراین در ادامه هر یک را به صورت واضح توضیح خواهیم داد:

• احراز هویت (Authentication) مربوط به اثبات هویت کاربر است؛ برای مثال گذرواژه، نام کاربری، سوالات امنیتی و اثر انگشت جزء این بخش هستند.
• کنترل دسترسی (Access Control) مربوط به دسترسی کاربر به اپلیکیشن است؛ به عبارت دیگر سیاست هایی را تعیین می کند که کاربران نمی توانند فراتر از مجوزهای مربوطه عمل کنند.
• مدیریت Session نیز مربوط به درخواست ها و ریکوئست های مرتبط به یک کاربر است؛ به عبارت دیگر یک مکانیزم توافقی است که پس از احراز هویت موفقیت آمیز کاربر بین او و اپلیکیشن مورد استفاده قرار می گیرد.

در ادامه نکاتی را برای تقویت امنیت بک اند (Back-End) معرفی خواهیم کرد:

1- تزریق نقص های برنامه نویسی

انجمن آنلاین OSWAP از سال 2010 به بعد حملات تزریق کد را به عنوان خطرناکترین تهدید برای وب اپلیکیشن ها معرفی کرد. تزریق نقص های برنامه نویسی (Injection Flaws) دیتای حاوی کلیدواژه را در اختیار کاربر قرار می دهد تا از طریق آن رفتار کوئری های ساخته شده در دیتابیس را تغییر دهند. برای مثال فرض کنید ما یک SQL اسکریپت داریم که تطبیق های موجود در دیتابیس را بررسی می کند :

در این صورت یک هکر می تواند با انجام تزریق SQL قسمت password را دستکاری کند، برای مثال با وارد کردن گذرواژه ‘OR 1 =’ 1 باعث بوجود آمدن کوئری SQL زیر می شود :

هکرها با انجام این کار می توانند به تمامی جدول های  کاربران دسترسی پیدا کنند که در این صورت رمز عبور (1 = ‘1’) برای همیشه معتبر خواهد ماند به گونه ای که اگر به عنوان ادمین وارد سیستم شوند می توانند هر تغییری که می خواهند را بر روی آن اعمال کنند!

پیشگیری

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

• از ابزارهای ORM استفاده کنید.
• تمام ورودی های دیگر را حذف کنید، نباید چیزی به جز date را در قسمت تاریخ ذخیره کنید.
• دیتا را جداسازی کنید تا فقط مواردی که دسترسی به آنها در یک مکان الزامی است در آنجا نگهداری شوند.
• کدهایی را بنویسید که رسیدگی به ارورهای آن ساده باشد. در حقیقت دیتابیس یا بک اند نباید خیلی طولانی باشد.

2- شکست مکانیزم احراز هویت (Broken Authentication)

همانطور که پیش تر به آن اشاره کردیم مکانیزم احراز هویت با ارائه مدارک معتبر از طرف کاربر سر و کار دارد که به عنوان اولین مانع در برابر دسترسی نامحدود ایستاده است. به هر حال اجرای ضعیف یا عدم رعایت سیاست های امنیتی منجر به شکست مکانیزم احراز هویت خواهد شد. حملات شکست احراز هویت معمولاً به سه صورت رخ می دهد :

• دزدیدن اطلاعات کاربری که در آن هکر فهرستی معتبر از نام کاربری و گذرواژه های کاربران را در اختیار دارد و می تواند برای تایید اعتبار این مدارک به صورت اتوماتیک حملات را انجام دهد.
• حملات بروت فورس (Bruteforce) در مواقعی که اپلیکیشن اجازه استفاده از رمز عبور ضعیف را به کاربران یا ادمین می دهد اتفاق خواهد افتاد.
• حمله نشست ربایی (Session Hijacking) زمانی اتفاق می افتد که اپلیکیشن شناسه نشست (Session ID) یا URL را در معرض نمایش عمومی قرار داده یا پس از هر بار لاگین آنها را تغییر نمی دهد.

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

پیشگیری

قبل از اجرای مکانیزم احراز هویت از خود بپرسید که در صورت به خطر افتادن این سیستم هکرها چه غنایمی بدست خواهند آورد سپس با توجه به جواب این سوال اقدامات زیر را انجام دهید :

• پیاده سازی مکانیزم احراز هویت چند مرحله ای (multi-factor authentication) برای مقاومت در برابر حملات خودکار
• تشویق یا اجبار کاربران برای انتخاب یک رمز عبور قدرتمند
• محدود کردن تعداد لاگین ناموفق
• استفاده از یک هش الگوریتم کارآمد؛ هنگام انتخاب الگوریتم حداکثر اندازه طولی را برای رمز عبور در نظر بگیرید.
• تست کردن سیستم زمان بندی Session و اطمینان از منقضی شدن توکن Session پس از خروج از حساب کاربری

3- شکست کنترل دسترسی (Broken Access Control)

مکانیزم کنترل دسترسی در واقع از آنچه کاربر تایید شده مجاز به انجام آن است اطمینان حاصل می کند. احراز هویت و مدیریت Session قوانین بنیادی کنترل دسترسی هستند اما وقتی این قواعد به درستی اعمال نشده باشند منجر به بروز مشکلات جدی خواهند شد. به طور کلی وجود نقص در مکانیزم کنترل دسترسی شامل موارد زیر است :

• پیکربندی غلط مکانیزم CORS که منجر به دسترسی غیر مجاز به API می شود.
• دستکاری متادیتا که منجر به دسترسی مستقیم به متدها (Methods) می گردد.
• حملات Forced browsing که در آن هکر مسیر یک URL را تغییر می دهد و از طریق آن به اطلاعات مهمی دسترسی پیدا می کند. برای مثال آدرس http://website.domain/user/ را به http://website.domain/admin تغییر می دهد.

پیشگیری

شکست دسترسی کنترل معمولاً در اثر عدم توجه به الزامات اساسی مدیریت دسترسی موثر (Effective Access Management) اتفاق می افتاد.

• به جز منابع عمومی از پذیرفتن مابقی منابع صرف نظر کنید.
• دایرکتوری لیستینگ (Directory Listing) سرور را غیرفعال کرده و از عدم وجود فایل های بک آپ نیز اطمینان حاصل کنید.
• دسترسی محدود به API را برای کاهش تاثیر حملات خودکار مورد ارزیابی قرار دهید.
• پس از خروج از بک اند، توکن های JWT را فسخ کنید.

4- افشای دیتا

افشای دیتا که به نقض داده (Data Breaches) نیز معروف است در واقع یک تهدید سایبری محسوب می شود که کسب و کارها و مشتریان آنها را در معرض خطر قرار می دهد. این موضوع زمانی رخ می دهد که اپلیکیشن از اطلاعاتی نظیر مدارک کاربران یا داده های حساس مانند کارت های اعتباری یا سوابق بهداشتی به خوبی محافظت نکرده باشد. در هر دقیقه 4000 هزار حمله افشای دیتا اتفاق می افتد و کمپانی IBM اذعان کرده است که هر بار حمله افشای دیتا حدود 3.9 میلیون دلار خرج روی دست کمپانی های بزرگ می گذارد.

پیشگیری

شما به عنوان یک توسعه دهنده بک اند باید اطلاعاتی که نیاز به محافظت دارند را مشخص کنید و از بروز موارد زیر جلوگیری بعمل آورید :

• رمزگذاری داده های حساس : تمام دیتای موجود در REST را رمزگذاری کنید و برای داده های در حال انتقال نیز از دروازه های ایمن SSL استفاده کنید.
• داده هایی که نیاز به حفاظت بیشتری دارند را شناسایی کرده و با استفاده از رمزگذاری کلید محور (Key-Based) فقط به کاربران مشروع اجازه دسترسی به آنها را بدهید.
• از به کارگیری الگوریتم های ضعیف خودداری کنید و همیشه الگوریتم های به روز و قدرتمند را مورد استفاده قرار دهید.
• یک برنامه بک آپ با امنیت بالا داشته باشید.

5- نا امنی Deserialization

مفاهیم deserialization و serialization زمانی به کار می روند که دیتا برای انتقال یا ذخیره در یک اپلیکیشن دیگر به object تبدیل می شود. مکانیزم serialization برای اینکه دیتا قابل استفاده شود آن را به قالب شی (Object Format) نظیر JSON یا XML تبدیل می کند و deserialization نیز فرآیند معکوس آن را انجام می دهد.

حمله به deserialization در واقع منجر به محروم سازی از سرویس (denial-of-service) و دسترسی کنترل می شود و اگر کلاس های اصلاح شده در اپلیکیشن وجود داشته باشند منجر به باگ RCE (اجرای کدها از راه دور) نیز می گردد.

مثال زیر به بهترین نحو serialization در زبان PHP را نشان می دهد :

این supercookie حاوی اطلاعاتی مانند شناسه کاربری، سطح کاربر و رمز عبور hash شده است. یک هکر می تواند با تغییر شی serialized شده به پنل ادمین دسترسی پیدا کند :

پیشگیری

شما باید شی serialized را فقط از منابع مورد اطمینان دریافت کنید، علاوه بر این باید اقدامات زیر را نیز انجام دهید :

• هرگز به ورودی های کاربر اعتماد نکنید.
• اعتبارسنجی دیتا: اگر اپلیکیشن شما جدا از یک رشته (String) است حتماً قبل از استفاده از ماهیت رشته اطمینان حاصل کنید.
• برای اینکه مطمئن شوید دیتا تغییر نکرده باشد از یک check استفاده کنید؛ این موضوع زمانی که در حال ارسال دیتا بین دو منبع مورد اعتماد هستید بسیار مفید خواهد بود (برای مثال ذخیره دیتا در سمت کاربر).

6- سرور XSS

حملات XSS یا Cross-Site Scripting نوعی تزریق محسوب می شود که در آن یک هکر از یک اپلیکیشن وب برای ارسال کدهای مخرب به کاربران مختلف استفاده می کند. این حملات زمانی اتفاق می افتد که هکر دیتای حاوی کدهای مخربی که در اپلیکیشن ذخیره شده اند را ارسال کند. این آسیب پذیری به صورت سمت سرور است و مرورگر به سادگی پاسخ را رندر می کند.

برای مثال پست های کاربران انجمن های اینترنتی معمولاً بدون تاییدیه در یک دیتابیس ذخیره می شوند، هکرها نیز از این فرصت استفاده کرده و پست هایی حاوی کدهای مخرب در آنجا منتشر می کنند. در نتیجه سایر کاربران لینک آن را از طریق ایمیل دریافت کرده یا در وبسایت بر روی آن کلیک می کنند!

پیشگیری

پس از شناسایی اولیه عملیاتی که به طور بالقوه در معرض خطر حملات XSS هستند باید دستورالعمل های زیر را انجام دهید :

• اعتبار سنجی ورودی : طول ورودی (Input) را مورد بررسی قرار دهید و از روش تطابق رشته در متن regex نیز استفاده کنید، همچنین فقط برای مجموعه ای از کاراکترهای خاص مجوز صادر کنید.
• اعتبار سنجی خروجی : در برخی از مواقع اپلیکیشن پاسخ خود را در دیتای نشات گرفته از کاربران یا اشخاص ثالث کپی می کند، در این حالت دیتا باید به صورت HTML کدگذاری شود تا از کاراکترهای مخرب و آلوده در امان بماند.
• محدود کردن HTML : اگر سیستم ثبت نظر و دیدگاه در وبسایت خود دارید، کاربران را به استفاده از تگ های بخصوصی محدود کنید. اگر می توانید از یک فریم ورک مناسب برای نشانه گذاری HTML تولید شده توسط کاربران استفاده کنید تا از عدم وجود ابزارهای اجرای جاوا اسکریپت در آن اطمینان حاصل کنید.