Transport Layer Protection

 با سلام خدمت دوستان گرامی.

یک نوع از تهدیدات برنامه های وب در زمان انتقال اطلاعات بین کلاینت و سرور میباشد. امروز میخوام مطلبی در مورد چگونگی انتقال اطلاعات بین کلاینت و سرور بصورت امن بنویسم. ابتدا یکی از تهدیدات مهم در این زمینه که MITM میباشد را بررسی میکنیم و سپس به رهکارهای مقابله با آن می پردازم.

یکی از مهم ترین تهدیدات در ارتباطات بین دو سیستم Man in the Middle یا به اختصار MITM میباشد که یکی از تهدیدات خطرناک بوده و توسط آن هکرها قادر به  دستیابی به اطلاعات مهم و محرمانه تبادلی خواهند بود. حملات Man in the Middle Attack

در Man in the Middle Attack  هکر مابین ارتباط بین دو سیستم قرار میگیرد و قادر به مشاهده و حتی ایجاد یا تغییر اطلاعات رد و بدل شده بین دو سیستم میباشد. مطابق شکل زیر:

 MITM

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

 درشکل زیر Peter به عنوان مهاجم در مابین ارتباط بین jack , jill قرار گرفته و از یکطرف به Jack خودش را Jill معرفی میکند و از طرف دیگر  به Jill خودش را Jack معرفی میکند تا در نهایت انتقال پول از طرف Jill برای Jack به حساب  Peter منتقل میشود.

 MITM2

راههای مختلفی برای انجام  Man in the Middle Attack(MITM)وجود دارند از جمله :

  1. استفاده از دستگاههای گوش کردن شبکه(Wire Tap Devices)  که بصورت فیزیکی به کابل شبکه متصل میشوند و  ترافیکی که از طریق کابل رد وبدل میشوند را شنود میکنند.

  2. در سطح ISP ترافیک ارسالی از طریق ISP که کلاینت به سرور متصل میشود قابل مونیتور کردن و تغییر میباشد.

  3. از طریق WiFi Hotspot که معمولا بصورت مجانی در بعضی مکانها مانند مترو و کافی شاپ و... ارائه میشوند ترافیک قابل مونیتور کردن و تغییر میباشد.

  4.  از طریقWireless Access Point    هایی که هکر بصورت مجانی ایجاد کرده و کامپیوتر خودش نیز به این شبکه بیسیم متصل است، کامپیوتر هکر در نقش واسط قرار میگیرد و کلاینت بمحض اتصال به این شبکه ، ترافیک ارسالی آن به سرور قابل مونیتور کردن و تغییر میباشد.

  5. در سطح Provider های میزبان برنامه وب.

      

