در توسینسو تدریس کنید

و

با دانش خود درآمد کسب کنید

Session Hijacking چگونه انجام می شود ؟ قسمت 7 : WebApp Hijack

سلام به دوستان عزیز ITPro ای و علاقه‌مندان به مباحث امنیت شبکه. در قسمت های پیشین تا جایی جلو رفتیم که موفق شدیم پرونده session hijacking در سطح Network را کامل ببندیم. طبق وعده در این قسمت باید داستان مربوط به hijack کردن session ها در لایه Application را بطور کامل مورد بررسی قرار دهیم. پس بی مقدمه اضافه، با ادامه مطلب همراه باشید:

سطح Application

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

Session ID ها را چگونه میتوان بدست آورد؟

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

  • بصورت جاسازی شده (Embeded) در URL که از طریق درخواست های HTTP GET موقعی که کلاینت بر روی لینک های موجود در صفحه کلیک میکند، از سوی اپلیکیشن دریافت میشود.
  • لا به لای فیلدهای یک فرم که به سمت وب اپلیکیشن ارسال میشود.
  • از طریق استقاده از کوکی ها

تمام این سه مکان توسط مهاجم قابل دسترس است.


1. اطلاعات جاساز شده session در URL را براحتی میتوان با بررسی لاگ های history مرورگر، پروکسی سرور و یا فایروال بدست آورد. حتی در صورتی که وب اپلیکیشن بصورت ضعیف کد نویسی شده باشد، مهاجم میتواند مجددا از session های موجود در history استفاده کرده و به وب اپلیکیشن دسترسی پیدا کند.
2. دسترسی به اطلاعاتِ موجود در فرمی که توسط فرمان POST برای وب اپلیکیشن ارسال میشود، کمی سخت تر است. اما بهر حال هرچه نباشد، از بستر شبکه عبور میکند و با استفاده از روش هایی مثل شنود کردن و یا MITM میتوان به آن ها هم دسترسی پیدا کرد.
3. کوکی ها هم از طریق سیستم لوکال کلاینت دسترس پذیرهستند که اطلاعات مرتبط به صفحات وب را در گشت و گذار اینترنتی کاربر ارسال و دریافت میکنند.
علاوه بر این سه روش، مهاجم با استفاده از تکنیک هایی میتواند session ID را حدس بزند و در غیر اینصورت با استفاده از یکی از سه مکان گفته شده، باید آن را سرقت کند. این روش ها عبارتند از:

شنود

با استفاده از تکنیک هایی نظیر روش هایی که برای TCP Session Hijacking گفته شد، مهاجم میتواند خود را در موقعیت "مرد میانی" (Man in the Middle) قرار دهد و از ابزارهای شنود کننده پکت (Packet sniffer) استفاده کند. اگر ترافیک HTTP که ارسال میشود رمز شده نباشد، مهاجم میتواند براحتی ترافیک را بسمت هاست خود هدایت کرده و در آنجا با تحلیل پکت ها، sessionID را بدست آورد. ترافیک های رمز نشده، session ID را با خود حمل میکنند حتی در مواردی علاوه بر session ID، شناسه های کاربری و پسوردها را بصورت plain text را نیز در خود دارند. بنابراین برای مهاجم چندان سخت نخواهد بود تا با تحلیل این پکت ها، اطلاعات مورد نیاز خود را از آن ها بدست آورد.

Brute Force

اگر session ID طوری باشه که بتوان با استفاده از الگویی آن درsession های بعدی را حدس زد، مهاجم میتواند از طریق روش Brute force، آن ها را حدس بزند. این روش به این صورت است که مهاجم بر اساس الگویی خاص، تعداد زیادی session ID را حدس زده و تست خواهد کرد. این روش را براحتی میتوان بصورت یک حمله اتوماتیک انجام داد و تا پیدا شدن یک session ID معتبر، ادامه خواهد داشت. در یک شرایط ایده آل، مهاجم میتواند با استفاده از یک خط DSL خانگی تا 1000 session ID را در ثانیه حدس بزند.بنابراین اگر الگوریتمی که session ID را میسازد، به حد کافی تصادفی و رندوم نباشد، مهاجم میتواند با استفاده از این روش بسرعت یک session ID قابل استفاده را حدس بزند.


گمراه کردن از طریق جلب اعتماد!

