امنیت وب با OWASP

همه‌ی ماهایی که در دنیای کامپیوترها (مخصوصا بر پایه وب) مشغول به فعالیت هستیم می‌دونیم که امنیت یکی از ارکان اصلی کارمون هست . اما همه ی ما نمیدونیم که چه رکن (فاکتور/ابزار)هایی می‎تونه برای برقراری امنیت به ما کمک کنه .

اینجاست که پای Open Worldwide Application Security Project (اُ-اَسپ / OWASP) میاد وسط !

توی تعریفی که OWASP توی سایت خودش راجع به خودش ارائه میده ، میگه که :

ما یک جامعه باز و متعهد به امکان سنجی، توسعه، تهیه، عملیات و نگهدای برنامه‌هایی که قابل اعتماد باشند هستیم . تمامی پروژه‌ها، ابزارها، اسناد، انجمن‌ها و بخش‌های ما رایگان و باز برای همه‌ی علاقه‌مندان به بهبود امنیت برنامه‌ها می‌باشد. بنیاد OWASP در تاریخ ۱ دسامبر ۲۰۰۱ راه‌اندازی شد و در تاریخ ۲۱ آوریل ۲۰۰۴ به شکل یک خیریه غیرانتفاعی در ایالات متحده آمریکا ثبت شد.

اونا توی سایتشون از چشم اندازشون :

نرم افزار ناامن بیشتری نداشته باشیم (no more insecure software)

و حتی ماموریتشون :

به عنوان یک جامعه باز جهانی، ما نیرویی هستیم که از طریق آموزش، ابزارها و همکاری، نرم‌افزارهای امن را تامین می‌کنیم.

هم گفتن .

توی OWASP ابزارها و اصول(/سیاست) های مختلفی وجود داره که امنیت رو از جنبه های مختلف مورد بررسی قرار میده و نکات توسعه امن رو به ما ارائه میده . بخوام مثال بزنم ، مثلا ابزاری به نام OWASP AMASS رو دارن که ابزار نقشه برداری از شبکه هست و کمک به شناخت آسیب پذیری ها می کنه یا ابزاری به اسم OWASP ZAP وجود داره (که در دسته ی penetration testing toolkits قرار میگیره) و با کمک اون می تونیم امنیت وبسایت خودمون رو محک بزنیم .

من قصد دارم در ادامه یک نگاهی به اولین مورد از بخشی به نام OWASP top 10 بندازم و آنچه رو که یاد میگیرم با شما به اشتراک بزارم . پس اگر توهم دوست داری یک نگاهی بندازی ببینی اولین اصل OWASP top 10 چیه ، همراه من باش .

A01: Broken Access Control (کنترل دسترسی شکسته)

برای اینکه ببینیم کنترل دسترسی شکسته چیه ، اول باید ببینیم مفهوم کنترل دسترسی چیه ؟

کنترل دسترسی (access control) سیاستی رو پیاده سازی می کنه که کاربران نباید خارج از مجوز های اون سیاست بتونن عملیاتی رو انجام بدن .

اگر این کنترل دسترسی شکسته بشه (broken access control) می تونه منجر به افشای اطلاعات حساس ، دستکاری و یا از بین رفتن تمام دیتاهای تجاری بشه .

کنترل دسترسی انواع مختلفی داره (مثل discretionary access control ، mandatory access control و ...) که هرکدومش هم دنیای خودش رو داره که اگر بخوایم بهشون بپردازیم خارج از حوصله شما و توان تایپی من هست ? پس فعلا به آنچه در توصیف نوشته های سایت OWASP هست می پردازیم.

آسیب پذیری هایی که در مورد کنترل دسترسی رایج هستند شامل موارد زیر میشن :

• Principle of least privilege :

داستان از این قراره که اگه ما یک آبدارچی رو استخدام می کنیم ، فقط کافیه که بهش کلید آبدارخونه رو بدیم و این کار غیرمنطقی ای هست که بهش کلید گاوصندوق رو هم بدیم که نکنه بعدا لازمش بشه ! توی دنیای امنیت هم داستان از همین قراره ، سطح دسترسی ای که به هر کاربر می دیم باید حداقل سطح دسترسی ای باشه که با اون سطح می تونه وظایفش رو انجام بده . مثلا اگر وظیفه ی شخص اینه که داده ای رو بزاره ، کار غیر منطقی ای هست بهش اجازه ویرایش داده های افراد دیگه رو هم بدیم. دسترسی ها باید به نقش ها و قابلیت ها (capabilities) به صورت حداقلی داده بشن .

