امنیت یک محصول نیست، اما یک فرآیند است

---

متاسفانه به دلیل پیچیدگی برخی از این فن‌آوری‌های امنیتی و از طرفی به خاطر نبود دانش کافی در اجرا و عدم آگاهی و توجه از سوی صاحبان وب‌سایت‌ها، بسیاری از این فن‌آوری‌ها بدون استفاده رها شده‌اند. برای مثال بیش از دو دهه از پیدایش و معرفی پروتکل انتقال ابرمتن امن (Secure HTTP – HTTPS) می‌گذرد و امروز تنها ۴۰٪ از وب‌سایت‌ها در سراسر جهان، با این فن‌آوری تطبیق داده شده و با این پروتکل به صورت سازگار فعال است.

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

در ادامه‌ی این مطلب به بررسی عمومی امنیت ۲۰۰ وب‌سایت پر بازدید و برتر جهان (براساس آمار الکسا) خواهیم پرداخت و همچنین به برخی از فناوری‌های مهم در راستای ارتقاء امنیت وب‌سایت‌ها اشاره خواهیم کرد و در انتها چند خطی درباره‌ای اینکه «امنیت یک محصول نیست، اما یک فرآیند است».

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

---

بررسی ۲۰۰ وب‌سایت پر بازدید

همانطور که در ابتدا گفته شد، برای آشنایی با وضعیت حاکم بر امنیت وب‌سایت‌ها، یک بررسی عمومی روی ۲۰۰ وب‌سایت پر بازدید جهان انجام شده است که در آن ۱۰ فاکتور امنیتی متفاوت، در شرایطی یکسان، طی یک آزمون کلی بررسی و نتایج گردآوری شده است. نمودار کلی نتایج مربوط به این بررسی را در این صفحه می‌توانید مشاهده کنید.

متاسفانه از مجموع ۲۰۰ وب‌سایت برتر دنیا در این بررسی، تنها ۱۵ مورد از آن‌ها در حالت خوب و ایده‌آل قرار داشه و ۱۰ وب‌سایت دیگر در وضعیت عادی یا همان متوسط و الباقی یعنی ۱۷۵ وب‌سایت در شرایط نامساعد و ریسک‌پذیر قرار دارند. شاید برای شما نیز سوال باشد که تست‌های این بررسی چه مواردی بوده‌ و چه فاکتورهایی برای این بررسی و امتیازدهی لحاظ شده است!

---

بررسی Cookies و Session‌s :

مسلما شرح کامل «کوکی چیست و چه کارهایی انجام می‌هد یا چه اهمیتی دارد» در حوصله‌ی این مطلب نیست. اما برای آن دسته از عزیزان که با تعریف و کارکرد cookie و session آشنا هستند، در این آزمایش دو فاکتور تاثیرگذار زیر در امنیت کوکی‌ها و نشست‌ها مورد بررسی قرار گرفته است.

Secure attribute: در سال ۱۹۹۷ برای اولین بار موضوع Secure Cookies مطرح شد و از آن به بعد برای جلوگیری از شنود کوکی‌ها و انتقال امن آن، پرچم (flag) ایمن‌سازی کوکی secure معرفی شد. فاکتوری که در امنیت cookie‌ها و sessionها تاثیر بسزایی ایفا می‌کند.

HttpOnly attribute: در بین سال‌های ۲۰۰۹ تا ۲۰۱۱ نیز برای پیشگیری از حملات تزریق کد و سرقت session‌ها یا همان Session-hijacking Attack راه‌حل دیگری در قالب یک پرچم جدید با نام HttpOnly جهت حفاظت از sessionها معرفی شد. این پرچم را می‌توان لایه‌ای دیگر در راستای ایمن‌سازی cookieها و sessionها دانست.

تست‌ها:

• Cookies-A: در این حالت کوکی‌ها با پرچم secure ایمن‌سازی و نشست‌ها با پرچم HttpOnly محافظت می‌شوند.

• Cookies-B: در این حالت کوکی‌ها فاقد پرچم secure بوده، اما به واسطه‌ی پروتکل HSTS به صورت ایمن منتقل می‌‌شوند.

• Cookies-C: در این حالت نشست‌ها فاقد پرچم secure بوده، اما به واسطه‌ی پروتکل HSTS به صورت ایمن منتقل می‌‌شوند.

