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

تمام برنامه های کاربردی تحت وب از منطق خاص خود برای عملیاتی کردن وب سایت مربوطه استفاده می کنند. نوشتن کد با استفاده از یک زبان برنامه نویسی در اصل چیزی به جز شکستن پروسه های پیچیده به گام های منطقی کوچک، نیست. البته ترجمه یک عملیات کوچک که برای انسان معنادار است به ترتیبی از دستورات که برای کامپیوتر قابل اجرا باشند، کاری است که نیاز به تجربه و مهارت فراوانی دارد و از طرف دیگر نوشتن کد مذکور به صورتی که امن و قابل اعتماد باشد، نیز کاری به مراتب دشوارتر است. زمانی که تعداد زیادی طراح و برنامه نویس به صورت موازی بر روی یک برنامه کاربردی کار می کنند، به احتمال بسیار زیاد مشکلات امنیتی متعددی بروز خواهند کرد. حتی در ساده ترین برنامه های تحت وب نیز منطق گسترده ای در هر گام برنامه وجود دارد و این امر منجر به ایجاد سطح حمله ای می شود که اغلب از آن چشم پوشی می گردد. بسیاری از تست نفوذها و مرور کدها بر روی آسیب پذیری های اصلی همچون تزریق 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) در اختیار وی قرار می گیرد.  اشتباه آنها در این بود که از یک متغیر استاتیک برای نگهداری این کد استفاده کرده بودند و در مواقع نادری به علت استاتیک بودن متغیر، همان کدی که به شخص بعدی تخصیص داده شده بود به فرد قبلی نیز انتقال پیدا می کرد و وی می توانست به هر دو حساب به صورت همزمان دسترسی پیدا کند!

مدیریت رخداد در شش مرحله- مقدمه

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

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

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

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

برنامه نویسی امن با زبان C –قوانین مدیریت حافظه

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

از استانداردهای معروف در این زمینه می توان به استانداردCERT برای کدنویسی امن اشاره کرد که یک سری از قوانین و پیشنهادات را برای کد نویسی امن با زبان های برنامه نویسی C، C++ و جاوا ارائه می دهد. هدف از این قوانین و پیشنهادات، حذف عادت های کدنویسی ناامن و رفتارهای تعریف نشده است که منجر به آسیب پذیری های قابل سوءاستفاده می شود. به کارگیری استانداردهای مذکور منجر به تولید سیستم های با کیفیت بالاتر می شود که در برابر حملات بالقوه، پایدارتر و مقاوم تر هستند.

در مقاله "آشنایی با استاندارد CERT برای برنامه نویسی امن"، کلیات استاندارد CERT در زمینه مزبور را توضیح دادیم و در سری مقاله های برنامه نویسی امن به زبان C به صورت تخصصی تر شیوه برنامه نویسی امن با این زبان را مورد بررسی قرار می دهیم. قابل ذکر است که در این استاندارد 89 قانون و 134 پیشنهاد برای برنامه نویسی امن با زبان C ارائه شده است که در این سری مقالات، مهمترین آنها را که در سطح یک قرار دارند، شرح خواهیم داد. برای کسب اطلاعات بیشتر در مورد سطح بندی قوانین و پیشنهادات به مقاله "آشنایی با استاندارد CERT برای برنامه نویسی امن" مراجعه فرمایید. در مقاله قبلی در مورد پیشنهادات سطح اول ارائه شده در مورد مدیریت حافظه صحبت کردیم و در مقاله حاضر به قوانین ارائه شده سطح اول در مورد مدیریت حافظه خواهیم پرداخت.

گامهای راه اندازی و به کارگیری یک Honeypot

پیش از این در پنج مقاله «Honeypot چیست؟»، «انواع Honeypot»، «کاربردهای Honeypot ها»، «مکانیزم های جمع آوری اطلاعات در Honeypot ها» و «مکانیزم های تحلیل اطلاعات در Honeypot ها» به معرفی اجمالی Honeypot ها، کاربردهای این سیستم ها و روش های جمع آوری وتحلیل اطلاعات در این سیستم ها پرداختیم. در این مقاله گام های راه اندازی و به کار گیری Honeypot ها را مورد بررسی قرار خواهیم داد.

به کار گیری یک Honeypot فیزیکی می تواند بسیار زمان بر و گران تمام شود، چرا که سیستم عامل های مختلف ممکن است به سخت افزارهای خاصی نیاز داشته باشند. به علاوه، هر Honeypot به سیستم فیزیکی خاص خود و حجم زیادی از تنظیمات پیکربندی احتیاج دارد. در ادامه، گام های عمومی برای به کار گیری یک Honeypot اولیه را بیان می کنیم. این گام ها، تا حدی به انواع دستگاه های شبکه، ابزارها و برنامه های نرم‌افزاری که در اختیار ما است، بستگی دارد.

مکانیزمهای تحلیل اطلاعات در Honeypot ها

پیش از این در چهار مقاله «Honeypot چیست؟»، «انواع Honeypot»، «کاربردهای Honeypot ها» و «مکانیزم های جمع آوری اطلاعات در Honeypot ها» به معرفی اجمالی Honeypot ها، کاربردهای این سیستم ها و روش های جمع آوری اطلاعات در این سیستم ها پرداختیم. در این مقاله مکانیزم های مختلف تحلیل اطلاعات در Honeypot ها را مورد بررسی قرار خواهیم داد.

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

مکانیزمهای جمع آوری اطلاعات در Honeypot ها

پیش از این در سه مقاله «Honeypot چیست؟»، «انواع Honeypot» و «کاربردهای Honeypot ها»، به معرفی اجمالی Honeypot ها و کاربردهای این سیستم ها پرداختیم. در این مقاله مکانیزم های مختلف جمع آوری اطلاعات در Honeypot ها را مورد بررسی قرار خواهیم داد.

جمع آوری اطلاعات در سیستمی که صرفا به این منظور طراحی شده است که مورد سوء استفاده مهاجمان و هکرها قرار گیرد، باید به صورتی باشد که علاوه بر اینکه تحلیل جدی فعالیت ها را ممکن می سازد، در عین حال مزاحم کار هکرها نیز نگردد. در شبکه هایی که از Honeypot به منظور تشخیص و تحلیل حملات و تهدیدات استفاده می کنند، داده‌ها می توانند در سه نقطه مختلف جمع آوری شوند که هریک مزایا و معایب خود را داراست. بر این اساس، سه مکانیزم مختلف برای جمع آوری اطلاعات در Honeypot ها تعریف می شود:

 

1- مبتنی بر میزبان 

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

 

الگوریتم های رمزنگاری با کلید متقارن

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