رویکردهای مدیریت ورودی کاربر

منتشر شده در دسته : بلاگ, تست نفوذ وب

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

مدیریت ورودی کاربر

نپذیرفتن ورودی های بد (لیست سیاه)

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

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

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

بسیاری از فیلترای مبتنی بر لیست سیاه را می توان با کمی تغییر ورودی ها دور زد . به عنوان مثال :

  • در صورتیکه کلمه SELECT در لیست سیاه بلاک شده باشد می توانید کلمه SeLeCt را در ورودی تزریق کنید.
  • در صورتیکه عبارت 1=1– بلاک شده باشد می توانید از عبارت 2=2– استفاده کنید.
  • در صورتیکه عبارت (‘alert(‘xss بلاک شده باشد می توانید از عبارت (‘prompt(‘xss استفاده کنید.
  • فیلترهای مبتنی بر لیست سیاه به ویژه آنهایی که در فایروال ها استفاده می شوند نسبت به حملات Null byte آسیب پذیر هستند. به دلیل شیوه متفاوت نگهداری رشته ها درج یک نال بایت 00% قبل از یک عبارت بلاک شده موجب توقف فرایند فیلترینگ ورودی می شود به عنوان مثال :
%00<script>alert(1)</script>

پذیرفتن ورودی های خوب (لیست سفید)

با استفاده از این رویکرد یک لیست سفید از رشته ها یا الگوها یا مجموعه ای از شاخص های شناخته شده و سالم ایجاد می شود. مکانیزم اعتبارسنجی تنها اجازه عبور به داده های موجود در لیست سفید را می دهد و دیگر موارد بلاک خواهند شد. برای مثال قبل از اینکه یک محصول از پایگاه داده درخواست شود , درخواست مربوطه بایستی فقط حاوی کاراکترهای عددی و حروف باشد و تنها شش کاراکتر طول داشته باشد. در برخی موارد این رویکرد امکان پذیر است و در صورت امکان رویکرد بسیار موثری هم خواهد بود. ولی این کار همیشه امکان پذیر نیست . برای مثال در صورت استفاده از این روش برای عضویت و نام کاربری اعضای سایت , ممکن است با مشکل مواجه شوید. نام کاربری برخی کاربران ممکن است حاوی دیگر کاراکترها مثل دش (-) یا نقطه باشد. گرچه این رویکرد به شدت موثر است ولی در همه موقعیت ها امکان استفاده از آن وجود ندارد.

پاکسازی

در برخی شرایط مجبور به قبول کردن ورودی کاربران هستیم و هیچ تضمینی هم بر ایمن بودن این ورودی وجود ندراد. در این شرایط به جای رد کردن ورودی کاربر اپلیکیشن بایستی قبل از پردازش آن را به روش های مختلف پاکسازی کند. مثلا کاراکترهای مخرب بالقوه حذف گردد یا به روش های مختلف همچون انکودینگ یا عبوردادن کاراکترها (Character Escaping)ورودی کاملا پاکسازی شود.

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

مدیریت ایمن داده ها

بسیاری از آسیب پذیری های موجود در اپلیکیشن های وب به دلیل عدم پردازش ایمن داده ها در اپلیکیشن پدیدار می شوند. در برخی موارد اعتبارسنجی ورودی ها مسئله نیست بلکه اطمینان از پردازش ایمن داده ها دارای اهمیت بالایی است. برای مثال می توان با استفاده از کوئری های پارامتر بندی شده مانع حملات تزریق اسکیوال شد . یک مثال دیگر از پردازش غیرایمن داده ها عبور مستقیم ورودی ها به دستورهای سیتم عامل و مفسر می باشد.

بررسی معنایی

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

خوشحال می شویم دیدگاههای خود را در میان بگذارید * فرصت پاسخگویی به سوالات در بلاگ وجود ندارد

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *