این روزها و با گسترش تجارت‌های برخط، اخبار در حوزه‌ی نشت و یا سرقت اطلاعات کاربران نیز به سرعت در حال افزایش است. در این میان به فراخور نوع تجارتی که روی یک کسب و کار برخط پایه‌گذاری می‌شود، میزان هزینه و دقتی که تیم‌های فنی و توسعه‌دهندگان روی این موضوعات نیز باید انجام دهند، افزایش می‌یابد.
در این یادداشت با یک مورد عملی، نگاهی اجمالی دارم به آن‌چه توسعه‌دهندگان می‌توانند انجام دهند تا یک تجارت را دچار آسیب‌های غیرقابل جبران کنند. موضوع در مورد یکی از درگاه‌های پرداخت‌یاری است که به تازگی فعالیت خود را شروع کرده است.
ذکر این نکته نیز لازم است که من تخصصی در حوزه‌ی امنیت ندارم و از ابزار خاصی هم برای کشف این مورد استفاده نکرده‌ام. فقط مشاهداتم را دنبال کردم و به نتیجه رسیدم.
به طور معمول سارقان اینترنتی کار خود را از مشاهده‌ی داده‌های آشکار برای کشف نقاط نفوذ در کاربردهای مختلف نرم‌افزاری آغاز می‌کنند. برای مثال به داده‌های موجود در سرآیند درخواست‌های وب مرتبط با این درگاه پرداخت‌یار دقت کنید:
از داده‌های موجود در این سرآیند اطلاعات ذی‌قیمتی را می‌توان استخراج کرد. برای مثال محدودیت تعداد درخواست به واسط برنامه‌نویسانه وب چه تعداد است و یا خادم وب این وب‌کاربرد چیست و نسخه‌ی آن چگونه است. البته این داده‌ها شاید در نگاه اول چندان کاربردی نباشند. اما بهتر است بدانید که متخصصان امنیت همین داده‌ها را نیز دستکاری می‌کنند تا کار برای سارقان و حمله‌کنندگان سخت‌تر شود.
اما نکته‌ی اصلی در این داده‌ها، سرآیندی با کلید phpdebugbar-id است. به طور عمومی در حوزه‌ی توسعه‌ی نرم‌افزار ابزارهایی که با عبارت‌هایی از جنس debug نام‌گذاری می‌شوند، برای بررسی رفتار نرم‌افزار در فراخوانی‌های مختلف استفاده می‌شوند. حالا اگر کلید سرآیندی با ترکیبی از این نام در یک درخواست وب مشاهده شود، با احتمال خوبی یک ابزار بررسی عملکرد نرم‌افزار روی این محصول در دسترس است. با کمی جستجو در اینترنت می‌توان به این نتیجه رسید که به طور مشخص ابزار phpdebugbar نیز یکی از همین ابزارها است که به توسعه‌دهندگان کمک می‌کند رفتار نرم‌افزار، چه در مورد فراخوانی توابع و کلاس‌ها و چه در حوزه‌ی سرآیندهای وب و یا فراخوانی‌های پایگاه داده، مورد ارزیابی قرار گیرد.
برآورد اولیه‌ی من این بود که احتمالا دسترسی به خروجی این ابزار برای کاربران با آدرس IP مشخصی محدود شده است و در دسترس همگان نیست. هر چند که همین رفتار هم در انتشار یک محصول غلط است اما خب می‌شد با کمی اغماض پذیرفت.
برای بررسی صحت این موضوع یک آدرس بی‌ربط از واسط برنامه‌نویسانه را فراخوانی کردم و متاسفانه ابزار خطایاب در دسترس من نیز بود.
تا اینجا من می‌توانستم از ابزار خطایاب برای بررسی چهارچوب توسعه‌ی نرم‌افزار و یا همان فریم‌ورک استفاده کنم و ساختار نرم‌افزار هدف را ارزیابی کنم. اما نکته‌ی بدی که کار را مجددا خطرناک‌تر می‌کرد وجود بایگانی از درخواست‌ها در همین ابزار خطایاب بود.
همان‌طور که در تصویر مشخص است، من می‌توانستم به بایگانی کاملی از درخواست‌های ارسال شده به این وب‌کاربرد دسترسی داشته باشم. با توجه به داده‌هایی که این ابزار در اختیار من می‌گذارد به سادگی به شمای فراخونی‌های پایگاه داده‌ی مرتبط با هر درخواست دسترسی پیدا کردم.
در گام بعدی سایر اطلاعاتی که روی هر درخواست در اختیارم بود را نیز ارزیابی کردم و متوجه شدم که تمامی سرآیندهای فراخوانی‌های http نیز در این بایگانی وجود دارد. به این ترتیب من به سادگی می‌توانستم علاوه بر به دست آوردن توکن‌های ارتباط سایر کاربران از طریق فراخوانی‌های پایگاه داده، این توکن‌ها را از روی سرآیندها نیز استخراج کنم، آن‌ها را جعل کرده و به جای آن‌ها درخواست‌های مختلف را به نرم‌افزار ارسال کنم.
البته بلافاصله بعد از انجام این بررسی سطحی، مشکل را به شرکت مربوطه گزارش کردم.
ما به عنوان توسعه‌دهندگان نرم‌افزار، نقشی کلیدی در تجارت‌های مختلف ایفا می‌کنیم. بسیار مهم است که همان‌طور که همواره در مسیر یادگیری تکنولوژی‌های مختلف و افزایش سطح دانش خود در زبان‌های برنامه‌نویسی هستیم، به موضوعات مرتبط با امنیت وبکاربردها نیز بهای لازم را بدهیم.
استفاده از ابزارهای مختلف در مسیر توسعه‌ی نرم‌افزار و رفع خطاهای آن امری ناگزیر و اجتناب‌ناپذیر است. اما در کنار آن باید با استفاده از روش‌های مختلف بررسی کیفیت کدها قبل از انتشار محصول روی محیط عملیاتی، از عدم وجود هر نوع حفره‌ی امنیتی هر چند ساده نیز جلوگیری کنیم.
در صورتی که تیم ما توان ارزیابی امنیتی محصول ما را ندارد، بهتر است از شرکت‌های مرتبط با این موضوعات کمک بگیریم و اجرای آزمون‌های امنیتی را به آن‌ها بسپاریم. قطعا کشف آسیب‌پذیری قبل از انتشار محصول و توسط تیم‌های متخصص، بهتر از کشف آن‌ها پس از انتشار است.
