معرفی حملات Comment Injection و راه های امن سازی آن

  • نویسنده: سعیده صادقی
  • تاریخ انتشار: شنبه ، ۰۲ مرداد ماه ۰۰
  • تعداد بازدید: 383
  • تعداد نظرها: 0
  • دسته بندی: ارزیابی امنیتی

در زمان کدنویسی برنامه های تحت وب و یا سایر اپلیکیشن ها، ممکن است برنامه نویسان قسمت هایی از کد برنامه را بنابر نیاز خود، غیر قابل اجرا نموده و یا توضیحاتی (comment) در آن یادداشت کنند. از سوی دیگر، درصورتیکه ورودی های برنامه به درستی اعتبار سنجی نشده باشند، مهاجم می تواند با ارسال کدهای مخرب به صورت Comment، سبب نادیده گرفتن بخش هایی از کد اصلی شده و سامانه یا سیستم را به خطر بیفتد. Comment injection در واقع  حمله ایست که مهاجم می تواند از این مساله سوء استفاده کرده و با تزریق دستورات در قسمت هایی از کد که به صورت توضیحات در آمده اند، عملیات بدخواهانه خود را اجرا نماید. با توجه به اهمیت آسیب پذیری تزریق کدهای مخرب که در سال 2017 صدر آسیب پذیریهای مهم معرفی شده توسط OWASP قرار داشت و در تسخه سال 2021 در جایگاه سوم قرار دارد، در این مقاله به توضیح آسیب پذیری مذکور بعنوان یکی از حملات مهم این دسته پرداخته شده و ضمن معرفی روشهای مختلف انجام این حملات، راهکارهای پیشگیری از وقوع آنها نیز مورد بحث قرار می گیرد.

مقدمه

در سالیان اخیر با گسترش نفوذ تکنولوژی و اینترنت در زندگی روزمره و استفاده از ابزارهای دیجیتال، مخاطبین کسب و کارها و سازمان ها تدریجا به سمت خرید کالا و دریافت خدمات مالی مورد نیاز از فضای آنلاین سوق داده شدند و این روند در چند سال آینده با سرعت بیشتری ادامه خواهد یافت. با ورود انبوهی از تقاضا به فضای مجازی جهت انجام تراکنش های مالی و تبادل اطلاعات در بستر ابزارهای هوشمند، فرصت مناسبی برای مهاجمان فضای آنلاین فراهم شده است.

مهاجمان، به کمک آسیب پذیری ها و رخنه های امنیتی موجود در برنامه های کاربردی تحت وب و همچنین با ایجاد بدافزارهای موبایلی، اقدام به سو استفاده یا سرقت اطلاعات کاربران نموده و همچنین با استفاده از بد افزار هایی که قابل ردیابی نیستند، اقدام به انجام حملات APT و یا گرفتن باج از اشخاص قربانی می کنند. از همین رو امنیت و حفاظت از اطلاعات در این فضا نقش پر اهمیتی ایفا می کند.

OWASP یا Open Web Application Security Project یک متدولوژی است که آسیب پذیری های رایج در برنامه های کاربردی را معرفی و راهکارهای شناسایی و رفع آن ها را بیان می کند. این متدولوژی محدود به سامانه های تحت وب نبوده و آسیب پذیری های اپلیکیشنهای موبایلی را نیز شامل می شود. برای جزئیات بیشتر در این زمینه، مقاله ده آسیب پذیری خطرناک در برنامه های موبایل بر روی وبلاگ آشنا ایمن در دسترس است.

 OWASP TOP 10  یک سند استاندارد آگاهی سازی برای برنامه نویسان و کارشناسان ارزیابی امنیت است که در آن به ده آسیب پذیری خطرناک (بر اساس حملات گزارش شده) در حوزه برنامه های تحت وب پرداخته شده است. این آسیب پذیری ها به ترتیب اهمیت عبارتند از:

  1. Injection
  2. Broken Authentication
  3. Sensitive Data Exposure
  4. XML External Entities (XXE)
  5. Broken Access Controls
  6. Security Misconfigurations
  7. Cross-Site Scripting
  8. Insecure Deserialisation
  9. Using Components with known vulnerabilities
  10. Insufficient Logging & monitoring

با توجه به اهمیت آسیب پذیری تزریق کدهای مخرب (که در سال 2017 صدر آسیب پذیریهای مهم معرفی شده توسط OWASP قرار داشت و در تسخه سال 2021 در جایگاه سوم قرار دارد) در این مقاله به توضیح عمیق آسیب پذیری Injection پرداخته و یکی از حملات مهم این دسته بنام Comment Injection  معرفی می شود.

معرفی حملات Injection

حملات تزریق یا injection نوعی از حملات هستند که در آن مهاجم از ضعف در اعتبار سنجی در ورودی ها سوء استفاده کرده و روی بخشی از درخواست یا کوئری تاثیر می گذارد ( تزریق یا بعبارت دیگر دستکاری و اضافه کردن مقادیر غیر مجاز در آن ) که منجر به اجرای دستور دلخواه خود خواهد شد. حملات injection انواع مختلفی دارد :

  1. Code injection
  2. CRLF injection
  3. Cross-site Scripting (XSS)
  4. Email Header Injection
  5. Host Header Injection
  6. LDAP Injection
  7. OS Command Injection
  8. XPath injection
  9. SQL Injection (SQLi)
  10. Comment injection

 

معرفی حمله Comment Injection

