بهره برداری از کنترل دسترسی یک مهارت اصلی مهاجمان است. ابزارهای SAST و DAST می توانند فقدان کنترل دسترسی را تشخیص دهند اما اگر کنترل دسترسی وجود داشته باشد، عملکرد آن را نمی توانند تأیید کنند. کنترل دسترسی با استفاده از ابزار دستی و یا احتمالا از طریق خودکار سازی برای فقدان کنترل دسترسی ها در چارچوب های خاص قابل شناسایی است.
ضعف های کنترل دسترسی عموما به دلیل نقص در تشخیص خودکار و نقص در تست عملکردی مؤثر توسط توسعه دهندگان نرم افزار وجود دارند. تشخیص کنترل دسترسی به طور معمول نمی تواند با توسل به آزمایش ایستا یا پویای خودکار انجام شود. تست دستی بهترین راه برای شناسایی کنترل دسترسی ناکارا یا نبود کنترل دسترسی است، از جمله روش )HTTP POST , GET ،(کنترل کننده ها، references object direct و غیره
تأثیر فنی این است که مهاجمان به عنوان کاربران یا ادمین ها عمل می کنند، یا استفاده کاربران از توابع با دسترسی خاص ، و یا ایجاد، دسترسی، به روز رسانی و یا حذف هر رکورد. تاثیر کسب و کار بستگی به الزامات حفاظتی برنامه و داده ها دارد.
کنترل دسترسی سیاست را به گونه ای اعمال می کند که کاربران نمی توانند خارج از مجوز های مرتبط با خود عمل کنند. شکست ها معمولا به افشای اطلاعات غیر مجاز، اصاح یا خراب کردن تمام داده ها یا انجام یک کار تجاری در خارج از محدوده کاربر منجر می شود.
آسیب پذیری های رایج کنترل دسترسی عبارتند از:
* دور زدن بررسی های کنترل دسترسی از طریق تغییر URL ، وضعیت برنامه کاربردی ، یا صفحه HTML ، یا با استفاده از یک ابزار سفارشی حمله API.
* اجازه دادن به کلید اصلی برای تعویض شدن با رکورد کاربران دیگر ، اجازه مشاهده یا ویرایش حساب کاربری دیگر.
* باال بردن امتیاز. کار کردن به عنوان یک کاربر بدون ورود به سیستم و یا کار کردن به عنوان یک مدیر زمانی که به عنوان یک کاربر وارد سیستم شده است.
* دستکاری متا دیتا، مانند بازنویسی یا مداخله با یک )JWT (Token Web JSON ، توکن کنترل دسترسی یا یک کوکی یا فیلد پنهان دستکاری شده برای افزایش امتیاز یا سوء استفاده از باطل سازیJWT
* اشتباه تنظیم CORS اجازه دسترسی غیر مجاز API را می دهد.
* اجبار به مرور صفحات مجاز به عنوان یک کاربر نامعتبر یا صفحات مجاز به عنوان یک کاربر معمولی. دسترسی به API با کنترل دسترسی های منقضی شده برای PUT ، POST و DELETE.
کنترل دسترسی تنها در صورتی که در کد سمت سرور مورد اعتماد یا API بدون سرور اعمال شود، مؤثر است، جایی که مهاجم نمی تواند بررسی کنترل دسترسی یا متا دیتا را تغییر دهد.
* به استثنای منابع عمومی، انکار به طور پیشفرض . )default by Deny)
* یک بار اعمال مکانیسم های کنترل دسترسی و استفاده مجدد از آنها در طول برنامه، از جمله به حداقل رساندن استفاده از CORS.
* کنترل دسترسی باید مالکیت رکوردها را به جای پذیرفتن اینکه کاربر می تواند هر رکوردی را ایجاد، خواندن، به روز رسانی و یا حذف کند، اعمال کند.
* الزامات محدودیت کسب و کار یکتا باید توسط مدل های دامنه اعمال شود.
* غیر فعال کردن فهرست دایرکتوری وب سرور و اطمینان از اینکه متا دیتای فایل )به عنوان مثال git )و فایل های پشتیبان در ریشه های وب موجود نیست.
* شکست های کنترل دسترسی را ثبت کنید، در صورت لزوم به مدیران هشدار دهد )برای مثال، شکست های مکرر(.
* بعد از خروج ، Token JWT ها باید روی سرور نا معتبر شود. توسعه دهندگان و کارکنان QA باید کنترل دسترسی عملکردی و تست های یکپارچه سازی را در نظر بگیرند.
سناریو شماره 1 :برنامه از داده های تأیید نشده در یک تماس SQL که دسترسی به اطلاعات حساب را دارد استفاده می کند:
;))"request.getParameter("acct ,1(pstmt.setString
;) (ResultSet results = pstmt.executeQuery
مهاجم به سادگی پارامتر 'acct 'را در مرورگر برای ارسال به هر تعداد حساب کاربری مورد نظر تغییر می دهد. اگر به درستی تأیید نشده باشد، مهاجم میتواند به هر حساب کاربر دسترسی پیدا کند.
http://example.com/app/accountInfo?acct=notmyacct
سناریو شماره 2 :مهاجم به سادگی URL های هدف را مرور می کند. حقوق مدیر برای دسترسی به صفحه مدیریت الزم است.
http://example.com/app/getappInfo
http://example.com/app/admin_getappInfo
اگر یک کاربر احراز هویت نشده بتواند به هر کدام از صفحه ها دسترسی داشته باشد، این یک نقص است. اگر غیر مدیر بتواند به صفحه مدیریت دسترسی پیدا کند، این یک نقص است
OWASP
OWASP Risk Rating Methodology
Article on Threat/Risk Modeling
External
ISO 31000: Risk Management Std
ISO 27001: ISMS
NIST Cyber Framework
جزییات بازدید : 3283
تاریخ انتشار : 23 / مرداد / 1398
آشنایی با حملات عدم کنترل سطح دسترسی مناسب برای تابع
در دسته بندی انواع حملات عدم کنترل سطح دسترسی مناسب برای تابع، ابتدا نیاز است با موضوعات مختلفی آشنا شویم. وبسایتها یا برنامههای کاربردی وب، بهصورت معمول فقط عملکردیهایی را برای کاربر نمایش میدهند که به آن نیاز دارند و یا حقوق استفاده از UI روی صفحه را به کاربر میدهند. بنابراین اگر وبسایت، حق دسترسیها یا عملکردهایی خارج از حالت معمول به کاربر اعطا کند، چه اتفاقی برای سرور و یا وبسایت خواهد افتاد؟ در کلیهی علوم امنیت، یکی از مهمترین شاخصهها، اعطای مجوزها و حق دسترسیهایی است که در کلیهی فرآیندهای اجرایی امن سازی باید موردبررسی قرار گیرند. در بحث امنیت دو موضوع Authentication و Authorization در اولویت لیست بررسیهای امن سازی قرار دارند و مهندسین امنیت باید با تفاوت آنها کاملاً آشنا باشند.
در اصل، حملات عدم کنترل سطح دسترسی به منطق شکاف امنیتی در اعطای مجوز یا Authorization ، ارجاع داده میشود. با اکسپلویت کردن این نوع از آسیبپذیریها، هکر یا کاربر غیرقانونی(میتواند کاربری دارای حساب کاربری در وبسایت باشد.) میتواند سطح دسترسیهای خود را افزایش داده و به قابلیتهای محدودشده توابع وبسایت دسترسی پیدا کند. بهعنوانمثال، سطح دسترسیهای ادمین سایت که بهصورت محدودشده برای ادمین در نظر گرفتهشدهاند، میتوانند بهعنوان هدفهایی برای هکرها محسوب شوند.
مکانیسم حمله
در این نوع حمله، مهاجمان غالباً با دستکاری URLها سعی بر استفاده از این آسیبپذیریها را دارند. برای مثال، فرض کنید که دو URL زیر برای یک وبسایت در نظر گرفتهشده است.
Example..com/account/view
Example..com/account/remove
در دو URL بالا کاربران نیاز به احراز هویت یا همان Authentication دارند؛ اما فرض کنید که نقطه پایانی /remove فقط برای کاربر Admin قابلدسترسی است. حال اگر یک کاربر احراز هویت نشده یا احراز هویت شده بدون سطح دسترسی ادمین، بتواند به نقطه پایانی /remove دسترسی پیدا کند، باعث ایجاد یک شکاف امنیتی در وبسایت خواهد شد و این آسیبپذیری بهاصطلاح عدم کنترل سطح دسترسی مناسب برای تابع شناخته میشود. اینیک مثال ساده از بیان کنترل دسترسی است و در ادامه این مقاله آموزشی با انواع این حملات آشنا خواهید شد.
روشهای جلوگیری از عدم کنترل دسترسی مناسب برای تابع
در اولین گام از روشهای پیشگیری از مسائل عدم کنترل سطح دسترسی ، تعیین خطمشی کنترل دسترسی، برای برنامه است. سیاست کنترل دسترسی، توصیفی از نیازهای امنیتی برای هر تابع و یا عملکرد است؛ که توسعهدهندگان میتوانند آن را بهصورت مداوم برای توابع مختلف انجام دهند.
در مرحله بعد، توصیه میشود که همیشه یک قاعده انکار پیشفرض(Deny-by-Default Rule) برای وبسایت استفاده شود. دسترسی به کلیهی توابع در برنامههای کاربردی وب باید بهصورت پیشفرض غیرفعال گردند و تنها به آن دسته از کاربران و قسمتهای وبسایت که به آن نیاز دارید باید دسترسی اعطا شود. در ادامه، حتی زمانی که دسترسی به تابعی در برنامه کاربردی وب داده شود باید کلیه درخواستها در زمان دسترسی تائید شوند.
برای تائید یا Verify کردن درخواستها، از لیستهای کنترل دسترسی و همچنین نقشهای احراز هویت شده استفاده کنید. باید توجه داشت که در ابتدای امر، کلیهی کنترل دسترسیها را بسته و در صورت لزوم از کنترل دسترسیهای خاص برای کاربران واجد شرایط استفاده نمایید.
در انتها، کلید حفاظت و پیشگیری از حملات عدم کنترل سطح دسترسی مناسب برای تابع، اجرای قوانین کنترل دسترسی، به کلیهی توابع و مسیرهای برنامههای کاربردی وب میباشد. زمانی که بتوانید این کنترل دسترسیها را بهصورت درستی پیادهسازی نمایید، میتوان گفت که اضافه کردن و بهروزرسانی کنترل دسترسیها، دیگر آسان خواهد بود.
انواع حملات عدم کنترل سطح دسترسی مناسب برای تابع
۱- حملات Directory Travel-Directory
همانگونه که میدانید، کلیهی وبسایتها و برنامههای کاربردی وب دینامیک، از یک وب سرور، برای اجرای کدهای نوشتهشده سمت سرور استفاده میکنند. این وب سرورها در سیستمعاملها متفاوت میباشند. در وب سرورها یک دایرکتوری بنام دایرکتوری وب وجود دارد که حاوی کلیهی فایلها و کدهای نوشتهشده برای وبسایت است. برای درک بیشتر این موضوع میتوان به تصویر زیر توجه کنید.
همانگونه که مشاهده میکنید دایرکتوریهای قبل از دایرکتوری وب(در اینجا wwwroot دایرکتوری وب است)، هیچوقت نباید در دسترس کاربران و یا کلاینتهای وبسایت قرار بگیرند. درصورتیکه کاربری بتواند به دایرکتوریهای ماقبل دایرکتوری وب دسترسی پیدا کند، یک شکاف امنیتی پیمایش مسیر یا همان Directory Travel-Directory رخداده است.
با یک سیستم آسیبپذیر به حملات پیمایش مسیر، هکر میتواند از این شکاف امنیتی برای دسترسی به بخشهای مختلف سیستم فایل استفاده نماید. در صورت موفقیت حمله پیمایش مسیر، حملهکننده قادر است به دایرکتوریهایی که نباید به آنها دسترسی داشته باشد، دسترسی پیدا میکند. بسته به نوع پیکربندی وبسایت، هکر یا مهاجم میتواند سطح دسترسیهای خود را ارتقا دهد و یا فقط قادر به مشاهده دایرکتوریها خواهد بود.
حمله پیمایش مسیر یا همان Directory Travel-Directory یکی از انواع حملات عدم کنترل سطح دسترسی مناسب برای تابع است که در سطح وبسایتها بسیار دیده میشود.
برای پیشگیری از این نوع حملات، کافی است تا طراح یا برنامهنویس وبسایت، کلیهی توابع و المانهایی که برای پیمایش مسیر در وبسایت استفاده میکند را با دقت بیشتری پیکربندی و تنظیم نماید.
۳- حملات Directory Travel-Files
اینگونه از حملات پیمایش مسیر کاملاً مشابه حملات Directory Travel-Directory هستند و تنها تفاوت این دو گونه از حمله در سطح دسترسی به فایل یا دایرکتوری است. در این حمله هکر میتواند با استفاده از پیمایش مسیر به فایلهای پیکربندی و حساس و حتی دادههای حیاتی دسترسی پیدا نماید و با استفاده از یک فراخوانی ساده اطلاعات را مشاهده کند.
۴- حملات Host header Attack
در ابتدای موضوع نیاز است که با مفهوم، هاست های اشتراکی، آشنا شویم. کلیهی وبسایتها برای ارائه خدمات خود نیاز به هاست و دامین دارند. در این میان اصلیترین موضوع، اجارهی هاست یا همان میزبان وب، است. هاست ها ازلحاظ تنوع و کیفیت دارای قیمتهای مختلفی میباشند. ممکن است هاست ها بهصورت اختصاصی و اشتراکی برای فروش از طرف هاستینگها ارائه شوند. در هاست های اختصاصی، میزبان هاست فقط یک وبسایت خاص میباشد. در هاست های اشتراکی تعداد زیادی میزبان بر روی یک هاست در حال اجرا میباشند.
یکی از مسائل مهم در ارائه خدمات هاست های اشتراکی این است که سرور هاستینگ بتواند تشخیص دهد که اطلاعات ارسالی و دریافتی برای کدامین میزبان ارائهشده است. بنابراین مفهومی بنام هدر میزبان ارائهشده است. در پروتکل HTTP با استفاده از عبارت Host ، به سرور هاست دستور داده میشود که اطلاعات، به میزبان اشارهشده، ارسال گردد.
در مثال زیر میبینید که یک درخواست GET به سمت سرور ارسالشده است. در این درخواست پارامتر Host مشخص میکند که میزبان دریافتکننده درخواست، چه میزبانی خواهد بود. در اینجا میزبان یا همان وبسایتی که باید اطلاعات را دریافت کند www..example..com است.
GET / HTTP/1.1
Host: www..example..com
حال به تشریح حملات Host header Attack(Cache poisoning) میپردازیم.
زمانی که درخواست از سمت کاربر به سمت سرور ارسال میشود؛ وب سرور، هدر هاست را خوانده و درخواست را برای میزبان موردنظر ارسال میکند. زمانی که هدر میزبان در درخواست ارسالی اشتباه بوده و یا تعریفنشده باشد، وب سرور درخواست را به اولین میزبان وب ارسال میکند. بنابراین مهاجم یا کاربر میتواند با دستکاری هدر هاست، درخواست خود را به اولین میزبان وب سرور ارسال نماید.
راه دیگر برای انتقال هدر درخواست بهصورت خودسرانه، استفاده از هدر X-Forwarded-Host است. در برخی از موارد با استفاده از این پارامتر، کاربر میتواند هدر میزبان را بازنویسی کند. به مثال زیر توجه کنید.
GET / HTTP/1.1
Host: www..example..com
X-Forwarded-Host: www..attacker..com
در درخواست بالا، کاربر یک درخواست برای سرور ارسال میکند. در ابتدای امر با پارامتر Host، میزبان www..example..com را درخواست مینماید؛ ولی با استفاده از پارامتر X-Forwarded-Host ، هدر هاست بازنویسی شده و درخواست به میزبان www..attacker..com ارسال میگردد. این نوع از بازنویسی آغازی برای یک شکاف امنیتی بهحساب میآید. برنامههای کاربردی وب به هدر میزبان(Host) پروتکل HTTP تکیه میکنند تا بتوانند درخواستها را به میزبان مقصد برسانند و این آغاز آسیبپذیری است. دلیل این امر، تکیهبر ورودی کاربر است. در اصل پروتکل HTTP نباید به درخواست کاربر اعتماد کند؛ زیرا ممکن است کاربر درخواست غیرمتعارفی را ارسال نماید و همانگونه که قبلاً بیانشده است، کلیهی ورودیهای کاربر باید کنترل شود.
دو بردار اصلی حمله برای Host Header وجود دارد.
حملات Host header Attack(Cache Poisoning)
حملات Host header Attack(Reset Poisoning)
برای آشنایی بیشتر با این دو نوع حمله میتوانید به مقاله انواع حملات افشای اطلاعات حساس و حیاتی در برنامههای کاربردی وب مراجعه نموده و در بخش مربوطه با این دو نوع حمله آشنایی بیشتری پیدا نماید.
۴- حملات Remote and Local File Inclusion(RFI/LFI)
دو آسیبپذیری شناختهشده در سطح وب با نامهای RFI و LFI وجود دارد. در این نوع حمله با توجه به عدم کنترل سطح دسترسی مناسب، نوع و شدت حمله برای اهداف متفاوت است. آسیبپذیری File Inclusion یا همان گنجاندن فایل، به هکر اجازه میدهد تا یک فایل را چه از راه Remote و یا Local به وبسایت تزریق نموده و بنا به سطح آسیبپذیری، به اطلاعات موردنظر خود دست یابد.
در این نوع حملات، چندین تابع وجود دارند که طراحان برای اضافه کردن کد PHP به صفحات از آنها استفاده میکنند.(مانند: include,include_once,require,require_once) این توابع به برنامه نویسان کمک میکند تا بتوانند کدهای خود را از مسیرهای مختلف به صفحات کد نویسی شده اضافه نمایند.
حال اگر هکر بتواند در دو حالت، فایلهای خود را در صفحات کد نویسی شده بگنجاند چه اتفاقی خواهد افتاد؟
در حملات RFI، اگر هکر بتواند یک اسکریپت یا کد PHP مخرب را از راه دور به وبسایت بگنجاند، این کار باعث میشود تا سرور سایت هدف، آن کدها را اجرا کرده و هکر به اهداف دلخواه خود دست بیابد.
در حملات LFI، اگر هکر بتواند فایلهای PHP یا حساسی که بر روی سرور سایت هدف قرار دارد را فراخوانی نموده و مشاهده نماید، گونهای از حملات LFI صورت پذیرفته است.
در حملات RFI شدت آسیبی که به تارگت وارد میشود بسیار بیشتر از حملات LFI خواهد بود.
بنابراین برنامه نویسان و طراحان برای جلوگیری از این حملات، باید ورودیهایی که برای کاربر تعریفشده است را بهصورت صحیح پیکربندی نموده و همچنین از توابع خطرناکی که عمل فراخوانی را انجام میدهند، جلوگیری به عملآورند؛ و یا در صورت نیاز، پارامترها را برای فراخوانی، بررسی و یا بهصورت صحیح پیکربندی نمایند. همچنین برای جلوگیری از آسیبپذیری RFI میتوان قابلیت allow_url_include را در فایل php.ini به مقدار صفر تغییر داد.
۵- حملات Local File Inclusion(SQLite Manager)
نرمافزار SQLite ، یکی از مشهورترین ابزارهای ذخیره و بازیابی اطلاعات است که میتواند از انواع سیستمعامل مانند ویندوز و لینوکس پشتیبانی نماید. در این میان ابزارهای متعدد رایگان و تجاری برای ایجاد و مدیریت فایل های SQLite وجود دارند که یکی از این ابزارهای SQLite Manager است. نسخههای خاصی از ابزار SQLite Manager دارای باگ LFI هستند که باعث میشود تا به فایل ها از راه دور دسترسی پیدا نمود. مرورگر فایرفاکس از نسخه ۵۷ به بعد، دیگر افزونه SQLite Manager را به علت مشکلات امنیتی فراوانش، پشتیبانی نمیکند.
۶- حملات Restrict Device Access
زمانی که یک وبسایت یا برنامه کاربردی وب، طراحی و پیادهسازی میشود، برنامهنویس سعی میکند تا با استفاده از سختافزارها و دیوایس های مختلف، دسترسیهای مجاز را به کاربران بدهند. برای درک بهتر موضوع با یک مثال این نوع حملات را بررسی میکنیم.
فرض کنید که طراح سایت، کدهای وبسایت را به صورتی نوشته است که با استفاده از پارامتر User_Agent در درخواستهای HTTP ، بتواند دستگاه و یا مرورگر کاربر را شناسایی نماید. حال برنامهنویس به صورتی کد نویسی کرده است که فقط تلفنهای هوشمند با مشخصات خاص بتوانند به وبسایت دسترسی داشته باشند؛ حال اگر دستگاهی غیر از تلفن هوشمند به وبسایت بخواهد دسترسی داشته باشد چه اتفاقی خواهد افتاد؟ در جواب باید گفت که هیچ دستگاهی غیر از تلفن هوشمند با مشخصات خاص طراح، نباید به وبسایت دسترسی داشته باشد. حال اگر طراح سایت، کدها و توابعی در برنامه خود بنویسد که عدم کنترل سطح دسترسی مناسبی برای تابع داشته باشند، باعث خواهد شد که هکر یا مهاجم با استفاده از دستکاری پارامتر User_Agent به وبسایتی که نباید به آن دسترسی داشته باشد، دسترسی پیدا کند.
۷- حملات Restrict Folder Access
این نوع از حملات عدم کنترل سطح دسترسی بسیار شبیه به حمله Restrict Device Access است. برای توضیح اینگونه از حملات یک مثال را ارائه خواهیم داد. فرض کنید که در یک سایت کاربران حتماً باید در سایت Login نمایند تا بتوانند به تعدادی فایل دسترسی داشته باشند؛ و کاربرانی که در سایت Login نکردهاند حق دسترسی به آن فایل ها را ندارند؛ و برای کاربران Login نشده خطای Forbidden ارسال شود. حال فرض کنید که یک هکر یا مهاجم بتواند به فایل هایی که نیاز به Login دارند، بدون هیچگونه Loginی دسترسی پیدا نماید. این مثالی بود از منطقه دسترسی فایل ها و فولدرها که یک آسیبپذیری شناختهشده در سطح وب میباشد.
۸- حملات Server Side Request Forgery(SSRF)
رخنه جعل درخواست سمت سرور یا همان SSRF یکگونه آسیبپذیری شناختهشده در سطح وب است که به مهاجم اجازه میدهد تا درخواستهای خود را به برنامههای کاربردی وب، سرور پشتی ارسال نمایند. در این نوع حمله مهاجم با استفاده از آسیبپذیری SSRF برای هدف قرار دادن سیستمهای داخلی پشت فایروال تلاش مینماید. آسیبپذیری SSRF زمانی رخ میدهد که مهاجم کنترل کامل یا جزئی به درخواستهای ارسالشده توسط برنامه کاربردی وب را داشته باشد. حملات SSRF یک نوع از حملات عدم کنترل سطح دسترسی است.