دوره SEC542 – بخش شانزدهم

دوره آموزشی SEC542

در این بخش از دوره SEC542 شما با مبحث Session در وب آشنا خواهید شد و نحوه استفاده و کاربرد آن در وب را فرا خواهید گرفت.

Stateless as a Way of Life

HTTP یک پروتکل stateless می‌باشد. این بدین معناست که اپلیکیشن باید متدی جهت شناسایی درخواست‌ها به عنوان قسمتی از یک session مشخص داشته باشد.
سرورها نیز باید راهی برای شناسایی درخواست‌هایی که مربوط به یک session هستند، داشته باشند. در غیر اینصورت خیلی از اپلیکیشن‌ها قادر نخواهند بود اطلاعات کاربردی را پیگیری نمایند.

بیشتر زبان‌های برنامه نویسی تحت وب مکانیزم مدیریت session را درون خود دارند. این مکانیزم‌ها درواقع روش‌های پیشنهادی جهت نگهداری وضعیت session ها می‌باشند زیرا بارها تست شده و اکثرا خطاهایشان برطرف شده‌اند.

زمانی که برنامه نویسان، سیستم مدیریت session خود را تولید می‌کنند، اغلب چیزی را فراموش می‌کنند. در این حالت نفوذگر این فرصت را پیدا می‌کند تا کارکرد اپلیکیشن را بر هم زند.
روش‌های محبوب شامل استفاده از کوکی‌ها، پارامترهای URL و فیلدهای مخفی در صفحات می‌باشند.

Session Tracking

برای ردیابی و track کردن session ها، یک توکن، شناسه عددی یا هر اطلاعات منحصر به فرد دیگری بین کلاینت و سرور رد و بدل می‌شود. این اطلاعات در سمت کلاینت بر روی مرورگر ذخیره شده و با درخواست‌ها به سرور ارسال می‌شود.

معمولا اپلیکیشن‌ها تنها از یک شناسه به عنوان توکن، Session ID یا دیتای عددی استفاده می‌کنند تا بتوانند session کاربران را دنبال کنند. در عین حال برنامه نویس (توسعه دهنده) می‌تواند از هر اطلاعاتی که دوست دارد به عنوان توکن استفاده کند. بطور مثال بعضی از برنامه نویسان همه اطلاعات مورد نیاز خود را به کاربر فرستاده و دوباره به سرور برمی‌گردانند. مشخص است که آن‌ها اطمینان دارند که کاربر اطلاعات دریافتی را بدون تغییر به سرور برمی‌گرداند.(افکار باطل!)

انواع Session : Client-Side vs. Server-Side

همه مکانیزم‌هایی که برای انتقال وضعیت session استفاده می‌شوند، یکی از این دو نوع session را پشتیبانی می‌کنند:

Client-Side
Server-Side

Client-Side (سمت کلاینت):

در session های سمت کلاینت، اپلیکیشن تمام اطلاعات session را به کاربر فرستاده و کاربر آن را بدون تغییر به سرور بازمی‌گرداند. این روش سربار کمتری روی سرور داشته و این امکان را فراهم می‌کند تا اپلیکیشن بین چندین سرور load-balanced شود بدون آنکه تنظیمات خاصی برای پشتیبانی از session ها در سرورهای مختلف صورت گیرد.

Session های سمت کلاینت نشانه خوبی برای مهاجمین است زیرا سرور کاملا به کلاینت اعتماد دارد و با سوء‌استفاده از این اعتماد، مهاجم می‌تواند مقادیر session را دستکاری کند.

Server-Side (سمت سرور):

در session های سمت سرور، همه اطلاعات session بر روی سرور ذخیره می‌گردد و یک session ID بین کلاینت و سرور رد و بدل می‌شود. گاهاً جهت پشتیبانی GUI یا دوستانه‌تر بودن اپلیکیشن، سرور باز هم اطلاعات session را به کلاینت ارسال می‌کند.

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

Popular Tracking

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

معمولا یک توکن بین کلاینت و سرور مبادله می‌شود. سرور از این توکن جهت map کردن اطلاعات session ذخیره شده بر روی خود، استفاده می‌نماید.
در زیر متدهای محبوب جهت ردیابی وضعیت session آورده شده است:

  • Cookies
  • پارامترهای URI
  • فیلدهای مخفی در فرم‌ها

ما به عنوان تست کننده باید این توکن‌ها را ارزیابی کنیم تا مشکلات و یا قابل پیش‌بینی بودن آن‌ها را بیابیم.

Cookies

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

کوکی‌ها در هدر HTTP ارسال شده و می‌توانند مشخصه “Secure” داشته باشند. این مشخصه به مرورگر اعلام می‌کند که کوکی را فقط می‌تواند در ارتباطات HTTPS ارسال کند.(از فاش شدن کوکی جلوگیری می‌کند.) همچنین می‌توان زمان نگهداری کوکی‌ها را مشخص نمود. لازم به ذکر است که اگر کوکی بدون زمان ذخیره شود، با بسته شدن مرورگر، کوکی ناپدید می‌شود.

هر دامنه معمولا می‌تواند تا 50 کوکی داشته باشد و هر کوکی سایزی کمتر 4 KB دارد. مثلا:

Set-Cookie: USERID=zaphod; expires=Fri, 27-Feb-2012; path=/; domain=.sec542.org

پارامترهای URI

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

http://www.sans.org/index.php?sessionId=124534

در این روش پارامترهای متعدد با علامت “&” از هم جدا می‌شوند. زمانی که کاربر بر روی لینک کلیک می‌کند، مرورگر دیتای موجود در URI را در یک درخواست با متد HTTP GET به سرور بازمی‌گرداند.

Hidden Form Fields

در یک اپلیکیشن، فرم‌ها برای دریافت ورودی از کاربر استفاده می‌شوند. فرم‌ها یا از قبل طراحی شده و یا توسط سرور تولید شده و در پاسخ‌های HTTP به مرورگر کاربر برگردانده می‌شوند. این فرم‌ها می‌توانند دارای چندین فیلد پنهان باشند. فیلدهای پنهان برای کاربر نمایش داده نمی‌شوند و حاوی اطلاعاتی هستند که باید در درخواست‌ها به سرور ارسال شوند. در ادامه کد مربوط به یک فیلد پنهان نوشته شده است:

Hidden Form Fields

معمولا ما شاهد آن هستیم که اطلاعات قابل توجهی در فیلدهای پنهان فرم‌ها ذخیره شده‌اند. این مصداق اعتماد برنامه نویس به تمامی کاربران اپلیکیشن است.

مطالب این بخش توسط سرکار خانم فهیمه رضایی تهیه شده است.

درباره نویسنده: احسان نیک آور

ممکن است دوست داشته باشید