• Bypassing access control :

این مورد حالتی رو شرح میده که مهاجم می تونه یک جوری اون چک کردن access control ما رو دور بزنه . مثلا همون طور که گفتیم ما میایم یک role (نقش) در نظر می گیریم تحت عنوان admin که بالاترین سطح دسترسی هارو هم داره ، حالا اگر ما اون نقش (role) کاربر رو از طریق url بگیریم و با توجه به اون بهش دسترسی بدیم ، مهاجم به راحتی با دستکاری url می تونه اون access control ما رو دور بزنه .

• Insecure direct object references :

تعریفش می شه اینکه یک مهاجم می تونه با ارائه یک شناسه منحصر به فرد یک شی دیگه به اون دسترسی داشته باشه . بخوایم براش مثال بزنیم ، فرض کنین شما یک api ای رو توسعه دادین که یک آیدی بهش پاس می دین و اون api داده های مربوط به کاربر با اون ID رو برای شما بر می گردونه . حالا اگر من بتونم به ID یک کاربر دیگه دسترسی پیدا کنم چی ؟ باید داده های اون کاربر رو هم بهم برگردونه؟ قطعا نه! پس این اصل داره به این اشاره می کنه که آقا نباید اجازه بدیم به یک آبجکت ما بدون کنترل دسترسی ، دسترسی مستقیم پیدا کنند.

• Missing access controls for POST, PUT and DELETE :

هممون میدونیم که http verb های مختلف وظایف مختلفی رو دارن ، و هممون میدونیم که از POST برای درج داده (create) ، از PUT برای به روز رسانی داده (update) و از DELETE برای حذف داده استفاده می کنیم . پس اینجا access control حائز اهمیت می شه که یک سیاست بچنیم چه کسانی (user/roles/capabilities) باید توانایی اجرای این verb ها رو داشته باشند .

• Elevation of privilege :

این آسیب پذیری حالتی رو شرح میده که به عنوان مثال ما بدون ورود به سایت (login) بتونیم قابلیت هایی که یک کاربر لاگین شده در سایت داره رو داشته باشیم و یا با لاگین شدن به سایت به عنوان کاربر ساده توانایی های یک ادمین سایت رو داشته باشیم، در واقع به صورت غیرمجاز سطح دسترسی خودمون رو بالا ببریم .

• Metadata manipulation :

دستکاری meta data یکی از آسیب پذیری های رایج دنیای وب هستش و وقتی اتفاق میوفته که یک مهاجم به دستکاری داده های مهم مثل cookie ها ، headerها و query string ها ، یا محتوای توکن (JWT) به هدف دسترسی غیرمجاز (unauthorized access) می پردازه .

اگر بخوایم برای meta data manipulation مثالی بزنیم ، به نوعی می تونیم به حمله ی replay اشاره کنیم . این حمله بدین صورت هستش که یک مهاجم session مربوط به یک کاربر احراز هویت شده (/یا توکنش) رو کپی می کنه و با استفاده از اون عملیات غیرمجازی رو انجام میده .

• CORS misconfiguration :

اگر شماهم در حوزه ی کلاینت فعالیت داشتین ، پس احتمالا جفتمون یک درد مشترک که خطاهای مربوط به CORS باشن رو تجربه کردیم و دادمون در اومده ?. ولی خب این سیاست ها (CORS policy) اگر درست پیکربندی بشه می تونه توی امنیت داشتنمون به ما کمک کنه . در واقع cross-origin resource sharing policies یک مجموعه سیاست هستند که تعریف میشن تا به وب سرور ها این اجازه رو بدن که دسترسی کدوم ـJS ها (/درخواست ها) در کدوم صفحات وبسایت به منابع مجاز/یاغیرمجاز هست. وقتی این CORS policy ها به درستی پیکربندی نشن ، این اجازه رو میدن که origin ها (web page) های غیر مجاز به یک api دسترسی پیدا کنند.

• Force browsing to authenticated pages :

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

و اما راه های مقابله چی هستن؟

نکته ای که باید به اون توجه بشه اینه که کنترل دسترسی ها باید در جایی اتفاق بیوفته که مهاجم توانایی تغییر(modify) بررسی هارو رو نداشته باشه ، در مورد راه های امن سازی کنترل دسترسی موارد دیگه ای هم به چشمم خورده اما در حال حاظر در مورد مواردی که در سایت OWASP برای مقابله با آسیب پذیری broken access control ارائه داده صحبت می کنیم .

