قرار بر این شد که سایتی را که قبلا با ابزارهای مایکروسافتی توسعه پیدا کرده بود و مورد حمله‌ی SQL Injection بود، بازطراحی و بازنویسی کنیم. نخستین مشکل این بود که سایت از نظر اندازه جزء سایت‌های متوسط به شمار می‌رود و بازطراحی آن به زمان قابل توجهی نیازمند بود. بنابراین اولویت نخست این بود که سایت فعلی به شکلی قابل قبول برگردد و جلوی حملات آتی هم گرفته شود تا مقداری فرصت برای کار جدید فراهم شود.
در این مسیر با مشکلات متعددی مواجه شدیم که پیدا کردن و رفع کردن آن حاوی تجربیات خوبی بود.
مشکل اول: عدم دسترسی به توسعه‌دهندگان اصلی و کد بودن سورس سایت
به دلیل اینکه سورس سایت کدشده بود، امکان پیدا کردن و مسدود کردن اشکال موجود تقریبا ناممکن بود. بنابراین تلاش شد، با روش‌های مختلف امکان دسترسی به صفحات حاوی فرم مسدود شود که آن هم بی‌نتیجه بود.
نخستین تجربه: هنگامی که سایتی جدید سفارش می‌دهید، در اختیار داشتن سورس سایت، ممکن است در آینده موضوعی حیاتی به شمار برود.
مشکل دوم: دسترسی به بانک اطلاعاتی
شرکتی که خدمات میزبانی سایت را بر عهده داشت، سیستم فنی و پاسخگویی چندان شناخته شده‌ای را در اختیار قرار نمی‌داد. پیدا کردن مسیر ارتباطی برای اتصال به پایگاه داده SQL Server حدود ۲ روز زمان را از بین برد.
تجربه‌ی دوم: انتخاب صحیح ابزارهای توسعه، سیستم میزبانی وب و نگهداری اطلاعات مهم در این موارد، موضوعی مهم است.
مشکل سوم: پیدا کردن و بازگرداندن اطلاعات تخریب شده
برای پیدا کردن رشته‌های مورد نظر در تمام جدول‌ها و فیلدهای پایگاه داده از اسکریپتی که در این صفحه قرار دارد استفاده شد.
تغییر دادن گروهی ردیف‌های پایگاه داده نیز، با کمک عبارت‌های منظم و تولید کوئری‌هایی روی داده‌های کپی شده از جداول به انجام رسید.
حمله کنندگان ظاهرا با استفاده از اسکریپتی به صورت دائم در حال ارسال اطلاعات مخرب درون وبسایت بودند، پس از اینکه با زحمت فراوان، ساختار نه چندان منظم بانک اطلاعاتی رمزگشایی و اصلاح شد، در زمان کوتاهی تمام زحمات بر باد رفت و سایت به وضعیت قبلی برگشت.
تجربه‌ی سوم: پیش از اصلاح سایت هک شده، ابتدا مسیرهای حمله را شناسایی و مسدود کنید.
مشکل چهارم: مسدود کردن مسیرهای حمله
با توجه به کد بودن سورس‌های سایت، راهی جز حدس و گمان و راه حل‌های ابتکاری برای مسدود کردن آن‌ها موجود نبود. نخستین حدس این بود که فرم‌های سایت محل حمله هستند. تلاش‌ها در جهت تغییر فایل‌ها برای جلوگیری از کارکرد فرم‌ها و همزمان عمل کردن سایت بی نتیجه ماند. پس از مدتی بررسی، راه حل ابتکاری به ذهنم رسید. کاربری که اسکریپت سایت با آن به بانک اطلاعاتی متصل می‌شد را طوری تغییر دادم که امکان نوشتن اطلاعات در جداول بانک اطلاعاتی را نداشته باشد. خوشبختانه این روش مشکلی در عملکرد سایت به وجود نیاورد. پس از آن دوباره اطلاعات تخریب شده بازسازی شدند.
تجربه‌ی چهارم: زمانی که ظاهرا هیچ راهی وجود ندارد ممکن است یک راه وجود داشته باشد !
جمع بندی نهایی: چنانچه قصد پیاده‌سازی محصولی نرم‌افزاری را دارید، اگر در این زمینه تخصصی ندارید، حتما از یک مشاور خبره برای ارزیابی پیمانکاران و راه حل‌های آنان استفاده کنید. ممکن است خسارت‌های ناشی از عدم انجام این کار به مراتب بیش از هزینه‌های استفاده از یک مشاور باشد.
