خلاصه ماجرا: چند ساعت است در وب فارسی، توییتر و فیسبوک مطلبی می چرخه در مورد اینکه آدم ها می تونن بدون لاگین کردن در بانک ملت و فقط با رفتن به آدرس یک صفحه و عوض کردن عدد پاس شده در آدرس بار به شکل SaleOrderId=1333683 به واریزی های افراد مختلف به حساب بعضی سازمان ها دستریس داشته باشن. مطلب زیر نگاهی است به راه حل های فنی حل این مساله.
بانک ها قراره یکی از جاهایی باشن که بالاترین سطح امنیت رو دارن اما سوتی های مداومی که از بانک ها می بینیم، این مساله رو کاملا زیر سوال برده. سوتی جدید متعلق به بانک ملت است و اجازه می ده هر کسی که به اینترنت دسترسی داره بدون کوچکترین قدم فنی یا سطحی ترین دانش مرتبط با امنیت، بتونه تراکنش های افراد دیگه رو ببینه!
این از کجا می یاد؟ از دو جا: آگاهی بسیار کم بانک ها در مورد امنیت و آگاهی بسیار کم برنامه نویس هایی که این چیزها رو نوشتن. نکته ای که جالبه کم تقصیرترین فرد در این وسط، نویسنده کد است و مقصرترین آدم کسی که پروژه رو به این آدم داده. این کسی که نوشتن چنین کد حساسی رو به چنین برنامه نویس ناآگاهی از مبانی امنیتی داده اما سوال سختیه. منطقا یک زنجیره بزرگ باید منجر به این سوتی های عظیم بشن.
مشاور پروژه
در قدم اول باید مشاور پروژه می تونست در دقیقه دوم تست این برنامه، بگه که این برنامه این مشکل عظیم رو داره. شاید واقعا این پروژه مشاور نداشته و اگر مشاوری داشته که اینجا رو دیده ولی از روش رد شده، منطقا فقط یک آدمی است که شغلش حقوق گرفتن برای پر کردن عنوان «مشاور» است. این آدم اگر پروژه رو دیده و اوکی کرده، نباید مشاور باشه.
مشاور فنی بانک
تقریبا مثل بالایی ولی حادتر. اگر بانک مشاور مرتبطی داره که این کد و نتیجه اش رو دیده و تشخیص نداده که اینجاش این مشکل حاد رو داره، باید همینجا اخراج بشه و بانک باید یک مشاور دیگه بگیره. متاسفم که در مورد یک همکار مجبورم این رو بگم ولی واقعا نقش مشاور فنی اینه که چیزهایی بسیار عمیقتر رو تشخیص بده. تشخیص چنین باگی در حدی مقدماتی است که حتی گروهی از مشتری های بانک هم باید بتونن تشخیصش بدن. اگر بانک اصولا مشاور فنی نداره، بهتره زودتر یکی بگیره.
مدیر پروژه
در مورد مدیرپروژه همیشه به سختی می شه نظر داد. آدمی است که از بالاتر بهش می گن باید محصول فلان رو در تاریخ فلان تحویل بدی و منابعش هم مشخصه. اگر الان شغل من تحویل یک سکوی نفتی در تاریخ ۲۹ اسفند ۱۳۹۶ باشه و یک تیم هم داشته باشم که کار رو درست بلد نباشن، ممکنه هر سوتی ای از من در بیاد (: در سطحی بالاتر می شه گفت که باید استعفا بدم ولی خب چند نفر داریم که بتونن راحت از شغلشون استعفا بدن. به نظر من مدیر پروژه اگر دفاع خوبی داشته باشه، تقصیر چندانی نداره.
تیم/شرکتی که کار رو قبول کرده
اینجا هم سخته. اگر با یک شرکت بیرونی طرف هستیم، خب اون شرکت باز شده که سود کنه. منطقا باید بانک کارش رو به یک شرکت غیرحرفه ای نده و شرکت ها نباید کار رو بگیرن ولی کیه که از پول بدش بیاد؟ به نظرم خود شرکت ها اگر از مفاد قرارداد عدول نکرده باشن چندان مقصر نیستن. الان یکی بیاد به من بگه یک میلیارد بهت می دیم برامون یک اسکچ از یوزراینترفیس یک سایت فروش کفش ورنی بزن، معلومه که قبول می کنم (: آبروم رو می برم ولی به پولش می ارزه و اگر طرف راضی است، منم راضی هستم.
اگر هم کار با کارمندها و تیمهای داخلی بوده که خب حرجی نیست. یکی رو استخدام کردین و گفتین فلان کار رو بکن. احتمالا از دید خودش تلاش کافی هم کرده و تنها حالتی که می شه ازش ناراضی بود اینه که براش دوره آموزشی و فرصت یادگیری فراهم کرده باشیم ولی بازم پیچونده باشه؛ معمولا هم اینطوری نیست.
گروهی که کار رو به این گروه دادن
اینها – در کنار مشاورها و بررسی کننده های کیفی – احتمالا بزرگترین مقصر هستن. نتیجه کار کاملا نشون می ده که نویسنده برنامه ها دید باز نسبت به جهان نداشته و گروه برنامه نویسیای بوده که تجربی و بدون بررسی نمونههای پذیرفته شده جهانی کار کرده و اصولا فکر نمی کرده در دنیای واقعی چه چیزهایی در انتظارش است. کسانی که چنین کاری رو به این گروه دادن احتمالا بیشترین تقصیر رو دارن. حتی اگر مدعی بشن که نمی دونستن این شرکت خوب نیست، باید پرسید که چرا از مشاور استفاده نکردن. اشتباه همیشه پیش می یاد ولی مهمه این گروه روشی رو پیش بگیرن که جلوی تکرار این مساله گرفته بشه.
سیستم نرم افزاری کشور
ما چیزی داریم به اسم شورای انفورماتیک و فکر کنم حتی به شرکت ها رتبه می ده و اینکارها. این در دنیای امروز تا حد زیادی ناکارا است. کاملا می شه تصور کرد که این برنامه رو یکی از شرکت های با رتبه بالا و مشهور نوشته باشن. امروزه تعداد مهندس و تعداد کارمند نشون نمی دن که یک برنامه خوب تولید خواهد شد.
حالا چیکار کنیم؟
اگر کاره ای در بانک ملت هستین، سریعا این بخش از سیستم رو بیارین پایین و بنویسین به خاطر تعمیرات تعطیله. بعد یک تسک فورس سریع با یک اتاق جنگ درست کنین (اتاقی که آدم ها می رن توش و تا وقتی مشکل حل نشده بیرون نمی یان و می تونن هر کسی که لازمه رو هم به اتاق اضافه کنن) و با دو تا مشاور خوب که بهشون حقوق خوبی می دین برنامه رو بررسی کنید. وقتی برنامه ای چنین مشکلات حادی داره اصلا بعید نیست مشکلات دیگه ای هم داشته باشه که عمیق تر از تغییر یک یو آر ال باشن و تاثیراتی بسیار بزرگتر از افشای اطلاعات شخصی آدم ها بذارن. همزمان با اتاق جنگ لازمه که یک پروژه مستقل تعریف بشه برای بررسی مستقل کد و انجام انواع تست های نفوذ. بانک شما همیشه در این مدت نماد بانکی بوده که سعی کرده تبلیغاتی بالاتر از سواد بصری جامعه داشته باشه و حالا لازمه سراغ سطح امنیتی ای بالاتر از متوسط جامعه هم برین. بعد هم باید بررسی کنین که در چه پروسه ای این برنامه به این گروه برنامه نویسی رسیده و اصلاحش کنین. ریلکس باشین و برای آینده برنامه بریزین (:
اگر هم برنامه نویس مستقل هستین، هر برنامه ای که اطرافتون می بینین رو با دقت نگاه کنین. یو آر الش چطوریه؟ آیا تعداد ریکوئست در دقیقه بهش کنترل شده است؟ در مورد استانداردهای توسعه نرم افزار بخونین و فریم ورک های موجود رو بررسی کنین. حواستون باشه که برنامه نویسی چیزی بسیار بسیار گسترده تر از نوشتن کد است. در واقع کد نویسی (Coder) سطح ورودی دنیای برنامه نویسی است و اگر می خواین توی این دنیا پیش برین، چیزی بسیار مفصلتر از دستور زبان مورد نیازه. سعی می کنم یک ویدئوکست با یک متخصص در این زمینه درست کنم. برم بهش زنگ بزنم!
به نظرتون از چه نقش هایی دیگه می تونیم حرف بزنیم؟ ناظر کیفی؟ کنترل کیفیت؟ تست امنیت؟