آخرین روشی که در این خصوص بیان خواهد شد، بر اساس گمراه کردن از طریق جلب اعتماد خواهد بود. شایدش نامش کمی زمخت به نظر برسد! اما حداقلش اینست که مفهوم را خوب میرساند. این روش به استفاده از HTML Injection و Cross Site Scripting یا همان XSS در سرقت اطلاعات session اشاره دارد.HTML Injection شامل پیدا کردن راهی برای تزریق کد مخرب HTML به وب است؛ در نتیجه مرورگر کلاینت آن را اجرا خواهد کرد و اطلاعات session را به مهاجم ارسال میکند.

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

عبارت "Cross site" به محدودیت های امنیتی تعیین شده برای اطلاعات مرتبط با یک وب سایت، اشاره میکند (مثل کوکی های session). هدف این حمله اینست که مرورگر را ترغیب به اجرا نمودن کد تزریق شده در چهارچوب permission های تعیین شده وب اپلیکیشن، کند. با این کار مهاجم میتواند اطلاعات session را از سمت کلاینت سرقت کند. البته موفقیت در این حمله بستگی به میزان آسیب پذیری وب اپلیکیشن هدف دارد.

خوب دوستان عزیز در اینجا داستان hijack کردن session در سطح Application هم به پایان رسید. حال میتوان گفت که با تئوری و مکانیسم کاری حمله Session Hijacking در ابعاد اصلی آن آشنا هستید و کم کم باید خود را برای اجرای یک حمله تست Session Hijacking آماده کنید.
در قسمت بعد در رابطه با راه‌های مقابله و پیشگیری از این نوع حمله صحبت خواهم کرد.


پایان بخش پنجم
مانا باشید.

نویسنده: احسان امجدی
منبع: جزیره امنیت اطلاعات و ارتباطات وب سایت توسینسو
هرگونه نشر و کپی برداری بدون ذکر منبع و نام نویسنده دارای اشکال اخلاقی می باشد.
#session_چیست #session_hijacking_چیست؟ #tcp_session_hijacking_چیست؟ #اموزش_امنیت_اطلاعات #آموزش_امنیت_شبکه #session_id_چیست؟ #یک_نشست_چیست؟ #application_session_hijacking_چیست
عنوان
1 Session چیست و چگونه کار می کند ؟ قسمت 1 رایگان
2 Session چیست و چگونه کار می کند ؟ قسمت 2 رایگان
3 Session Hijacking چگونه انجام می شود ؟ قسمت 3 : نقش پروتکل TCP رایگان
4 Session Hijacking چگونه انجام می شود ؟ قسمت 4 : Session چیست ؟ رایگان
5 Session Hijacking چگونه انجام می شود ؟ قسمت 5 : لایه 7 و 3 شبکه رایگان
6 Session Hijacking چگونه انجام می شود ؟ قسمت 6 : Desync Attacks رایگان
7 Session Hijacking چگونه انجام می شود ؟ قسمت 7 : WebApp Hijack رایگان
8 Session Hijacking چگونه انجام می شود ؟ قسمت 8 : ابزارهای Hijack رایگان
9 روش های جلوگیری از Session Hijacking قسمت 9 : بخش 1 رایگان
10 روش های جلوگیری از Session Hijacking قسمت 10 : بخش 2 رایگان
زمان و قیمت کل 0″ 0
5 نظر
فرهاد مهریاری

خیلی مفید بود.

حالا چند تا سوال دارم :)

1. مهاجم وقتی session id بدست آورد چه کاری میتونه بکنه ؟(اگر این سوال خیلی کلی هست پیشاپیش معذرت میخام )

2. توی قسمت سرور ساید وب اپ اگه ما توی هر درخواست session id رو تغییر بدیم و اهراز هویت رو از طریق پایگاه داده انجام بدیم ( یعنی کاربر پس از ورود تی دیتابیس یه رکوردی مبنی بر آنلاین بودن کاربر ذخیره بشه ) با این روند در ضریب امنیتی وب اپ تفاوتی ایجاد میشه؟

3. توی وب اپ توی یکی از صفحات مثلا یک فرمی هست که درخواست http با متد post رو ارسال می کنه

با شنود ی که گفتین همه ی اون اطلاعاتی رو که توی اون فرم فرستادیم رو میشه شنود کرد؟

