Insecure Direct Object References

InSecure Direct Object References

برای درک بهتر از این نقطه ضعف امنیتی بهتر است ابتدا تعریف  Direct Object Reference را بدانیم:

Direct Object Reference

در برنامه های وب اکثرا از یک Identifier یا کلید بعنوان پارامتراستفاده میگردد تا بتوان به یک رکورد در دیتابیس یا یک فایل یا دایرکتوری ارجاع داشت. این پارامتر میتواند Id مربوط به حساب یک مشتری بانک و یا نام یک محصول و ... باشد.

برای  مثال Http://www.mybank.ir/Account?id=236 که پارامتر  id یک ارجاع به Account های مشتریان بانک میباشد. با ارسال درخواست فوق از طرف کلاینت برنامه اطلاعات حساب مشتری شماره 236 را برای کلاینت ارسال میکند. حتی در بعضی موارد این ارجاعات بصورت Incremental پیاده  سازی شده است و بنابراین با افزایش مقدار id  (برای مثال id=237 )  و ارسال آن به سرور، اطلاعات فرد دیگری قابل مشاهده خواهد شد.

این نقطه ضعف امنیتی بعنوان چهارمین تهدید امنیتی در برنامه های وب میباشد که در OWASP بدان اشاره شده است.

 

InSecure Direct Reference Object

اگر چنین ارجاعاتی در برنامه بشکلی باشند که با دستکاری پارامترها بتوان به یک Object دیگر (مثلا یک رکورد دیگر از دیتابیس) دسترسی پیدا کنیم در حالیکه  مجاز به دسترسی به آن رکورد نباشیم آنگاه  InSecure Direct Object Reference اتفاق افتاده است.

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

  

راههای کاهش ریسک:

 

  1. مشکل واقعی در Insecure Direct Object Reference مربوط به عدم وجود Access Control میشود. به زبان دیگر قبل از اینکه اطلاعات مربوطه از بانک اطلاعاتی بازیابی شوند Authorization بدرستی انجام نگرفته است و حدود دسترسی کاربر کنترل نشده است. بنابراین بکارگیری کنترل دسترسی صحیح منجر به کاهش ریسک خواهد شد.

  2. استفاده از Indirect Object Reference که در واقع یک Mapping بین Id  مرتبط با Object داخل برنامه با Id  که در دنیای بیرون به کاربران نمایش داده میشود میباشد که فقط در محدوده Session کاربر Authorized شده قابل استفاده میباشد. برای  مثال Id هر مشتری بانک  توسط  یک الگوریتم به مقدار رندومی تغییر یافته و این Mapping در سمت سرور ذخیره شده برای کلاینت ارسال میشود. سپس با هر درخواست از طرف کلاینت که طبیعتا شامل Id  میباشد که مپ شده ، سرور عمل عکس آن را انجام میدهد و به Id واقعی تبدیل کرده بازیابی اطلاعات از دیتابیس را انجام میدهد. یک نمونه از این Mapping میتواند بشکل زیر باشد:

 که این متد توسط متد زیر فراخوانی میشود:

بخاطر اینکه این مقادیر توسط الگوریتمهای رمزنگاری بصورت رندوم ایجاد شده اند احتمال حدس زدن و یا تکراری بودن آنها کم میباشد و اگر هم اینکار را بطریقی هکر بتواند انجام دهد با انجام Access Control  صحیح  در داخل برنامه از دسترسی به اطلاعات بدون مجوز جلوگیری خواهد شد. به مثال زیر توجه کنید:

Http://www.mybank.ir/Account?id=fZugRxwpbOd3uS47QJ4DEpSt4vN20L32

 

 که Id بشکل رندوم تغییر یافته و تغییر یا حدس زدن روش تولید آن و دسترسی به Id فرد دیگر کار مشکلی میباشد. به یاد داشته باشید که این تبدیل از نظر Performance یک Overhead را به برنامه تحمیل میکند.

 

استفاده از GUID بجای فیلدهایInteger  بعنوان کلید جداول ایده ای است که بعضی از برنامه نویسان ازآن استفاده میکنند  زیرا مقادیر آنها منحصر بفرد میباشد اما آنها مشکلاتی دارند:

  • هر چند آنها منحصر بفرد هستند اما رندوم بون آنها زیر سوال میباشد. Eric Lippert  از اعضای تیم کامپایلر #C در مایکروسافت معتقد است که Guid ها رندوم نیستند و برای مواردی که نیاز به رندوم بودن میباشد بایستی از ابزار مناسب آن استفاده نمود.

    در همین راستا میبینیم که در ASP.NET نیز در زمان ایجاد SessionID که لازمست یک مقدار رندومی باشد  که قابل حدس زدن توسط هکرها نباشد،  مایکروسافت از کلاس RNGCryptoServiceProvider برای تولید یک آرایه 15 بایتی رندوم استفاده کرده است وسپس آنرا بصورت یک رشته  24 کاراکتری Encode نموده است. (جزییات بیشتر در کلاس SessionIDManager توسط Reflector قابل مشاهده است.)

    در یک روش دیگر که در سایت  DotNetNoob آمده است،  توضیح داده شده است که چگونه میتوان توسط کلاس RNGCryptoServiceProvider  یک  Secure Guid ایجاد کرد.

    بنابراین در مواردی که رندوم بودن مقادیر متغیرها و پارامترها دربرنامه  یک نیاز اساسی میباشد (بطوریکه مقادیر بعدی یا قبلی آنها توسط هیچ ابزاری قابل حدس زدن و تولید شدن نباشند) استفاده از GUID  از نظر Security دارای ایراد جدی میباشد.

  • استفاده از آنها بعنوان کلید در جداول نسبت به فیلدهای Integer از Performance ضعیفتری در ذخیره و بازیابی رکوردها برخوردار بوده وهمچنین آنها فضای بیشتری در جداول میگیرند.

/ 1 نظر / 18 بازدید
نمايشگاه هاست www.hostexhibition.com

با سلام به شما دوست عزيز : از سايت من ديدن کنيد براي شما يک پيشنهاد خوب دارم تبديل و بلاگ شما به سايت دائمي هاستينگ رايگان هديه ما به شما با من در تماس باشين يا هو اي دي host_iran هاست,هاست رايگان,هاستينگ,فروش هاست,خريد هاست,سرور مجازي,وي پي اس با تشکر[گل] [گل]