پرش به محتویات

API8:2019 تزریق ورودی‌های مخرب

عوامل تهدید / مسیر حمله ضعف امنیتی پیامد
API خاص: قابلیت بهره‌برداری3 میزان شیوع2 : قابلیت تشخیص3 پیامد فنی3 : خاص کسب و کار
مهاجمین تلاش می‌کنند تا هرچه مسیر‌ برای تزریق (از جمله، ورودی‌های مستقیم، متغییرها و سرویس‌های یکپارچه) وجود دارد را با داده‌های مخرب پر کنند و انتظار دارند این اطلاعات بدست لایه مفسر برسد. وجود ‌آسیب‌پذیری تزریق ورودی‌های مخرب، امری متداول بوده و معمولا در پرس و جو‌های SQL، LDAP یا NoSQL، دستورات سیستم عامل، تجزیه کنندگان XML و ORM یافت می‌شود. این نقص‌ها به سادگی در زمان بازبینی کد منبع قابل کشف می‌باشند. مهاجمین نیز برای این منظور از اسکنرها و Fuzzerها استفاده می‌کنند. ‌آسیب‌پذیری تزریق ورودی‌های مخرب می‌تواند منجر به افشای اطلاعات و یا از دست رفتن اطلاعات شود. همچنین ممکن است این ضعف منجر به اختلال در سرویس‌دهی شده و یا حتی باعث از دست رفتن کامل دسترسی میزبان شود.

آیا API از نظر نقص تزریق ورودی‌های مخرب آسیب‌پذیر است؟

از منظر نقصِ تزریق ورودی‌های مخرب API ‌آسیب‌پذیر است اگر:

  • اطلاعات وارد شده توسط کاربر توسط API اعتبار سنجی، فیلتر یا پاکسازی نشود.
  • اطلاعات وارد شده توسط کاربر به صورت مستقیم استفاده شده و یا به انواع دستورات پرس و جو (SQL یا NoSQL یا LDAP) یا دستورات سیستم عامل، تجزیه‌کنندگان XML، ORM یا ORM افزوده شود.
  • اطلاعات دریافت شده از سیستم‌های خارجی توسط API اعتبار سنجی، فیلتر یا پاکسازی نشود.

مثال‌هایی از سناریوهای حمله

سناریو #1

میان‌افزار یک دستگاه کنترل (فرزندان) توسط والدین تابعی را در مسیر /api/CONFIG/restore ارائه می‌کند، که انتظار دارد مقدار appId ارسال شده به سمت آن، دارای مقادیر چند متغیره باشد. با استفاده از یک دیکامپایلر، مهاجم در می‌یابد مقدار appId بدون هیچ‌گونه تغییر یا پاکسازی‌ به یک فراخوانی سیستمی ارسال می‌شود.

snprintf(cmd, 128, "%srestore_backup.sh /tmp/postfile.bin %s %d",
         "/mnt/shares/usr/bin/scripts/", appid, 66);
system(cmd);

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

$ curl -k "https://${deviceIP}:4567/api/CONFIG/restore" -F 'appid=$(/etc/pod/power_down.sh)'

سناریو #2

سامانه تحت وب ساده‌ای با عملکرد‌های اولیه CRUD ، برای انجام عملیات‌های رزرو وجود دارد. مهاجم موفق به شناسایی تزریق NoSQL از طریق متغیر bookingId در رشته پرس و جو و در درخواست حذف رزرو شده است. درخواست مذکور شبیه به DELETE /api/bookings?bookingId=678 می‌باشد.

سرور API از تابع زیر برای رسیدگی کردن به درخواست‌های حذف استفاده می‌کند:

router.delete('/bookings', async function (req, res, next) {
  try {
      const deletedBooking = await Bookings.findOneAndRemove({'_id' : req.query.bookingId});
      res.status(200);
  } catch (err) {
     res.status(400).json({error: 'Unexpected error occured while processing a request'});
  }
});

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

DELETE /api/bookings?bookingId[$ne]=678

چگونه از آسیب‌پذیری تزریق ورودی‌های مخرب پیشگیری کنیم؟

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

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

مراجع

OWASP

خارجی