در حملات MITM یکی از موارد مورد علاقه هکرها کوکیهای Session و Authentication میباشند:

  • اگر فرم Login بصورت HTTPS نباشد (در سالهای نه چندان دور در Gmail و Yahoo صفحه Login بصورت HTTP بود اما با کلیک کردن دکمه Submit، اطلاعات بصورت رمز شده در کانال HTTPS فرستاده میشد.) این پروسه دارای ضعف امنیتی میباشد که در شکل زیر آمده است: در شکل فوق بدلیل اینکه صفحه Login بصورت HTTP درخواست میشود فرصت تغییر اطلاعات را برای مهاجمین فراهم می آورد و هکر میتواند هنگامیکه سرور، پاسخ درخواست صفحه لاگین را میفرستد در بین راه با تزریق کد جاوا اسکریپت،KeyLogger  را به پاسخ سرور اضافه کرده و برای کلاینت ارسال کند تا در زمانیکه کاربر نام و پسورد خود را وارد میکند اطلاعات کاربر در پشت صحنه توسط اسکریپت تزریق شده برای کامپیوتری که تحت کنترل هکر است ارسال شود. (برای نمونه عینی این تکنیک، هک کردن رمز کاربران Gmail, Yahoo توسط ISP دولتی تونس در سال 2011 را میتوان مثال زد) .

  • حتی اگر فرم Login بصورت HTTPSباشد اما داخل صفحه Mixed Contentداشته باشیم (یعنی بعضی از المانهای صفحه Login مانند کدهای جاوا اسکریپت یا Image و CSS و ... از منابع خارج از وبسایت و بصورت HTTP در داخل صفحه Login لود شوند مانند CDNهای گوگل و...) باز امکان MITM و تزریق Keylogger یا به سرقت رفتن کوکی ها وجود دارد.

    بنابراین برای جلوگیری از این مطلب در صورتیکه میخواهید به منابع خارج از سایت رفرنس بدهید از Protocol Relative URLدر آدرسها استفاده کنید. برای مثال در شکل زیر برای فایل JS:

     

    همانطوریکه میبینید در آدرس فایل Prototype.js نام پروتکل نیامده است (HTTP یا HTTPS) بنابراین اگر صفحه Login بصورت HTTPS باشد فایل فوق نیز از سایت گوگل در پروتکل HTTPS لود میشود و اگر بصورت HTTP باشد فایل نیز از گوگل بصورت HTTP لود خواهد شد.

  • برای اینکه بعضی صفحات حساس (مانند Login) تحت هیچ شرایطی غیر از SSL قابل لود شدن نباشند:

    •  HTTP Module نوشته شود تا درخواستهای غیر از SSL  به آن صفحات، Redirect شود به آدرس SSL آن صفحه. البته این Redirection میتواند بعضی مشکلات امنیتی را زمینه ساز شود (مانند SSL Striping)که در قسمت بعد توضیح داده خواهد شد.

    • در ASP.NET Web Forms در  مواردی که میخواهید از Request.IsSecure استفاده کنید باید به محدودیتهای آن توجه داشته باشید زیرا در ارتباطاتی که Load Balancer و Device های دیگر مابین سرور و کلاینت میباشند این تکنیک جواب نمیدهد.

    • در MVC فقط کافیست در Controller Action مربوطه یک Attribute بنام RequireHttps قرار بدهیم.

      راهکار دیگر استفاده از HSTS در Response Header میباشد که باعث میشود Browser تا مدت زمان مشخصی تمامی درخواستها را بصورت HTTPS ارسال کند. (HSTS در قسمت بعد توضیح داده شده است.)

  • کوکی Authentication در ASP.NET با نامپیشفرض .ASPXAuth بسیار مهم و حیاتی است و اگر در یک ارتباط  رمز نشده ارسال شود هکر ممکن است از طریق MITM کوکی را بدزدد و  قادر به Session Hijacking  و استفاده از اطلاعات Session قربانی بشود. این تهدید امنیتی در OWASP تحت عنوان Use TLS for All Login Pages and All Authenticated Pages  اشاره شده است.

    نکته مهم در اینجا اینست که عدم بکارگیری SSL/TLS برای صفحات بعد از صفحه Login، کوکی مهم Authentication  و همینطور Session را در معرض تهدید به سرقت رفتن توسط  مهاجم قرار خواهد داد.

     

     بنابراین برای محافظت از کوکی ها میبایست :

    • درخواستها  در HTTPS  ارسال شوند.

    • در برنامه (که بصورت HTTPS میباشد) از Protocol Relative URL در آدرسی دهی به منابع خارج از سایت استفاده کنید تا آن منابع در کانال امن و HTTPS در صفحات برنامه لود شوند.

    • میبایست مشخصهSecure  که یک Flag در HTTP Response میباشد فعال شده باشد.  اگر در کوکی ،  FlagSecure فعال باشد فقطبرای درخواستهایی که در کانال امن (SSL) از طرف Browser برای سرور فرستاده میشوند کوکی ارسال میگردد و برای درخواستهایی که  HTTP هستند (و نه HTTPS) کوکی  فرستاده نمیشود) بنابراین اگر در داخل یک صفحه HTTPS لاگین کرده باشیم و سپس یک صفحه ای که HTTP است را درخواست کنیم، در داخل صفحه جدید بعنوان کسی که لاگین نکرده توسط برنامه شناسایی میشویم چون کوکی .ASPXAUTH فرستاده نشده است.همچنین در این شرایط اگر درخواست یک صفحه HTTPS بدهیم دوباره کوکی ASPXAUTH برای سرور فرستاده میشود و بعنوان فرد لاگین شده و معتبر توسط سرور شناسایی میشویم.)

      برای فعال کردن این Flag برای کوکی Authentication در ASP.NET در Web.config باید مشخصه requireSSL=True باشد. مطابق شکل زیر:

5

 

 

 

  

برای اینکه این برای اینکه مشخصه برای تمام کوکیها نیز فعال باشد مطابق شکل در Web.config:

 6

در این حالت بطور پیشفرض تمامی کوکیها بصورت Secure میباشند مگر اینکه بصورت Explicit در داخل برنامه در زمان ایجاد یک کوکی مشخصه Secure=False قرار بدهیم که در واقع RequireSSL که در Web.config تنظیم کردیم برای این کوکی خاص Override شده و آن کوکی دیگر Secure نخواهد بود.

      • اگر  روی یک سایتSSL فعال شده باشد و مطابق شکل فوق در Web.config برای تمام کوکیها RequireSSL=True باشد و فرض کنیم Session فیکس شده باشد آنگاه با ارسال یک درخواست برای یک صفحه بصورت HTTP ،  کوکی  ASP.NET_SessionId یک مقدار جدید خواهد داشت و در واقع مقدار کوکی  برای این دو صفحه (یکی HTTP و دیگری HTTPS )متفاوت میباشد. ولی اگر  RequireSSL=True  نباشد  آنگاه مقادیر کوکی برای این دو صفحه یک مقدار خواهند داشت و اطلاعات کاربران در رفت و آمد بین این دو صفحه از بین نمیرود.


در برنامه هایی که  Mixed Content (هم محتوای HTTP و هم محتوای HTTPS)داریم Secure Flag بسیار کمک کننده است. بدین معنی که اگر  وبسایتی داریم که SSL میباشد و Secure Flag کوکی Authentication فعال است اگر برنامه نویس در داخل یک صفحه یک Image یا فایل JS قرار داده باشد که آدرس Source آن  HTTPS نباشد و بصورت HTTP باشد (با همان آدرس و Scheme  اما در HTTP) در زمان لود شدن صفحه با درخواست کردن آن عکس یا فایل جاوا اسکریپت از سرور، کوکی Authentication  ارسال نخواهد شد.

محافظت از کوکیها و درخواستهای HTTP ناخواسته در سایتی که HTTPS میباشد توسط  HSTS امکانپذیر است.