• Cookies-D: در این حالت کوکی‌ها فاقد پرچم secure بوده و یا در حالت ناامن با پروتکل http منتقل می‌شوند.

• Cookies-E: در این حالت نشست‌ها فاقد پرچم HttpOnly منتقل می‌شوند.

• Cookies-F: در این حالت نشست‌ها فاقد پرچم secure بوده و در حالت ناامن با پروتکل http منتقل می‌شوند.

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

نتایج:

---

بررسی CORS:

کنترل دسترسی به منابع مختلف یک سایت یا سرور و همچنین تنظیمات اشتراک گذاری منابع بین منشاءهای مختلف، و بسیاری دیگر از تنظیمات پیش نیاز کارکرد سرویس‌ها، موضوعی است که CORS یا همان Cross-origin resource sharing بر آن نظارت داشته و به آن می‌پردازد. به صورت کلی وب‌سایت‌ها نیازی به اشتراک گذاشتن منابع به صورت عمومی نداشته و در صورت توجه نکردن به این موضوع ممکن است تبعات سنگینی مال و حتی امنیتی به بار آید.

تست‌ها:

• CORS-A: کنترل دسترسی به منابع و تنظیمات اشتراک‌گذاری منابع، به درستی انجام شده است.

• CORS-B: منابع تعریف شده در فایل‌ crossdomain.xml یا clientaccesspolicy.xml در تخصیص و کنترل دسترسی‌ها صحیح نبوده و سرور در تخصیص و کنترل با مشکل مواجه است.

• CORS-C: منابع و محتوای سایت و همچنین سرور بدون کنترل، با دسترسی کامل در اختیار عموم قرار دارد.

نکته: خوشبختانه در اغلب وب‌سایت‌های بررسی شده در این مرحله، نتایج تست‌ رضایت بخش بوده که دلیل عمده‌ی آن (نظر شخصی من) تنظیمات پیش فرض و استاندارد تعریف شده‌ی سرورهاست که کنترل منابع و اشتراک گذاری‌ منابع بین منشاءهای مختلف، به‌صورت نظارت شده است. به همین دلیل در نتایج کلی خبری از حالت CORS-C نیست!

نتایج:

---

بررسی Content Security Policy:

در حال حاضر به جرائت می‌توان گفت Content Security Policy (من بهش سیاست امنیتی محتوا می‌گم) یکی از مهم‌ترین شاخصه‌های امنیتی وب‌سایت‌ها به شمار می‌رود. CSP یا همان خط مشی امنیتی، روشی برای ایمن‌سازی وب‌سایت‌ها و محافظت از محتوا در برابر تهدیدات و آسیب‌پذیری‌های امنیتی است که تعریف و تشریح همه‌ی اجزاء در آن به دقت با جزئیات کامل، پیاده سازی می‌شود.

عموما وب‌سایت‌ها برای اجرای صحیح و دقیق CSP، می‌بایست به‌صورت کامل سیاست خودشان را در ابتدای راه‌اندازی وب‌سایت تهیه و تدوین کنند و به مرور زمان به‌صورت مستمر این خط مشی امنیتی را مورد ارزیابی و مرور قرار دهند. ضمنا اگر با Content-Security-Policy آشنایی داشته باشید، حتما می‌دانید که از سال ۲۰۱۵ جایگزین دو شیوه‌ی منسوخ پیش از خود یعنی X-Webkit-CSP و X-Content-Security-Policy شده است.

تست‌ها:

• CSP-A: در این حالت CSP دسترسی پیش‌فرض را برای تمام منابع منع و به صورت مستقل محتوا را بدون دستورات unsafe-inline و unsafe-eval تعریف و پیاده‌سازی کرده است.

• CSP-B: در این حالت CSP دسترسی منابع را به صورت مستقل بدون دستورارت unsafe-inline و unsafe-eval تعریف و پیاده‌سازی کرده است.

• CSP-C: در این حالت CSP ضمن قبول اجرای دستورات خطی ناامن unsafe-inline در بخش منابع مرتبط با پوسته‌ی محتوا، تعریف و پیاده سازی شده است.

• CSP-D: در این حالت CSP ضمن تعریف سیاست کلی سایت، با قبول اجرای دستورات توابع ناامن unsafe-eval، تعریف و پیاده سازی شده است.

