اشتباهات رایج در منطق برنامه های تحت وب – قسمت اول

تمام برنامه های کاربردی تحت وب از منطق خاص خود برای عملیاتی کردن وب سایت مربوطه استفاده می کنند. نوشتن کد با استفاده از یک زبان برنامه نویسی در اصل چیزی به جز شکستن پروسه های پیچیده به گام های منطقی کوچک، نیست. البته ترجمه یک عملیات کوچک که برای انسان معنادار است به ترتیبی از دستورات که برای کامپیوتر قابل اجرا باشند، کاری است که نیاز به تجربه و مهارت فراوانی دارد و از طرف دیگر نوشتن کد مذکور به صورتی که امن و قابل اعتماد باشد، نیز کاری به مراتب دشوارتر است. زمانی که تعداد زیادی طراح و برنامه نویس به صورت موازی بر روی یک برنامه کاربردی کار می کنند، به احتمال بسیار زیاد مشکلات امنیتی متعددی بروز خواهند کرد. حتی در ساده ترین برنامه های تحت وب نیز منطق گسترده ای در هر گام برنامه وجود دارد و این امر منجر به ایجاد سطح حمله ای می شود که اغلب از آن چشم پوشی می گردد. بسیاری از تست نفوذها و مرور کدها بر روی آسیب پذیری های اصلی همچون تزریق SQL و یا cross-site-scripting تمرکز می کنند، زیرا آسیب پذیری های مذکور دارای امضای قابل تشخیص بوده و در مورد بردارهای حمله آنها به اندازه کافی تحقیق شده و اطلاعات وجود دارد. در نقطه مقابل، شناسایی آسیب پذیری های موجود در منطق برنامه بسیار سخت است، زیرا هر نمونه آسیب پذیری ممکن است تنها یک بار و برای یک برنامه خاص اتفاق بیفتد که قابل تشخیص توسط ابزارهای اتوماتیک شناسایی آسیب پذیری ها نیست. به همین دلیل به آسیب پذیری های مذکور چندان توجه نشده و این امر موجب می شود علاقه هکرها به شدت جلب این دسته از نقص های امنیتی شود.

در این مقاله در مورد انواع نقص های منطقی که اغلب در برنامه های کاربردی تحت وب وجود دارند، صحبت خواهیم کرد.

 

طبیعت نقص های امنیتی منطقی

 

همان طور که گفته شد نقص های امنیتی در برنامه های کاربردی تحت وب، بسیار متفاوت از یکدیگر هستند. برخی از آنها ممکن است به راحتی قابل تشخیص و برطرف کردن باشند و برخی دیگر ممکن است از انواع تست نفوذها و مرور کدها جان سالم به در برند. این آسیب پذیری ها بر خلاف آسیب پذیری های تزریق SQL  و یا cross-site-scripting  دارای امضاها و رفتارهای مشخص نیستند. تنها ویژگی مشترک در آنها ناقص بودن منطق برنامه است که در اغلب موارد به علت پیش فرض های واضح و یا نهان برنامه نویسان به وجود می آید. در حالت کلی یک برنامه نویس ممکن است استنتاج کند که " اگر "A" اتفاق بیفتد، آنگاه "B" اتفاق می افتد و من باید "C" را انجام بدهم، اما برنامه نویس از خود سوال کاملاً متفاوتی نمی کند که "چه روی خواهد داد اگر "X" اتفاق بیفتد؟" و به این ترتیب نمی تواند سناریویی را که از فرض مورد نظر پیروی نمی کند، مدیریت نماید. در موقعیت های مختلف فرض ناقص می تواند منجر به بروز آسیب پذیری هایی با درجه اهمیت متفاوت شود. در ادامه با چند مثال واقعی در مورد فرض های ناقص بیشتر توضیح می‌دهیم.

 

تغییر رمز عبور

 

در این مثال، یک برنامه کاربردی تحت وب متعلق به یک شرکت مالی، دارای یک تابع تغییر رمز عبور برای کاربران نهایی است. برای تغییر رمز عبور کاربر باید رمز عبور قدیمی خود را وارد کرده و پس از آن رمز عبور جدید را وارد کند. همچنین باید رمز عبور جدید را دوباره تأیید کند تا فعال شود. در این برنامه مدیران می توانند رمز عبور هر کاربر را بدون نیاز به دانستن رمز عبور قدیمی تغییر دهند. این دو برنامه در یک اسکریپت سرور پیاده سازی شده اند.

 

String existingPassword = request.getparameter("existingPassword");

If (null == existingPassword)

{

            Trace("Old password not supplied, must be an administrator");

            Return true;

}

Else

{

            Trace(" verifying user's old password");

            …

 

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

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

 

پروسه های چند مرحله ای

 

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

 

1-      مرور کاتالوگ محصولات و اضافه کردن آیتم های مورد نظر به سبد خرید

2-      بازگشت به سبد خرید و نهایی کردن سفارش

3-      وارد کردن اطلاعات پرداخت

4-      وارد کردن اطلاعات ارسال سفارش

 

در اینجا برنامه نویسان فرض کرده اند که کاربران از ترتیب مورد نظر برای دسترسی به صفحات استفاده می کنند، زیرا صفحات وب سایت آنها را به همین ترتیب هدایت می کند. در نتیجه بنا بر فرض برنامه نویسان سفارشی که به مرحله ارسال رسیده است، مرحله پرداخت را به درستی پشت سر گذاشته است. فرض ناقص در این مثال اینست که برنامه نویسان در نظر نگرفته اند که کاربران هر قسمت از درخواست را کنترل می کنند و بنابراین مهاجم می تواند درخواست را به هر ترتیبی که بخواهد ارسال کند. برای مثال می تواند از مرحله 2 به مرحله 4 برود به این معنی که بدون کامل کردن مرحله پرداخت به مرحله ارسال کالا برسد!

به برنامه نویسان توصیه می شود حالت های مختلف ترتیب گام ها را برای پروسه های چند مرحله ای در نظر بگیرند.

 

پاک کردن رکوردهای ثبت وقایع

 

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

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

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

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

 

 در قسمت بعدی چندین مثال دیگر را در مورد فرض های ناقص در منطق برنامه توضیح می دهیم.