HSTS (HTTP Strict Transport Security) به مرورگر Force میکند که درخواستها را (در یک مدت زمان مشخصMAX Age ) فقط از طریق HTTPS ارسال کند. برای مثال اگر یک فایل CSS هم از طریق HTTP و هم از طریق HTTPS در یک سایت قابل لود شدن باشد در اینصورت اگر عمدا درخواست HTTP برای فایل بدهیم و HSTS نیز فعال باشد فایل بصورت HTTPS  ارسال میگردد و نه HTTP. و در نتیجه کوکی محافظت میگردد. مکانیزم HSTS  میبایست توسط برنامه وب و با اضافه کردن یک HeaderResponse به نام Strict-Transport-Security انجام پذیرد.

  SSL Striping(حملاتی که با تبدیل درخواستهای HTTPS به HTTP انجام میشوند) :

    • این نوع از حملات برای اولین بار در سال 2009 با ارائه ابزاری به نام SSLStrip توسط شخصی به نام  Moxie Marlinspike نمایش داده شد. این ابزار از نقطه ضعفی استفاده میکند که بیشتر در طرز استفاده از سایتهای HTTPS میباشد بدین معنی که درخواستهایی که به سایتهای SSL میرسند عموما توسط Redirection از یک درخواست  HTTP میباشند( و نه با تایپ کردن یک آدرس HTTPS ). مثلا کاربران معمولا آدرس سایت فرضی Example که HTTPS میباشد را بصورت Http://www.example.com وارد میکنند که این درخواست توسط سرور با مکانیزم Status Code 301 (Permanent Move) جواب داده میشود ودر این پاسخ Location جدید به آدرس HTTPS://www.example.com تغییر پیدا میکند وبرای کلاینت ارسال میشود. مجددا کلاینت برای آدرس جدید درخواست دوم برای سرور ارسال مینماید.

      مطابق شکل زیر بخاطر اینکه اولین ارتباط با سرور بصورت HTTP است هکر توسط مکانیزم MITM در وسط ارتباط بین کلاینت و سرور قرار میگیرد و توسط ابزار SSLStrip درخواست ارتباط HTTPS که از سرور می آید را (توسط Status Code 301) به HTTP تبدیل کرده و برای کلاینت میفرستد و کلاینت هم بدون توجه به این تغییر، درخواست صفحه HTTP را از سرور میکند . همچنین مهاجم  درخواستی که از کلاینت می آید را HTTPS کرده برای سرور میفرستد و سرور نیز متوجه تغییری در این ارتباط نخواهد شد.

      در OWASP به این مشکل امنیتی اشاره شده است:

      DO NOT Perform Redirects From Non-TLS Page to TLS Login Page

      7 

      بخاطر اینکه مرورگر در اثر این حمله هیچ هشداری را به کاربر نمیدهد (در مقایسه با هشداری که مرورگر در مواجهه با  Certificate های قلابی میدهد) اگر کاربر متوجه نشود که آدرس سایت بصورت HTTP میباشد هکر بدون سرو صدا موفق به انجام خواسته خود شده است.

      HSTS میتواند برای جلوگیری از این نوع حمله استفاده شود اما اگر کاربر اولین بار از سایت دیدن میکند و یا دوره زمانی استفاده از HSTS تمام شده باشد  HSTS نمیتواند از SSLStrip جلوگیری نماید.  زیرا در اولین درخواست از سایت(که طبیعتا بصورت HTTP خواهد بود)، SSLStrip انجام پذیر خواهد بود و یا هکر میتواند با تغییر در Response Header کاربر را به سایت دیگر که مشابه سایت اصلی میباشد (Homograph Attack ) برای مقاصد Phishing بفرستد.  برای همین بعضی از مرورگرها مانند کروم و فایرفاکس از امکانی به نام Preloaded HSTS استفاده میکنند که لیستی از سایتهایی که  از HSTS پشتیبانی میکنند را در خود دارد و مرورگر که درخواستی را میفرستد (حتی برای اولین درخواست) اگر آن سایت در لیست باشد بصورت اتوماتیک مرورگر درخواست را بصورت HTTPS  میفرستد.

      اما اخیرا حملاتی برای دور زدن HSTS انجام شده است. همچنین HSTS محدودیتهایی دارد:

    • این راهکار در browser های کروم و فایرفاکس  پیاده سازی شده است اما IE 10  و SAFARi فعلا نمیتوانند پشتیبانی کنند.

    • برای استفاده از این Header  میبایست در ابتدا حتما یک ارتباط HTTPS ایجاد شده باشد و در این ارتباط، سرور Header  مربوط به HSTS را در  Response Headers قرار میدهد و برای Browser ارسال میکند . بنابراین اگر ارتباط اولیه HTTPS نباشد Browser قادر به تشخیص HSTS در HTTP Response که از  سرور ارسال شده نخواهد بود.

    • مرورگر در سایتهایی که Certificate بصورت  Self-Signed باشد و توسط CA معتبر صادر نشده باشد از دسترسی به سایت  جلوگیری مینماید و خطامیدهد.

      بنابراین :

      مهمترین عامل در جلوگیری از این حمله خود کاربر میباشد. اگر کاربران برای ورود به سایتهایی که حساسیتهای اطلاعاتی زیادی درآن وجود دارد (مثلا بانکداری الکترونیکی) عادت به تایپ اسم سایت بصورت HTTPS نمایند یا آدرس HTTPS آنرا بصورت Bookmark در بیاورند و همینطور عادت کنند که  قبل از ورود اطلاعات خود در صفحه لاگین، Certificate سایت را مطابق شکل زیر بررسی نمایند آنگاه در صورتیکه مورد حمله قرار بگیرند براحتی متوجه خواهند شد.

       8


    • نتیجه:

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

  1. تا جایی که مقدور است از SSL در ارتباطاتی که اطلاعات حساس مابین کلاینت و سرور رد و بدل میشود استفاده کنید . برای مثال فرم Login  و فرمهای تغییر پسورد و یا جاهایی از سیستم که حساسیتهای اطلاعاتی وجود دارد و همینطور صفحاتی که نیازبه Authentication دارند میبایست حتما از SSL استفاده شود. استفاده از SSL در تمام برنامه وب(Site-Wide SSL) یک هزینه ای از لحاظ Performance دارد اما این Overhead چه مقداراست؟

/ 1 نظر / 95 بازدید
احسان

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