• به جز منابع (resource) هایی که به صورت عمومی هستند ، دسترسی به تمام منابع رو غیرمجاز کنین . بخوایم مثال بزنیم اگر من دارم api می نویسم ، میدونم api هایی که داره صفحه اولم رو میسازه باید public باشه ، که با توجه به ماهیت سایتم اگر کسی صفحه اول سایت رو باز کرد بتونه محتوای مورد نظر من رو ببینه ، اما دلیلی نداره api هایی که داده های یک کاربر خاص رو با استفاده از ID داره برمیگردونه public باشه .

• یک بار سیاست های مربوط به کنترل دسترسی رو پیاده سازی کنین و در تمام برنامه از اون ها استفاده کنین. خب در توضیح این مورد می تونیم بگیم که کنترل دسترسی سناریوها و حالت های مختلفی داره ، بخوام یک مثال بزنم ، مثلا یک نوع از کنترل دسترسی داریم تحت عنوان RBAC یا (role based access control) ، این سیاست میگه توی طراحی سیستمت اول نقش های مورد نظرت (roles) ها رو پیدا کن ، بعد ببین هر نقش با توجه به شرح وظایفش چه دسترسی هایی نیاز داره ، دسترسی ها رو به نقش ها اعطا کن و نقش هارو به کاربران منسوب کن. نکته ای که بهش اشاره میشه اینه که حتی کوچکترین سیاست هارو هم در نظر بگیرین ، مثل همون CORS policy ها که ازش صحبت کردیم .

• نکته ی بعدی ای که بهش اشاره شده در مورد طراحی مدل کنترل دسترسیمون هست . میگه آقا توی طراحی مدل کنترل دسترسی حواسمون به این باشه که هر موجودیت بتونه رکورد های تحت مالکیت (ownership) خودش رو ایجاد یا بروزرسانی کنه . و دادن قابلیت CRUD (create, read, update, delete) روی تمامی رکورد ها احتمالا یک ضعف امنیتی محسوب می شه . بخوام براش مثال بزنم ، اگر شما یک نقش حسابدار دارین ، احتمالا طبق سیاست های شرکتتون فقط همون نقش باید اجازه درج داده در جدول مربوط به فاکتور ها رو داشته باشه .

• محدودیت های بیزینسی رو در domain model در نظر بگیریم . خب همونطور که می دونین، توی طراحی یک نرم افزار ما یک بخشی به نام domain model داریم که توی این بخش ما حالات (state) و منطق (logic) های مربوط به بیزینس رو تحت عنوان رفتارها و قوانین به نرم افزار انتقال میدیم . در این بند هدف بر این بوده که محدودیت های بیزینسی رو در سطح نرم افزار هم ببینیم . مثلا اگر توی سطح بیزینس (جایی که کارفرما یک درخواستی داره) عنوان میشه که افرادی که کمتر از 2 سال سابقه بیمه دارند نمی تونن به فلان منابع دسترسی داشته باشن ، شما باید این محدودیت رو در لایه ی نرم افزارتون در نظر داشته باشین و اعمال کنین if کمتر از دوسال سابقه then نتونه منابع رو ببینه ? .

• مورد بعدی Disable web server directory listing هستش ، در واقع directory listing به یک قابلیت web server ها اشاره می کنه که این اجازه رو به ما میده که بین فایل ها و پوشه ها گشت و گذار کنیم :)) به این صورت که شما وقتی آدرس یک پوشه که در مسیر root directory هست رو میزنین ، مثل تصویر زیر میتونین به فایل ها دسترسی پیدا کنین

علاوه بر اون میگه به طور کلی فایل های مهم و فایل هایی که شامل متادیتا میشن ، مثل فایل های مربوط به git یا فایل هایی مثل package.json درجاوااسکریپت که نشون میده از چه package هایی استفاده کردیم ، مثل composer.json که مشابه package.json هست اما برای php، مثل فایل های مربوط به لاگ ها ، مثل بک آپ هایی که گرفتیم و ... نباید در webserver root directory قرار بگیرن و از طریق web server در دسترس باشند.

• لاگ گرفتن از تمام درخواست های کنترل دسترسی ناموفق ! هدف از این بند این هست که بتونیم الگوهای تشخص نفوذ رو بدست بیاریم ، مثلا اگر در یک بازه زمانی برای لاگین کردن کلی درخواست داشتیم که همش ناموفق بوده می تونیم یک حمله ی brute force روی یک اکانت رو تشخیص بدیم .

(این مورد رو گوشه ذهنتون داشته باشین که سیستم هایی مثل IPS هم برای تشخیص الگوهای نفوذ وجود دارند اما چون مورد این بحث OWASP نیست ماهم اینجا بهش نمی پردازیم)

• استفاده از api rate limiter :

به طور کلی api rate limiter یک سیاست محدودیت گذاری روی api هستش ، کارکرد اون هم به این صورت هست که بر اساس سیاست های کاری سامانه مون یک سیاست تعریف می کنیم ، مثلا میگیم هر کاربر بر اساس IP مجازه در دقیقه حداکثر 10 درخواست به فلان API ارسال کنه. اگر بتونیم یک سیاست درست برای rate limiting در نظر بگیریم ، میتونه توی امنیت و کنترل دسترسی به ما کمک کنه ، بخصوص در برابر ابزار های automated attack که ابزار هایی هستند که حالت های مختلفی رو در نظر میگیرن و با درخواست های زیاد سعی دارن حالات زیادی رو ایجاد کنند که از یک آسیب پذیری استفاده کنن ، حالا اگر ما یک سیاست برای rate limiting داشته باشیم که تعداد درخواست های هر api رو محدود کنه ، درصد امکان آسیب پذیری از این طریق رو کاهش دادیم.

• مورد بعدی در مورد identifier های احراز هویت هستش ، در یک نوع طبقه بندی میتونیم بگیم به طور کلی ما دو نوع احراز هویت داریم :

1 - Stateful

2 - Stateless

در مورد stateful athentication یک شناسه سمت سرور نگهداری میشه (session) که وقتی ما یکبار ارتباطمون با سرور برقرار میشه ، متناظر اون ارتباط یک session ایجاد میشه که مارو در درخواست های بعدی احراز هویت می کنه ، توی این بند در مورد stateful session ها میگه که آقا وقتی کاربر ما دکمه خروج رو زد حواسمون به اون session سمت سرور هم باشه که باید نامعتبر بشه .

در مورد stateless authentication هم میتونیم به توکن های JWT اشاره کنیم که صرفا یک توکن هست که بر خلاف stateful ، متناظر اون توی سرور هیچ چیزی ذخیره نمی شه ! و اعتبار سنجی اون بر اساس مکانسیم های رمزنگاری و امضای دیجیتال هستش . توی این بند برای stateless token ها توصیه می کنه که short lived باشن ، حالا short lived یعنی چی ؟ هر توکن که تولید میشه یک TTL (time to live) داره که مشخص میکنه اون توکن برای چه مدت معتبر هستش ، قاعدتا هرچی زمان اعتبار یک توکن کمتر باشه ، امنیت هم بالاتر میره . اما خب توی این بند اشاره میکنه برای توکن هایی که نیاز داریم طول اعتبارشون بیشتر باشه از استاندارد های OAuth برای ابطال دسترسی ها استفاده کنین .

این ها مواردی بود که در سایت OWASP برای مقابله با آسیب پذیری broken access control ذکر شده بود که تشریحشون کردیم ، در نهایت این وظیفه ی QA و توسعه دهنده ها هستش که موارد مربوط به کنترل دسترسی رو تست کنن.

چند سناریو از این آسیب پذیری و نحوه ی حمله به اون :

• سناریو اول :

در نظر بگیرین که یک برنامه ، از داده های اعتبار سنجی نشده برای ایجاد یک SQL جهت دسترسی به اطلاعات یک حساب کاربری استفاده می کنه :

pstmt.setString(1, request.getParameter(&quotacct&quot));
 ResultSet results = pstmt.executeQuery( );

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

https://example.com/app/accountInfo?acct=notmyacct

و اینجوری به اطلاعات کاربری حسابی که مال خودش نیست دسترسی پیدا می کنه .

• سناریو دوم :

در نظر بگیرین یک api توسعه دادیم که اطلاعات یک application رو برای ما بر میگردونه ، بنابر این بوده که اگر ادمین درخواست بده ، اطلاعات بیشتری رو ببینه ، حالا اگر ما در مورد access controlling اطلاعاتی نداشته باشیم ممکنه بیایم api هامون رو به صورت زیر طراحی بکنیم :

https://example.com/app/getappInfo
 https://example.com/app/admin_getappInfo

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

این بود اولین قسمت از 10 قسمت مربوط به OWASP TOP TEN . مباحث مربوط به این بخش بیشتر انتزاعی بود . خیلی دوست دارم اگر فرصت بشه 10 تاشو باهم بررسی کنیم و آگاهیمون رو ببریم بالا تر

مرسی که تا اینجا همراهم بودی ❤

راستی این هم صفحه لینکدین منه ، اگر دوست داشتی منو دنبال کن .