• CSP-E: در این حالت CSP موافق اجرای دستورات خطی ناامن unsafe-inline و دستورات توابع ناامن unsafe-eval بوده و یا اجازه‌ی بارگیری منابع از طریق ارتباط ناامن http تعریف و پیاده‌سازی کرده است.

• CSP-F: در این حالت CSP تعریف و پیاده‌سازی به پیاده سازی نشده است.

نکته: عمدتا به دلیل استفاده از دستورات unsafe-inline برای ویژگی style، هیچ وب‌سایتی در آزمایش CSP-A و CSP-B موفق به کسب نتیجه‌ی مثبت نشده است.

نتایج:

---

بررسی HPKP Policy یا به زبان عامیانه همان دیوار مرگ:

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

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

حال تعریف و کاربرد HPKP) HTTP Public Key Pinning) یا همان پین کردن کلید عمومی چیست؟ HPKP‌ یک سازوکار امنیتی است که به وب‌سایت‌هایی که از پروتکل HTTPS استفاده می‌کنند، این امکان را می‌دهد که لیست کلید‌های عمومی گواهی‌نامه‌های امنیتی مورد استفاده را برای یک بازه‌ی زمانی از پیش تعیین شده، به صورت مطمئن به اطلاع بازدیدکنندگان یا همان کاربران برسانند. طی این فرآیند امکان دور زدن و جعل اطلاعات گواهی‌نامه‌‌ها و مراجع صدور گواهی‌نامه‌ها (مانند حملات فرد میانی یا همان MitM attacks) به شدت کاهش می‌یابد.

تست‌ها:

• HPKP-A: در این حالت کلید عمومی به‌صورت کاملا صحیح پین شده است.

• HPKP-B: در این حالت کلید عمومی پین شده برای مدت کمتر از ۱۵ روز نزد کاربرها از زمان آخرین بازدید معتبر خواهی بود.

• HPKP-C: در این حالت کلید عمومی مورد استفاده قرار نگرفته است.

• HPKP-D: در این حالت کلید عمومی به اشتباه پین شده است.

نکته: علت بالا بودن درصد سایت‌های فعال با HPKP ، صرفا وجود بیش از ۳۰ دامنه‌ی محلی مربوط به شرکت Google در لیست سایت‌های پربازدید دنیا با کلید عمومی پین شده است.

نتایج:

---

بررسی پروتکل HSTS:

HSTS یک پروتکل جدید بوده که در سال ۲۰۱۲ توسط IETF معرفی و پس از آن به عنوان یک استاندارد رسمی برای جلوگیری از سرقت کوکی‌ها Sessions Hijacking و پیشگیری از بارگیری محتوای صفحات بر مبنای پروتکل http معرفی شد. در توضیحی ساده‌تر HTTP Strict Transport Security یک پروتکل سخت‌گیر ( جدی و مصمم 😏 ) برای انتقال امن اطلاعات بین سرور و کلاینت‌ برپایه پروتکل https بوده و اجازه‌ی استفاده از ارتباط ناامن http را به کاربر نداده و این مسئله از بروز خطرات احتمالی، جلوگیری می‌کند.

تست‌ها:

• HSTS-A: در این حالت تنظیمات HSTS فعال بوده و اسم وب‌سایت به لیست از پیش بارگیری HSTS مرورگرها اضافه شده است.

• HSTS-B: در این حالت تنظیمات HSTS به درستی فعال شده است.

• HSTS-C: در این حالت تنظیمات HSTS برای مدت زمان کمتر از ۶ ماه تعریف شده‌ است.

• HSTS-D: در این حالت تنظیمات HSTS فعال نبوده یا برای وب‌سایتی که از پروتکل https پشتیبانی نمی‌کند، فعال شده است.

نکته: فعال کردن و ثبت HSTS در لیست از پیش بارگذاری شده‌ی مرورگرها، جزء مواردی است که مسئولان وبسایت باید از پیچیدگی فرآیند غیرفعال سازی آن آگاهی داشته باشند.

نتایج:

---

بررسی Redirection:

شاید بتوان گفت ساده‌ترین آزمایش انجام شده در این بررسی‌ها، تنظیمات مربوط به Redirection است. Redirection عمل انتقال و هدایت مجدد درخواست‌‌ها از پروتکل http به https را انجام می‌دهد که این عمل سبب برقراری ارتباط امن بین سرویس گیرنده و سرویس دهنده می‌شود.

