Softwaring

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

کلیه تکنیکهای مهندسی اجتماعی مبتنی بر ویژگیهای تصمیم گیری انسان است که تحت عنوان Cognitive Biasesبه معنی الگویی از انحراف در قضاوت که در موقعیتهای خاصی بروز میکند شناخته میشود. این تصمیم گیریهای غلط را گاهی "اشکال در سخت افزار انسان" گویند. جالب اینجاست که به قول Kevin Mitnick که یکی از مشهورترین متقلبین در این زمینه است: "این روش بسیار ساده تر از نفوذ به سیستم کاربران از راه روشهای متداول Hacking است".

برخی از این تکنیکها به شرح زیر است:

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

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

Road Apple: تکنیکی که با سواستفاده از کنجکاوی افراد آنها را قربانی مقاصد خود میسازند. در این روش معمولا یک مدیوم فیزیکی مانند یک CD یا Cool Disk با عنوانی اغوا کننده درج شده روی آن مانند "لیست حقوق مدیر عامل" را در سر راه افراد – مثلا در آسانسور یا راه پله – قرار میدهند. این مدیوم حاوی برنامه ای برای ارسال اطلاعات از روی دستگاه میزبان به هکر بوده که به راحتی توسط قربانی در سیستم شخصی خود قرار داده میشود.

این روزها با گسترش روشهای تراکنش الکترونیکی مالی نظیر Internet Payment، Mobile Payment و ... و عدم گسترش فرهنگ رعایت ملاحظات امنیتی آن انتظار میرود این روشهای سرقت اطلاعات بیش از پیش گسترش پیدا کند (به خاطر بیاوریم که هنگام دریافت پول از خودپردازها همیشه چندین جفت چشم مراقب هستند که خدای ناکرده در  فرآیند دریافت پول از دستگاه دچار اشتباه نشویم!)

I don't think anybody yet has invented a pastime that's as much fun, or keeps you as young, as a good job. (Frederick Hudson Ecker, Chairman, Metropolitan Life)

اشکال تقسیم با ممیز شناور Intel Pentium (1994)

معادله زیر را در ماشین حساب PC خود وارد کنید:

(4195835 / 3145727) * 3145727 - 4195835

در صورتی که پاسخ صفر است پردازنده شما بدون عیب است. در صورتی که هر پاسخ دیگری مشاهده کردید، پردازنده دستگاه شما یک Intel Pentium  قدیمی است که در کلیه پردازنده های سری ساخت پردازنده شما تکرار شده است.

در 30 اکتبر 1994، دکتر Thomas R. Nicely  از کالج Lynchburg (ویرجینیا) در یکی از آزمایشات خود پاسخ غیر منتظره ای در تقسیم معادله مورد آزمایش بر روی Pentium PC خود مشاهده کرد. وی این کشف را بر روی اینترنت قرار داد و پی از آن خیل عظیمی از دیگر افرادی که در محاسبات خود به مشکل مشابه برخورد کرده بودند این مشکل را گزارش کردند. خوشبختانه این مشکل تنها در محاسبات پیچیده­ نمود پیدا می­کرد و بیشتر برنامه های محاسبه ای تجاری نظیر محاسبه مالیات و سود و زیان به چنین مشکلی برخورد نکرده بودند.

چیزی که این داستان را برجسته می سازد نه اشکال یاد شده، بلکه نحوه برخورد Intel با این مشکل بود:

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

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

·         شرکت Intel تحت فشار رسانه ها و افکار عمومی اعلام کرد که پردازنده های دارای مشکل را تعویض می کند اما به شرطی که دارنده آن بتواند ثابت کند که از این اشکال متاثر شده است.

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

در نهایت Intel از نحوه برخورد خود با این مشکل عذرخواهی کرده و متحمل هزینه ای بالغ بر 400 میلیون دلار برای تعویض پردازنده های معیوب خود گردید. در حال حاضر Intel کلیه مشکلات شناخته شده را بر روی وب سایت خود قرار می دهد و به دقت بازخورد مشتریان خود را در گروههای خبری اینترنتی دنبال می کند.

When you reach for the stars, you may not quite get one, but you won't come up with a handful of mud either. (Leo Burnett, Chairman, Leo Burnett Co Inc)

کاوشگر مریخ ناسا 1999 (NASA Mars Polar Lander - 1999)

در 3 دسامبر سال 1999 کاوشگر مریخ که قرار بود روی سطح کره مریخ فرود بیاید ناپدید شد. هیئت بررسی شروع به تحقیق در مورد علت این امر نمود و مشخص شد که علت، ست شدن نادرست یک بیت (!) بوده است. همه اتهامات متوجه تیم تست نرم افزار این کاشف شد.

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

