آبجی
14th February 2010, 01:43 AM
یکی از قدیمی ترین حملاتی که به برنامه های وب صورت می گیره، Session Hijacking (سرقت Session) هست.
برای آشنایی با این نوع حمله بهتره که کمی در مورد نحوه ی هندل کردن Session ها در ASP.NET صحبت کنیم.
Session برای نگهداری داده هایی به کار میره که برای هر کاربر منحصر به فرد هستند. مثلا نمایش نام کاربر پس از لوگین، در تمامی صفحات سایت.
Session در حافظه ی سرور نگهداری میشه. ASP.NET برای اینکه بتونه تشخیص بده که هر Session متعلق به کدام کاربر هست، مشخصه ای یکتا برای هر Session ایجاد می کنه و این مشخصه رو در یک کوکی با نام ASP.NET_SessionID قرار میده. با ایجاد هر درخواست به سرور، ASP.NET مشخصه ی موجود در این کوکی رو بررسی می کنه و از این طریق متوجه میشه که کدام Session در حافظه ی سرور متعلق به کاربر هست.
به این مشخصه ی یکتا Session ID گفته میشه.
پر واضح هست که اگر کوکی ها در مرورگر کاربر غیر فعال باشند، استفاده از Session عملا کاربردی نداره. به طور خلاصه اگر فردی بتونه این کوکی رو به سرقت ببره، به راحتی می تونه خودش رو صاحب Session شما معرفی کنه.
میزان خطری که Session Hijacking در پی داره به نوع اطلاعاتی که در اون هست و نحوه ی استفاده ی برنامه نویس از Session بستگی داره.
به عنوان مثال، در حالتی که از Session تنها برای نگهداری نام کاربری استفاده میشه، سرقت Session سودی برای فرد مهاجم نداره چون تنها چیزی که ممکنه نصیب اون بشه (که البته باز هم بستگی به نحوه ی برخورد برنامه نویس با Session داره) نام کاربری هست!
اما اگر مثلا شماره ی حساب بانکی یا سطح دسترسی کاربر در Session ذخیره میشه با خطری جدی مواجه هستید.
Session Hijacking معمولا به دو طریق انجام می گیره:
۱) حدس زدن Session ID
2) سرقت کوکی حاوی Session ID
حدس زدن Session ID
این مورد به ندرت اتفاق می افته چون ASP.NET به طور خودکار این ID رو تولید می کنه و اعدادی که تولید میشن ۱۲۰ بیتی و کاملا راندوم هستند. البته میشه تولید این ID ها رو خودتون با استفاده از کلاس SessionIDManager بر عهده بگیرید اما این کار اصلا پیشنهاد نمیشه. فرضا اگر روال شما برای اختصاص SessionID یک عدد تصاعدی مثل فیلدهای از نوع AutoNumber در SQL Sever باشه، فرد مهاجم می تونه با بررسی چند باره ی محتویات کوکی ذکر شده، از این روش مطلع بشه.
سرقت کوکی حاوی Session ID
در مورد سرقت کوکی در مقاله ی قبلی توضیح دادم. XSS می تونه یکی از روش هایی باشه که منجر به سرقت کوکی ها میشه.
راهکار مقابله به Session Hijacking
راهکاری که میشه استفاده کرد، “منحصر به فرد تَر کردن” Session ID هست.
بدین شکل که برخی مشخصه های کاربر همانند IP و User Agent رو همراه با یک کلید رمز به یک الگوریتم Hash همانند HMACSHA1 که یک کلید رو برای رمزنگاری می پذیره داد و رشته ی رمزنگاری شده رو به انتهای SessionID اضافه کرد.
فرایند فوق رو به راحتی میشه از طریق یک HttpModule پیاده سازی کرد.
روال EndRequest مکان خوبی برای الصاق مشخصه ی به دست آمده به انتهای SessionID هست.
روال BeginRequest نیز می تونه برای بررسی صحت این مشخصه استفاده بشه.
کدنویسی بر عهده ی خودتون
نتیجه گیری پایانی: هر چند که هیچ روشی همواره امنیت رو به طور صد در صد تضمین نمی کنه، اما امنیت رو باید یک وضعیت نسبی در نظر گرفت. مجموعه تلاش هایی که انجام میدیم تا راه نفوذ به برنامه رو برای فرد مهاجم سخت تر کنیم.
برای آشنایی با این نوع حمله بهتره که کمی در مورد نحوه ی هندل کردن Session ها در ASP.NET صحبت کنیم.
Session برای نگهداری داده هایی به کار میره که برای هر کاربر منحصر به فرد هستند. مثلا نمایش نام کاربر پس از لوگین، در تمامی صفحات سایت.
Session در حافظه ی سرور نگهداری میشه. ASP.NET برای اینکه بتونه تشخیص بده که هر Session متعلق به کدام کاربر هست، مشخصه ای یکتا برای هر Session ایجاد می کنه و این مشخصه رو در یک کوکی با نام ASP.NET_SessionID قرار میده. با ایجاد هر درخواست به سرور، ASP.NET مشخصه ی موجود در این کوکی رو بررسی می کنه و از این طریق متوجه میشه که کدام Session در حافظه ی سرور متعلق به کاربر هست.
به این مشخصه ی یکتا Session ID گفته میشه.
پر واضح هست که اگر کوکی ها در مرورگر کاربر غیر فعال باشند، استفاده از Session عملا کاربردی نداره. به طور خلاصه اگر فردی بتونه این کوکی رو به سرقت ببره، به راحتی می تونه خودش رو صاحب Session شما معرفی کنه.
میزان خطری که Session Hijacking در پی داره به نوع اطلاعاتی که در اون هست و نحوه ی استفاده ی برنامه نویس از Session بستگی داره.
به عنوان مثال، در حالتی که از Session تنها برای نگهداری نام کاربری استفاده میشه، سرقت Session سودی برای فرد مهاجم نداره چون تنها چیزی که ممکنه نصیب اون بشه (که البته باز هم بستگی به نحوه ی برخورد برنامه نویس با Session داره) نام کاربری هست!
اما اگر مثلا شماره ی حساب بانکی یا سطح دسترسی کاربر در Session ذخیره میشه با خطری جدی مواجه هستید.
Session Hijacking معمولا به دو طریق انجام می گیره:
۱) حدس زدن Session ID
2) سرقت کوکی حاوی Session ID
حدس زدن Session ID
این مورد به ندرت اتفاق می افته چون ASP.NET به طور خودکار این ID رو تولید می کنه و اعدادی که تولید میشن ۱۲۰ بیتی و کاملا راندوم هستند. البته میشه تولید این ID ها رو خودتون با استفاده از کلاس SessionIDManager بر عهده بگیرید اما این کار اصلا پیشنهاد نمیشه. فرضا اگر روال شما برای اختصاص SessionID یک عدد تصاعدی مثل فیلدهای از نوع AutoNumber در SQL Sever باشه، فرد مهاجم می تونه با بررسی چند باره ی محتویات کوکی ذکر شده، از این روش مطلع بشه.
سرقت کوکی حاوی Session ID
در مورد سرقت کوکی در مقاله ی قبلی توضیح دادم. XSS می تونه یکی از روش هایی باشه که منجر به سرقت کوکی ها میشه.
راهکار مقابله به Session Hijacking
راهکاری که میشه استفاده کرد، “منحصر به فرد تَر کردن” Session ID هست.
بدین شکل که برخی مشخصه های کاربر همانند IP و User Agent رو همراه با یک کلید رمز به یک الگوریتم Hash همانند HMACSHA1 که یک کلید رو برای رمزنگاری می پذیره داد و رشته ی رمزنگاری شده رو به انتهای SessionID اضافه کرد.
فرایند فوق رو به راحتی میشه از طریق یک HttpModule پیاده سازی کرد.
روال EndRequest مکان خوبی برای الصاق مشخصه ی به دست آمده به انتهای SessionID هست.
روال BeginRequest نیز می تونه برای بررسی صحت این مشخصه استفاده بشه.
کدنویسی بر عهده ی خودتون
نتیجه گیری پایانی: هر چند که هیچ روشی همواره امنیت رو به طور صد در صد تضمین نمی کنه، اما امنیت رو باید یک وضعیت نسبی در نظر گرفت. مجموعه تلاش هایی که انجام میدیم تا راه نفوذ به برنامه رو برای فرد مهاجم سخت تر کنیم.