در زمان کدنویسی برنامه های تحت وب و یا سایر اپلیکیشن ها، ممکن است برنامه نویسان قسمت هایی از کد برنامه را بنابر نیاز خود، غیر قابل اجرا نموده و یا توضیحاتی (comment) در آن یادداشت کنند. از سوی دیگر، درصورتیکه ورودی های برنامه به درستی اعتبار سنجی نشده باشند، مهاجم می تواند با ارسال کدهای مخرب به صورت Comment، سبب نادیده گرفتن بخش هایی از کد اصلی شده و سامانه یا سیستم را به خطر بیفتد. تزریق Comment در واقع  حمله ایست که مهاجم می تواند از این مساله سوء استفاده کرده و با تزریق دستورات در قسمت هایی از کد که به صورت توضیحات در آمده اند منجر به آسیب پذیری های مختلفی از جمله remote file inclusion شده، به پایگاه داده دسترسی گرفته، فایل های مخرب را بارگذاری کند، کد دلخواهش را اجرا و اقدامات مخرب را انجام دهد. 

 

انواع مختلف تزریق Comment

با توجه به اینکه مهاجم کدهای مخرب مورد نظرش را در کدام قسمت سامانه تزریق کند، حمله 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

جهت کامنت کردن بخش هایی از یک درخواست، مهاجم ممکن است از کارکترهای استاندارد استفاده کند که معمولا به همان فرمت زبان برنامه نویسی شده، جهت خاتمه دادن به ادامه درخواست نوشته می شود. یک مثال جالب، استفاده از روش Null byte است که در آن تمام درخواست پس از آن در پایگاه داده MS کامنت خواهد شد.

اضافه کردن بایت/کاراکتر تهی تکنیکی جهت بهره­برداری از برنامه­های کاربردی است که به درستی پسوندهای خاتمه دهنده را مدیریت نمی کنند. این تکنیک می تواند منجر به حملات دیگری از جمله تزریق SQL اجرای کد دلخواه، مرور دایرکتوری و ... شود.

جهت اعمال پسوند NULL کدهای زیر به کار گرفته می شود:

PATH%00

PATH[0x00]

PATH[alternate representation of NULL character]

%00

در ادامه نمونه هایی از تزریق Null Byte برای آشنایی بیشتر ذکر شده است.

Php Script

مثال زیر نشان دهنده استفاده از این تکنیک جهت دستکاری 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 

Java

روند حمله تزریق 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 

حمله Adobe PDF ActiveX

دسته ای دیگر از حملات شامل سوء استفاده از سرریز بافر در اجزای 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 ارجاع می دهد، اجرا شود.

Shell

در شل یا بش نیز کاراکتر # جهت اتمام توضیحات در کد استفاده می شود. برای مثال کد (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 برداشته شده است.

تزریق HTML (injection)

اگر هیچ محدودیتی در مورد اینکه چه کسی قادر به درج نظرات است وجود نداشته باشد، می توان با تگ های شروع کننده کامنت "<!--" محتوای نمایش داده شده باقی مانده در وب سایت را کامنت کرد.

برای مثال اگر تابع (invisible.php) به صورت زیر باشد:

 

خروجی آن شامل دو خط است:

hello!: [‘user’]

Welcome friend!

اما اگر درخواست به صورت " GET /invisible.php?user=<!--" ارسال شود، محتوای بعد از user بصورت کامن در نظر گرفته شده و نمایش داده نخواهد شد. بنابراین صرفاً نتیجه زیر بر گردانده خواهد شد:

hello!:

File Upload Bypass

در بارگزاری فایل نیز می توان با استفاده از تزریق مقدار بایت (00%) فرایند اعتبار سنجی فایل بارگذاری شده را دور زد.

فرض کنید تنها فرمت فایل مجاز برای آپلود در یک سامانه، فرمت png باشد و سامانه در زمان بارگذاری، این پسوند را بررسی می کند. اگر فایل مخرب به صورت fUpload.php باشد، با اعمال تغییرات بر روی نام فایل مورد نظر به صورت filename=”fUpload.php%00.png” می توان فایل مخرب مورد نظر را بارگذاری کرد. به این روش نام فایل بعد از نال بایت ادامه ی نام فایل“ .png” را نادیده گرفته و فایل مورد نظر با پسوند ".php" اجرا خواهد شد.

  

راهکارهای امن سازی

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

 

  • استفاده از عبارت های آماده شده (Prepared Statement) توسط پرس و جوهای پارامتریک:

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

  • استفاده از Stored Procedures

به منظور اعتبار سنجی داده لازم است در ابتدا تفاوت بین درخواست و داده مشخص شود. روش های ذخیره شده (Stored Procedures) این مساله را با نوشتن پرس و جو با نشانگر برای پارامترها حل می کند، به طوری که داده ها می توانند بعدا به آنها منتقل شوند.

  • استفاده از لیست های مجاز:

تنها مواردی که در لیست مجاز تعریف شده امکان وارد شدن دارد.

  • بررسی نوع داده­ی ورودی: برای مثال بررسی اینکه در فیلد شماره تلفن تنها عدد وارد شود.
  • ایجاد محدودیت در سطح دسترسی کاربران: بعنوان مثال کاربر ساده سطح دسترسی کامل به دیتابیس نداشته باشد.
  • استفاده از آخرین نسخه های پایدار نرم افزارها و کتابخانه ها و به روز رسانی مستمر سرویسها
  • در قسمت بارگزاری فایل لازم است نام فایل اعتبار سنجی شود و کاراکترهای غیر مجاز پذیرش نشوند. برای این منظور می توان از کد اسکی کاراکترها استفاده کرد؛ به این صورت که کد اسکی کاراکتر null یا "0" مقدار صفر داشته که به معنی استفاده از null بایت است.

همچنین راهکاری که جهت پیشگیری از حمله Adobe PDF ActiveX پیشنهاد می شود به روز رسانی این نسخه به  6.0.2 است، که توسط شرکت Adobe Reader ارائه شده است.

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

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

 
 
 
 
 
نویسنده: سعیده صادقی دسته بندی: ارزیابی امنیتی