حمله به برنامه‌های NoSQL

در چند سال اخیر پشته‌ی پایگاه داده‌های MEANS۱ بسیار مورد توجه توسعه‌دهندگان برنامه‌های مبتنی بر وب قرار گرفته است. دلیل اصلی این محبوبیت پشتیبانی این پشته از برنامه‌های جاوا اسکریپت سمت کارخواه و کارگزار است که امکان توسعه‌ی سریع را به برنامه‌نویسان می‌دهد.

یکی از پراستفاده‌ترین پایگاه داده‌ها در این پشته، پایگاه داده‌ی MongoDB است. این پایگاه داده برنامه‌ای NoSQL بوده و از اسنادی همچون JSON استفاده می‌کند که این امر انعطاف‌پذیری زیادی را به همراه دارد.

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

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

مجموعه‌ها در پایگاه داده‌ی MongoDB بسیار شبیه به جداول در پایگاه داده‌های استاندارد هستند. آن‌ها مجموعه‌ای از داده‌های مختلف را نگهداری کرده و بازیابی سریع این داده‌ها را امکان‌پذیر می‌کنند. در ادامه یک مجموعه در پایگاه داده‌ی MongoDB با نام rockband را مشاهده می‌کنید.

به راحتی می‌توان بر روی این پایگاه داده پرس‌وجو انجام داد و MongoDB نیز عملگرهای مختلف و قدرتمندی دارد. به‌طور مثال در مجموعه‌ای دیگر اگر بخواهیم کالاهایی با مقدار بیش از ۲۵ را پرس‌وجو کنیم، دستور زیر این کار را انجام خواهد داد:
db.products.find( { qty: { $gt: ۲۵ } } )
این مسئله برای یک آزمونگر نفوذ بسیار مهم است چرا که باید بداند یک پرس‌وجو چگونه اجرا می‌شود. همچنین می‌دانیم تا زمانی‌که بتوانیم آرگومان‌های ورودی به پایگاه داده را ویرایش کنیم، می‌توانیم از پایگاه داده بخواهیم هرکاری که ما می‌گوییم را انجام دهد.

باید به این نکته نیز اشاره کنیم که فرمت JSON دارای نویسه‌های خطرناک زیادی نسبت به SQL معمولی است. از این نویسه‌ها می‌توان به / {} : اشاره کرد.
یکی از خوبی‌های پشته‌ی MEAN این است که به راحتی و به‌سرعت می‌توان برنامه‌های مبتنی بر وب طراحی کرد. پس از تنظیم پیکربندی‌های پایه‌ای، باید مسیری برای توابع جاوا اسکریپت ایجاد کنیم تا با استفاده از آن بتوانیم پرس‌وجو‌ها را مدیریت کنیم. در ادامه بهتر است یک مثال را مشاهده کنیم.

app.listen(port);
app.get(‘/documents/:id’, function (req, res) {

این دستورات، درخواست‌های همچون /documents/a۹۵۷۷۰۵۰-۳۱cf-۱۱e۶-۹۵۷b-۴۳a۵e۸۱bf۷۱e را به سمت تابع ما هدایت خواهد کرد. تابع ما می‌تواند آرگومان id را دریافت کرده و در پایگاه داده‌ی MongoDB به دنبال آن بگردد. و اینک یک سؤال: انتخاب پویشگر وب شما برای این پرس‌وجو چگونه خواهد بود؟ آیا به انتهای آن درخواست نویسه‌ی «’» را اضافه خواهد کرد؟ آیا واقعاً از NoSQL پشتیبانی می‌کند؟

در هر صورت ما همواره در مدیریت آرگومان‌های ورودی کاربر باید مراقب باشیم. در مثال بالا، این پرس‌وجو به شکل زیر نشان داده خواهد شد:

var param = req.params.id;
db.collection(‘documents’).findOne( { friendly: param } ), function (err, result) {

مشاهده می‌کنیم که آرگومان id در داخل متغیر param ذخیره می‌شود و در عملگر جستجو به‌عنوان پارامتر friendly مورد استفاده قرار می‌گیرد. در حال حاضر باید نگران یک چیز باشیم: آیا این کد امن است؟ مهم نیست چه چیزی را وارد پارامتر id می‌کنیم. با آن مانند یک رشته رفتار خواهد شد و راه گریزی از آن نیست.

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

var param = req.bodu.id;
var searchparam = JSON.parse(“{ \”friendly:\” ” + param + ” }”);
db.collection(‘documents’).findOne(searchparam), function (err, result) {

مشکل اینجاست که توسعه‌دهندگان تصمیم گرفته‌اند متغیر param را به رشته‌ی JSON تبدیل کنند. اینک شما می‌توانید بفهمید که این روش متفاوت با شیوه‌ای است که پایگاه داده‌ی MongoDB رفتار می‌کند.
در مثال بالا می‌توان پرس‌وجو را تا حدودی دست‌کاری کرد. مثال زیر را ببینید:

$ curl http://vulnsite/documents/ -d “id={ \”\$ne\”: null }”

در این دستور چه اتفاقی افتاده است؟ پارامتر id در بدنه‌ی یک درخواست HTTP ارسال شده است. زمانی‌که کد مقدار مربوطه را دریافت کرده و شیء JSON را می‌نویسد، پرس‌وجوی نهایی به شکل زیر خواهد بود:

{ friendly: { $ne: null } }

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

{ “$regex”: “^a” }

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

{ friendly: { $regex: “^a” } }

این پرس‌وجو اولین سندی که GUID آن با نویسه‌ی a شروع می‌شود را بازیابی خواهد کرد. این واقعاً عالی است! ما می‌توانیم بدون انجام جستجوی فراگیر، نویسه به نویسه اسناد مختلفی را بازیابی کنیم.
همان‌طور که می‌بینیم، پایگاه داده‌های NoSQL و برنامه‌هایی که از آن استفاده می‌کنند در برابر حملات تزریق آسیب‌پذیر هستند. پس هرگز نباید دست‌کاری پارامترهای ورودی توسط مهاجمان را دست‌کم بگیریم و همواره باید ورودی‌های کاربر را به‌درستی پالایش کنیم. با افزایش محبوبیت پایگاه داده‌های NoSQL انتظار می‌رود در آینده شاهد حملات زیاد و جدیدی علیه این پایگاه داده‌ها باشیم.

۱. (مخفف نویسه‌های اول هریک از پایگاه‌ داده‌های MongoDB، Express.js، Angular.js و Node.js)

منبع: asis

درباره نماد امنیت وب

“نماد امنیت وب” به عنوان یکی از شرکت های پیشتاز در زمینه امنیت نرم افزار و سرویس های تحت وب، با ارائه سرویس های امنیتی برای تمامی کسب و کار ها و دارای نمایندگی شرکت Acunetix (اکوانتیکس) بعنوان محبوب ترین اسکنر امنیتی black box در دنیا، ایمنی وب سایت شما را در مقابل حمله هکر ها تضمین می کند.

اسکن امنیتی وب سایت
(5000 تومان)

نوع وب سایت: وبلاگ، شرکتی، تجارت الکترونیک و کسب و کارحرفه ای
آسیب پذیری های OWASP (شامل بررسی 10 آسیب پذیری متداول)
اسکن نرم افزار/وب سایت توسط Acunetix نسخه 11
اسکن تمامی پورت ها با ابزار Nmap
اسکن وب سرور و پیکربندی آن توسط ابزار Nikto
اسکن تزریق توسط نرم افزار قدرتمند SQLmap