چطور امنیت وب سایت خود را بالا ببریم؟

امنیت وبسایت

قراردادن وب‌سایت روی اینترنت، به این معنی است که وبسایت در معرض حملات هکرها، اسکن پورت‌ها، شنود ترافیک و داده‌کاوی (Data mining) قرار خواهد گرفت. اگر شانس با ما یار باشد، ممکن است سایت گاهی ترافیک واقعی و معتبر نیز داشته باشد، به شرط آن که وبسایت به خاطر حمله از کار نیفتاده یا «دیفیس» (Deface) نشود.

اکثر کاربران می‌دانند که در هنگام ورود به وب‌سایتی، باید دنبال نشان «قفل»کنار نوار آدرس باشند تا از امنیت آن اطمینان حاصل کنند. اما این یکی از ابتدایی‌ترین مراحل محافظت از یک وب سرور است. حتی اس اس ال (SSL) نیز می‌تواند به صورت‌های مختلف بکار گرفته شود، و البته برخی از انواع آن برتری نسبی به برخی دیگر دارند. همچنین، کوکی‌ها اطلاعات حساس وب‌سایت را ذخیره می‌کنند و ایمن‌سازی آن‌ها می‌تواند از جعل هویت جلوگیری کند. به علاوه، ایجاد چندین سد امنیتی و پیکربندی مختلف می‌تواند از وب‌سایت شما در مقابل حملات سایبری دستی و خودکار محافظت نماید؛ داده‌های کاربران و مشتری‌های شما نیز بدین طریق از سواستفاده مصون می‌ماند.

در ادامه، 13 راهکار برای افزایش امنیت وب‌سایت شما و همچنین افزایش مقاومت سرور وب ارائه شده است.

اقداممزیت
1. استفاده از SSL در سراسر وب‌سایترمزگذاری ترافیک وب‌سایت
2. اعتبار‌سنجی گواهینامه SSLاطلاع از وضعیت و تاریخ انقضای گواهینامه
3. استفاده از رمزگذاری SHA256استفاده از بهترین رمزگذاری موجود
4. غیرفعال کردن مجموعه‌های رمزنگاری ناامنکاهش آسیب‌پذیری‌ها در اس اس ال
5. مخفی کردن اطلاعات headerعدم شناسایی پیکربندی
6. استفاده‌ از کوکی‌های HttpOnlyعدم اجازه به ترافیک رمز‌گذاری نشده
7.  فعال سازی امنیت انتقال HTTP (یا HSTS)جلوگیری از خوانده شدن داده‌های کوکی توسط اسکریپتها
8. استفاده از کوکی‌های امنجلوگیری از انتقال داده‌های کوکی به صورت رمزگذاری‌نشده
9. ایمن سازی فرآیند‌های وب سروراستفاده از پیکربندی‌های بهینه
10. اطمینان از معتبربودن ورودی فرم‌هاجلوگیری از سواستفاده از فرم
11. محافظت در برابر SQL injectionجلوگیری از اکسپلویت
12. محافظت در برابر حمله‌ی DoSامکان ادامه‌ی ارائه‌ی خدمات در زمان حمله DoS
13. تست مستمر پیکربندی‌هاکسب اطمینان از تمامی موارد قبلی

1. استفاده از SSL در سراسر وب‌سایت

قفلی که در محل آدرس مروگر نشان داده می‌شود، قطعاً به معنی امن بودن وب‌سایت است، مگر نه؟ در واقع، این بدین معنی است که در آن لحظه، شما از یک درگاه SSL استفاده می‌کنید. اما به منظور بهره‌مند شدن از تمامی امکانات امنیتی اس اس ال، و ارتباطات رمزگذاری شده‌ی معتبر، این دسترسی باید در تمامی صفحات وب‌سایت –و نه در برخی از صفحات آن- برقرار باشد، در غیر این صورت، کلاینت تنها بین صفحات رمزگذاری شده و صفحات غیررمزگذاری شده جابه‌جا می‌شود. دسترسی به هر صفحه باید تنها از طریق اس اس ال ممکن باشد. اطلاعاتی که خارج از پروتکل SSL ارسال شود، به صورت متن ساده بوده و هر کسی که وقت و حوصله‌اش را داشته باشد، می‌تواند به آن نفوذ کند. حتی یک فرم ساده با اطلاعات حساس یا درگاه رمز که بیرون از محیط رمزگذاری‌شده باشد، می‌تواند امنیت کل وب‌سایت را به خطر اندازد.

درباره SSL بیشتر بخوانید:

2. اعتبار‌سنجی گواهینامه SSL

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

اغلب ارائه‌دهندگان اس اس ال، به صورت خودکار توسط همه‌ی مرورگرهای مرسوم معتبر شناخته می‌شوند؛ با این حال، بهتر است ریسک نکنید و مطمئن شوید که شرکتی که اس اس ال را از آن خریده‌اید، با تغییرات مرورگرها آشنا بوده و به روز است. عدم توجه به این نکته ممکن است عواقب نامطلوبی به دنبال داشته باشد، مثل زمانی که سایت‌هایی را که از یک پروتکل تبادل کلید دیفی-هلمن نسبتاً ضعیف استفاده می‌کردند، توسط فایرفاکس و کروم بلاک شدند. تغییرات اساسی و بزرگ این‌چنینی، مسئولان وب‌سایت را مجبور به صدور دوباره گواهینامه و یا به‌روز‌رسانی پیکربندی سرورهایشان می‌سازد.

