دوره SEC542 – بخش چهل و یکم

در این بخش از دوره آموزشی SEC542 از موسسه SANS به آشنایی با آشنایی با JSON و همچنین فریم ورک ها می پردازیم.

JavaScript Libraries/Frameworks

یکی دیگر از مشکلات ما با AJAX، پیچیدگی اپلیکیشن است. غالبا، توسعه‌دهندگان اپلیکیشن چندین تابع و قابلیت را در یک فایل JavaScript می‌گنجانند. اگرچه این موضوع در اکثر اپلیکیشن‌ها دیده می‌شود، با این حال فراوانی آن در اپلیکیشن‌های AJAX بیش‌تر است.

دلیل این قضیه آنست که AJAX در کتابخانه‌ها و فریم‌ورک‌های پیچیده‌ای مورد استفاده قرار گرفته است تا جایی که یک مارکت از فریم‌ورک‌های در حال توسعه AJAX ارائه شده است.

Framework Files

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

به عنوان مثال زمانی که برنامه‌نویس توابع مربوط به قابلیت‌های صفحات مدیریتی (admin) را در فایل‌های js قرار می‌دهد؛ ما به طور مستقیم به صفحات مدیریتی سایت دسترسی نداریم اما می‌توانیم توابع JavaScript مربوطه را مستقیما فراخوانی کنیم. مثلا ممکن است در چنین اپلیکیشنی بتوانیم کاربر جدید به سیستم اضافه کرده و با آن لاگین کنیم.

Third-Party Frameworks

اغلب در طول تست، کتابخانه‌هایی از سایت‌های دیگر (third-party) پیدا می‌کنیم. این کتابخانه‌ها با ارائه قابلیت‌های مختلف و از پیش‌ساخته شده، به توسعه‌دهندگان وب کمک زیادی می‌کنند. این قابلیت‌ها ممکن است در جهت زیباسازی اپلیکیشن و یا پیاده‌سازی روند کسب و کار اپلیکیشن باشد. به عنوان مثال می‌توان به JQuery و MooTools اشاره نمود.

در فاز mapping اپلیکیشن، ما باید کتابخانه‌ها و فریم‌ورک‌های استفاده شده را یافته و به کمک کامنت‌ها یا عنوان فایل‌ها، آن‌ها را شناسایی کنیم. با شناسایی این کتابخانه‌ها می‌توانیم اطلاعات زیادی از اپلیکیشن بدست آوریم. مثلا کتابخانه‌ها هرکدام استفاده‌های خاصی دارند، بنابراین می‌توانیم بر اساس کتابخانه‌های استفاده شده، بخشی از کارکرد و هدف اپلیکیشن را دریابیم. علاوه بر این، کتابخانه‌ها ممکن است نقاط ضعف و آسیب‌پذیری‌هایی را برای اپلیکیشن به ارمغان بیاورند.

کشف Framework ها

در مرحله spider کردن سایت، بیشتر فایل‌های API باید پیدا شوند. با نگاه کردن به نقشه اپلیکیشن، باید فایل‌های .js که توسط صفحات مختلف لود شده‌اند را ببینیم. در این مرحله باید فایل‌های یافت شده را پارس کرده و کدهای آن‌ها را بررسی کنیم.

ما به جستجوی توابع جالبی مانند هر فراخوانی از XMLHttpRequest می‌پردازیم. همچنین می‌توانیم توابع مختلفی که دیتا را از محل‌های دیگر دریافت می‌کنند یا به عملکرد “حساسی” اشاره می‌کنند (مانند عملیات مدیریتی) را جستجو کنیم.

اکسپلویت آسیب‌پذیری‌های Framework

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

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

حملات دیتا

از آنجائیکه اپلیکیشن‌های AJAX قابلیت مبادله حجم زیادی از دیتا را دارند، گاهی پیش می‌آید که دیتایی بیش‌تر از حد نیاز به کاربر (مهاجم) باز گردانده شود. وب‌سرویس‌های فراخوانی شده توسط اپلیکیشن، دیتای خود را به اپلیکیشن برمی‌گردانند و از آنجائیکه بیش‌تر کدنویسی این دسته از اپلیکیشن‌ها در سمت کلاینت انجام شده، دیتای دریافتی به دست مهاجم می‌رسد.

بسیاری از سرویس‌ها حجم زیادی از دیتا را به کلاینت داده و با کدهای سمت کلاینت، این دیتا را فیلتر می‌کنند.

انواع فرمت‌های دیتا

AJAX برای انتقال دیتا می‌تواند از هر فرمتی که برنامه‌نویس می‌خواهد، استفاده کند. برای مثال، برنامه‌نویس می‌تواند یک رشته با طول ثابت را به کد سمت کلاینت ارسال کند. اما معمولا، AJAX از دو فرمت استفاده می‌کند.

