در این مطلب به کلیه سوالات شما در خصوص سشن (Session) و حملات مربوط به آن (Session Hijacking) پاسخ داده خواهد شد و با مفاهیم مرتبط با آن آشنا خواهیم شد.
Session یکی از آن دسته مفاهیمی است که در علم IT بسته به موقعیت خود میتوان به چیزهای مختلفی اشاره داشته باشد: shell session، tcp session، login session، desktop session، browser session، server session و ... .همین موضوع است که باعث شده تا کنون نتوانیم دقیقا درک صحیحی از یک session داشته باشیم. این مشکل تنها محدود به session نمیشود و مفاهیم دیگری نظیر cache هم دارای همین مشکل هستند: database cache، browser cache، framework cache، network cache و ... . خوب...! از این بحث های حاشیه ای که بگذریم، اولین چیزی که باید در مورد session ها بدانیم، استفاده ای است که از آن ها میشود.
در حالت کلی مفهوم یک session را باید از روی حالات و وضعیت های مختلف وب اپلیکیشن در زمانی که یک یوزر با آن در ارتباط است، بررسی کرد. از نظر من یک session نمونه ای از کنش های متقابل یک یوزر با یک وب اپلیکیشن است اما تاکید بر این موضوع در اینجا نمیتواند کمک زیادی در فهم قضیه نماید. در حال حاضر برای یک web session بهتر است از این باب وارد شویم: " session ساختاری از داده است که وب اپلیکیشن از آن برای نگهداری موقتی اطلاعات استفاده میکند. این اطلاعات موقتی فقط در زمانی که یوزر با وب اپلیکیشن در ارتباط است کارایی دارد و خصوصیات یوزر را بیان میکنند.
برای مثال شما میتوانید نام یوزر را در session ذخیره کنید تا دیگر برای هر بار ارتباط با وب اپلیکیشن، نیازی به ارسال کوئری نباشد یا مثلا میتوانید در session، اطلاعات مربوط به ارتباط صفحات با یکدیگر را ذخیره نمایید (برای مثال بین صفحات مرتبط با پروسه پرداخت اینترنتی). از طرف دیگر میتوان session را به دید یک حافظه موقت دید که بسرعت قابل دسترسی است و به هر یوزری که قصد استفاده از اپلیکیشن را دارد، تخصیص داده میشود و در نهایت هنگام خروج یوزر از وب اپلیکیشن، از بین میرود.
از دید کلی این تمام آن چیزی بود که ماهیت یک session را نشان میدهد اما اگر بخواهیم کمی ریزتر از session بدانیم، باید گفت که مکانیسم کاری و نحوه پیاده سازی آن در اپلیکیشن هم در مراحل بعدی نکات مهمی هستند که باید از آن ها سر در بیاوریم. داستان را ادامه میدهیم: این حافظه موقت میتواند بصورت یک فایل متنی در file system، در یک دیتابیس و یا بر روی حافظه داخلی برنامه ای که اپلیکیشن را اجرا میکند، وجود داشته باشد. دومین چیزی که باید در این باب بدانیم، ساختار یک session است.
Session یک ساختار داده ای بر مبنای زوج پارامتر " کلید- مقدار (ارزش)" یا همان "key-value" بزبان دیگر است. این ساختار را میتوانید بصورت یک hash table تصور کنید که هر یوزر برای آن که بتواند دیتای خود را در آن قرار دهد، باید یک hash key بگیرد. در بحث session هم میتوان hash key را معادل session ID دانست. یعنی هر یوزری که بخواهد اطلاعات خود را در session ذخیره نماید، باید یک session ID داشته باشد. ساختار اطلاعاتی session شبیه شکل زیر است:
با توجه به شکل بالا، وقتی که شما میگویید "session من" منظورتان غیرمستقیما اشاره به همان اطلاعاتی دارد که داخل session وجود دارد. هر یوزری فقط میتواند به session یا session هایی که مربوط به خود است، دسترسی داشته باشد. Session میتواند هم بر روی سرور و هم بر روی کلاینت ذخیره شود. اگر بر روی کلاینت باشد، توسط مرورگر و عمدتا بصورت یک کوکی ذخیره میشود و اگر بر روی سرور باشد، session ID ها توسط سرور ایجاد و مدیریت خواهند شد. بنابراین اگر میلیون ها کاربر به سرور ارتباط داشته باشند، به ازای تک تک آن ها session id منحصر بفرد ایجاد و ذخیره میشود.خوب حالا میخواهم دقیقا بر روی session های ذخیره شده بر روی سرور زوم کنم:
در این قسمت میخواهیم بگوییم که یوزرها چگونه به session هایشان دسترسی پیدا میکنند؟ در مورد یک اپلیکیشن تک کاربره مثل یک desktop application، فقط یک یوزر وجود دارد، در نتیجه فقط یک session وجود خواهد داشت بنابراین برای اپلیکیشن کار سختی نیست که بین یوزر و session اطلاعاتی او ارتباط برقرار کند. اما در مورد یک وب اپلیکیشن، یک سرور کلاینت های مختلفی را روبروی خود دارد.
در این حالت سرور از کجا متوجه میشود که چه session ای متعلق به یوزری ست؟ این جا دقیقا همان نقطه ای است که نقش و اهمیت session id خود نمایی میکند.قانون کلی به این صورت است که شما به عنوان یک کلاینت، به سرور session id خود را تحویل میدهید و در مقابل، سرور در صورتی که اطلاعات متناظر با session id شما را درون دیتا استور session هایش پیدا کند، حق دسترسی به آن را به شما خواهد داد.
ساختار session شبیه گاوصندوقی ست که دیتای ما درون آن قرار دارد و کلید این گاوصندوق، session id است. سرور اطلاعات session را فقط به یوزری نشان خواهد داد که session id صحیح را ارائه دهد. بنابراین همانطور که در بحث session hijacking هم تاکید داشتیم، اگر مهاجم به هر نحوی بتواند session id شما را بدست آورد، میتواند session شما را برباید. در شکل زیر دقیقتر عملکرد session نشان داده شده است:
از لحظه ای که شما با صفحه وب ارتباط میگیرید، شروع میکنیم. وقتی که از طرف سرور، صفحه وب مورد نظر شما ارسال و باز میشود، در پشت صحنه، علاوه بر محتوای خود صفحه وب، سرور، session id را نیز (برای شناسایی کانکشن شما در بین تمام درخواست هایی که از یوزرهای دیگر دریافت کرده است)، برای شما ارسال کرده است. این session id میتواند در قالب یک کوکی و یا دو حالت دیگری که قبلا در رابطه با آن ها صحبت شد، باشد. اصلا بگذارید کمی این صحبت های گاها عجیب غریب و خارجکی را بطور عملی تجربه کنیم! کنسول را باز کرده و کوکی ها را چک کنید؛ چیزی که مشاهده میکنید، مانند شکل زیر است:
قبل از این که توضیح مرتبط را ارائه دهم، دقت کنید که JSP اطلاعات session id را با نام JSESSIONID ارسال و ذخیره میکند. در مورد ASP هم ASPSESSIONID و برای PHP هم PHPSESSIONID صدق میکند. پس از آن که شما به صفحه وب مورد نظر لاگین کردید، اپلیکیشن، اطلاعات هویتی مثل یوزر و پسورد شما را اعتبار سنجی کرده و لاگین می کنید. در این موقع session id در session ذخیره میشود و هر زمانی که درخواستی را به سرور ارسال کنید، نیازی به لاگین مجدد نخواهید داشت. البته به تاریخ expire موجود در session هم دقت کنید. در مورد این موضوع بعدا مفصل صحبت خواهد شد. طبق وعده ای که از بخش پیش دادیم، الان میخواهم در رابطه با مکانیسم کاری session و شکل زیر صحبت کنم:
دیاگرام بالا را مرور میکنیم تا متوجه شویم که وقتی شما درخواستی را برای سرور ارسال میکنید، چه اتفاقاتی میافتد. به عنوان مثال شما به صفحه gmail وارد شدید و لاگین کردید. تا اینجای کار سرور یک session بهمراه session id برای شما ایجاد و بسمت کلاینت که شما باشید (فرضا بصورتیک کوکی) ارسال کرده است. حال در ادامه میخواهید به صفحه drafts خود بروید.
خوب! حالا حالتی را فرض کنید که در آن بجای session id، فقط در درخواست ارسالی به سرور، user id خود را فرستادید و به سرور گفتید که قصد مشاهده صفحه drafts را با استفاده از این user id دارید. این به این معنی است که اگر هرکسی user id شما را بداند، میتواند به صفحه drafts های شما دسترسی داشته باشد و این دقیقا موضوعی است که هیچکسی دوست ندارد با آن روبرو شود.
شما ترجیح میدهید که اپلیکیشن، اجازه دسترسی به اطلاعات مربوط به صفحه drafts را فقط به خودتان دهد و نه هر شخص دیگری که user id شما را دارد.در این حالت تنها چاره ای که برای محافظت از محرمانگی اطلاعات شما و پیشگیری از وقوع حوادثی اینچنینی وجود دارد، اینست که قبل از آن که اجازه دسترسی دهد، اپلیکیشن مطمئن شود که شخصی که اطلاعات را درخواست کرده، واقعا خود شمائید.
بنابراین اپلیکیشن ها برای محافظت از محرمانگی دیتا، باید ابتدا از هویت شما مطلع شوند.فرض میکنیم که هیچ session id در این تبادل وجود ندارد یا بهتر است بگوییم فرض کنیم اصلا session id ای تعریف نشده است؛ وقتی که شما صفحه drafts را از سرور درخواست میکنید، سرور واقعا نمیداند که drafts چه کسی را شما درخواست کرده اید. بنابراین ابتدا از شما میخواهد که به اپلیکیشن لاگین کنید.
گفتیم که HTTP پروتکل شلخته و بی قاعده ایست؛ بنابراین در حافظه خود سابقه لاگین کردن های شما را بخاطر نمیسپارد و به همین علت نمیداند که شما الان لاگین هستید. در هر درخواستی که بسمت سرور بفرستید، چون http چیزی از گذشته خاطرش نیست، همین داستان مجددا اجرا میشود و از شما خواسته میشود که علیرغم لاگین بودن، لاگین کنید. واضح است که این موضوع خیلی خواب آور و خسته کننده است.
مثال بالا فقط نمونه ای از مشکلاتی بود که session ها آن را حل کردند. برای جلوگیری از لاگین های پیاپی بعد از اولین لاگین به اپلیکیشن، session ها در تمام مدتی که به سرور کانکت هستید، شما را لاگین نگه میدارند. اساسا، پس از انکه برای اولین مرتبه لاگین کردید، سرور، session ای را که معرف هویت شما است در خود نگه میدارد و بشما این اجازه را میدهد تا بدون احراز هویت مجدد، درخواست دیگری ارسال کنید. این همان چیزی است که session ها را کاربردی و پراستفاده کرده است.
همانطور که میدانید و احتمالا خودتان نیز به نوعی درگیر این موضوع هستید، مدتی میشود که تجارت پررونقی در بحث پرداخت الکترونیک بوجود آمده که بواسطه آن اطلاعات حساسی مانند یوزرنیم، پسورد و حتی مشخصات محرمانه‌مان مانند جزئیات حساب بانکی و کارت اعتباری مرتبا در دنیای وب در حال انتقال است. اطلاعات هویتی و مالی همیشه در زیر سایه سرقت شدن هستند اما این موضوع باعث نشده است که کاربران بتوانند از مزایای استفاده از اپلیکیشن های تحت وب صرفنظر کنند و بقول معروف عطایش را به لقایش ببخشند.
تفکر درستی ست! چرا که خواسته یا ناخواسته آینده در تصرف تجارت الکترونیک است و فرار کردن از آن مشکلی را حل نمیکند. پس بهتر است با آشنایی هرچه بیشتر با مقوله Session Hijacking و حتی تهدیدات دیگر در این زمینه راه استفاده از این شاهراه پرسود و هوس انگیز را برای خودمان صاف کنیم.قبل از آنکه نیاز باشد تا آستین ها را بالا بزنیم! و وارد جزئیات Session Hijacking شویم، لازم است که بدانیم در این سلسله صحبت هایی که در آینده خواهد شد، چه کسی، چه نقشی را بازی میکند؟
باید با پروتکل های آسیب پذیر آشنا شویم و همچنین بدرستی درک کنیم که session ها چه هستند و چگونه از آن ها استفاده میشود؟بر اساس آن چیزی که خودم درباره این موضوع میدانم و تحقیق کردم، به این نتیجه رسیدم که سه پروتکل اصلی که در بحث session hijacking، جریان داده را مدیریت میکنند، TCP, UDP و HTTP هستند ولی با این حال بصورت کلی میتوان گفت که پروتکل هایی مانند telnet، FTP و DNS که از Encryption استفاده نمیکنند هم آسیب پذیر هستند. برای این که بتوانیم وارد بحث Session hijacking شویم باید مختصرا در هرکدام از این پروتکل ها ورود کنیم:
همانطور که میدانید، TCP مخفف عبارت Transmission Control Protocol است که از آن به عنوان یکی از پروتکل های اصلی در شبکه های TCP/IP یاد میشود. در شرایطی که پروتکل IP فقط با پکت ها سرو کار دارد، پروتکل TCP بین دوهاستی که میخواهند با هم ارتباط بگیرند، کانکشن ایجاد میکند و جریانی از اطلاعات را منتقل میکند. TCP این تضمین را میدهد که علاوه برتحویل موفقیت آمیز، دیتا با همان ترتیبی که ارسال شده بودند، تحویل گردند.TCP برای تضمین تحویل صحیح اطلاعات، از پکت هایی موسوم به (Acknowledgment (Ack و همچنین Sequence Number استفاده میکند تا بتواند با ایجاد یک جریان قابل اعتماد بین دو سر ارتباط، به هدف خود برسد.شکل های زیر خلاصه ای از صحبت های گفته شده را به تصویر میکشند:
کانکشن بین کلاینت و سرور با 3-way Handshake شروع میشود (شکل1). نحوه کار به این صورت است:
بعد از آنکه handshake اتفاق افتاد، تنها چیزی که رخ خواهد داد، ارسال پکت های دیتا و به تبع آن افزایش Sequence Number به منظور شناسایی پکت های ارسال و دریافت شده است. در شکل 2 میبینیم که کلاینت یک بایت اطلاعات (حرف "َA") را با Sequence Number ای برابر با X+1 به سرور ارسال کرده و در مقابل، سرور با ارسال یک پکت ACK با عدد X+1 ) X+2 به علاوه 1 بایت برای کاراکتر "A")، تائیدی برای کلاینت بازپس خواهد فرستاد.
X+2 در واقع همان Sequence Number ای است که سرور از کلاینت انتظار دریافت آن را خواهد داشت. بازه و بستری که در آن تمام دیتا به این صورت توسط TCP بین کلاینت و سرور رد و بدل میشود، TCP Session نامیده میشود. توضیحات داده شده، اولین مرحله ایست که برای تشریح Session Hijacking باید آن را خوب درک کرده باشید. در قسمت بعد راجع به دو پروتکل دیگر یعنی UDP و HTTP و نقش آن ها در Session Hijacking صحبت خواهم کرد.
UDP نقش خود را چگونه بازی میکند؟ همانطور که از قسمت قبل بخاطر دارید، TCP، از پارامتر Sequence Number برای پیشبرد اهداف خود در three-way handshake استفاده میکرد اما در UDP چنین نیست. از پروتکل UDP عمدتا در جهت Broadcast کردن پیام ها در شبکه و یا ارسال کوئری های DNS استفاده میشود. از آنجایی که این پروتکل Connectionless است و مانند TCP مکانیسم پیچیده ای ندارد، برای فرآیند session hijacking پروتکل لذیذتری! است. همانطور که در مورد TCP هم تعریف کردیم، در UDP هم یک session را بستر ایجاد شده پس از ارسال داده بین سرور و کلاینت معرفی میکنیم. پروتکل UDP را میتوان حالت دوم از اجرای یک session hijacking در نظر گرفت.
اگر بخواهم این پروتکل را خیلی اتو کشیده! و رسمی معرفی کنم باید بگویم که HTTP، یک پروتکل بنیادی و اساسی در دنیای گسترده وب یا همان www خودمان است. HTTP مشخص میکند که پیام ها چگونه قالب بندی و ارسال شوند و وب سرورها و مرورگرها در مقابل پیام ها و فرمان های مختلف چه واکنشی باید از خود نشان دهند. به عنوان مثال، وقتی که شما یک URL را در مرورگر وارد میکنید و کلید اینتر را میزنید، در واقع یک دستور HTTP به وب سرور ارسال میشود که وب سرور پس از دریافت آن را به صفحه وب درخواست شده، منتقل میکند.
این نکته مهم است که بدانید HTTP یک پروتکل بلا تکلیف! است. هر تراکنشی در این پروتکل بدون در نظر گرفته شدن اطلاعات تراکنش های قبلی، بی درنگ اجرا میشود. نتیجه این میشود که HTTP هیچ برنامه ای برای تمایز دادن یک کاربر از کاربر بعدی در دل خود ندارد. برای سامان دادن به این وضع و همچنین تشخیص سابقه یک کاربر، وب اپلیکیشن ناچار است جور HTTP را بکشد و به اطلاعات هر کاربر یک HTTP Session تخصیص میدهد. این session سابقه یک تراکنش را منحصربفرد میکند.HTTP آخرین مرحله ایست که session hijacking میتواند در آن رخ دهد.
تا اینجا موفق شدیم مراحل اجرای session hijacking را یاد بگیریم. در حرکت بعدی میخواهم درباره قربانی صحبت کنم. هرچه نباشد، یک سر قضیه را تشکیل میدهد! بله.. درست است؛ همانطور که اکثرا درست حدس نزدید، قربانی داستان ما یک Host و در واقع کلاینت نیست. در این ماجرا قربانی همان session هایی است که قرار است hijack (سرقت) شوند.در مورد TCP و UDP همانطور که در بالا هم گفته شد، session ها همان بازه زمانی و بستری هستند که در حین کانکت شدن کلاینت و ارسال داده ها به سرور ایجاد شده اند.
در ابتدای session، کاربر/کلاینت احراز هویت میشود و سپس یک session همان بازه رد و بدل شدن ack number ها از کلاینت به سرور و بلعکس تلقی میشود. برای آنکه بتوانیم این مفهوم را با یک HTTP Session تمایز دهیم، TCP/UDP session ها را با عنوان TCP/IP Stream از این به بعد یاد خواهیم کرد. TCP/UDP session ها با تحت کنترل گرفتن پکت های ارسال شده بین کلاینت و سرور hijack (سرقت) میشوند.
اما در مورد HTTP باید گفت که session ها همان بازه زمانی و بستری هستند که کاربر به وب اپلیکیشن دسترسی دارد که معمولا از Logon تا Logoff کاربر ادامه دارد. Session های HTTP به session های TCPوابستگی دارند و بسته به این که درخواست کاربر موجود در دل TCP/IP Stream ها مستقیما، بواسطه پروکسی و یا حتی از IP Address های مختلف به آن ها رسیده باشد، فرق دارند. فکر میکنم جمله کمی سنگین بود! بنابراین لطفا یکبار دیگر با دقت جمله پیشین را بخوانید.
یک HTTP session تمام سوابق فعالیت کاربر که با وب اپلیکیشن داشته است را بر خلاف TCP/IP Session ها را درخود نگه میدارد. همانطور که قبلا هم به آن اشاره شد، HTTP یک پروتکل بلاتکلیف است و به چنین پرونده ای از سوابق کاربر در قالب یک http session نیاز دارد. در نتیجه sessionهای وب اپلیکیشن سوابق کاربران را بطور مجزا در دل خود نگهداری میکنند. پیاده سازی این session ها کاملا بستگی به وب اپلیکیشن مورد استفاده دارد. اگر بخواهم مطلب را در یک خط خلاصه کنم باید بگویم که " وقتی که یک کاربر به اپلیکیشن لاگین میکند، session بر روی سرورایجاد میشود تا بتواند وضعیت فعالیت این کاربر را برای درخواست های بعدیش نزد خود نگه دارد.
" Session تمام پارامترهای لازم و اطلاعات هویتی کاربری را که با آن ارتباط داشته است، ذخیره میکند. این اطلاعات تا زمانی که کاربر لاگ آف نشود و یا برای یک بازه زمانی تعریف شده، غیرفعال نگردد، موقتا در مموری سرور ذخیره میشوند.پس مهم است که بدانیم session ها عموما در این مرحله چگونه مدیریت میشوند. برای شناخت راحتر یک session، هر session متناظر یک session ID میشود. در واقع در مورد درخواست های HTTP مربوط به یک session، این ID متناظر است که بین کلاینت وسرور رد و بدل خواهد شد. وب اپلیکیشن ها معمولا مدیریت session را در دو حالت client-side و یا server-side پیاده سازی میکنند.
در پیاده سازی client-side، اطلاعات مربوط به احراز هویت کاربر در همان سمت کلاینت و در قالب یک کوکی ذخیره میشود. کلاینت اطلاعاتی را که درون کوکی خود پیدا میکند (که شامل session ID هم هست)، با درخواست خود به سرور ارسال میکند تا سرور بداند که چه کسی اطلاعات را درخواست کرده است. در مقابل، پیاده سازی server-side، همین اطلاعات را درون سرور و در دیتابیس back-end خود ذخیره میکند. از session ID برای ایندکس کردن اطلاعات کاربر در دیتابیس استفاده میشود؛ بنابراین سرور میتواند براحتی به محض دریافت درخواست از سوی کاربر، اطلاعات هویتی آن را فراخوانی کند.
در این قسمت میخواهم در اینباره مفاهیم بیشتری را جهت آشنایی و درک کامل شما با مفهوم session hijacking بیان کنم. پس بی مقدمه اضافی، با ادامه مطلب همراه باشید: خوب تا اینجا آموختید که session hijacking در چه سطوحی میتواند رخ دهد و قربانی که همان session ها بودند را در این سه مرحله شناختید. گام بعدی که قرار است به آن بپردازیم، نوع رفتار و عملکرد session hijacking در هرکدام از این سه سطح است.
همانطور که میدانید، session hijacking یک حمله امنیتی است که با هدف ربایش و تصاحب session کاربر در یک شبکه رخ میدهد. این حمله شامل بازه متنوعی از تکنیک هاست که در طی همه آن ها session های وب اپلیکیشن و یا TCP/IP به تصاحب مهاجم در میآید. در واقع اگر ربایش session موفقیت آمیز باشد، مهاجم میتواند خود را بجای کاربر و یا کلاینتی جا بزند که session اش را ربوده است و در نتیجه میتواند بجای آن ها به اطلاعات حساس موجود در session ها دسترسی پیدا کند.
گفتیم که session hijacking میتواند در سه سطح پروتکل TCP، UDP و HTTP رخ دهد. پس اگر کلی تر بخواهیم به موضوع نگاه کنیم، میتوان گفت که این حمله در دو سطح کلی Network و Application میتواند اتفاق بیافتد؛ چرا که پروتکل های TCP و UDP را میتوانیم زیر مجموعه ای از سطح Network و پروتکل HTTP را زیر مجموعه از سطح کلی Application در نظر گرفت. این دو سطح در واقع به دو نوع session (از لحاظ ساختار) اشاره دارند که قابل hijack شدن هستند.
سطح Network به دستکاری و یا ربایش session های TCP و یا UDP که بین سرور و کلاینت ایجاد شدند، اشاره دارد و سطح Application اشاره به تصاحب session ID هایی دارد که بوسیله آن ها میتوان session های HTTP یک وب اپلیکیشن را تحت اختیار گرفت.
حملاتی که در هر کدام از سطوح رخ میدهد را نمیتوان کاملا مستقل و بی ارتباط به سطح دیگر دانست. در اغلب اوقات، بسته به سیستمی که مورد حمله قرار میگیرد، این دو سطح در کنار هم مورد حمله قرار میگیرند. برای مثال اگر بروی یک TCP session حمله موفقی صورت بپذیرد، بی شک بواسطه آن، مهاجم این امکان را خواهد داشت تا بتواند مستقیما بر روی session کاربر در سطح Application هم حمله ای داشته باشد و اطلاعات مورد نیاز خود را بدست آورد.
Session hijacking در سطح Network، برای مهاجمان امتیاز ویژه ای دارد؛ چرا که در این سطح پایه های کار ثابت است ولی در سطح Application مهاجم ناچار است بسته به وب اپلیکیشنی که میخواهد session آن را برباید، فوندانسیون کار را تغییر دهد. این حمله بر روی جریان داده ای از پروتکل اتفاق میافتد که در تمام وب اپلیکیشن ها ثابت و بین آن ها مشترک است.
هدف رباینده یک TCP session، ایجاد وضعیتی است که بوسیله آن کلاینت و سرور نتوانند اطلاعات بهم رد و بدل کنند، بنابراین مهاجم میتواند با استفاده از این فرصت، پکت هایی با پارامترهای مجاز در session واقعی (Sequence Number) را جعل کرده و به هر دو طرف ارتباط ارسال کند. بنابراین با کار میتواند کنترل session را بدست بگیرد. در این حالت حتی اگر ارتباط بین کلاینت وسرور وصل شود و ایندو بصورت واقعی ادامه ارسال اطلاعات را از سر بگیرند، به علت آن که Sequence Number کلاینت با Ack Number سرور مطابقت ندارد (و بلعکس)، ایندو پکت هایی که از یکدیگر میگیرند را drop (نابود) میکنند.
برای مثال فرض کنید که به ازای هر پکتی که کلاینت به سرور میفرستند، یک عدد به sequence number اش اضافه میکند (و بلعکس). حال فرض کنید ارتباط بین کلاینت وسرور زمانی که sequence number کلاینت برابر 3 است، قطع میشود. در این هنگام مهاجم با ارسال پکت های جعلی طبق همان روال یعنی sequence number شماره 4 به بعد به سرور ارتباط به را بصورت جعلی ادامه میدهد (و بلعکس). حال فرض کنید وقتی که بلطف پکت های جعلی مهاجم sequence number کلاینت برابر 7 است، ارتباط مجددا برقرار میشود.
حال کلاینت واقعی به زعم خود و با توجه به آن که پیش از قطع شدن ارتباط، آخرین sequence number برابر 3 بوده، پکت های واقعی خود را با sequence number شماره 4 به بعد برای سرور ارسال میکند. کلاینت خبر ندارد که در زمان قطع بودن ارتباط، مهاجم کار را با پکت های جعلی ادامه داده و در واقع سرور الان منتظر رسیدن پکتی با sequence number برابر 8 است.
به همین خاطر سرور به علت عدم تطابق sequence number فعلی با آن چیزی که انتظار دارد، پکت های کلاینت را drop میکند و در مقابل از آنجایی که مهاجم با رعایت ترتیب صحیح sequence number ها توانسته است session را از آن خود کند، سرور ادامه session را با سیستم مهاجم انجام خواهد داد. همین اتفاق در مورد پکت هایی که سرور برای کلاینت ارسال خواهد کرد هم می افتد. بنابراین مهاجم توانسته است با در اختیار گرفتن session بجای هر طرفی از ارتباط، با طرف دیگر صحبت کند.
در این مثال یعنی یک حمله اکتیو علیه TCP session، وضعیت ناهمزمانی (ناهمگامی/ desynchronize) در حالتی رخ میدهد که TCP session باز است و اطلاعات در حال تبادل هستند (وضعیت پایدار). روش های مختلف دیگری هم وجود دارد که مهاجم با استفاده از آن ها میتواند وضعیت ناهمزمانی را در session موجود ایجاد کند.در قسمت بعد به تکنیک ها و روش هایی خواهم پرداخت که مهاجم بوسیله آن ها میتواند مانند روش TCP hijacking که در بالا توضیح داده شد، در session قربانی وضعیت ناهمزمانی ایجاد کند و آن را در اختیار خود بگیرد.
به این جا رسیدیم که علاوه بر روش TCP hijacking، روش های دیگری نیز برای ایجاد ناهمگامی (desynchronize) در روند انتقال اطلاعات از کلاینت به سرور و بلعکس وجود دارند که طبق وعده در این بخش آن ها را توضیح میدهم. پس بی مقدمه اضافه، بسراغ ادامه داستان میرویم:
اگر بخواهم خیلی ساده IP Spoofing را تعریف کنم باید بگویم که روشی است که بوسیله آن میتوان بصورت غیرمجاز به سیستم ها دسترسی پیدا کرد. روش به این صورت است که مهاجم با IP Address ای که ظاهرا متعلق به یک سیستم مجاز است، به کامپیوتر مورد نظر پیغام ارسال میکند. در بحث hijacking، یک سیستم مجاز همان کلاینت است. کار به این صورت است که مهاجم IP کلاینت را بدست میآورد و هدر پکت های خود را طوری اصلاح میکند که انگار آن از طرف آن آدرس IP ارسال شده اند.
این روش به مهاجم این امکان را میدهد تا بتواند خود پکت های ظاهرا مجازش را بسازد و آن ها را در بین پکت های ارسالی در TCP session تزریق (inject) کند. این پکت ها source-route شده هستند به این معنی که ارسال کننده آن ها از ابتدا مسیر آن را تا رسیدن به مقصد مشخص کرده است.با استفاده از این پکت های Source-route شده، مهاجم میتواند پکت ها را به سمت هاست جعلی خودش مسیر دهی کند و این در حالی است که سرور فکر میکند که با کلاینت (قربانی) در حال رد و بدل اطلاعات است.
وقتی که مهاجم توانست با موفقیت یک IP را spoof کند، با استفاده از اطلاعات موجود در پکت دریافت شده از سرور میتواند sequence number بعدی که سرور انتظار دریافت آن را دارد، حدس بزند. بنابراین با استفاده از این اطلاعات پکت جعلی خودش را قبل از آن که کلاینت پاسخ دهد، به TCP session تزریق میکند و به این صورت همانند روش قبلی که در قسمت پیش گفته شد، ناهمگامی در ارتباط بین سرور و کلاینت پیش میآید. باقی داستان همانی است که در روش قبل ( TCP session) گفته شد.
اگر روش source-routing را کنار بگذاریم، مهاجم میتواند با استفاده از روش blind hijacking هم میتواند اطلاعات آلوده خود را به TCP session تزریق کند. به این روش "blind" یا "کور" گفته میشود چرا که مهاجم اطلاعات و یا دستورات خود را فقط میتواند ارسال کند و امکان مشاهده پاسخی که در برابر آن از سرور و یا کلاینت صادر میشود را ندارد. در این روش مهاجم بر اساس اصول و قوانینی که وجود دارد، پاسخی که از طرف سرور و کلاینت صادر میشود را حدس خواهد زد.
این روش شامل استفاده از یک شنود کننده پکت است که میتواند ارتباطات بین کلاینت و سرور را شنود و حتی ویرایش کند. در این روش مهاجم در بین راه کلاینت و سرور اطلاعات رد و بدل شده را شنود کرده و با واسطه قرار دادن در ارتباط بین کلاینت و سرور میتواند براحتی تمام محتوای پکت های رد و بدل شده را ویرایش کرده و به سمت دیگر نود مجددا ارسال کند. نکته موجود در این روش اینست که تمام پکت ها با عبور از هاست مهاجم به طرف دیگر نود خواهد رسید.
اولین تکنیکی که در این روش میتوان بکار برد، استفاده از پکت های جعلی ICMP است که ترافیک بین کلاینت و سرور را بسمت هاست مهاجم تغییر مسیر میدهد. ICMP افزونه ای از IP است و در اصل برای ارسال پیام های خطا که نشان دهنده بروز خطا در پردازش پکت های موجود در کانکشن است، استفاده میشود. در این حالت، مهاجم پیام های جعلی را برای گول زدن کلاینت و سرور ارسال میکند که محتوای آن ها اینست که مسیری که از هاست مهاجم عبور میکند، بهتر از مسیر اصلی است (بهتر از لحاظ سرعت، کوتاهی مسیر و یا مسیری بدون خطا).
تکنیک دومی که در این روش کاربرد دارد، ARP Spoofing است. ARP مخفف Address Resolution Protocol است. هر هاست-ی از جدول های ARP برای تطابق آدرس های IP لوکال به آدرس سخت افزاری یا همان MAC استفاده میکند. ARP spoofing شامل ارسال ARP reply های جعلی برای فریب هاست هایی ست که برای آپدیت جدول ARP خودشان، ARP request را broadcast کرده اند.
این ARP reply های جعلی، کاری که میکنند اینست که تمام IP های موجود درجدول ARP سیستم ها را با مک آدرس سیستم مهاجم متناظر میکنند. نتیجه این میشود که جدول ARP سیستم ها پر از IP های مختلفی ست که همگی به یک آدرس مک اشاره دارند. بهمین خاطر تمام ترافیک هایی که به مقصد هرکدام از آن IP ها آدرس دهی شده اند مستقیما به سیستم مهاجم ارسال میشوند. مهاجم میتواند پس از تغییرات لازم روی پکت ها آن را بسمت مقصد واقعی شان ارسال کند.
Session hijacking در سطح پروتکل UDP مشابه TCP session hijacking است با این تفاوت که UDP به نسبت TCP پروتکل ضعیفتری است که در مکانیسم کاری خود از sequence number و یا ACK number استفاده نمیکند. درUDP، مهاجم تنها کاری که میکند اینست که قبل از آن که سرور بتواند با پیغام reply به درخواست کلاینت پاسخ دهد.
بصورت خیلی ساده یک reply جعل کرده و بجای سرور به‌سمت کلاینت ارسال میکند. اگر موقعیت اجرای hijack از طریق Man in the Middle فراهم باشد، کار برای مهاجم ساده تر هم خواهد شد چرا که بخاطر موقعیتش در بین مسیر ارتباطی سرور و کلاینت، میتواند مانع از رسیدن پیغام reply از سرور به کلاینت شود و بنابراین با خیال راحت تری کار جعل را انجام دهد.
یکی از تاثیرات جانبی که در کنار TCP session hijacking میتواند رخ دهد، TCP ACK Storm است. اگر مهاجم دقت کافی را نداشته باشد، بخاطر TCP ACK Storm شدیدی که در شبکه رخ میدهد، عمل ربایش session اش، بسیار توی چشم خواهد آمد.TCP ACK Packet Storm در نتیجه ایجاد حالت ناهمگامی در ارتباط بین سرور و کلاینت رخ میدهد. در این حالت، کلاینت و سرور نمیتوانند به همدیگر هیچ پکتی را که قابل قبول برای طرف دیگر باشد، ارسال کنند که همانطور که قبلا گفتیم این موضوع به علت ناهمگامی در sequence number هاست.
در این حالت برای آن که دو طرف ارتباط بتوانند مجددا حالت همگامی (synchronize) را بین خودشان ایجاد کنند، مرتبا برای همدیگر ACK number هایی را ارسال میکنند که قابل قبول برای طرف دیگر نیست. چرخه ارسال این پکت های ACK بحدی میرسد که سبب ایجاد TCP ACK Packet Storm میشود؛ کارایی شبکه بسیار افت خواهد کرد و به همین علت سیستم IDS در شبکه بسرعت این مشکل را شناسایی میکند.
وقتی که TCP ACK Storm رخ میدهد، مهاجم باید بسرعت و در کمترین زمان ردپای خود را پاک کند. برای آن که شبکه از حالت TCP ACK Storm خارج شود، مهاجم جدول ARP را تغییر میدهد. مهاجم مشابه همان روشی که در ARP Spoofing انجام داده بود، شروع به جعل پیام های ARP Reply کرده ولی اینبار بجای آن که مشابه ARP Spoofing، به تمام آدرس های IP موجود در جدول ARP (IP هایی که در حمله session hijacking دخیل بودند) آدرس مک خود را اختصاص دهد، آن ها را با آدرس های سخت افزاری (مک) ای متناظر میکند که اصلا وجود خارجی ندارند.
بنابراین با این حرکت پکت هایی که سبب بوجود آمدن TCP ACK Storm شده بودند، به علت آدرس های اشتباه در جدول ARP دیگر به هیچ جایی ارسال نمیشوند و در نتیجه Storm (طوفان) قطع میشود.به فرض آنکه هیچ TCP ACK Storm ای رخ ندهد، مهاجم میتواند پس از آنکه حمله اش به اتمام رسید، ردپایش را با همگام سازی مجدد کلاینت و سرور (دو سر ارتباط) پاک کند.
برای همگام سازی مجدد، sequence number کلاینت باید با آن عددی که سرور در ادامه از کلاینت انتظار دارد، یکسان شود. مهاجم میتواند اینکار را با ارسال درخواستی جعلی به سرور انجام دهد. خوب دوستان عزیز تا اینجا توانستیم تمام جزئیات مربوط به hijacking در سطح Network را یاد بگیریم. در قسمت بعد سعی بر این خواهد بود تا hijack در سطح Application را بطور کامل تشریح کنم.
سطح Application چه کاری انجام می شود؟ در این سطح، مهاجم فقط در پی ربایش session های موجود نیست بلکه علاوه بر آن سعی میکند تا با استفاده از اطلاعات سرقت شده، session های جدیدی نیز بسازد. ربایش session در این سطح عمدتا براساس بدست آوردن یک session ID معتبر برای تحت کنترل گرفتن session موجود و یا ایجاد یک session غیرمجاز است.
تا زمانی که وب اپلیکیشن ها از session ID برای تشخیص هویت استفاده می کنند، میتوان گفت که سرقت session در این سطح تماما منحصر به بدست اوردن session ID میشود. بدین معنی که زمانی که session ID بدست امد، میتوان گفت که تقریبا کار تمام است و session ربایش شده است.Session ID ها را معمولا در سه مکان میتوان جستجو کرد :
تمام این سه مکان توسط مهاجم قابل دسترس است.
با استفاده از تکنیک هایی نظیر روش هایی که برای TCP Session Hijacking گفته شد، مهاجم میتواند خود را در موقعیت "مرد میانی" (Man in the Middle) قرار دهد و از ابزارهای شنود کننده پکت (Packet sniffer) استفاده کند. اگر ترافیک HTTP که ارسال میشود رمز شده نباشد، مهاجم میتواند براحتی ترافیک را بسمت هاست خود هدایت کرده و در آنجا با تحلیل پکت ها، sessionID را بدست آورد. ترافیک های رمز نشده، session ID را با خود حمل میکنند حتی در مواردی علاوه بر session ID، شناسه های کاربری و پسوردها را بصورت plain text را نیز در خود دارند. بنابراین برای مهاجم چندان سخت نخواهد بود تا با تحلیل این پکت ها، اطلاعات مورد نیاز خود را از آن ها بدست آورد.
اگر 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 آماده کنید. در قسمت بعد در رابطه با راه‌های مقابله و پیشگیری از این نوع حمله صحبت خواهم کرد.
سلام به دوستان عزیز ITPro ای و علاقه‌مندان به مباحث امنیت شبکه. امیدوارم تا اینجای کار از سری مقالات session hijacking خسته نشده باشید که اگر اینطور باشد، باید بشما این مژده را بدهم که این مقاله آخرین بخش از سری مباحث session hijacking خواهد بود که در آن به معرفی ابزارهای لازم جهت سنجش آسیب پذیری session ها می‌پردازیم.در ادامه به معرفی برخی از ابزارهای مفید جهت تشخیص میزان حساسیت شبکه و وب اپلیکیشن های شما به ربایندگان session می پردازم:
این دو ابزار جزو ابزارهای خوب در زمینه man in the middle proxy بحساب میایند. این ابزارها با ایجاد اختلال در دیتای HTTP Session، به یوزر این امکان را میدهند تا دیتای را قبل از انتقال کامل، تغییر دهند. شما میتوانید با استفاده از این ابزارو قرار دادن خود در حالت man in the middle، متوجه شوید که شبکه شما در برابر مهاجمان چقدر ضعیف است. این دو ابزار میتوانند در پکت های بین کلاینت و سرور دستکاری کرده و حتی میتوانند بطور مجزا هم با سرور و هم با کلاینت از طریق ssl session صحبت کنند. این کار باعث جعل دیتا بین دو سر ارتباط میشود. این دو برنامه رایگان و قابل دانلود هستند.
این دو ابزار، مانند اسنیفرهای شبکه عمل میکنند که از آن ها میتوانید برای TCP session hijacking استفاده کنید. این دو ابزار میتوانند طوری تنظیم شوند که ترافیک خاصی را شنود کنند و حملات خودکار session hijacking انجام دهند. اغلب روش هایی مانند ویرایش جدول ARP و ناهمگام سازی TCP، که در این سری از مقالات بیان شد، توسط این دو ابزار انجام میشوند. این دو ابزار برای سنجش اسیب پذیری شبکه شما مورد استفاده قرار میگیرند.
این ابزار کوکی ها را به منظور تعیین میزان سختی پیش بینی و یا تعیین مقدار session id های داخلشان آنالیز میکند. اساسا این ابزار جزو برنامه های خوب در سنجش میزان قدرت مقاومت کوکی ها در برابر مهاجمان است. خوب دوستان در اینجا به پایان سری مقالات session hijacking رسیدیم. امیدوارم علاوه بر این که استفاده کافی را از آن ها برده باشید، بر میزان علم امنیت شما هم افزوده شده باشد.
در ادامه صحبت ها، روش های پیشگیری و اقدامات متقابل برای آن که دچار حمله session hijacking نشویم را بیان میکنم. پس بی مقدمه اضافه، با ادامه مطلب همراه باشید: روش ها و تکنیک های مختلفی وجود دارد تا با کمک آن بتوان از hijack شدن session جلوگیری کرد. در همان راستایی که در مورد session hijacking بحث شد، در مورد اقدامات پیشگیرانه آن ها هم صحبت میکنیم. یعنی صحبت ها را به دو سطح Network و Application مجزا میکنیم.
در این سطح، تمام صحبت ها و اقدامات انجام شده درباره محافظت از پکت ها میباشد. مهمترین استراتژی برای نیل به هدفمان اینست که تفسیر و تحلیل داده توسط مهاجم را سخت تر کنیم. در واقع اگر مهاجم نتواند هدرهای داده ها را بطور صحیح بخواند، قطعا نخواهد توانست که پکت های جعلی را ایجاد و در جریان داده، تزریق کند.
مهمترین اقدام پیشگیرانه که خواندن هدرها را برای مهاجم سخت میکند، پیاده سازی پروتکل های انتقال رمز شده مثل IPSec، SSL، TLS و SSH میباشد." در صورت پیاده سازی چنین پروتکل هایی، مهاجم برای ربایش session باید از طریق tunnel زدن به یکی از پروتکل های بالا کار خود را پیش گیرد که در اینصورت حداقل باید session key که از tunnel محافظت میکند را بداند و همانطور که میدانیم، حدس زدن و یا سرقت session key ناشدنی و یا بسیار سخت است. "
همانطور که در بالا گفته شد، پروتکل های رمز شده ادامه کار مهاجم را بسیار سخت میکند. در واقع اگر مهاجم تا پیش از این فرضا دو مرحله تا سرقت session فاصله داشت، با پیاده سازی چنین پروتکل هایی، باید هفت خان رستم را طی کند! به این مفهوم که مهاجم ابتدا باید ارتباطات بین دو سر ارتباط را رمزگشایی کند (پیدا کردن session key) و در صورت موفقیت در این کار در مرحله بعد باید بتواند بطور صحیح پکت های مخرب خود را طوری رمز کند که کلاینت باور کند که این پکت برای اوست. در غیر اینصورت هر پکتی که مهاجم بدون استفاده از session key ارسال کند، توسط هاست از بین میرود.
این پروتکل خود مجموعه ای از پروتکل های زیر مجموعه ای است که برای اطمینان از امنیت تبادل پکت ها در لایه IP توسعه داده شده اند. IPSec دو روش رمزنگاری دارد: Transport و Tunnel.در حالت Transport، فقط بخش دیتا در هر پکت رمز میشود و هدر پکت دست نخورده و بی هیچ اقدام امنیتی ای باقی میماند. اما در حالت Tunnel هر دو بخش دیتا و هر رمز میشوند.
در هر دو روش IPSec توانسته است امنیت نسبی را در مقابل session hijacking ایجاد کند اما روش Tunnel ایده آل تر است چرا که هر دو بخش دیتا و هدر را با هم رمز میکند. بنابراین کار را برای مهاجم سخت تر خواهد کرد. در این حالت مهاجم حتی نمیتواند متوجه شد که پکت ها از کجا میآیند و به کجا میروند.IPSec پروتکلی است که از لایه Network محافظت میکند و به عبارتی میتوان آن را مهمترین پروتکل در محافظت از اطلاعات پکت ها بحساب آورد.
این پروتکل از فایل های مربوط به وب که بصورت محرمانه و از طریق کانکشن ssl ارسال میشوند، محافظت میکند. اکثر مرورگرها آن را پشتیبانی میکنند. بر طبق قراردادی که وجود دارد، URL هایی که به یک کانکشن ssl نیاز دارند، با HTTPS (در عوض HTTP) شروع میشوند. البته SSL در لایه Application بیشتر نقش محافظتی خود را ایفا میکند چرا که دیتای ارسال شده از طریق http session را رمز میکند.
همانطور که قبلا هم گفته شد، این پروتکل شبکه را در برابر IP Spoofing و IP Source Routing که تکنیک های رایج در session hijacking هستند، محافظت میکند. با پیاده سازی این پروتکل، مهاجم بیشترین کاری که از دستش بر میآید، disconnect کردن ssh session است و نمیتواند ترافیک را منحرف و یا کانکشن رمزشده را سرقت کند.
در کنار رمزنگاری هدر و دیتا و سخت کردن دسترسی مهاجم به آن ها میتوانید امکان رخداد سرقت session را با استفاده از خنثی کردن ترفندهای مهاجم نیز کاهش دهید. تکنیک های IP Spoofing و Source Route Packet همیشه قابل اجرا هستند و استفاده از ssh نیز فقط اجرای موفق آن ها را سخت تر میکند اما میتوانیم با امن کردن بیش از پیش فایروال ها و روترهای خود، اجرای این تکنیک ها را از ریشه غیر فعال کنیم. این دیوایس ها در حکم خط مقدم مبارزه با حملات هستند.
برای مثال شما میتوانید رول هایی را بنویسید که پکت های Source route شده را نادیده بگیرد یا اینکه با ایجاد تغییراتی در پیکربندی شبکه میتوان از وقع Arp Spoofing جلوگیری کرد. شما میتوانید از جدول های استاتیک ARP که مستقیما بر درخواست های ARP تکیه نمیکنند، استفاده کنید و یا آنکه اگر اصرار بر استفاده از ARP دارید، میتوانید با استفاده از ابزاری مثل ARP Watch، تغییراتی که در جدول ARP ایجاد میشود را مانیتور کرد. علاوه بر اینها میتوانید با غیرفعال کردن قابلیت Redirect شدن ترافیک ICMP، کار مهاجم را در تغییر مسیر ترافیک به سیستم خودش برای ایجاد حالت man in the middle سخت تر نمایید.
همانطور که در بخش پیش دیدید، پیشگیری از session hijacking در سطح Network عمدتا منحصر به امن کردن پکت ها بود، بهمین ترتیب در سطح Application پیشگیری از این حمله شامل محافظت و مراقبت از session id در برابر سرقت و یا حدس زدن میباشد. همانطور که قبلا هم گفتیم، در بحث http session ها، session id یعنی کلید دستیابی به session ای خاص.
نکته کلیدی در محافظت از وب اپلیکیشن در برابر تهدید ربایندگان session، پیاده سازی یک ساختار و الگوریتم قدرتمند در ایجاد session id است. مدیریت session چه بصورت client side باشد و چه بصورت server side، این موضوع هیچ فرقی نمیکند و در هر دو حالت صادق است. در ادامه تکنیک هایی بیان خواهد شد که به هر چه قوی تر شدن session Id در وب اپلیکیشن ها کمک شایانی خواهند کرد:
طول session id باید به اندازه‌ای باشد که آن را در برابر حملات brute-force که صرفا به منظور حدس زدن و بدست آوردن session id معتبر است، محافظت کند. این افزایش طول باید طوری باشد که مهاجم تا زمانی که session منقضی (expire) نشده، نتواند حتی رنج و محدوده ای که session id ها بر اساس آن تولید میشوند را حدس بزند. بر اساس نوع پردازنده و میزان پهنای باندی که وجود دارد طول session id تعیین میشود. اما توصیه شده است که طول آن کمتر از 50 کاراکتر نباشد.
ممکن است که ایجاد session id ها بصورت ترتیبی باشد و یا آن که عدد شاخصی (index) برای یک یوزر به عنوان session id در نظر گرفته شود که با تغییر کاربر، آن نیز تغییر کند. در این صورت براحتی میتوان session id های معتبر را حدس زد. بنابراین توصیه میشود که ایجاد و تخصیص session id معتبر کاملا بصورت تصادفی و رندوم باشد. در این صورت مقدار بعدی session id را که توسط الگوریتم رندوم تولید میشود را بسختی میتوان حدس زد.
به انتهای session id یک کد اصالت (هویتی) اضافه کنید تا بوسیله آن مطمئن شوید که session id دستکاری نشده است. در این روش درستی کد هویتی در هر درخواستی که سمت سرور میرود، چک خواهد شد. با انجام این کار دستکاری در کوکی ها و session id توسط مهاجم سخت تر خواهد شد. برای نمونه، این کدهای هویتی که میتواند مورد استفاده قرار گیرد شامل مقدار هش شده ی جمع مقادیر session token های معتبر ( که توسط سرور ارسال میشوند)، آدرس IP کلاینت و یک برچسب زمانی کد شده از زمان استارت شدن session، هستند.
بجای آنکه وب اپلیکیشن را مجبور به ایجاد session id های مخصوص به خودش کنید، میتوانید برای این کار از application server ای استفاده کنید که کارش بطور خاص تولید session id است. نمونه های چنین session id هایی، ASPSESSIONID و JSESSIONID هستند. این session id ها عموما session id هایی هستند که نحوه تولیدشان طوری است که کمترین آسیب پذیری را در برابر session hijacking دارند.
با رمز کردن session id ها میتوان امنیت بیشتری را در قبال آن ها فراهم کرد. شما میتوانید کدی را بنویسید که هر session token ای را رمز کند و یا آن که کل session را با استفاده از ssl رمزنگاری کنید.
خوب در بالا روش هایی را که منجر به تولید session id قدرتمند میشدند را بیان کردم. حال میخواهیم از جنبه دیگر قضیه کنع بروز session hijacking شویم. در زیر به روش هایی اشاره شده است که بوسیله آن ها مهاجم را هر چه بیشتر برای اجرای حمله تحت فشار قرار میدهیم. روش های زیر برای تامین بیشتر امنیت وب اپلیکیشن در برابر هایجکرها بیان میشوند:
سرور باید اعتبارسنجی نسبتا دقیقی را از تمام پارامترهای ورودی اش که از طرف کلاینت‌ها میایند، انجام دهد.تمام دیتای موجود در درخواست های GET و POST، باید بطور دقیق مانیتور شوند تا به این وسیله شانس های موفق حملات HTML Injection و XSS کاهش یابد.
یوزرها معمولا از سیستم های کلاینت مشترک استفاده میکنند. بنابراین این نکته مهم است که بعد از بازه زمانی مشخصی از آخرین فعالیت یوزر، session آن بسته و نامعتبر شود. اگر چنین بازه زمانی برای session در نشر گرفته نشود، در واقع به مهاجم برای اجرای حمله Brute force و یا احیانا استفاده از session سرقتی، بازه زمانی نامحدود داده ایم.
راه دیگری که برای محدود کردن بازه زمانی که مهاجم حمله brute force را قبل از منقضی شدن session انجام میدهد، وجود دارد، تولید مجدد session token در بازه های کوتاهی از زمان است. HTTP Server میتواند بطور یکپارچه، توکن ها را منقضی و مجددا تولید کند تا بدین وسیله مهاجم بازه زمانی بسیار کمی را برای اکسپلویت (سوء استفاده) کردن هر توکن معتبر داشته باشد.
با ایجاد تمایز بین بخش های امن و ناامن سایت، میتوانیم برای ورود به قسمت های حساس سایت، احراز هویت مجدد انجام دهیم. نتیجه این میشود که اگر مهاجم کنترل session یوزر را بدست آورده باشد، نمیتواند فعالیت های خاص انجام دهد و یا به بخش های حساس سایت وارد شود (برای مثال در یک اپلیکیشن آنلاین بانکی و یا انتقال پول ). این کار باعث میشود تا لایه امنیتی بیشتری را در مقابل مهاجم ایجاد کنید.
تلاش برای شناسایی brute force session hijacking، قطعا راه خوبی برای محافظت از session ها میباشد. OWASP پیشنهاد میکند از session token هایی که مانند تله های انفجاری هستند، استفاده کنید؛ این توکن ها هرگز تولید نشده اند اما اگر مهاجمی سعی در brute force بازه ای از توکن ها را داشته باشد، به عنوان توکنی معتبر خود را به مهاجم نشان خواهند داد. وقتی که شما با کمک این توکن های قلابی، تلاش برای session hijacking را شناسایی کردید، میتوانید IP سورس را بلاک کرده و یا اکانت مورد نظر را لاک کنید.