ویرگول
ورودثبت نام
عماد عابدینی
عماد عابدینی
خواندن ۲ دقیقه·۲ سال پیش

آسیب‌پذیری Class-Validator نسبت به XSS و SQLi

اگه برای sanitize و بررسی valid بودن ورودی‌ها از class-validator استفاده می‌کنید، دقت کنید که نسبت به XSS و SQL_Injection آسیب‌پذیره.

امروز که برای یک پروژه NestJSی می‌خواستم ازش استفاده کنم تو مستنداتش تابعی مرتبط با جلوگیری از این دو آسیب‌پذیری پیدا نکردم، اول فکر کردم شاید Built-in داره این کارو میکنه... (ولی اینطور نبود)

یه پارامتر به اسم forbidUnknownValues داره که اگه trueش کنی تا حدودی جلوی این دو آسیب‌پذیری رو می‌گیره (فقط تا حدودی)

در مورش سرچ کردم، SNYK-ID هم گرفته حدودا 6 ماه پیش، ولی با این حال این مشکل هنوز برطرف نشده...! (در حال حاضر ورژنش v0.13.2)، فقط ظاهرا 6 ماه پیش به forbidUnknownValues تو مستندات اشاره‌ای نشده بوده ولی الان تو مستندات اوردنش با این توضیح که بهتره true بشه.

https://security.snyk.io/vuln/SNYK-JS-CLASSVALIDATOR-1730566

چند لینک مرتبط با این موضوع:

https://github.com/typestack/class-validator/issues/1422

https://nvd.nist.gov/vuln/detail/CVE-2019-18413

https://vuldb.com/?id.144159

----

  • خلاصه که اگه می‌خواستین از class-validator استفاده کنید، تا زمانی که این مشکل رو برطرف نکرده پیشنهاد می‌کنم ورودی‌ها رو بعد از دریافت حتما escape کنید.
  • درسته که اگه از یه ORM خوب استفاده کنیم و Front رو هم مثلا با Vue,React و Angular بزنیم، تا حد خیلی زیادی جلوی این دو آسیب‌پذیری گرفته میشه، ولی اینکه بخوایم فقط خروجی رو encode کنیم و کنترلی روی ورودی‌ها نداشته باشیم منطقی نیست.
  • در خصوص ORM هم همونطور که میدونید XSS از نوع Reflected و Dom-Based ارتباطی با دیتابیس نداره.
  • بعد از true کردن پارامتر forbidUnknownValues هم فقط تا حدودی امن تر میشه (نه کامل)
  • میشه از توابعی که در حال حاضر داره هم برای جلوگیری از این دو آسیب‌پذیری استفاده کرد ولی اون توابع کاربرد اصلیشون این نیست.
  • برای جلوگیری از این دو آسیب پذیری به خصوص XSS، فقط escape کردن ورودی کافی نیست (فرض می‌کنیم bypass شد، پس بهتره در کنار escape کردن، چیزای دیگه رو هم در نظر بگیریم)


این پست رو لینکدین هم گذاشته بودم، اونجا یه سوال پرسیدن که چون سوال خوبی بود گفتم اینجا هم بذارمش:

متن سوال:

خود nest جلو xss رو نمیگیره؟ یا اگه اون پکیج Helmet رو با nest تلفیق کنیم کارساز نیست؟

از اونجایی که XSS یه آسیب‌پذیری Client-sideه، پس Nest نمیتونه تاثیر خاصی برای جلوگیری از این آسیب‌پذیری داشته باشه.
در خصوص helmet، فقط میاد یکسری header اضافه میکنه و خودشم توضیح داده که:
It's not a silver bullet, but it can help

اینم باید در نظر بگیریم که خیلی وقتا آسیب‌پذیری‌ها به صورت chain شده‌ان و ممکنه خودشون به تنهایی تو پروژه ما هیچ خطری نداشته باشن، ولی موقعی که با هم ترکیب میشن باعث آسیب‌پذیری میشن، مثلا خیلی ها دیدم میگن پروژمون TokenBaseه و توکن هم گذاشتیم تو LocalStorage یا مثلا میگن کوکی هارو HttpOnly گذاشتیم پس قطعا مشکلی از نظر XSS نیست!! در صورتی که XSS مثل اینه که دسترسی به کنسول Browser داریم، با کنسول چه کارایی میشه انجام داد؟ با XSS هم میشه... (برای طولانی نشدن پست توضیح در خصوص CSP رو اینجا نیاوردم)

در خصوص XSS خلاصه کار اینه که روی ورودی ‎ها و خروجی‌ها کنترل داشته باشیم، حالا چون این وسط احتمال bypass وجود داره پس بهتره در کنارش چیزای دیگه هم رعایت کنیم.


شاد و موفق باشین...



class validatorsql injectionxssnestjsبرنامه نویسی
توسعه دهنده وب و اپلیکیشن‌های اندرویدی | http://emad-abedini.ir
شاید از این پست‌ها خوشتان بیاید