اگه میشه ، برای امنیت اطلاعات ، اونا رمزگذاری بشه بهتره یا اینکه از پروتکل https استفاده بشه ؟

احسان امجدی

1. ببین وقتی که شما مثلا در یک صفحه لاگین اطلاعاتتو وارد میکنی و به وب سایت لاگین میشی، در ازای این احراز هویتی که انجام شده و شما تونستید به اون وب سایت لاگین کنید، یک session برای شما ایجاد میشه. این session تا زمانی که خودتون از اون وب سایت لاگ آف نشید اعتبار داره (مگه براش expire time در نظر گرفته باشن). در ازای این session ای ایجاد شده، متناظر با اون یک session ID براتون از طرف وب اپلیکیشن ایجاد میشه. این session ID حکم کلید طلایی برای وارد شدن و دسترسی به اون وب اپلیکیشن رو داره و تا زمانی که session شما فعاله، هرکی اون session ID رو داشته باشه و داخل کوکی و یا URL (بسته به فرمت و نوع رفتار وب اپلیکیشن) وارد کنه و بسمت سرور بفرسته، بدون نیاز به وارد کردن اطلاعاتی مثل یوزرنیم و پسورد مستقیما بجای شما وارد وب اپلیکیشن میشه و در واقع session شما رو ربایش میکنه.

2. """ توی قسمت سرور ساید وب اپ اگه ما توی هر درخواست session id رو تغییر بدیم و اهراز هویت رو از طریق پایگاه داده انجام بدیم""" تا الان هم فرض بر این بوده که همینطوری عمل میشه. ببین عمر یک session فعال تا زمانیه که شما از وب سایت لاگ آف نکرده باشید... لاگ آف که کنید، هرچند session ID شما لو رفته باشه و اتکر هم بجای شما داخل وب سایت باشه،،،session شما از بین میره و طبیعتا دیگه اون session ID اعتبار نداره. اگه مجددا به وب سایت لاگین کنید، یک session جدید با session ID جدید براتون تشکیل میشه. پس یادت باشه که تمام این صحبت ها و بحث لو رفتن session ID تا زمانی برای اتکر مفید و قابل استفاده هستش که اون session هنوز فعال باشه.

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

3. بله بسته به این که با چه ابزاری و با چه روشی شنود میکنی، میشه همه اطلاعات رمز نشده رو شنود کرد. (البته نه به این سادگی ولی امکانش هست). اگه ارتباط با پروتکل HTTPS باشه یا اطلاعات با روش دیگه ای رمز شده باشند، در حالت عمومی امکان شنود نیست.

فرهاد مهریاری

خیلی خیلی ممنون.

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

شدیدا منتظر قسمت بعدی هستم :)

احسان امجدی

"اینکه اگه احراز هویت با پایگاه داده نباشه ، و مهاجم بتونه خودش یه session ایجاد کنه"

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

اون چیزی که یک session فعال رو با ارزش میکنه و باعث میشه که مهاجم بخواد اون رو سرقت کنه، در واقع همون احراز هویتیه که در قِبل اون session انجام شده و مورد تائید هستش. اینطوری اون session دارای مجوز دسترسی به بخش های خاص و شخصی کاربر در وب اپلیکیشن هستش و همین باعث میشه که اتکر بخواد اونو سرقت کنه.

فرهاد مهریاری

البته منظور من از اینکه با پایگاه داده اهراز هویت بشه این هست که :

وقتی لاگین میکنه بعد از چک کردن وجود همچین کاربر و درست بودن رمز عبور

در یک جدول دیگه ای به نام مثلا onlines ایدی اون کاربر ذخیره بشه

بعد کاربر در هربار که به صفحه ی جدیدی از وب اپ میره چک بکنه که تولیست انلاین ها همچین کاربری هست یا نه

و وقتی که میگیم اهراز هویت با پایگاه داده نباشه یعنی بعد از لاگین و چک کردن اطلاعات نام کاربری و رمزعبور ، فقط در session یک ایدی از کاربر ذخیره میشه و کاربر در هر بار که به صفحه ای از وب اپ میره چک میکنه که توی session ایدی ذخیره شده یا نه


بازم ممنون

نظر شما
برای ارسال نظر باید وارد شوید.
از سرتاسر توسینسو
تنظیمات حریم خصوصی
تائید صرفنظر
×

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