تست‌ها:

• Redirection-A: نتایج این تست به سه حالت زیر تقسیم شده است.

• تمام redirect‌ها طبق لیست از پیش بارگیری شده‌ی پروتکل HSTS انجام می‌شود.

• تمام درخواست‌ها به صورت کامل از پروتکل http به https منتقل می‌شود.

• دسترسی به پروتکل http غیرفعال بوده و تمام درخواست طبق بستر https امکان پذیر است.

• Redirection-B: عمل انتقال و هدایت مجدد، موجب انتقال به یک میزبان دیگر شده و این مسئله سبب از کار افتادن پروتکل HSTS‌ می‌شود.

• Redirection-C: تنظیمات به درستی انجام نشده است، اما درخواست‌های ارسالی در نهایت منتقل و هدایت می‌شوند.

• Redirection-D: هیچ‌گونه انتقال و هدایتی برای ایجاد بستر امن ارتباطی صورت نمی‌گیرد.

نکته: سایت‌های فاقد پروتکل امن https به همراه سایت‌های دارای این پروتکل و فاقد تنظیمات redirection در نتایج آزمایش Redirection-D نمایش داده شده‌اند.

نتایج:

---

بررسی SRI:

مبحث کنترل منابع زیر مجموعه و اطمینان از صحت و عدم تغییر داده‌ها، موضوعی بود که برای اولین بار در سال ۲۰۱۴ مطرح شد. Subresource Integrity شیوه‌‌ای است که با آن غالبا در جهت اطمینان از تمامیت و صحت فایل‌های بازخوانی شده و تامین امنیت در بارگیری از منابع عمومی، مانند CDNها مورد استفاده قرار می‌گیرد.

در صورت استفاده از SRI می‌توان مطمئن بود که فایل‌های بازخوانی شده از سایر منابع، بدون تغییر در ساختار و داده‌ها، بارگیری می‌شوند. SRI با تطبیق و مقایسه‌ی Hash فایل‌ها، از بارگیری فایل‌های آلوده یا دستکاری شده و تغییر یافته، ممانعت کرده و از به خطر افتادن وب‌سایت‌ها و بازدیدکنندگان جلوگیری می‌کند.

تست‌ها:

• SRI-A: منابع استفاده شده به صورت مطمئن با SRI در بستر امن پروتکل https بارگیری می‌شوند.

• SRI-B: تمامی فایل‌های بدون SRI از منبع داخلی بارگیری می‌شوند.

• SRI-C: فایل‌های اسکریپت بدون SRI در بستر امن پروتکل https بارگیری می‌شوند.

• SRI-D: منابع استفاده شده به صورت مطمئن با SRI در بستر ناامن پروتکل http بارگیری می‌شوند.

• SRI-E: متابع استفاده شده بدون SRI در بستر ناامن پروتکل http بارگیری می‌شوند.

نکته: SRI از الگوریتم SHA-2 جهت رمزنگاری و ایجاد هش فایل‌ها استفاده می‌کند و می‌توان از sha256, sha384 و sha512 در کنار هم استفاده کرد.

نتایج:

---

بررسی XCTO:

مراقبت از فرمت فایل‌های استفاده شده در صفحات وب و حفاظت از آن‌ها در مقابل MIME Sniffing (من بهش حملات مبتنی بر فرمت فایل‌ها میگم) مبحثی بود که برای اولین بار در سال ۲۰۰۸ (اگه اشتباه نکنم) توسط شرکت مایکروسافت طی فرآیند تولید مرورگر IE8 به آن پرداخته شد. بعد از آن، استفاده از XCTO یا همان X-Content-Type-Options برای پیشگیری از MIME Sniffing و سایر حملات مرتبط در برخی از نسخه‌های اینترنت‌اکسپلورر و همچنین گوگل‌کروم، به عنوان یک استاندارد معرفی شد.

تست‌ها:

• XCTO-A: تنظیمات XCTO با دستور nosniff به درستی تنظیم شده است.

• XCTO-B: تنظیمات XCTO مورد استفاده قرار نگرفته است.

نتایج:

---

بررسی XFO:

