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

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

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

 

محدودیت های عددی

 

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

 

Bool CAuthCheck::RequiresApproval(int amount)

{

            If (amount <= m_apprTreshold)

                        Return false;

            Else return true;

}

 

برنامه نویسان در اینجا فرض کرده اند که با این برنامه هیچ کس نمی تواند مبالغی بیش از حد تعیین شده را بدون اجازه مدیر خود جابجا کند. فرض برنامه نویسان در اینجا ناقص است چون در نظر نگرفته اند که ممکن است فردی سعی کند تا مبالغ منفی را جابجا کند. در این صورت فرد نیازی به تأیید مدیر خود ندارد زیرا هر مقدار منفی کمتر از Trshold است. جالب است که در همین برنامه تابع مربوط به نقل و انتقالات بانکی مبالغ منفی را پذیرفته و آن را به عنوان انتقال معکوس در نظر می گیرد. برای مثال در صورتی که قرار است مبلغ X از حساب A به حساب B منتقل شود، می توان مبلغ –X را از حساب B به A منتقل کرد. با این حساب کاربر خرابکار می تواند هر مقداری را که بخواهد در قالب عددی منفی در بین حساب ها جابجا کند!

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

 

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

 

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

 

تقلب در تخفیف

 

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

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

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

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

 

شرایط رقابتی در ورود به سیستم

 

این مثال مربوط به یک برنامه کاربردی تحت وب متعلق به یک بانک است. در این برنامه راهکارهای متعددی برای ورود و تأیید هویت افراد دیده شده است. از دیدگاه طراحان و برنامه نویسان این برنامه، افراد خرابکار به هیچ وجه نمی توانند وارد این سیستم شوند. با وجودی که آنها تمام نکات امنیتی و راهکارهای موجود برای تأیید هویت امن را رعایت کرده بودند، اما گاهی اوقات مواجه با اتفاقی عجیب می شدند؛ زمانی که کاربری وارد سیستم می شد می توانست به کنترل کامل حساب کاربری دیگری نیز دسترسی پیدا کند. ظاهراً این اتفاق به صورت تصادفی رخ می داد و حتی دسترسی به حساب کاربران دیگر نیز به صورت تصادفی بود. بعد از تحقیقات بسیار مشخص شد، زمانی که دو کاربر به صورت تقریباً همزمان وارد سیستم می شوند، کاربری که اول وارد شده است می تواند به حساب کاربری فردی که بلافاصله بعد از او وارد سیستم شده است دسترسی پیدا کند. در بررسی کد برنامه معلوم گشت که برنامه برای هر فرد که وارد سیستم می شود بعد از گذشتن از مراحل ورود به سیستم (login) یک کد تأیید هویت ایجاد می کند که با استفاده از آن کنترل حساب کاربری تا زمان خروج از سیستم (logout) در اختیار وی قرار می گیرد.  اشتباه آنها در این بود که از یک متغیر استاتیک برای نگهداری این کد استفاده کرده بودند و در مواقع نادری به علت استاتیک بودن متغیر، همان کدی که به شخص بعدی تخصیص داده شده بود به فرد قبلی نیز انتقال پیدا می کرد و وی می توانست به هر دو حساب به صورت همزمان دسترسی پیدا کند!

 

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