یکی از مهترین مسائل در این فرآیند این است که کاوشگر تشخیص دهد که چه زمانی بر روی سطح مورد نظر فرود آمده تا به موقع موتور فرود خود را خاموش کند. برای این منظور ناسا که در دیگر سفینه های خود از رادارهای گرانقیمتی بهره برده بود تصمیم گرفت که برای کاهش هزینه ها، از مکانیزم ساده تری استفاده کند. به این شکل که در زیر سه پایه فرود کاوشگر سوییچ های تماسی (Contact Switch) تعبیه کردند تا به محض برخورد این سوییچ ها با سطح مریخ، یک بیت ست شده و در اثر قطع شدن سوخت، موتور فرود خاموش شود.

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

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

هر دو تیم به طور مجزا کار خود را بدون نقص انجام داده بود اما اشکال مزبور تنها هنگامی بروز میکرد که دو تیم باهم ترکیب شوند  (Integration Test).

(منبع: Software Testing,Ron Patton, Sams Publishing, 2005)

You can't build a reputation on what you are going to do. (Henry Ford)

The conventional definition of management is getting work done through people, but real management is developing people through work.

(Agha Hasan Abedi, President, Bank of Credit and Commerce International, Luxembourg)

حتما با قانون Pareto آشنا هستید، همان قانون 80/20. به نظر میرسد این قانون در مورد Bottleneck های (ترجمه فارسی پیشنهاد شود لطفا!) نرم افزار نیز صدق می کند. بسیار دیده ام که با تغییر بخش کوچکی از کد، کارایی (Performance) نرم افزار به میزان قابل توجهی افزایش پیدا کرده است. سعی می کنم برخی از تجربیات خود را در این زمینه به اشتراک بگذارم. قطعا بیشتر دوستان و همکاران گرامی - که بیشتر آنها نسبت به من از تجربیات بسیار بالاتری برخوردارند – این مطالب را صرفا یادآوری تلقی می کنند. بیشتر مثال ها و نمونه ها به زبان C# و .Net Framework 2.0  خواهد بود.

کار با رشته ها:

کمتر کد نویسی پیدا میشود که با رشته ها کار نکرده باشد. یکی از کاربردهای رایج استفاده از رشته ها چسباندن متوالی رشته ها به یکدیگر است. به عنوان یک صورت مساله فرض کنید که می خواهیم یک فایل Comma Separated Value (CSV) بسازیم و برای این کار باید تعداد زیادی از رشته های کوچک را با فاصل کاما (,) به هم متصل (Concatenate) کرده و در یک فایل بنویسیم.

راه 1: استفاده از System.String

String s1 = “”;

foreach(string s2 in AnArrayOfStrings)

{

      s1 += s2;

}

راه 2: استفاده از System.Text.StringBuilder

StringBuilder s1 = new StringBuilder();

foreach(string s2 in AnArrayOfStrings)

{

s1.Append(s2);

}

مقایسه راه حل ها: پس از آزمایش راه حل ها به نتایج جالب توجهی خواهید رسید. نتیجه مقایسه دو راه حل برای افزودن 3000 رشته کوچک به یک رشته به شرح زیر است:

استفاده از System.String:    7147 میلی ثانیه

استفاده از System.Text.StringBuilder:    17 میلی ثانیه (!)

علت اختلاف زیاد دو راه حل این است که هنگام استفاده از System.String هر مرتبه که یک رشته به رشته ای الحاق می شود، رشته جدیدی (جدید s1) ایجاد می شود و رشته قبلی (s1 قدیمی) رها (Abandon) می شود و اشاره گر خود را از دست می دهد تا Garbage Collector آنرا پاکسازی نماید. شاید بسیاری از برنامه نویسان تعجب کنند که پس از اجرای تکه کد زیر 4 رشته جدید در حافظه به وجود خواهد آمد:

string s;

s = “a”;

s += “b”;

s += “c”;

s += “d”;

When you row another person across the river, you get there yourself. (Fortune Cookie)

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

چندی پیش کتابی مطالعه می کردم به نام The ART of SOFTWARE TESTING نوشته Glenford J. Myers . نسخه اول این کتاب در سال 1979 یعنی حدود 30 سال پیش - همسن خودم(!) نوشته شده که در سال 2004 توسط چند نویسنده دیگر با افزودن مطالبی چاپ مجدد شده است. به نقل از نویسندگان اخیر بسیاری از مطالب آن بدون هیچ تغییری منعکس شده و تنها بخش کوچکی به آن اضافه شده است. در ابتدا و پیش از شروع مطالعه کتاب تصور کردم که احتمالا به دلیل گذشت این همه سال و منقضی شدن مطالب، به سرعت کتاب را کنار خواهم گذاشت اما هرچه جلوتر میرفتم بیشتر خوشحال میشدم که میتوان کتابی در حوزه نرم افزار نگاشت که پس از 30 سال بسیاری از مطالب آن هنوز دارای اعتبار بوده و اتفاقا تازگی داشته باشد.

 مطالعه این کتاب را به همکارانی که به مباحث آزمون نرم افزار و همچنین جاودانگی(!) علاقه دارند توصیه میکنم.