اولین گزینه، فرمتی است که AJAX آن را در نام خود نیز دارد و آن XML است. XML فرمتی مبتنی بر تگ بوده و استفاده از آن بسیار رایج است. اما XML نسبت به فرمت‌های دیگر دیتا سنگین‌تر است.

مورد بعدی JSON است. ما در بخش‌های بعد بیش‌تر به جزئیات JSON می‌پردازیم.

آشنایی با مباحث AJAX

هر دوی این فرمت‌ها احتیاج دارند تا سمت کلاینت پردازش (parse) شوند. مثلا برای تبدیل یک متن JSON به یک آبجکت، می‌توان از تابع eval استفاده کرد. اما توجه کنید که استفاده از این تابع می‌تواند مشکلات امنیتی به همراه داشته باشد. تابع eval، کامپایلر JavaScript را فراخوانی می‌کند. از آنجائیکه JSON زیرمجموعه‌ای از JavaScript است، کامپایلر به درستی متن ورودی را پردازش کرده و یک ساختار آبجکت می‌سازد. جهت جلوگیری از هرگونه ابهام و مشکل در قواعد نحوی JavaScript ، متن ورودی باید داخل پرانتز قرار بگیرد:

تابع eval سرعت بالایی دارد. با این حال این تابع می‌تواند هر برنامه JavaScript را کامپایل و اجرا کند، به همین دلیل ممکن است باعث بروز مشکلات امنیتی شود. استفاده از eval زمانی توصیه می‌شود که ورودی آن معتبر و مورد اعتماد باشد. راه امن‌تر به کار بردن یک JSON parser است.

JSON

JavaScript Object Notation (JSON) یک فرمت سبک برای تبادل دیتا است. هم درخواست و هم پاسخ HTTP می‌تواند در یک آبجکت JSON ذخیره شود. از این نظر می‌توان مانند یک آرایه به آن نگاه کرد. در کد سمت کلاینت، JavaScript دیتای JSON را به کمک فراخوانی eval یا یک JSON parser در حافظه بارگذاری می‌کند.

تست نفوذ کننده در پاسخ‌های سرور اپلیکیشن، آبجکت JSON را برای یافت هر دیتای اضافی و جالب بررسی می‌کند. اما در درخواست‌های ارسالی، تست نفوذ کننده می‌تواند پیلودهای مربوط به هر یک از حملات معمول مانند SQL injection یا XSS را تزریق کند و ببیند که اپلیکیشن چگونه به آیتم‌های غیرمنتظره واکنش نشان می‌دهد.

JSON Format

فرمت JSON اساسا یک آرایه است که می‌تواند شامل آرایه‌های دیگری نیز باشد؛ بطوریکه همه آن‌ها تنها یک record set را تشکیل می‌دهند. هم درخواست و هم پاسخ‌های HTTP از این فرمت استفاده می‌کنند. مثال زیر یک آبجکت JSON را نشان می‌دهد:

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

اکسپلویت JSON

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

همچنین باید به خاطر داشته باشیم که JSON یکی از نقاط injection در مراحل تست است. injection دومین صورت اکسپلویت JSON است که اغلب به دلیل شکل پیچیده آن در JSON، نادیده گرفته می‌شود.

افشاء اطلاعات JSON

از آنجائیکه JSON برای ارسال اطلاعات به کلاینت استفاده می‌شود، و بیش‌تر برنامه نویسان نمی‌خواهند که بار پردازش اطلاعات را روی سرور قرار دهند، به همین دلیل معمولا دیتای غیر ضروری و بیش از حد نیاز به کلاینت ارسال می‌گردد. حتی ممکن است کل دیتا به کلاینت داده شود و در سمت کلاینت فقط یک رکورد از آن به کاربر نشان داده شود.

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

JSON Injection

برای اجرای JSON Injection باید بر روی درخواست‌ها تمرکز کنیم. برای این کار می‌توانیم از ابزارهای پراکسی که قبلا معرفی کردیم، استفاده کرده و پیلود هر حمله‌ای که می‌خواهیم را تزریق کنیم. معمولا در این دسته از اپلیکیشن‌ها، حملات SQL injection و XSS با موفقیت بیش‌تری رخ می‌دهند.

به خاطر داشته باشید در عین حال که ما از درخواست‌های JSON به عنوان نقاط injection استفاده می‌کنیم، ممکن است به حملات code injection نیز برخورد کنیم. در این حملات هم کدهای سمت کلاینت و هم کدهای سمت سرور ممکن است هدف حمله قرار گیرد.

برای پیدا کردن code injection کافی است دیتایی را بیابیم که در پاسخ‌های JSON بازگردانده شده و مقدار آن را بتوانیم کنترل کنیم. مثلا اگر بتوانیم نام خود را با قطعه‌ای از کد JavaScript ذخیره کنیم، آنگاه زمانی که این مقدار از طریق JSON بازگردانده شود، کد JavaScript ما اجرا می‌گردد.

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

مطالب این بخش توسط سرکار خانم فهیمه رضایی تهیه شده است.