شاید تا به حال کلمه‌ی «کلیک دزدی» را شنیده باشید و احتمالا با مفهوم iframe آشنا هستید و شاید هم نه! 😏 اما مطمئنا تجربه‌ی مشاهده‌ی وب‌سایت‌هایی را در نتایج جستجوی موضوعات مختلف داشته‌اید که مطالب و محتویات وب‌سایت‌های دیگر را نمایش می‌دهند.

XFO یا همان X-Frame-Options یکی از تنظیمات بسیار موثر برای مقابله با Clickjacking بوده و در عین حال با ایجاد یک بستر مطمئن این امکان را به شما می‌دهد که نظارت دقیق‌تری در استفاده و خواندن شدن مطالب و محتوای وب‌سایت شما در سایر صفحات وب داشته باشید. ضمن اینکه بحث فریب و آلوده ساختن دستگاه‌های بازدیدکنندگان برخی مطالب و موضوعات، به واسطه‌ی سوءاستفاده از iframe امکان‌پذیر بوده و آمار آن، این روزها رو به افزایش است.

تست‌ها:

• XFO-A: در این حالت XFO توسط CSP در بهترین حالت، تنظیم شده و نحوه‌ی بارگیری مطالب و محتوا در سایر وب‌سایت‌ها را کنترل می‌کند.

• XFO-B: در این حالت XFO با دستورات SAMEORIGIN و DENY تنظیم شده است.

• XFO-C: در این حالت هیچ‌گونه تنظیمی برای XFO انجام نشده است.

نتایج:

---

بررسی XSSP:

تاریخچه‌ی حملات مبتنی بر تزریق کد یا همان Cross Site Scripting به سال ۱۹۹۶ باز می‌گردد. از همان زمان آسیب پذیری XSS یکی از تهدیدات شناخته شده‌ و حساس بسیاری از وب‌سایت‌ها بوده و سال‌هاست برای پیشگیری از آن، راهکارهای مختلفی معرفی شده است. X-XSS-Protection یا همان XSSP نیز یکی از این موارد بوده که از سال ۲۰۱۰ برای محافظت کلی از صفحات وب، در وب‌سایت‌ها به عنوان یک استاندارد رسمی معرفی شده است.

تست‌ها:

• XSSP-A: تنظیمات XSSP با مسدود سازی و یا محدود سازی، جلوی حملات تزریق کد را می‌گیرد.

• XSSP-B: در این حالت از XSSP استفاده نشده است و احتمال آسیب‌پذیری وب‌سایت در مقابل حملات تزریق کد وجود دارد.

نتایج:

---

جمع‌بندی

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

از نظر من، پاسخ این سوال‌ها به سه علت احتمالی زیر مربوط می‌شود:

• نگرانی بابت از دست دادن تعدادی از کاربران، به سبب پشتیبانی نشدن برخی از این فناوری‌ها توسط مرورگرهای قدیمی

• عدم دانش کافی و آگاهی از مزایای داشتن امنیت بالا و همان جمله‌ی معروف «چه کاریه حالا، فعلا که اتفاقی نیافتاده!»

• هزینه‌های نسبتا بالای پشتیبانی امنیتی از وب‌سایت‌ها و سرویس‌ها و همچنین هزینه‌های تالیف و تبیین سیاست‌های امنیتی

همان‌طور که می‌دانید، اغلب این وب‌سایت‌ها جز معروف‌ترین و حتی بزرگترین‌ مجموعه‌های دنیای اینترنت و تجارت محسوب می‌شوند. مسلما هرکدام از این سایت‌ها، به لحاظ نوآوری در فعالیت و نوع کارکرد، یک محصول یا خدمات ویژه به کاربران اینترنت ارائه می‌دهند که حتی می‌توان آن محصولات را جزء برترین‌های دنیا نامید. اما این مسئله دلیل بر مستحکم و مقاوم بودن امنیت وب‌سایت‌های آن‌ها در برابر حملات سایبری و تهدیدات متداول نبوده و مسلما در آینده نیز نخواهد بود. بطبع برای داشتن امنیت کافی در هر سرویس یا وب‌سایتی، می‌بایست فرآیندهای متعدد امنیتی طی گردد. پس به خاطر داشته باشید «امنیت یک محصول نیست، اما یک فرآیند است». شما نیز اگر آگاهی و دانش فنی کافی دارید، یا علاقمند هستید که از بزرگترین و پربازدیدترین وب‌سایت‌های جهان، به لحاظ امنیتی پیشه بگیرید، از همین امروز اقدام کنید.

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