3. استفاده از رمزگذاری SHA256

در بالا اشاره‌ای به تغییرات گسترده‌ی مرورگر‌ها کردیم. یکی از بهترین نمونه‌ها از این موضوع، رمزگذاری استاندارد SHA1 است که دیگر امن تلقی نمی‌شود، و جای آن را استانداردهای SHA256 گرفته‌اند که سیستم رمزگذاری قوی‌تری است. اگر در گواهینامه وب‌سایت شما SHA256 درج شده باشد، شما در حال استفاده از سیستم رمزگذاری مدرن هستید. اما اگر تنها SHA1 درج شده باشد، مجبور به صدور دوباره یا جایگزینی آن با گواهی 2048 بیت SHA256 هستید زیرا از سال 2017، مرورگرها دیگر از SHA1 پشتیبانی نمی‌کنند. لازم به ذکر است که استانداردهای رمزگذاری، با یافتن نقاط ضعف استانداردهای کنونی و ابداع روش‌های امن‌تر، در آینده نیز به تغییر و تحولات خود ادامه خواهند داد.

4. غیرفعال سازی مجموعه‌های رمزنگاری بدون امنیت

حتی اگر بهترین گزینه‌های رمزگذاری نیز در اختیار شما باشد، بدان معنا نیست که گزینه‌های بدتر دیگر در کنار آن‌ها وجود ندارند. پیکربندی‌های اولیه‌ی بیشتر وب سرورها هنوز هم به مجموعه‌های رمزنگاری اس اس ال ناامنی مانند RC4، اجازه فعالیت می‌دهند. این مجموعه‌ها باید حتما بر روی وب سرور (Apache و IIS) غیرفعال شوند تا هکرها نتوانند به آن نفوذ کرده و آن‌ها را اکسپلویت کنند. ذکر این نکته ضروری است که این اقدام، نه تنها برای امنیت، که برای قابل استفاده بودن و در دسترس بودن وب‌سایت نیز بسیار حائز اهمیت است؛ برخی مروگرها به طور خودکار وب‌سایت‌هایی را که از مجموعه‌های رمزنگاری بی‌امنیت استفاده می‌کنند بلاک و مسدود می‌کنند.

5. پنهان‌کردن اطلاعات هدر (Header)

افشا کردن نوع و نسخه‌ی وب‌سرور، تنها به افراد سودجو در نفوذ به وب‌سایت شما کمک خواهد کرد. با شناسایی پلتفرم یا نسخه‌ای خاص، مهاجمان به آسانی می‌توانند حملات خود را روی نقاط آسیب‌پذیر وب سرور مورد استفاده شما متمرکز کنند. هدرهای X-Powered-By، اطلاعات سرور و.NET ASP (در مواردی که قابل دسترسی باشند) از جمله این اطلاعات هستند. بهترین توصیه این است که هدرها را مخفی کرده و از افشای اطلاعات برای بازدیدکنندگان خودداری کنید. در پیکربندی پیش‌فرض این اطلاعات پنهان نشده‌اند، به همین خاطر احتمالا بسیاری از سرورهای سازمانی بدون اطلاع شما این اطلاعات را از طریق هدر در اختیار بازدیدکنندگان قرار می‌دهند.

6. فعال سازی امنیت انتقال HTTP (یا HSTS)

