بخش های اصلی

آموزش HTTP

HTTP – امنیت

HTTP برای ارتباط از طریق اینترنت به کار میره، بنابراین توسعه دهنده های برنامه ها، ارائه دهنده های اطلاعات و کاربران باید از محدودیت های امنیتی در HTTP/1.1 آگاه باشن. در این آموزش راه حل های قطعی برای مشکلاتی که به آن ها اشاره خواهیم کرد نیامده ولی توصیه هایی برای کاهش ریسک های امنیتی آورده شده.

فاش شدن اطلاعات شخصی

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

  • باید اطلاعات محرمانه به شکل رمزگذاری شده در سرور ذخیره بشن.
  • فاش شدن نسخه ی نرم افزار خاصی از سرور باعث میشه که سرور در برابر حمله های نرم افزاری آسیب پذیرتر بشه، به این حالت حفره های امنیتی میگن.
  • پراکسی ها بعنوان دروازه ای از طریق فایروالِ شبکه خدمت رسانی می کنن، باید در انتقال اطلاعات سرآیندی که هاست را قبل از فایروال شناسایی می کنه، احتیاط بیش تری بشه.
  • ممکنه اطلاعاتی که در فیلدِ ‘Form’ فرستاده شده، با منافع حریم شخصی کاربر یا سیاست امنیتی سایت در تضاد باشه از این رو نباید این فیلد بدون داشتن این قابلیت که کاربر بتواند محتوا را غیرفعال یا فعال کنه یا تغییرش بده، منتقل بشه.
  • کلاینت ها نباید در یک درخواستِ (نا امن) HTTP، فیلد سرآیندِ Referer (ارجاع دهنده) داشته باشن (درصوتیکه صفحه ی مورد ارجاع از طریق یک پروتکل امن انتقال یافته باشه).
  • نویسنده های سرویس هایی که از پروتکلِ HTTP استفاده می کنن، نباید از فرم های مبتنی بر GET برای ارسال داده های حساس استفاده کنن، چون این کار باعث رمزگذاری داده در Request-URI میشه.

نامِ مسیرها و فایل های مبتنی بر حمله

سند باید محدود به سندهای بازگردانده شده با درخواستِ HTTP بشه تا فقط آن هایی در محدوده باشن که مورد نظر مدیران سرورها هستن.

برای مثال، UNIX، Microsoft Windows و بقیه سیستم عامل ها از ‘..’ بعنوان مسیر استفاده می کنن تا سطح دایرکتوریِ بالای سطح فعلی را نشان بدن. در چنین سیستم هایی، در صورتی که به منبعی خارج از منابعی که در محدوده ی دسترس پذیرِ سرورِ HTTP در نظر گرفته شده، اجازه دسترسی داده شده باشه، سرورِ HTTP  باید چنین ساختارهایی را در Request-URI ممنوع کنه.

DNS Spoofing (حقه زدنِ DNS)

کلاینت هایی که از HTTP استفاده می کنن، تأکید زیادی بر سرویس نام دامنه دارن و به این دلیل معمولاً در معرض حملات امنیتی مبتنی بر mis-association عمدیِ مبتنی بر آدرسِ IP و نام های دامنه هستن. بنابراین کلاینت ها باید با در نظر گرفتن ادامه ی اعتبارِ IP number/تخصیص نامِ DNS محتاط باشن.

اگه کلاینت های HTTP نتایج مربوط به جستجوی نام هاست را به منظور بهبود کارایی در حافظه ی نهان ذخیره کنن، باید اطلاعاتِ TTL گزارش شده توسط DNS را هم در نظر بگیرن. اگه کلاینت های HTTP این قانون را در نظر نگیرن، زمانی که آدرسِ IPیِ قبلی سرور که قبلاً دسترس پذیر بود، تغییر کنه، به آن ها حقه زده میشه.

سرآیندهایِ Location و Spoofing (حقه زدن)

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

اعتبارنامه ی اهراز هویت

معمولاً کلاینت های HTTPیِ موجود و عامل های کاربران، اطلاعات شناسایی اهراز هویت را نگه میدارن. HTTP/1.1 متدی برای سرور نداره تا کلاینت ها را به سوی بی اعتنایی به این اعتبارنامه ها هدایت کنه که این خودش ریسک امنیتیِ بزرگیِه.

کارهایی در مورد این مسئله هست که میتوان انجام داد، و توصیه میشه در محافظ های صفحه نمایش، idle time-outها و متدهای دیگه ای که مشکلات امنیتی مربوط به این مسئله را کاهش میدن، از پسورد حفاظتی استفاده بشه.

پراکسی ها و ذخیره کردن در حافظه ی نهان (caching)

پراکسی هایِ HTTP،  men-in-the-middle هستن و فرصتی برای حمله ی men-in-the-middle فراهم میکنن. پراکسی ها به اطلاعات وابسته به امنیت، اطلاعات شخصیِ اشخاصِ کاربران و سازمان ها، و اطلاعات مختصِ کاربران و محتوای ارائه دهنده ها دسترسی دارن.

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

پراکسی هایِ caching (ذخیره سازی در حافظه ی نهان) از زمانی که محتوای حافظه ی نهان، هدفی جذاب برای اعمال تخریب گر شده، بیش تر مستعد آسیب شدن. بنابراین، محتوای حافظه ی نهان باید بعنوان اطلاعاتی حساس محافظت بشه.

در صورتی که سوال و یا نظری دارید، از بخش نظرات با ما در میان بگذارید.

خبـرنــامه

Newsletters

در خبــرنـامه سافت اسکیل عضو شویــد تا جدیدترین هـای سایت را بلافاصله در ایمیل خـود دریافت کنیـد

شما چه نظر و یا سوالی درباره این نوشته دارید؟

مبحث آموزشی

آموزش HTTP

HTTP

پرســیدن سؤال جدید

سؤال های تخصصی خود را از ما بپرسید

تبلیغات

دنبال کردن تلگرام کانال سافت اسکیل

https://telegram.me/softskill_ir

عملیات کاربران

خبـرنــامه

Newsletters

در خبــرنـامه سافت اسکیل عضو شویــد تا جدیدترین هـای سایت را بلافاصله در ایمیل خـود دریافت کنیـد