در زمان کدنویسی برنامه های تحت وب و یا سایر اپلیکیشن ها، ممکن است برنامه نویسان قسمت هایی از کد برنامه را بنابر نیاز خود، غیر قابل اجرا نموده و یا توضیحاتی (comment) در آن یادداشت کنند. از سوی دیگر، درصورتیکه ورودی های برنامه به درستی اعتبار سنجی نشده باشند، مهاجم می تواند با ارسال کدهای مخرب به صورت Comment، سبب نادیده گرفتن بخش هایی از کد اصلی شده و سامانه یا سیستم را به خطر بیفتد. Comment injection در واقع حمله ایست که مهاجم می تواند از این مساله سوء استفاده کرده و با تزریق دستورات در قسمت هایی از کد که به صورت توضیحات در آمده اند، عملیات بدخواهانه خود را اجرا نماید. با توجه به اهمیت آسیب پذیری تزریق کدهای مخرب که در سال 2017 صدر آسیب پذیریهای مهم معرفی شده توسط OWASP قرار داشت و در تسخه سال 2021 در جایگاه سوم قرار دارد، در این مقاله به توضیح آسیب پذیری مذکور بعنوان یکی از حملات مهم این دسته پرداخته شده و ضمن معرفی روشهای مختلف انجام این حملات، راهکارهای پیشگیری از وقوع آنها نیز مورد بحث قرار می گیرد.
در سالیان اخیر با گسترش نفوذ تکنولوژی و اینترنت در زندگی روزمره و استفاده از ابزارهای دیجیتال، مخاطبین کسب و کارها و سازمان ها تدریجا به سمت خرید کالا و دریافت خدمات مالی مورد نیاز از فضای آنلاین سوق داده شدند و این روند در چند سال آینده با سرعت بیشتری ادامه خواهد یافت. با ورود انبوهی از تقاضا به فضای مجازی جهت انجام تراکنش های مالی و تبادل اطلاعات در بستر ابزارهای هوشمند، فرصت مناسبی برای مهاجمان فضای آنلاین فراهم شده است.
مهاجمان، به کمک آسیب پذیری ها و رخنه های امنیتی موجود در برنامه های کاربردی تحت وب و همچنین با ایجاد بدافزارهای موبایلی، اقدام به سو استفاده یا سرقت اطلاعات کاربران نموده و همچنین با استفاده از بد افزار هایی که قابل ردیابی نیستند، اقدام به انجام حملات APT و یا گرفتن باج از اشخاص قربانی می کنند. از همین رو امنیت و حفاظت از اطلاعات در این فضا نقش پر اهمیتی ایفا می کند.
OWASP یا Open Web Application Security Project یک متدولوژی است که آسیب پذیری های رایج در برنامه های کاربردی را معرفی و راهکارهای شناسایی و رفع آن ها را بیان می کند. این متدولوژی محدود به سامانه های تحت وب نبوده و آسیب پذیری های اپلیکیشنهای موبایلی را نیز شامل می شود. برای جزئیات بیشتر در این زمینه، مقاله ده آسیب پذیری خطرناک در برنامه های موبایل بر روی وبلاگ آشنا ایمن در دسترس است.
OWASP TOP 10 یک سند استاندارد آگاهی سازی برای برنامه نویسان و کارشناسان ارزیابی امنیت است که در آن به ده آسیب پذیری خطرناک (بر اساس حملات گزارش شده) در حوزه برنامه های تحت وب پرداخته شده است. این آسیب پذیری ها به ترتیب اهمیت عبارتند از:
با توجه به اهمیت آسیب پذیری تزریق کدهای مخرب (که در سال 2017 صدر آسیب پذیریهای مهم معرفی شده توسط OWASP قرار داشت و در تسخه سال 2021 در جایگاه سوم قرار دارد) در این مقاله به توضیح عمیق آسیب پذیری Injection پرداخته و یکی از حملات مهم این دسته بنام Comment Injection معرفی می شود.
حملات تزریق یا injection نوعی از حملات هستند که در آن مهاجم از ضعف در اعتبار سنجی در ورودی ها سوء استفاده کرده و روی بخشی از درخواست یا کوئری تاثیر می گذارد ( تزریق یا بعبارت دیگر دستکاری و اضافه کردن مقادیر غیر مجاز در آن ) که منجر به اجرای دستور دلخواه خود خواهد شد. حملات injection انواع مختلفی دارد :
در زمان کدنویسی برنامه های تحت وب و یا سایر اپلیکیشن ها، ممکن است برنامه نویسان قسمت هایی از کد برنامه را بنابر نیاز خود، غیر قابل اجرا نموده و یا توضیحاتی (comment) در آن یادداشت کنند. از سوی دیگر، درصورتیکه ورودی های برنامه به درستی اعتبار سنجی نشده باشند، مهاجم می تواند با ارسال کدهای مخرب به صورت Comment، سبب نادیده گرفتن بخش هایی از کد اصلی شده و سامانه یا سیستم را به خطر بیفتد. تزریق Comment در واقع حمله ایست که مهاجم می تواند از این مساله سوء استفاده کرده و با تزریق دستورات در قسمت هایی از کد که به صورت توضیحات در آمده اند منجر به آسیب پذیری های مختلفی از جمله remote file inclusion شده، به پایگاه داده دسترسی گرفته، فایل های مخرب را بارگذاری کند، کد دلخواهش را اجرا و اقدامات مخرب را انجام دهد.
با توجه به اینکه مهاجم کدهای مخرب مورد نظرش را در کدام قسمت سامانه تزریق کند، حمله Comment Injection به انواع مختلفی تقسیم می شود که در ادامه به تشریح هر یک پرداخته می شود:
در صورتی که درخواست های ارسال شده به سمت پایگاه داده قابل دستکاری باشند، مهاجم می تواند از کاراکتر خاتمه دهنده در درخواست خود استفاده کرده و به این وسیله منجر به خاتمه یافتن درخواست و در نظر نگرفتن ادامه درخواست شود. برای مثال درخواست پایگاه داده زیر را مشاهده کنید:
SELECT body FROM items WHERE id = $ID limit 1;
فرض کنید مهاجم از طریق درخواست با متد GET ، در مقدار پارامتر ID عبارت $ID: "1 or 1=1; #" را تزریق کرده باشد. بنابراین درخواست به صورت زیر خواهد شد:
SELECT body FROM items WHERE id = 1 or 1=1; # limit 1;
پس از کاراکتر #، همه چیز از جمله limit 1 توسط پایگاه داده دور ریخته می شود، بنابراین تنها رکوردهای ستون body به عنوان یک پاسخ پرس و جو دریافت می شود. به این ترتیب محدودیت مد نظر برنامه نویس در این کوئری، بای پس شده و مهاجم می تواند نسبت به برشماری اطلاعات زیاد از پایگاه داده، اقدام نماید.
کاراکترهایی که در پایگاه داده های مختلف می توانند برای کامنت کردن درخواستها استفاده شوند، عبارتند از:
MySQL: #, --
MS SQL: --
MS Access: %00
Oracle: --
جهت کامنت کردن بخش هایی از یک درخواست، مهاجم ممکن است از کارکترهای استاندارد استفاده کند که معمولا به همان فرمت زبان برنامه نویسی شده، جهت خاتمه دادن به ادامه درخواست نوشته می شود. یک مثال جالب، استفاده از روش Null byte است که در آن تمام درخواست پس از آن در پایگاه داده MS کامنت خواهد شد.
اضافه کردن بایت/کاراکتر تهی تکنیکی جهت بهرهبرداری از برنامههای کاربردی است که به درستی پسوندهای خاتمه دهنده را مدیریت نمی کنند. این تکنیک می تواند منجر به حملات دیگری از جمله تزریق SQL اجرای کد دلخواه، مرور دایرکتوری و ... شود.
جهت اعمال پسوند NULL کدهای زیر به کار گرفته می شود:
PATH%00
PATH[0x00]
PATH[alternate representation of NULL character]
%00
در ادامه نمونه هایی از تزریق Null Byte برای آشنایی بیشتر ذکر شده است.
مثال زیر نشان دهنده استفاده از این تکنیک جهت دستکاری URL و دسترسی پیدا کردن به فایل های دلخواه سیستمی بعلت آسیب پذیری موجود در PHP است:
$whatever = addslashes($_REQUEST['whatever']);
include("/path/to/program/" . $whatever . "/header.htm");
در این دستور هر ورودی که به /header.htm ختم شده باشد، مجاز شمرده می شود. مهاجم با سوء استفاده از این موضوع، کد مخرب یا آدرس غیرمجاز خود را در میانه درخواست تزریق می کند و انتهای درخواست، بدون تغییر باقی می ماند تا برنامه آنرا بعنوان یک درخواست مجاز قبول نماید. اما در زمان پردازش درخواست، از آنجا که کلیه بخشهای درخواست که بعد از کارکتر Null آمده اند، پردازش نمی شوند، لذا دسترسی به آدرس غیر مجاز برای مهاجم میسر خواهد شد. بعنوان مثال با دستکاریURL و با استفاده از پسوند های NULL در انتهای مسیر فایل مورد نظر، می توان به فایل رمز ها دسترسی پیدا کرد:
https://vuln.example.com/phpscript.php?whatever=../../../etc/passwd%00header.htm
روند حمله تزریق NullByte در جاوا نیز رایج است. بعنوان مثال فرض کنید یک کاربر درخواست دسترسی به فایل خاصی را با فرمت ".db" که توسط توسعه دهنده برای مقاصد اعتبار سنجی اعمال می شود، داشته باشد. همان درخواست را می توان توسط مهاجم شبیه سازی کرد؛ اما به شیوه ای متفاوت برای دسترسی به منبع سیستم با تعبیه یک بایت null "00٪ " با نام فایل و فرمت معتبر. این کار با استفاده از قطعه کد قابل انجام است:
String fn = request.getParameter("fn");
if (fn.endsWith(".db"))
{
File f = new File(fn);
//read the contents of “f” file
…
}
در اینجا هر درخواستی که با .db تمام شود، معتبر شمرده خواهد شد. بنابراین یک کد نرمال باید ساختاری مطابق زیر داشته باشد:
https://www.example.host/mypage.jsp?fn=report.db
اما مهاجم با قرار دادن آدرس غیرمجاز خود در میانه این درخواست و حفظ کردن .db در انتهای آن، این درخواست را به ظاهر مجاز خواهد کرد، اما در زمان پردازش، به serverlogs.txt دسترسی خواهد یافت که دسترسی به آن غیرمجاز بوده است.
https://www.example.host/mypage.jsp?fn=serverlogs.txt%00.db
دسته ای دیگر از حملات شامل سوء استفاده از سرریز بافر در اجزای ActiveX (PDF.OCX) برای اجرای کد از راه دور است. بدلیل آنکه نرم افزار طول رشته را در نام فایل بررسی نمی کند و برای آن محدودیتی در نظر گرفته نشده است، مهاجم می تواند با قراردادن یک رشته طولانی از حروف، موجب سرریز شدن حافظه بافر شده و با استفاده از حملات buffer overflow، کدهای مخرب خود را تزریق و دسترسی های غیرمجاز را برای خود فراهم کند.
بعنوان مثال اگر یک لینک به صورت زیر درخواست شود، وب سرورهایی که درخواست را در NULL BYTE "00%" خاتمه می دهند (مشخصاً وب سرور های IIS و Netscape Enterprise) آنرا بصورت کامل به Adobe ActiveX منتقل می نمایند.
GET /some_dir/file.pdf.pdf%00[long string] HTTP/1.1
اگرچه URI درخواست شده هنگام فراخوانی فایل قطع می شود، رشته کامل هنوز به جزء Adobe ActiveX منتقل می شود و پس از آن باعث بروز سرریز بافر در Rtlheapfree() شده و به این ترتیب مهاجم قادر به باز نویسی حافظه دلخواه خواهد شد. این امر می تواند با اضافه کردن محتوای مخرب به پایان هر لینک تعبیه شده که به وب سرور مایکروسافت IIS یا Netscape Enterprise Web Server ارجاع می دهد، اجرا شود.
در شل یا بش نیز کاراکتر # جهت اتمام توضیحات در کد استفاده می شود. برای مثال کد (file.php) زیر را مشاهده کنید:
<?
$ =sth $_GET[‘what:];
system("/usr/bin/find -name '$sth' -type f");
?>
مهاجم می تواند با استفاده از عبارت "/find.php?what=*'%20%23*" (که در آن %20%23 کد شده کاراکتر # به صورت url است)، محدودیت "*-type f*" را دور بزند.
بنابراین دستور مجاز زیر
"/usr/bin/find -name '*' -type f"
به حالت غیر مجاز
"/usr/bin/find -name '*' #-type f"
تبدیل می شود.
بنابراین در نهایت دستوری که اجرا می شود عبارت است از:
/usr/bin/find -name '*'
که در آن محدودیت type f برداشته شده است.
اگر هیچ محدودیتی در مورد اینکه چه کسی قادر به درج نظرات است وجود نداشته باشد، می توان با تگ های شروع کننده کامنت "<!--" محتوای نمایش داده شده باقی مانده در وب سایت را کامنت کرد.
برای مثال اگر تابع (invisible.php) به صورت زیر باشد:
خروجی آن شامل دو خط است:
hello!: [‘user’]
Welcome friend!
اما اگر درخواست به صورت " GET /invisible.php?user=<!--" ارسال شود، محتوای بعد از user بصورت کامن در نظر گرفته شده و نمایش داده نخواهد شد. بنابراین صرفاً نتیجه زیر بر گردانده خواهد شد:
hello!:
در بارگزاری فایل نیز می توان با استفاده از تزریق مقدار بایت (00%) فرایند اعتبار سنجی فایل بارگذاری شده را دور زد.
فرض کنید تنها فرمت فایل مجاز برای آپلود در یک سامانه، فرمت png باشد و سامانه در زمان بارگذاری، این پسوند را بررسی می کند. اگر فایل مخرب به صورت fUpload.php باشد، با اعمال تغییرات بر روی نام فایل مورد نظر به صورت filename=”fUpload.php%00.png” می توان فایل مخرب مورد نظر را بارگذاری کرد. به این روش نام فایل بعد از نال بایت ادامه ی نام فایل“ .png” را نادیده گرفته و فایل مورد نظر با پسوند ".php" اجرا خواهد شد.
با توجه به اینکه این حمله در زبان های مختلف و در قسمت های مختلف سامانه به گونه های مختلفی اجرا می شود، راهکارهای مختلفی برای رفع آن وجود خواهد داشت، یکی از راهکارها به روز رسانی نسخه های کتابخانه و توابع استفاده شده در سامانه است، در موارد دیگر راه حل کلی آن اعتبار سنجی ورودی ها توسط برنامه به شکل صحیح است که در زیر به توضیح بیشتر آن پرداخته شده است:
عبارت های آماده سازی یک قالب خاص آماده شده است که به صورت پارامتری شده ورودی ها را دریافت می کند و پس از آنکه ورودی را تجزیه و تحلیل کرد، آن را اجرا کند به این صورت امکان انجام حملات injection وجود نخواهد داشت.
به منظور اعتبار سنجی داده لازم است در ابتدا تفاوت بین درخواست و داده مشخص شود. روش های ذخیره شده (Stored Procedures) این مساله را با نوشتن پرس و جو با نشانگر برای پارامترها حل می کند، به طوری که داده ها می توانند بعدا به آنها منتقل شوند.
تنها مواردی که در لیست مجاز تعریف شده امکان وارد شدن دارد.
همچنین راهکاری که جهت پیشگیری از حمله Adobe PDF ActiveX پیشنهاد می شود به روز رسانی این نسخه به 6.0.2 است، که توسط شرکت Adobe Reader ارائه شده است.
اما جهت اطمینان کامل از ایمن بودن سامانه در مقابل آسیب پذیری ها پیشنهاد می گردد صاحبان نرم افزار، علاوه بر موارد که اشاره شد، انجام آزمون های نفوذ پذیری را به صورت دوره ای در برنامه خود قرار دهند. علاوه بر این لازم است با استفاده از بررسی های دوره ای، از به روز بودن سرویسها و امن سازی مستمر آنها اطمینان حاصل نمود.
در پستهای بعدی در مورد سایر آسیب پذیری ها و نحوه مقابله با آنها، بیشتر خواهیم خواند. برای مطالعه مقالات بیشتر در زمینه امنیت سایبری، به وبلاگ تخصصی آشنا ایمن مراجعه کنید.