HSTS یا همان امنیت انتقال HTTP (در سیستم عامل‌های ویندوز و لینوکس) ، مرورگرها را ملزم به برقراری ارتباط تنها از طریق SSL می‌کند. با این کار، درخواست‌های غیر اس اس ال (http://) به طور خودکار به اس اس ال (https://) تبدیل می‌شوند. عدم استفاده از این قابلیت می‌تواند منجر به حملات مرد میانی یا (man in the middle (MITM بشود که در آن عامل خرابکار می‌تواند یک کاربر وب را حین جابه‌جایی بین صفحات غیر SSL و صفحات SSL، به یک سایت جعلی منتقل کند.

7. استفاده‌ از کوکی‌های HttpOnly

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

8. استفاده از کوکی‌های امن

کوکی‌های امن تنها در بستر SSL قابلیت انتقال دارند. از این رو، از ردیابی اطلاعات بالقوه حساس در مسیر انتقال بین سرور و کلاینت جلوگیری می‌شود. عدم استفاده از کوکی‌های امن اشخاص ثالث را قادر به دسترسی به کوکی ارسال شده به کلاینت خواهد کرد و شخص می‌تواند با جعل هویت، خود را به عنوان کلاینت به وب سرور معرفی کند. البته واضح است که برای استفاده از کوکی‌های امن، ابتدا باید SSL سراسری را برای سایت فعال کرده باشید تا کوکی‌ها دیگر در بسترهای رمزگذاری‌نشده ارسال نشوند.

9. ایمن سازی فرآیند‌های وب سرور

پروسس‌ها یا سرویس‌های خود وب‌سرور هم نباید به عنوان root یا Local System اجرا شوند. در سیستم‌های لینوکس، بسیاری از سرورهای وب به عنوان یک کاربر اختصاصی جداگانه با اختیارات محدود اجرا می‌شوند، ولی می‌توانید برای اطمینان، نوع کاربر و اختیارات آن را دوباره بررسی کنید. در سیستم‌های مایکروسافت، احتمال بالایی وجود دارد که پیکربندی اصلی Local System باشد؛ و از همین رو، باید قبل از اجرا، آن را به یک کاربر اختصاصی و جداگانه تغییر دهید، به‌جز در مواردی که وب سرور نیاز به دسترسی منابع دامنه داشته باشد. کاربر مورد اشاره نباید یک کاربر ادمین –یا از آن بدتر ادمین دامنه– باشد، و دسترسی به فایل باید تا حد ممکن، محدود شود. با انجام چنین کاری، در صورتی که یک سرور وب آلوده شد، می‌توانید با ایزوله‌کردن و محدودکردن حساب مورد استفاده‌ی آن وب سرور، از آلوده‌شدن منابع بیشتر جلوگیری کنید.

10. اطمینان از معتبربودن ورودی فرم‌ها

اگر فرم‌هایی دارید که از کاربر ورودی می‌گیرند، باید تمام روش‌ها و مکانیزم‌های ورود داده را اعتبارسنجی کنید تا مطمئن شوید تنها داده‌های مناسب وارد پایگاه‌داده شده و ذخیره‌سازی شود؛ این اولین قدم در محافظت در برابر SQL injection (یا همان تزریق SQL) و دیگر اکسپلویت‌هایی است که داده‌های مخرب را وارد فرم می‌کنند و از این طریق از آن سواستفاده می‌کنند. این کار باید از سمت برنامه‌نویسان انجام بگیرد؛ پس اگر در رویه‌های استاندارد فعلی وجود ندارد، باید به آن‌ها اضافه شود.

11. محافظت در برابر SQL Injection (تزریق SQL)

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

درباره SQL بیشتر بخوانید:

12. محافظت در برابر حملات DoS

حملات منع سرویس یا DoS، حجم عظیمی از اتصال‌ها و/یا پکت‌ها را روانه‌ی سرورها می‌کنند؛ این روند تا اضافه‌بار شدن سرور و عدم توان پاسخ‌دهی به درخواست‌های واقعی ادامه خواهد یافت. هیچ راه‌حل قطعی برای جلوگیری از وقوع چنین حملاتی وجود ندارد، چرا که از مسیرهای ارتباطی معتبر و واقعی استقاده می‌کنند. اما اقداماتی وجود دارد که در صورت وقوع چنین حمله‌ای، با آن مقابله کند. استفاده از شرکت‌های ارائه‌دهنده خدمات ابری مانند Akamai یا CloudFlare می‌تواند تقریبا به طور کامل خطر حملات DoS به وب‌سایت شما را از بین ببرد؛ این راه‌حل‌ از منابع عظیم ساختار ابری برای کاهش بار حمله‌ی DoS استفاده می‌کند، و همچنین مکانیزم و الگوی ترافیک مخرب را شناسایی کرده و آن را بلاک می‌کند. البته راه‌حل جایگزینی نیز وجود دارد؛ استفاده از سیستم کاهش بار روی سرورهای خودتان که بر روی قوائد و اصول مشابهی بنا شده است ولی این روش به منابع سخت‌افزاری اجرایی شما محدود می‌شود.

بیشتر بخوانید:

13. تست مستمر پیکربندی‌ها

مهم‌ترین عامل در تامین امنیت یک سرور، شفافیت آن است. بدون دانستن این که چه اتفاقی در حال وقوع است، چه چیزی تغییر کرده است و چه چیزی باید تغییر کند، امید کمی برای داشتن سروری امن در طولانی مدت خواهید داشت. تست مستمر پیکربندی‌ها و سنجیدن آن‌ها با سیاست‌های شرکت، به تیم‌های IT شانس این را می‌دهد که خلاهای امنیتی را، قبل از آنکه مورد سواستفاده قرار بگیرند، پر کنند. هم‌چنین، تست مستمر پیکربندی‌ها، مراکز داده را مجبور می‌کند فرایندهای خود را استاندارد کرده و مسیر بارهای کاری را هموارتر کنند؛ ایجاد تصویری دقیق از سیستم و در دست داشتن تاریخچه‌ای از الگوهای داده‌ها، امکان تصمیم‌گیری بهتر و سریع‌تر را در زمان ایجاد تغییرات فراهم می‌کند. حتی تطبیق‌پذیری استانداردی مثل PCI یا HIPAA نیز می‌تواند با آزمایش پیکربندی خودکار، ساده‌تر شود. هیچکدام از 12 مورد قبلی، بدون آزمایش مستمر، توانایی تقویت امنیت را نخواهند داشت.

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

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *