- اجرای کنترل دسترسی
کنترل دسترسی (یا مجوز) اجازه دادن یا رد درخواست های خاص از یک کاربر، برنامه یا فرآیند است. با هر تصمیم کنترل دسترسی، یک موضوع معین درخواست دسترسی به یک شی معین می کند. کنترل دسترسی فرآیندی است که خط مشی تعریف شده را در نظر می گیرد و تعیین می کند که آیا یک موضوع خاص مجاز به دسترسی به یک شی معین است یا خیر. کنترل دسترسی همچنین شامل عمل اعطا و لغو آن امتیازات است. کنترل دسترسی اغلب در سطوح مختلف اعمال می شود، به عنوان مثال، با توجه به یک برنامه کاربردی با یک پایگاه داده، هم در سطح منطق تجاری و هم در سطح ردیف پایگاه داده اعمال می شود. علاوه بر این، برنامه‌ها می‌توانند روش‌های متعددی برای انجام عملیات ارائه دهند (به عنوان مثال، از طریق API یا وبسایت). تمام آن سطوح مختلف و مسیرهای دسترسی باید تراز باشند، یعنی از همان بررسی‌های کنترل دسترسی برای محافظت در برابر آسیب‌پذیری‌های امنیتی استفاده شود. مجوز (تأیید دسترسی به ویژگی ها یا منابع خاص) معادل احراز هویت (تأیید هویت) نیست.
در این بخش که مهمترین بخش یک برنامه است، و مانند یک مرزبان وظیفه جلوگیری از ورود غیر مجاز را برعهده دارند، تهدیداتی نیز وجود دارد که به معرفی برخی از این تهدیدات میپردازیم:
- یک مهاجم می‌تواند از یک سیاست کنترل دسترسی با پیکربندی ضعیف برای دسترسی به داده‌هایی که سازمان قصد دسترسی دادن آنها به کاربران را نداشته، استفاده کند.
- یک مهاجم می تواند چندین مؤلفه کنترل دسترسی را در یک برنامه کشف کند و از ضعیف ترین آنها سوء استفاده کند.
- یک مدیر ممکن است فراموش کند که یک حساب قدیمی را از کار بیاندازد و یک مهاجم می تواند آن حساب را پیدا کند و از آن برای دسترسی به دادهها استفاده کند.
- مهاجم می‌تواند به داده‌هایی دسترسی پیدا کند که دارای خط‌مشی است که در مرحله نهایی اجازه دسترسی کاهش یافته است. (عدم رد پیش فرض)
در بخش کنترل دسترسی، با شناخت تهدیدها، اکنون باید متوجه شویم که چگونه سیاستهای کنترل دسترسی را پیاده سازی کنیم. در ادامه حداقل مجموعه ای از الزامات طراحی کنترل دسترسی است که باید در مراحل اولیه توسعه برنامه در نظر گرفته شود.
- کنترل دسترسی را کاملاً از سمتFront طراحی کنید هنگامی که یک الگوی طراحی کنترل دسترسی خاص را انتخاب کردید، مهندسی مجدد کنترل دسترسی در برنامه خود با یک الگوی جدید اغلب دشوار و زمان بر است. کنترل دسترسی یکی از حوزه‌های اصلی طراحی امنیتی برنامه‌ها است که باید از قبل کاملاً طراحی شود، به‌ویژه هنگام رسیدگی به نیازهایی مانند کنترل دسترسی multi-tenancy و horizontal (وابسته به داده).
دو نوع اصلی طراحی کنترل دسترسی باید در نظر گرفته شود.
- کنترل دسترسی مبتنی بر نقش (RBAC)[1] مدلی برای کنترل دسترسی به منابع است که در آن اقدامات مجاز روی منابع با نقش‌ها شناسایی می‌شوند نه با هویت‌های فردی فردی.
- کنترل دسترسی مبتنی بر ویژگی (ABAC)[2] دسترسی کاربر را بر اساس ویژگی‌های دلخواه کاربر و ویژگی‌های دلخواه شی، و شرایط محیطی که ممکن است در سطح جهانی شناخته شوند و بیشتر با خط‌مشی‌های مورد نظر مرتبط هستند، اعطا یا رد می‌کند. طراحی کنترل دسترسی ممکن است ساده شروع شود اما اغلب می تواند به کنترل امنیتی پیچیده و با ویژگی های سنگین تبدیل شود. هنگام ارزیابی قابلیت کنترل دسترسی چارچوب‌های نرم‌افزاری، اطمینان حاصل کنید که عملکرد کنترل دسترسی شما امکان سفارشی‌سازی را برای نیاز خاص ویژگی کنترل دسترسی شما فراهم می‌کند.
- هر درخواست دسترسی را مجبور کنید از طریق بررسی کنترل دسترسی انجام شود که مجبور باشند از یک لایه تأیید کنترل دسترسی عبور کنند. فن‌آوری‌هایی مانند فیلترهای جاوا یا سایر مکانیسم‌های پردازش خودکار درخواست، مؤلفه‌های برنامه‌نویسی ایده‌آلی هستند که اطمینان حاصل می‌کنند که همه درخواست‌ها از طریق بررسی کنترل دسترسی انجام می‌شوند. این به عنوان نقطه اجرای سیاست در RFC 2904 نامیده می شود.
- بررسی کنترل دسترسی را یکپارچه کنید از یک روش یا روال کنترل دسترسی واحد استفاده کنید. این از سناریویی جلوگیری می کند که در آن چندین پیاده سازی کنترل دسترسی دارید، جایی که اکثر آنها صحیح هستند، اما برخی ناقص هستند. با استفاده از یک رویکرد متمرکز، می‌توانید منابع امنیتی را بر بررسی و تعمیر یک کتابخانه مرکزی یا عملکردی که بررسی کنترل دسترسی را انجام میدهد، متمرکز کنید و سپس از آن در سراسر پایگاه کد و سازمان خود استفاده مجدد کنید.
- به صورت پیش فرض رد شود اطمینان حاصل کنید که به طور پیش فرض، همه درخواست ها رد می شوند، مگر اینکه به طور خاص مجاز باشند. این همچنین شامل دسترسی به API (REST یا webhooks) با کنترل‌های دسترسی از دست رفته است. راه های زیادی وجود دارد که این قانون در کد برنامه ظاهر می شود. چند نمونه عبارتند از:
- کد برنامه ممکن است هنگام پردازش درخواست های کنترل دسترسی، خطا یا استثنا ایجاد کند. در این موارد، کنترل دسترسی همیشه باید رد شود.
- هنگامی که یک مدیر یک کاربر جدید ایجاد می کند یا یک کاربر برای یک حساب جدید ثبت نام می کند، آن حساب باید به طور پیش فرض حداقل دسترسی داشته باشد یا تا زمانی که آن دسترسی پیکربندی نشده باشد.
- هنگامی که یک ویژگی جدید به یک برنامه اضافه می شود، تا زمانی که به درستی پیکربندی نشده باشد، همه کاربران باید از استفاده از آن خودداری کنند.
- اصل کمترین امتیاز / به موقع (JIT)، دسترسی کافی (JEA) نمونه ای از اجرای این اصل، ایجاد نقش ها و حساب های ممتاز اختصاصی برای هر عملکرد سازمانی است که به فعالیت های بسیار ممتاز نیاز دارد و از استفاده از نقش/حساب "مدیریت" که به طور کامل روزانه دارای امتیاز است، خودداری کنید.
برای بهبود بیشتر امنیت، می توانید Just-in-Time (JIT) یا Just-enough-Access (JEA) را پیاده سازی کنید. اطمینان حاصل کنید که به همه کاربران، برنامه ها یا فرآیندها فقط دسترسی کافی برای دستیابی به ماموریت فعلی خود داده شده است. این دسترسی باید به موقع، زمانی که موضوع درخواست را ارائه می‌کند، فراهم شود و دسترسی برای مدت کوتاهی اعطا شود. مراقب سیستم هایی باشید که قابلیت های پیکربندی کنترل دسترسی جزئی[3] را ارائه نمی دهند.
- در کدهایتان از قوانین سخت استفاده نکنید بسیاری از فریم ورکهای برنامه به طور پیش فرض کنترل دسترسی مبتنی بر نقش را دارند. یافتن کد برنامههای کامل شده در این فریم ورکها، از طریق بررسی کردن کدها در این بحث معمول است.
}if (user.hasRole("ADMIN")) || (user.hasRole("MANAGER")) deleteAccount(); } |
مراقب این نوع برنامه نویسی مبتنی بر نقش در کد باشید. دارای محدودیت ها یا خطرات زیر است:
- برنامه نویسی مبتنی بر نقش با این ماهیت شکننده است. ایجاد بررسی نقش نادرست یا قانون گمشده[4] در کد آسان است.
- نقش‌های کدگذاری سخت[5] اجازه multi-tenancy را نمی‌دهند. اقدامات شدیدی مانند چندشاخه شدن کد یا افزودن تست برای هر کاربر لازم است تا به سیستم‌های مبتنی بر نقش اجازه دهند قوانین متفاوتی برای کاربران مختلف داشته باشند.
- پایگاه‌های کد بزرگ با بررسی‌های کنترل دسترسی زیاد می‌تواند ممیزی یا تأیید سیاست کلی کنترل دسترسی برنامه را دشوار کند.
- نقش‌های کدگذاری سخت نیز می‌توانند به‌عنوان یک درب پشتی[6] در هنگام ممیزی دیده شوند.
- مثال اجرای سیاست ABAC
لطفاً با استفاده از روش برنامه نویسی زیر، نکات اجرایی کنترل دسترسی زیر را در نظر بگیرید:
}if (user.hasPermission("DELETE_ACCOUNT")) ;()deleteAccount } |
بررسی‌های کنترل دسترسی مبتنی بر ویژگی یا ویژگی‌ها با این ماهیت، نقطه شروعی برای ساختن سیستم‌های کنترل دسترسی با طراحی خوب و غنی هستند. این نوع برنامه نویسی همچنین امکان سفارشی سازی کنترل دسترسی بیشتری را در طول زمان فراهم می کند.
اگر بخواهیم یک ابزار آزمون کنترل دسترسی برای بررسی سطح امنیت برنامه شما معرفی کنیم برنامه ZAP[7] را معرفی میکنیم. (ZAP) یک ابزار تست نفوذ رایگان و منبع باز است که تحت چتر پروژه امنیت نرم افزار (SSP) نگهداری می شود. ZAP به طور خاص برای آزمایش برنامه های کاربردی وب طراحی شده است و هم انعطاف پذیر و هم قابل توسعه است. در نوع خود، ZAP چیزی است که به عنوان "پراکسی مرد در وسط[8]" شناخته می شود. بین مرورگر آزمایش‌کننده و برنامه وب قرار می‌گیرد تا بتواند پیام‌های ارسال شده بین مرورگر و برنامه وب را رهگیری و بررسی کند، در صورت نیاز محتویات را اصلاح کند و سپس آن بسته‌ها را به مقصد ارسال کند. می توان از آن به عنوان یک برنامه کاربردی مستقل و به عنوان یک فرآیند مخفی استفاده کرد. شکل زیر عملکرد نرم افزار زپ را نشان میدهد:
اگر پروکسی شبکه دیگری از قبل در حال استفاده باشد، مانند بسیاری از محیط های شرکتی، ZAP را می توان برای اتصال به آن پراکسی پیکربندی کرد، تصویر زیر گویای این موضوع است:
ZAP قابلیت‌هایی را برای طیف وسیعی از سطوح مهارت ارائه می‌کند - از توسعه‌دهندگان، آزمایش‌کنندگان تازه‌کار تا تست‌های امنیتی، تا متخصصان تست امنیتی. ZAP نسخه هایی برای هر سیستم عامل اصلی و Docker دارد، بنابراین شما به یک سیستم عامل وابسته نیستید. قابلیت‌های اضافی به‌طور رایگان از میان انواع افزونه‌ها در بازار ZAP در دسترس است که از داخل سرویس گیرنده ZAP قابل دسترسی است. از آنجایی که ZAP منبع باز است، کد منبع را می توان برای مشاهده دقیق نحوه اجرای عملکرد بررسی کرد. هرکسی می‌تواند داوطلب شود تا روی ZAP کار کند، باگ‌ها را برطرف کند، ویژگی‌ها را اضافه کند، درخواست‌های کششی برای رفع اشکال در پروژه ایجاد کند، و افزودنی‌های نویسنده برای پشتیبانی از موقعیت‌های تخصصی را اجرا نماید.
در ادامه مبحث به تعدادی از آسیب پذیریهای کنترل دسترسی اشاره میکنیم. کنترل دسترسی سیاستی را اعمال می کند که کاربران نمی توانند خارج از مجوزهای مورد نظر خود عمل کنند. خرابی‌ها معمولاً منجر به افشای غیرمجاز اطلاعات، اصلاح یا تخریب همه دادهها یا انجام یک کار تجاری خارج از محدودیت‌های کاربر می‌شوند. اکنون به چند مثال از آسیبپذیری در این سطح میپردازیم:
- سناریوی شماره 1: برنامه از داده های تایید نشده در تماس SQL استفاده می کند که به اطلاعات حساب دسترسی دارد:
یک مهاجم به سادگی پارامتر "acct" مرورگر را تغییر می دهد تا هر شماره حسابی را که می خواهد ارسال کند. اگر به درستی تأیید نشود، مهاجم می تواند به حساب هر کاربری دسترسی داشته باشد.
https://example.com/app/accountInfo?acct=notmyacct |
- سناریوی شماره 2: یک مهاجم به سادگی مرورگرها را مجبور می کند تا URL ها را هدف قرار دهند. برای دسترسی به صفحه مدیریت، حقوق مدیر الزامی است.
https://example.com/app/getappInfo
https://example.com/app/admin_getappInfo
اگر یک کاربر احراز هویت نشده بتواند به هر یک از صفحات دسترسی پیدا کند، این یک نقص است. اگر یک غیر ادمین بتواند به صفحه مدیریت دسترسی داشته باشد، این یک نقص است.
[1] Role Based Access Control
[2] Attribute Based Access Control
[3] granular
[4] missing role
[5] Hard-Coded Roles
[6] backdoor
[7] Zed Attack Proxy
[8] man-in-the-middle proxy
دیدگاه خود را بنویسید